Contents

Send Us Your Comments............................................... xi

Preface......................................................................... xiii

Audience.............................................................................................. xiii

Related Documents........................................................................... xiii

Customer Support............................................................................. xiii

Review Patch Documentation....................................................... xiii

Improved Process for Oracle Retail Documentation Corrections xiv

Oracle Retail Documentation on the Oracle Technology Network xiv

Conventions........................................................................................ xiv

1....................................................... Preinstallation Tasks 1

Requesting Infrastructure Software................................................. 1

Installation Terminology.................................................................... 1

Check Supported Database Server Requirements....................... 2

Check Supported Application Server Requirements.................. 3

Check Supported Web Browser and Client Requirements....... 4

Supported Radio Frequency Device Requirements..................... 4

Supported Oracle Retail Products.................................................... 5

Supported Oracle Retail Integration Technologies..................... 5

UNIX User Account Privileges to Install the Software............... 5

2......................................................... RAC and Clustering 7

3................................... Database Installation Tasks – Full 9

Create Staging Directory for RWMS Installer............................... 9

Create the RWMS Database............................................................... 9

Create the Database Instance Using the Oracle Generic Template 10

Create the required RWMS Tablespaces...................................... 11

Create the Schema Owner for RWMS........................................... 12

Run the RWMS Database Schema Installation.......................... 13

4................................ Database Installation Tasks – Patch 15

Create Staging Directory for RWMS Installer............................. 15

(Optional) Analyze Changes in the Patch................................... 15

Run the RWMS Database Schema Installation.......................... 15

5..... Application Server Installation Tasks – RWMS Forms 17

Create Staging Directory for RWMS Installer............................. 17

Prepare Application Server for RWMS......................................... 18

Install RWMS Oracle Forms............................................................ 18

6.................. Application Server Installation Tasks – Patch 21

Create Staging Directory for RWMS Installer............................. 21

(Optional) Analyze Changes in the Patch................................... 21

Run the RWMS Application Installation.................................... 21

Install RWMS Oracle Forms............................................................ 21

7.......... Enhanced Navigation and Dashboards Installation 23

Steps to Create the New Domain with ADF Libraries............. 24

Start the RWMSDomain and the Node Manager...................... 33

Start the Managed Server.................................................................. 34

Run the RWMS Installer................................................................... 35

Custom Authentication Provider set up...................................... 36

Disable User Lock Out Settings...................................................... 44

Application: Logging File Settings................................................ 44

8................... Manual Installation and Configuration Tasks 47

This section covers the installation and configuration of external components and other dependencies for RWMS 14.1......................................................... 47

Prerequisites......................................................................................... 47

Path References Used in this Section............................................ 47

BI Server Component Installation Tasks...................................... 48

Installation Process Overview........................................................ 49

Install Oracle BI EE 11g..................................................................... 49

Post Install Steps................................................................................. 67

Installing the RWMS BI Publisher Templates............................ 71

Configuring the RWMS JDBC connection................................... 73

Configure RWMS Email Server in BI Publisher......................... 78

Configuring Forms to use BI Publisher........................................ 80

Check the Configuration of formsweb.cfg................................... 80

Configuring the Forms Installation Environment Files........... 82

RWMS Wallet Configurations........................................................ 89

Application (Java) Wallet................................................................. 89

Oracle Wallet........................................................................................ 90

WLS Database Credential Store...................................................... 90

Adding Radio Frequency Launch Configurations................... 90

File Placement...................................................................................... 90

Update the RF Launch Modules.................................................... 91

rwms_rf_menu.html Module.......................................................... 91

close.html Module.............................................................................. 91

Update fmrweb.res for Keymapping............................................. 94

Client Side Configurations for Java Security Updates............. 94

9................................................ Web Services Installation 97

Create a Managed Server.................................................................. 97

Create a Datasource........................................................................... 97

Deploy RWMS Service EAR File..................................................... 97

Configure Web Service Security...................................................... 99

10..................................................... Patching Procedures 101

Oracle Retail Patching Process..................................................... 101

Supported Products and Technologies...................................... 101

Patch Concepts.................................................................................. 102

Patching Utility Overview............................................................. 103

Changes with 14.1............................................................................ 103

Patching Considerations................................................................ 104

Patch Types........................................................................................ 104

Incremental Patch Structure.......................................................... 104

Version Tracking.............................................................................. 104

Apply all Patches with Installer or ORPatch........................... 105

Environment Configuration.......................................................... 105

Retained Installation Files............................................................. 105

Reloading Content........................................................................... 105

Java Hotfixes and Cumulative Patches...................................... 106

Backups............................................................................................... 106

Disk Space.......................................................................................... 106

Patching Operations........................................................................ 107

Running ORPatch............................................................................ 107

Merging Patches............................................................................... 117

Compiling Application Components......................................... 118

Deploying Application Components......................................... 120

Maintenance Considerations........................................................ 121

Database Password Changes....................................................... 121

WebLogic Password Changes...................................................... 122

Infrastructure Directory Changes................................................ 122

DBManifest Table............................................................................. 123

RETAIL_HOME relationship to Database and Application Server 123

Jar Signing Configuration Maintenance.................................... 123

Customization................................................................................... 124

Patching Considerations with Customized Files and Objects 124

Registering Customized Files....................................................... 125

Custom Compiled Java Code........................................................ 127

Extending Oracle Retail Patch Assistant with Custom Hooks 129

Troubleshooting Patching............................................................. 133

ORPatch Log Files............................................................................ 133

Restarting ORPatch......................................................................... 133

Manual DBManifest Updates....................................................... 133

Manual Restart State File Updates.............................................. 135

DISPLAY Settings When Compiling Forms............................. 135

JAVA_HOME Setting...................................................................... 135

Patching Prior to First Install........................................................ 135

Providing Metadata to Oracle Support...................................... 136

A........... Appendix: Oracle Database 12cR1 Parameter File 139

B........................... Appendix: Tablespace Creation Scripts 141

Non-Encrypted Tablespace Creation......................................... 141

Encrypted Tablespace Creation................................................... 141

Configure a Wallet:.......................................................................... 142

Encryption at Tablespace Level................................................... 143

C........... Appendix: Sample Oracle Net Files for the Server 145

listener.ora.......................................................................................... 145

tnsnames.ora...................................................................................... 146

D Appendix: RWMS Database Schema Installation Screens 147

E Appendix: RWMS Application (forms) Installation Screens 157

F Appendix: RWMS Enhanced Navigation and Dashboards Installation Screens 169

G...................................... Appendix: RWMS Analyze Tool 189

Run the RWMS Analyze Tool....................................................... 189

H........................... Appendix: Common Installation Errors 191

Database Installer Hangs on Startup......................................... 191

Warning: Could not create system preferences directory..... 191

WLS_FORMS server failed to restart.......................................... 192

Warning: Couldn't find X Input Context................................... 192

Unresponsive Drop-Downs.......................................................... 193

Could not execl robot child process: Permission denied...... 194

ConcurrentModificationException in Installer GUI.............. 194

ORA-04031 (unable to allocate memory) error during database schema installation 194

X Error of failed request: BadWindow (invalid Window parameter) 195

RIB Errors............................................................................................ 195

Error Connecting to Database URL............................................. 196

I................................................. Appendix: URL Reference 197

JDBC URL for a Database............................................................... 197

JNDI Provider URL for an Application...................................... 197

J......................... Appendix: Single Sign-On for WebLogic 199

What Do I Need for Single Sign-On?.......................................... 199

Can Oracle Access Manager Work with Other SSO Implementations? 199

Oracle Single Sign-on Terms and Definitions.......................... 200

What Single Sign-On is not........................................................... 201

How Oracle Single Sign-On Works............................................. 201

Installation Overview...................................................................... 203

User Management............................................................................ 203

K............................ Appendix: Setting Up an Oracle Wallet 205

Steps to Set up a pl/sql Wallet..................................................... 205

Additional Wallet Commands..................................................... 207

Setting up Application (Java) Wallet for RWMS .env File.... 207

Setting Up WLS Database Credential Store.............................. 209

L Appendix: Setting Up Password Stores with wallets/credential stores 215

About Database Password Stores and Oracle Wallet............ 215

Setting Up Password Stores for Database User Accounts.... 216

Setting up Wallets for Database User Accounts...................... 217

For RMS, RWMS, RPM Batch using sqlplus or sqlldr, RETL, RMS, RWMS, and ARI 217

Setting up RETL Wallets................................................................ 219

For Java Applications (SIM, ReIM, RPM, RIB, AIP, Alloc, ReSA, RETL) 220

How does the Wallet Relate to the Application?.................... 223

How does the Wallet Relate to Java Batch Program use?..... 223

Database Credential Store Administration............................... 223

Managing Credentials with WSLT/OPSS Scripts.................. 227

listCred................................................................................................ 228

updateCred......................................................................................... 229

createCred........................................................................................... 229

deleteCred........................................................................................... 229

modifyBootStrapCredential........................................................... 230

addBootStrapCredential................................................................. 231

Quick Guide for Retail Password Stores (db wallet, java wallet, DB credential stores) 233

M........................... Appendix: Manual Forms Compilation 243

N........................................... Appendix: Installation Order 245

Enterprise Installation Order........................................................ 245

Supported on	Versions Supported
Application Server OS	OS certified with Oracle Fusion Middleware 11g Release 1 (11.1.1.7). Options are: § Oracle Linux 6 for x86-64 (Actual hardware or Oracle virtual machine). § Red Hat Enterprise Linux 6 for x86-64 (Actual hardware or Oracle virtual machine). § AIX 7.1 (Actual hardware or LPARs) § Solaris 11 SPARC (Actual hardware or logical domains) § HP-UX 11.31 Integrity (Actual hardware, HPVM, or vPars)
Application Server	Oracle Fusion Middleware 11g Release 1 (11.1.1.7) Components: § Oracle WebLogic Server 11g Release 1 (10.3.6) § Oracle Forms Services 11g Release 2 (11.1.2.2) One-off Patches: § Patch 17448420: MANIFEST ATTRIBUTE ERROR IN JAVA CONSOLE WHILE RUNNING FORMS URL WITH 7U45_B11 Java: § JDK 1.7+ 64 bit For Enhanced Navigation and Dashboards Components: § Oracle WebLogic Server 11g Release 1 (10.3.6) § Oracle ADF (Application Development Framework) 11.1.1.7 With patch 18277370 § Enterprise Manager Application 11.1.1.7 Optional (if SSO is required) § Oracle WebTier 11g (11.1.1.7) Oracle Access Manager 11g Release 2(11.1.2.2) Note: A separate WebLogic 10.3.6 installation is required for Oracle Access Manager 11g Release 2(11.1.2.2) § Oracle Access Manager Agent (WebGate) 11g Release 2 (11.1.2.2) § Oracle Identity Management 11gR1 (11.1.1.7) Other components: § Oracle BI Publisher 11g (11.1.1.7)

TABLESPACE_NAME	SIZE
ENCRYPTED_RETAIL_INDEX	12G
ENCRYPTED_RETAIL_DATA	10G
RETAIL_INDEX	10G
RETAIL_DATA	8G
LOB_DATA	2G
USERS	2G

Variable	Description	Example
JAVA_HOME	Java home needed to run the GUI. Java 1.7 is required	JAVA_HOME=/usr/java/jdk1.7.0_17.64bit export JAVA_HOME
NLS_LANG	Locale setting for Oracle database client	NLS_LANG=AMERICAN_AMERICA.AL32UTF8 export NLS_LANG
DISPLAY	Address and port of X server on desktop system of user running install. Optional for dbschema installer	DISPLAY=<IP address>:0 export DISPLAY

Variable	Description	Example
JAVA_HOME	Java home needed to run the GUI. Java 1.7 is required	JAVA_HOME=/usr/java/jdk1.7.0_17.64bit export JAVA_HOME
NLS_LANG	Locale setting for Oracle database client	NLS_LANG=AMERICAN_AMERICA.AL32UTF8 export NLS_LANG
DISPLAY	Address and port of X server on desktop system of user running install. Optional for dbschema installer	DISPLAY=<IP address>:0 export DISPLAY

Variable	Description	Example
DOMAIN_HOME	The location of the WebLogic domain.	DOMAIN_HOME= /u00/webadmin/product/10.3.X/WLS/ user_projects/domains/ClassicDomain export DOMAIN_HOME
WLS_INSTANCE	The name of the managed server that the forms component is installed in.	WLS_INSTANCE=WLS_FORMS export WLS_INSTANCE
ORACLE_SID	The database/SID or pluggable database service name where the RWMS schema resides.	ORACLE_SID=rwmsdb
DISPLAY	Address and display number of X server on desktop system of user running install. Required for forms application installer, even when the installer is run in text mode.	DISPLAY=<IP address>:0 export DISPLAY
NLS_LANG	Locale setting for Oracle database client	NLS_LANG=AMERICAN_AMERICA.AL32UTF8 export NLS_LANG
JAVA_HOME	JAVA_HOME should point to your valid JDK installation. Typically, this is the JDK being used by WEBLOGIC HOME.	JAVA_HOME=/vol.rtk/java/os_platform/jdk1.7.0_45.64bit

Variable	Description	Example
DOMAIN_HOME	The location of the WebLogic domain.	DOMAIN_HOME= /u00/webadmin/product/10.3.X/WLS/ user_projects/domains/ClassicDomain export DOMAIN_HOME
WLS_INSTANCE	The name of the managed server that the forms component is installed in.	WLS_INSTANCE=WLS_FORMS export WLS_INSTANCE
ORACLE_SID	The database/SID or pluggable database service where the RWMS schema resides	ORACLE_SID=rwmsdb export ORACLE_SID
DISPLAY	Address and display number of X server on desktop system of user running install. Required for forms application installer, even when the installer is run in text mode.	DISPLAY=<IP address>:0 export DISPLAY
NLS_LANG	Locale setting for Oracle database client	NLS_LANG=AMERICAN_AMERICA.AL32UTF8 export NLS_LANG
JAVA_HOME	JAVA_HOME should point to your valid JDK installation. Typically, this is the JDK being used by WEBLOGIC HOME.	JAVA_HOME=/vol.rtk/java/os_platform/jdk1.7.0_45.64bit export JAVA_HOME

Variable	Description	Example
J2EE_ORACLE_HOME	The location of the WebLogic installation that contains the RWMS Enhanced Navigation and Dashboards Domain.	J2EE_ORACLE_HOME=/u00/webadmin/product/wls_retail export J2EE_ORACLE_HOME
J2EE_DOMAIN_HOME	The location of the WebLogic domain that contains the RWMS Enhanced Navigation and Dashboards managed server.	J2EE_DOMAIN_HOME=/u00/webadmin/product/wls_retail/user_projects/domains/RWMSDomain export J2EE_DOMAIN_HOME
DISPLAY	Address and display number of X server on desktop system of user running install. Optional for Enhanced Navigation and Dashboards installation	DISPLAY=<IP address>:0 export DISPLAY
NLS_LANG	Locale setting for Oracle database client	NLS_LANG=AMERICAN_AMERICA.AL32UTF8 export NLS_LANG
JAVA_HOME	JAVA_HOME should point to your valid JDK installation.	JAVA_HOME=/vol.rtk/java/os_platform/jdk1.7.0_45.64bit

Manual Installation and Configuration Tasks

This section covers the installation and configuration of external components and other dependencies for RWMS 14.1.

Prerequisites

The following prerequisites have been assumed to have been completed successfully:

§ The RWMS Database Schema installation into a running Oracle 11gR2 database platform must be completed.

§ The RWMS application components must be installed into a working WebLogic 10.3.6 domain.

§ The RWMS Enhanced Navigation and Dashboard must be installed into a working WebLogic 10.3.6 domain

Path References Used in this Section

The directory structures outlined in this section will vary according to your specific configuration of the target WebLogic domain. We will therefore use the labels outlined in the following table as references to directories used for the configuration of external dependencies for RWMS 14.1 throughout the rest of this section.

Note the directory names for each of the labels outlined below for your installation environment.

Label	Description	Example Directory
<STAGING_DIR>	The application installation staging directory as defined for the source installation files
<INSTALLATION_NAME>	The installation name of the RWMS system as defined for the application installation	rwms14inst
<WLS_JAVA_HOME>	The JDK location used by the WebLogic Server instance being installed to.	/u00/webadmin/java/jdk1.7.0_45.64bit
<BI_REPOSITORY>	The BI Publisher 11g reports repository where the reports are present .	/u00/webadmin/product/fmw/wls_obiee/user_projects/domains/bifoundation_domain/config/bipublisher/repository
<RWMS_REPOSITORY>	The RWMS User report templates repository.	<BI_REPOSITORY>/Users/ Guest/RWMS REPOSITORY
<RWMS_SYSTEM_REPOSITORY>	The RWMS System reports repository	<BI_REPOSITORY>/Users/Guest/RWMS SYSTEM REPOSITORY
<WLS_SERVER_CONFIG_DIR>	The configuration base directory for the WebLogic server instance supporting the Oracle Forms environment.	/u00/webadmin/product/10.3.6/WLS_Forms/domains/ClassicDomain/config/fmwconfig/servers/WLS_FORMS
<FORMS_INSTALL_BASE>	The Oracle Forms base configuration directory.	<WLS_SERVER_CONFIG_DIR>/ applications/ formsapp_11.1.2 /config
<RETAIL_HOME>	The final installation directory for RWMS application to run from (such as forms, extras, and reports).	/u00/webadmin/rwms14inst/

Note: In the following sections, the Oracle BI EE 11g installation steps are sample. Refer to the Oracle Business Intelligence 11g Installation Guide for more information.

BI Server Component Installation Tasks

Oracle BI Publisher is used as the main RMS, RWMS, REIM, and SIM reporting engine and can be used in conjunction with external printing solutions like label printing. This section describes the installation of Oracle BI Publisher as a server application within WebLogic 10.3.6. One deployment of BI Publisher can be used for any and all of the RMS, RWMS, REIM, and SIM reports.

When installing BI Publisher 11g, refer to the appropriate Fusion Middleware guides for the installation of the product in a WebLogic server environment.

Installation Process Overview

Installing the BI Publisher server as a standalone web application in a WebLogic server involves the following tasks:

1. Run RCU to create BIPublisher related database schemas and other db objects.

2. Install Oracle BI EE under an existing Weblogic Server (WLS) 10.3.6 and choose “Enterprise Install”.

3. Configure Oracle BI EE, create default bifoundation_domain and configure component “Business Intelligence Publisher” only.

4. Select the BIPlatform schema for update of the ORACLE 12c DB

5. Configure ports and document and test the URL’s that are created.

The following post-installation tasks are involved once BI Publisher has been installed:

6. Set up and copy the RWMS BI Publisher Report Templates produced for RWMS.

7. Configure the BI Publisher repository. Set security model, add users, assign roles, add reports, add printers, set repository path, set data source, etc.

8. Set up for the RWMS application specific configuration files to integrate BI Publisher with the RWMS online app.

Install Oracle BI EE 11g

1. Run the Repository Creation Utility to create the BiPublisher-related database schemas and other database objects. Create the BIPlatform schema into an existing ORACLE 12c database.

Note: Download Repository Creation Utility software from http://www.oracle.com/technetwork/middleware/bi-enterprise-edition/downloads/bi-downloads-1525270.html. Install it on your desktop

2. Export your DISPLAY.

Example: export DISPLAY=10.141.10.110:0.0

3. Launch Oracle BI EE RCU Repository Creation Utility to create the Oracle BI EE schemas need for the Oracle BIPublisher installation.

§ Go to $RCU_HOME/bin.

Example: /linux/x86_64/ofm_11g/RCU_11.1.1.7/rcuHome/bin>

Start RCU: ./rcu

4. Click Next.

5. On this screen select Create Repository and Click Next

6. On the Database Connection Details screen, enter your Oracle Database information.

7. Click OK.

8. On the Select Components screen, select Oracle Business Intelligence check box and click Next.

9. Click OK.

10. Select Use same passwords for all schemas, enter in the password and click Next.

11. In the Map Tablespaces screen – accept the defaults by selecting Next.

12. Click OK.

13. Click OK.

14. The Summary of the Components created by the RCU tool is displayed. Click Create.

15. Click Close.

16. Install Oracle BI EE and select “Enterprise Install”. To initiate the Oracle BI EE installer – via command line navigate to: <OBIEE_INSTALL>/obiee11.1.1.7/bishiphome/Disk1 and enter:

./runInstaller

17. Click Next:

18. Select Skip Software Updates and click Next.

19. Select Enterpise Install and click Next.

20. Click Next.

21. Enter in credentials for Weblogic Admin and Domain Name:

22. Enter in the Oracle Middleware Home where you want to install Oracle BI EE and click Next.

§ Example: /u00/webadmin/product/wls_obiee

Note: The remainder of the text entries will auto fill.

23. Select Business Intelligence Publisher only and click Next.

24. Enter the data base credentials of the BIPLATFORM schema.

25. Enter the Data base credentials for the MDS Schema.

26. Configure your BI ports. This screen allows you to assign Oracle BI EE ports from the staticports.ini file. Edit this file to make sure you will have the ports you want for your BiPublisher components. Otherwise the installer will assign default port numbers.

§ This file is located in the Oracle BI EE software at: <OBIEE_INSTALL>/obiee11.1.1.7/bishiphome/Disk1/stage/Response/staticports.ini.

§ Only need to update the top section – See below for example for non-ssl setup:

[WEBLOGIC]

#The Domain port no. This is the listen port of Weblogic Adminserver for the domain.

Domain Port No = 27001

#The "content" port for the BIEE apps. This is the Weblogic Managed Server port on which BIEE applications are deployed.

Oracle WLS BIEE Managed Server Port No = 29704

#The SSL port for the Weblogic Managed Server

#Oracle WLS BIEE Managed Server SSL Port No = 9804

#The Weblogic node manager port

Node Manager Port No = 9556

27. Uncheck software updates and Click Next.

28. Click Yes.

29. Click Install.

30. The following screen will appear automatically and continue to the next screen.

31. The following screen will appear automatically. Click Next when the button becomes enabled.

32. The final Completion screen gives important details regarding file locations and Important URLS for managing the Weblogic server as well as URLS for xmlp server. Make sure to copy these details by using the Save button. Click Finish.

33. To test your BIPublisher installation - launch the BI Publisher with the xmlpserver URL. Login with the credentials you entered in your Oracle BI EE configuration (weblogic / password).

Post Install Steps

1. After sign on, select “Administration”.

2. On the System Maintenance Section, click Server Configuration.

3. On this screen - In the Server Configuration Folder section, enter the path to your repository. On the Catalog section enter Catalog Type: Oracle BI Publisher – File System from the drop down menu.

§ This is the path you entered in the Configuration Section and Catalog Section:

§ Example: /u00/webadmin/product/wls_obiee/user_projects/domains/bifoundation_domain/config/bipublisher/repository

4. Click Apply.

5. Click Administration link at top of screen.

6. Click on the Security Configuration link under the Security Center to setup a super user and apply the BI Publisher security model.

7. Enable a superuser by checking the “Enable Local SuperUser” box and by entering name and password on the corresponding fields on this screen.

8. Mark “Allow Guest Access” check box. Enter “Guest” as Guest Folder Name.

9. Click Apply.

10. Scroll down the screen and locate the Authorization section:

11. Select BI Publisher Security from the Security Model list.

12. The default user name for the BI Publisher Security Model is Administrator.

13. On the password text field, enter a value that you can remember. It is going to be the password for Login to xmlpserver.

14. Click Apply.

§ Leave BI Publisher up while completing the next section.

Installing the RWMS BI Publisher Templates

In this section we have outlined how the RWMS report templates are installed into the appropriate BI server repositories. RWMS requires two sub directories to be created within the path indicated by <BI_REPOSITORY>.

Report files are placed by the installer in the directory, RETAIL_HOME/reports, and must be copied into the newly created BI server repository directory.

1. Change directory to the <RETAIL_HOME>/reports used for the application install. This directory contains a RWMS directory with “RWMS REPOSITORY” and “RWMS SYSTEM REPOSITORY” subdirectories. These two directories contain reports directories whose names reflect the names of report templates provided with RWMS.

2. Copy the RWMS directory and all of its subdirectories to <BI_REPOSITORY>/Reports/Guest. This will copy over the RWMS REPOSITORY and RWMS SYSTEM REPOSITORY directories according to the following table paths.

Example:

cp -R RWMS " /u00/webadmin/product/fmw/wls_obiee/user_projects/domains/bifoundation_domain/config/bipublisher/repository/Guest/ "

Placement of Report Templates

Directory	RWMS Repository	RWMS System Repository
asn_recv_package_audit_sys	P	P
asn_receiving_receipt_sys	P	P
best_before_date	P
bill_of_lading_sys	P	P
container_manifest_sys	P	P
gift_card_report_sys		P
inventory_by_item	P
inventory_by_location	P
labor_performance_day_summary	P
labor_performance_detail	P
labor_performance_week_summary	P
pack_slip_labels_sys		P
pick_package_audit_sys	P	P
pts_containers_to_close_sys		P
quality_audit_sys	P	P
receiving_receipt_sys	P	P
receiving_register	P
recv_package_audit_list_sys	P	P
return_to_vendor	P
rtv_advice_sys	P	P
unit_pick_group_sys		P
unresolved_appointment	P
error_log	P
cycle_count_log	P
confirm_fwd_case_picks_sys		P
qualified_container_sys	P	P
pick_labels_lbl		P
receiving_labels_lbl		P
ship_labels_lbl		P
ticketing_lbl		P
generic_lbl		P
prd_classification_code_sys		P
system_control_parameter_sys	P	P
user_summary_sys		P
user_task_history_sys	P	P

Configuring the RWMS JDBC connection

Follow the below steps to configure a JDBC connection for the RWMS Data Source, which is required for RWMS reports.

1. If not still logged into BIPublisher –

§ Login with the credentials you entered in your Oracle BI EE configuration. (weblogic / password)

2. If the server was restarted –

§ Login as the super user that was created in prior security setup steps.

Note: You will not be able to login to xmlpserver as weblogic any more because we have already changed the Security Model.

3. Click the Administration link at top of screen

4. Select the JDBC Connection hyperlink in the Data Sources lists.

5. Click the Add Data Source button.

6. Enter the appropriate details for the RWMS data source. Click Test Connection to test the connection on the screen once the data is entered.

– Data Source Name: RWMS

o Must be RWMS due to code dependencies.

– Driver type is ORACLE 11g

– Database driver class should be oracle.jdbc.OracleDriver.

– Connection string is similar to this example:

o Pluggable: jdbc:oracle:thin:@dbhostname:1521/servicename

o Non- Pluggable dbc:oracle:thin:@dbhostname:1521:SID

– Enter the username and password for the RWMS application user’s data source. Click Test Connection to test the connection on the screen once the data is entered.

7. Scroll to the bottom of the screen and check the Allow Guest Access check box. Click Apply.

8. Click Catalog link at the top of the screen – and then click the Guest folder on the left so that it is highlighted.

9. Click the Permissions link on the lower left of the screen.

10. Click OK.

11. Restart WebLogic Server.

Configure RWMS Email Server in BI Publisher

Follow the below steps to configure an email server in BI Publisher. The email server will be used by the RWMS application to email Manifesting and BOL reports when shipping containers.

1. Login as the super user that was created in prior security setup steps.

2. Click the Administration link at the top of the screen.

3. Under the Delivery section click on the Email Link.

4. Click Add Server

5. Fill in the appropriate values and Click Apply:

§ Server Name: There are no dependencies here. It can be named anything.

§ Host: This is the host name of the server in which the mail server resides.

§ Port: This is the email server port for the email server. The default for these is usually 25.

§ Username: Credential for email server. Not always required.

§ Password: Credential for email server. Not always required.

Configuring Forms to use BI Publisher

This section provides information about how to configure forms for BI.

Check the Configuration of formsweb.cfg

The formsweb.cfg file is modified by the application installer to add the appropriate entries for the RWMS Forms configurations. Please validate the file to ensure that the following items have been updated accordingly by the installer. In italics and higlighted are post installation configuration changes.

The file is typically found within the WebLogic domain configuration folder in the subdirectory <DOMAIN_HOME>/config/fmwconfig/servers/WLS_FORMS/applications/formsapp_11.1.2 /config directory and is named from the <INSTALLATION_NAME> value.

For example:

/u00/webadmin/product/wls_forms/user_projects/domains/ClassicDomain/config/fmwconfig/servers/WLS_FORMS/applications/formsapp_11.1.2/config/

The following is a sample of URL definitions that were created by the installer from the formsweb.cfg file.

[rwms14inst]

envfile=./rwms14inst/rwms14inst.env

width=950

height=685

separateFrame=true

lookAndFeel=Oracle

colorScheme=swan

archive=frmall.jar,rwms-icons.jar

form=logon_scr.fmx

userid=/@rwms14inst

#ssoMode=true

#ssoDynamicresourceCreate=true

[rwms14inst_hh]

envfile=./rwms4inst/rwms14inst.env

width=100%

height=100%

separateFrame=false

form=hh_intro_s.fmx

lookAndFeel=Oracle

Logo=false

colorScheme=swan

background=false

ShowMenuBar=false

ShowStatusBar=false

baseHTMLjinitiator=basejini.htm

baseHTML=base.htm

otherparams=term=/u00/webadmin/product/10.3.X/WLS_Forms/user_projects/domains/ClassicDomain/config/fmwconfig/servers/WLS_FORMS/applications/formsapp_11.1.2 /config/rwms14inst/fmrweb.res usesdi=YES

splashScreen=false

HTMLbodyAttrs=scroll="no" topmargin="0" leftmargin="0 marginheight="0" marginwidth="0" onload="window.moveTo(0,0);"

userid=/@rwms14inst

#ssoMode=true

#ssoDynamicresourceCreate=true

[rwms14inst_tm]

envfile=./rwms4inst/rwms14inst.env

width=100%

height=100%

separateFrame=false

form=tm_intro_s.fmx

Logo=false

lookAndFeel=Oracle

background=false

colorScheme=swan

ShowMenuBar=false

ShowStatusBar=false

baseHTMLjinitiator=basejini.htm

baseHTML=base.htm

otherparams=term=/u00/webadmin/product/10.3.X/WLS_Forms/user_projects/domains/ClassicDomain/config/fmwconfig/servers/WLS_FORMS/applications/ formsapp_11.1.2 /config/rwms14inst/fmrweb.res usesdi=YES

splashScreen=false

HTMLbodyAttrs=scroll="no" topmargin="0" leftmargin="0 marginheight="0" marginwidth="0" onload="window.moveTo(0,0);"

userid=/@rwms14inst

#ssoMode=true

#ssoDynamicresourceCreate=true

[rwms14inst_wr]

envfile=./rwms4inst/rwms4inst.env

width=100%

height=100%

separateFrame=false

form=wr_intro_s.fmx

Logo=false

background=false

lookAndFeel=Oracle

colorScheme=swan

ShowMenuBar=false

ShowStatusBar=false

baseHTMLjinitiator=basejini.htm

baseHTML=base.htm

otherparams=term=/u00/webadmin/product/10.3.X/WLS_Forms/user_projects/domains/ClassicDomain/config/fmwconfig/servers/WLS_FORMS/applications/ formsapp_11.1.2 /c

onfig/rwms14inst/fmrweb.res usesdi=YES

splashScreen=false

HTMLbodyAttrs=scroll="no" topmargin="0" leftmargin="0 marginheight="0" marginwidth="0" onload="window.moveTo(0,0);"

userid=/@rwms14inst

#ssoMode=true

#ssoDynamicresourceCreate=true

Note: The installer inserts a splashScreen= line at three locations in the formsweb.cfg file. Having these lines in the formsweb.cfg file may sometimes cause issues and should be commented out (#splashScreen=false).

Configuring the Forms Installation Environment Files

This section outlines the entries that need to be updated in the <INSTALLATION_NAME>.env file. Please validate the file to ensure that the following items have been updated accordingly. The file is typically found within the WebLogic domain configuration folder in the subdirectory <DOMAIN_HOME>/config/fmwconfig/servers/WLS_FORMS/applications/formsapp_11.1.2 /config directory and is named from the <INSTALLATION_NAME> value. For example:

/u00/webadmin/product/wls_forms/user_projects/domains/ClassicDomain/config/fmwconfig/servers/WLS_FORMS/applications/formsapp_11.1.2/config/

The following are an explanation of some variables that will be added to the <rwms_instalation_name>.env (Example: rwms14inst.env) file by the rwms installer.

Field Title	RWMS_REPORTS_URL
Field Description	This field points to BI Publisher URL location for the RWMS reports repository. RWMS Installer does not update this. This is a required manual entry.
Example	http://<bip_hostname>:<Port>/xmlpserver/servlet/report?f=/Guest/RWMS/RWMS+REPOSITORY/

Field Title

RWMS_REPORTS_URL

Field Description

This field points to BI Publisher URL location for the RWMS reports repository.

RWMS Installer does not update this. This is a required manual entry.

Example

http://<bip_hostname>:<Port>/xmlpserver/servlet/report?f=/Guest/RWMS/RWMS+REPOSITORY/

Field Title	RWMS_REPORTS_TEMP
Field Description	This is for specifying a subdirectory of the application war files. It is used as a drop off location for reports generated in BI publisher so that the application server can pick them up and display them to the users. RWMS Installer does not update this. This is a required manual entry. The trailing sub directories for the RWMS_REPORTS_TEMP variable after …/war in the example below must exactly match with the directories trailing the /forms/that is set by the RWMS installer for RWMS_REPTEMP_ALIAS.
Example	/u00/webadmin/product/wls_forms/user_projects/domains/ClassicDomain/servers/WLS_FORMS/tmp/_WL_user/formsapp_11.1.2 /spn4wj/war/rwms/reptemp

Field Title

RWMS_REPORTS_TEMP

Field Description

This is for specifying a subdirectory of the application war files. It is used as a drop off location for reports generated in BI publisher so that the application server can pick them up and display them to the users.

RWMS Installer does not update this. This is a required manual entry.

The trailing sub directories for the RWMS_REPORTS_TEMP variable after …/war in the example below must exactly match with the directories trailing the /forms/that is set by the RWMS installer for RWMS_REPTEMP_ALIAS.

Example

/u00/webadmin/product/wls_forms/user_projects/domains/ClassicDomain/servers/WLS_FORMS/tmp/_WL_user/formsapp_11.1.2 /spn4wj/war/rwms/reptemp

Field Title	RWMS_REPORT_END_POINT_URL
Field Description	This field is used by RWMS forms to access BI Publisher’s ReportService web service, which is required for emailing and executing reports. RWMS Installer does not update this. This is a required manual entry.
Example	http://<bip_hostname>:<Port>/xmlpserver/services /v2/ReportService?wsdl

Field Title

RWMS_REPORT_END_POINT_URL

Field Description

This field is used by RWMS forms to access BI Publisher’s ReportService web service, which is required for emailing and executing reports.

RWMS Installer does not update this. This is a required manual entry.

Example

http://<bip_hostname>:<Port>/xmlpserver/services /v2/ReportService?wsdl

Field Title	RWMS_SCHEDULE_END_POINT_URL
Field Description	This field is used by RWMS forms to access BI Publisher’s ScheduleService web service, which is required for emailing and executing reports. RWMS Installer does not update this. This is a required manual entry.
Example	http://< bip_hostname>:<Port>/xmlpserver/services /v2/ScheduleService?wsdl

Field Title

RWMS_SCHEDULE_END_POINT_URL

Field Description

This field is used by RWMS forms to access BI Publisher’s ScheduleService web service, which is required for emailing and executing reports.

RWMS Installer does not update this. This is a required manual entry.

Example

http://< bip_hostname>:<Port>/xmlpserver/services /v2/ScheduleService?wsdl

Field Title	RWMS_BI_USER
Field Description	The installer now uses the Java wallet files for passing the correct credentials to BI Publisher. This is the account ID of the BI User account. It is not used if the wallet is in use. (RWMS_WALLET_LOGON=TRUE) Note: The RWMS installer by default does not create this entry in the .env file. It is used as a literal string when the other .env file variable RWMS_WALLET_LOGON=FALSE and would need to be manually added.
Example	<BI Publisher user id>

Field Title

RWMS_BI_USER

Field Description

The installer now uses the Java wallet files for passing the correct credentials to BI Publisher. This is the account ID of the BI User account. It is not used if the wallet is in use. (RWMS_WALLET_LOGON=TRUE)

Note: The RWMS installer by default does not create this entry in the .env file. It is used as a literal string when the other .env file variable RWMS_WALLET_LOGON=FALSE and would need to be manually added.

Example

Field Title	RWMS_BI_PWD
Field Description	The installer already correctly sets the alias so no changes are necessary. It is used to pass credentials to BI Publisher via its web services. Note: RWMS installer does not create the wallet. The java wallet that needs to be created in order to use this will need to have a matching alias. Note: If the .env file variable RWMS_WALLET_LOGON is set to FALSE this variable will be used by the application as a literal string and needs to be set as well as RWMS_BI_USER in order for BI Publisher to work.
Example	Wallet Example: BI_ALIAS Non wallet usage: <password>

Field Title

RWMS_BI_PWD

Field Description

The installer already correctly sets the alias so no changes are necessary. It is used to pass credentials to BI Publisher via its web services.

Note: RWMS installer does not create the wallet. The java wallet that needs to be created in order to use this will need to have a matching alias.

Note: If the .env file variable RWMS_WALLET_LOGON is set to FALSE this variable will be used by the application as a literal string and needs to be set as well as RWMS_BI_USER in order for BI Publisher to work.

Example

Wallet Example: BI_ALIAS

Non wallet usage: <password>

Field Title	RWMS_DB_CONNECT
Field Description	This is set to a Java wallet alias by the installer. It is used in the purging of cont_labels_to_print table by passing a fully qualified database connection when labels are printed via the RWMS application. Note: The Java wallet used for this variable is not setup by the installer. See RWMS Wallet Configurations in this install guide for information on how to set it up. Note: If the .env file variable RWMS_WALLET_LOGON is set to FALSE this variable will be used by the application as a literal string.
Example	Wallet Example: <schema_owner>_<db_servicename> Non wallet usage: <dbuser>/<password>@<db_servicename>

Field Title

RWMS_DB_CONNECT

Field Description

This is set to a Java wallet alias by the installer. It is used in the purging of cont_labels_to_print table by passing a fully qualified database connection when labels are printed via the RWMS application.

Note: The Java wallet used for this variable is not setup by the installer. See RWMS Wallet Configurations in this install guide for information on how to set it up.

Note: If the .env file variable RWMS_WALLET_LOGON is set to FALSE this variable will be used by the application as a literal string.

Example

Wallet Example: <schema_owner>_<db_servicename>

Non wallet usage: <dbuser>/<password>@<db_servicename>

Field Title	RWMS_WALLET_PATH
Field Description	This variable is used by the application to determine where the java wallet file is located at so that the application can access the RWMS_BI_USER, RWMS_BI_PWD, and RWMS_DB_CONNECT values. The installer will create a value for this variable. Note: The Java wallet used for this variable is not setup by the installer. See RWMS Wallet Configurations in this install guide for information on how to set it up.
Example	/projects/rwms14/extras/javawallet

Field Title

RWMS_WALLET_PATH

Field Description

This variable is used by the application to determine where the java wallet file is located at so that the application can access the RWMS_BI_USER, RWMS_BI_PWD, and RWMS_DB_CONNECT values.

The installer will create a value for this variable.

Note: The Java wallet used for this variable is not setup by the installer. See RWMS Wallet Configurations in this install guide for information on how to set it up.

Example

/projects/rwms14/extras/javawallet

Field Title	RWMS_WALLET_PARTITION
Field Description	This variable is used by the application to determine what partition is to be used for the java wallet that the RWMS application uses so that the application can access the RWMS_BI_USER, RWMS_BI_PWD, and RWMS_DB_CONNECT values. The RWMS installer will create a value for this variable. Note: The Java wallet used for this variable is not setup by the installer. See RWMS Wallet Configurations in this install guide for information on how to set it up.
Example	rwms14inst

Field Title

RWMS_WALLET_PARTITION

Field Description

This variable is used by the application to determine what partition is to be used for the java wallet that the RWMS application uses so that the application can access the RWMS_BI_USER, RWMS_BI_PWD, and RWMS_DB_CONNECT values.

The RWMS installer will create a value for this variable.

Note: The Java wallet used for this variable is not setup by the installer. See RWMS Wallet Configurations in this install guide for information on how to set it up.

Example

rwms14inst

Field Title	RWMS_WALLET_LOGON
Field Description	This variable is used by the application to determine if it should consider theRWMS_BI_USER – RWMS_BI_PWD – and RWMS_DB_CONNECT variables as wallet aliases or string values. By default the installer set up variables in the .env file for java wallet usage, but the wallet file must be created as a post installation step. There are detailed instructions in the Appendix of this installation guide on how to do this.
Example	TRUE or FALSE

Field Title

RWMS_WALLET_LOGON

Field Description

This variable is used by the application to determine if it should consider theRWMS_BI_USER – RWMS_BI_PWD – and RWMS_DB_CONNECT variables as wallet aliases or string values.

By default the installer set up variables in the .env file for java wallet usage, but the wallet file must be created as a post installation step. There are detailed instructions in the Appendix of this installation guide on how to do this.

Example

TRUE or FALSE

Field Title	RWMS_SYS_REPORTS_DIR
Field Description	This variable is a reference to the Guest sub directory within BI Publisher in which the reports reside that the RWMS application accesses via the BI Publisher web service interface. RWMS Installer does not update this. This is a required manual entry.
Example	/Guest/RWMS/RWMS SYSTEM REPOSITORY/

Field Title

RWMS_SYS_REPORTS_DIR

Field Description

This variable is a reference to the Guest sub directory within BI Publisher in which the reports reside that the RWMS application accesses via the BI Publisher web service interface.

RWMS Installer does not update this. This is a required manual entry.

Example

/Guest/RWMS/RWMS SYSTEM REPOSITORY/

Field Title	RWMS_FORMS_SERVER
Field Description	The RWMS installer creates this entry. The RWMS application at run time will concatenate this value with the RWMS_REPTEMP_ALIAS value and render the report to the end user in a web browser. The value is the forms server and port portion of the forms application URL.
Example	http://<formshostname>:<port>

Field Title	RWMS_REPTEMP_ALIAS
Field Description	The RWMS installer creates this entry. The RWMS application at run time will concatenate this value with the RWMS_FORMS_SERVER value and render the report to the end user in a web browser. The value that it is set to is related to the forms war directory where it can be accessed and displayed by the forms server. The trailing sub directories for the RWMS_REPORTS_TEMP variable after …/war must exactly match with the directories trailing the /forms/ portion of the example below. This variable is used by the forms application server so that it knows where to pick the reports when the forms server renders the report to the user.
Example	/forms/rwms/reptemp/

Field Title

RWMS_REPTEMP_ALIAS

Field Description

The RWMS installer creates this entry. The RWMS application at run time will concatenate this value with the RWMS_FORMS_SERVER value and render the report to the end user in a web browser. The value that it is set to is related to the forms war directory where it can be accessed and displayed by the forms server. The trailing sub directories for the RWMS_REPORTS_TEMP variable after …/war must exactly match with the directories trailing the /forms/ portion of the example below.

This variable is used by the forms application server so that it knows where to pick the reports when the forms server renders the report to the user.

Example

/forms/rwms/reptemp/

Field Title	ORACLE_RWMS_EXTRAS
Field Description	The RWMS installer creates this entry. It is where the installer will also place the following jar files. httputil.jar, bihelper.jar, wmsSecurity.jar, and retail-public-security-api.jar.
Example	<RETAIL_HOME>/extras

Field Title	RF_LAUNCH_VALUE_ALIAS
Field Description	The RWMS installer creates this entry. This variable is used by the forms application server to find the RF launch screen modules and render them to the user. The RWMS application at run time will concatenate this value with the RWMS_FORMS_SERVER value and render the RF menu to end users on the terminal server. The Adding Radio Frequency Launch Configurations section of this install guide explains file placement for rf_launch modules and configuration.
Example	/forms/rwms/rf_launch/

Field Title

RF_LAUNCH_VALUE_ALIAS

Field Description

The RWMS installer creates this entry. This variable is used by the forms application server to find the RF launch screen modules and render them to the user. The RWMS application at run time will concatenate this value with the RWMS_FORMS_SERVER value and render the RF menu to end users on the terminal server.

The Adding Radio Frequency Launch Configurations section of this install guide explains file placement for rf_launch modules and configuration.

Example

/forms/rwms/rf_launch/

Field Title	CLASSPATH
Field Description	You will need to add the jars listed below: httputil.jar The installer should have placed it in the <RETAIL_HOME>/extras directory. bihelper.jar The installer should have placed it in the <RETAIL_HOME>/extras directory. wmsSecurity.jar The installer should have placed it in the <RETAIL_HOME>/extras directory. retail-public-security-api.jar The installer should have placed it in the <RETAIL_HOME>/extras directory. The below jars are also to be added in the classpath. jrf.jar <ORACLE_HOME>/oracle_common/modules/oracle.jrf_11.1.1/jrf.jar javax.persistence.jar - <ORACLE_HOME>/oracle_common/modules/javax.persistence.jar xmlparserv2.jar - <ORACLE_HOME>/oracle_common/modules/oracle.xdk_11.1.0/xmlparserv2.jar xml.jar - <ORACLE_HOME>/oracle_common/modules/oracle.xdk_11.1.0/xml.jar orai18n-mapping.jar - <ORACLE_HOME>/oracle_common/modules/oracle.nlsrtl_11.1.0/orai18n-mapping.jar com.oracle.toplink_1.1.0.0_11-1-1-6-0.jar - <ORACLE_HOME>/modules/com.oracle.toplink_1.1.0.0_11-1-1-6-0.jar org.eclipse.persistence_1.2.0.0_2-3.jar - <ORACLE_HOME>/modules/org.eclipse.persistence_1.2.0.0_2-3.jar com.bea.core.antlr.runtime_2.7.7.jar - <ORACLE_HOME>/modules/com.bea.core.antlr.runtime_2.7.7.jar weblogic.jar <ORACLE_HOME>/wlserver_10.3/server/lib/weblogic.jar

Field Title

CLASSPATH

Field Description

You will need to add the jars listed below:

httputil.jar

The installer should have placed it in the <RETAIL_HOME>/extras directory.

bihelper.jar

The installer should have placed it in the <RETAIL_HOME>/extras directory.

wmsSecurity.jar

The installer should have placed it in the <RETAIL_HOME>/extras directory.

retail-public-security-api.jar

The installer should have placed it in the <RETAIL_HOME>/extras directory.

The below jars are also to be added in the classpath.

jrf.jar <ORACLE_HOME>/oracle_common/modules/oracle.jrf_11.1.1/jrf.jar

javax.persistence.jar - <ORACLE_HOME>/oracle_common/modules/javax.persistence.jar

xmlparserv2.jar - <ORACLE_HOME>/oracle_common/modules/oracle.xdk_11.1.0/xmlparserv2.jar

xml.jar - <ORACLE_HOME>/oracle_common/modules/oracle.xdk_11.1.0/xml.jar

orai18n-mapping.jar - <ORACLE_HOME>/oracle_common/modules/oracle.nlsrtl_11.1.0/orai18n-mapping.jar

com.oracle.toplink_1.1.0.0_11-1-1-6-0.jar - <ORACLE_HOME>/modules/com.oracle.toplink_1.1.0.0_11-1-1-6-0.jar

org.eclipse.persistence_1.2.0.0_2-3.jar - <ORACLE_HOME>/modules/org.eclipse.persistence_1.2.0.0_2-3.jar

com.bea.core.antlr.runtime_2.7.7.jar - <ORACLE_HOME>/modules/com.bea.core.antlr.runtime_2.7.7.jar

weblogic.jar <ORACLE_HOME>/wlserver_10.3/server/lib/weblogic.jar

The following is an example of the entries used for a working <INSTALLATION_NAME>.env file:

…

CLASSPATH=/scratch/u00/webadmin/product/wls_retail/as_1/forms/j2ee/frmsrv.jar:/scratch/u00/webadmin/product/wls_retail/as_1/jlib/ldapjclnt11.jar:/scratch/u00/webadmin/product/wls_retail/as_1/jlib/debugger.jar:/scratch/u00/webadmin/product/wls_retail/as_1/jlib/ewt3.jar:/scratch/u00/webadmin/product/wls_retail/as_1/jlib/share.jar:/scratch/u00/webadmin/product/wls_retail/as_1/jlib/utj.jar:/scratch/u00/webadmin/product/wls_retail/as_1/jlib/zrclient.jar:/scratch/u00/webadmin/product/wls_retail/as_1/reports/jlib/rwrun.jar:/scratch/u00/webadmin/product/wls_retail/as_1/forms/java/frmwebutil.jar:/scratch/u00/webadmin/product/wls_retail/as_1/jlib/start_dejvm.jar:/scratch/u00/webadmin/product/wls_retail/as_1/opmn/lib/optic.jar:/vol.rtk/pkg_mocks/rwms141/retail_home_app/extras/httputil.jar:/vol.rtk/pkg_mocks/rwms141/retail_home_app/extras/bihelper.jar:/vol.rtk/pkg_mocks/rwms141/retail_home_app/extras/wmsSecurity.jar:/vol.rtk/pkg_mocks/rwms141/retail_home_app/extras/retail-public-security-api.jar:/u00/webadmin/product/wls_retail/oracle_common/modules/oracle.jrf_11.1.1/jrf.jar:/u00/webadmin/product/wls_retail/oracle_common/modules/javax.persistence.jar:/u00/webadmin/product/wls_retail/oracle_common/modules/oracle.xdk_11.1.0/xmlparserv2.jar:/u00/webadmin/product/wls_retail/oracle_common/modules/oracle.xdk_11.1.0/xml.jar:/u00/webadmin/product/wls_retail/oracle_common/modules/oracle.nlsrtl_11.1.0/orai18n-mapping.jar:/u00/webadmin/product/wls_retail/modules/com.oracle.toplink_1.1.0.0_11-1-1-6-0.jar:/u00/webadmin/product/wls_retail/modules/org.eclipse.persistence_1.2.0.0_2-3.jar:/u00/webadmin/product/wls_retail/modules/com.bea.core.antlr.runtime_2.7.7.jar:/u00/webadmin/product/wls_retail/wlserver_10.3/server/lib/weblogic.jar

…

#RWMS Application Server added lines

NLS_DATE_FORMAT=DD-MON-RR

NLS_LANG=AMERICAN_AMERICA.AL32UTF8

FORMS_USERNAME_CASESENSITIVE=1

FORMS_REJECT_GO_DISABLED_ITEM=FALSE

RWMS_SYS_REPORTS_DIR=/Guest/RWMS/RWMS SYSTEM REPOSITORY/

RWMS_REPORTS_URL=http://bihostname:29704/xmlpserver/servlet/report?f=/Guest/RWMS/RWMS+REPOSITORY

RWMS_REPORTS_TEMP=/u00/webadmin/product/10.3.X/WLS/user_projects/domains/ClassicDomain/servers/WLS_FORMS/tmp/_WL_user/formsapp_11.1.2/spn4wj/war/rwms/reptemp

ORACLE_RWMS_EXTRAS=/u00/projects/rwms14.1/devlinf/extras

RWMS_FORMS_SERVER=http://formshostname:9001

RWMS_REPTEMP_ALIAS=/forms/rwms/reptemp/

RF_LAUNCH_VALUE_ALIAS=/forms/rwms/rf_launch/

RWMS_WALLET_PATH= /projects/rwms14/extras/javawallet

RWMS_WALLET_PARTITION=rwms14inst

RWMS_WALLET_LOGON=TRUE

RWMS_BI_PWD=BI_ALIAS

RWMS_DB_CONNECT=wms01_mydb

RWMS_REPORT_END_POINT_URL=http://bihostname:29704/xmlpserver/services/v2/ReportService?wsdl

RWMS_SCHEDULE_END_POINT_URL=http://bihostname:29704/xmlpserver/services/v2/ScheduleService?wsdl

…

If not using a wallet to configure the variables used to integrate BIPublisher and RWMS the following is an example of how the impacted entries are used for a working <INSTALLATION_NAME>.env file:

#RWMS_WALLET_PATH=/projects/rwms14/extras/javawallet #RWMS_WALLET_PARTITION=rwms14inst

RWMS_WALLET_LOGON=FALSE

RWMS_BI_USER=retail.user

RWMS_BI_PWD=welcome1

RWMS_DB_CONNECT=wms01/retail@mydb

RWMS Wallet Configurations

The RWMS application is comprised of several entities that require logon credentials to be passed back and forth. These credentials are kept secure by the use of several different types of wallets. The reason that multiple wallets are required is that the some of the RWMS entities are from different tech stacks. The RWMS application needs to allow ADF, Oracle Forms, BIPublisher, and batch script interfaces to be able to communicate. Below is a summary of each type of wallet that is utilized and how it works in the application.

Application (Java) Wallet

Note: This wallet must be created manually. The installer does not create it.

§ Its purpose is to provide credentials for the RWMS application to be able to print reports via web service connections to in BI Publisher.

§ This wallet is not setup by RWMS installer.

§ See Setting up Application (Java) Wallet for RWMS .env File for instructions on how to set this up.

§ Used to store values for the variables setup in the RWMS forms .env file.

– RWMS_WALLET_PATH:

– By default the RWMS installer creates this entry in the .env file, but does not actually create the wallet.

– The path here should be set to the location where the wallet will reside once it is created. The location is a suggested location, but can actually reside anywhere on the file system that the RWMS application has access to.

– RWMS_WALLET_PARTITION:

– By default the RWMS installer creates this entry in the .env file, but does not actually create the wallet entry.

– This value is the partition of the wallet that is used to look up the credentials.

– RWMS_WALLET_LOGON:

– By default the RWMS installer creates this entry in the .env file as TRUE.

– This value tells the RWMS application whether or not to consider the variables

– Setting this to FALSE, commenting it out, or deleting the entry will be accepted as a FALSE value by the application and will result in RWMS application considering credential variables as clear text.

– RWMS_BI_USER:

– No alias for this variable is stored in the wallet. The application uses the RWMS_BI_PWD for this purpose.

– Used to store a BI Publisher username credential for RWMS application to access BI Publisher reports via web services.

– Only used in when RWMS_WALLET _LOGON is set to FALSE and will be in clear text.

– RWMS_BI_PWD:

– By default the RWMS installer creates this entry in the .env file, but does not actually create the wallet entry.

– The variable value is an alias that access the credentials used to log into BI Publisher in order to print reports from the application.

– When RWMS_WALLET _LOGON is set to FALSE – this value should be clear text in the .env file.

– RWMS_DB_CONNECT:

– By default the RWMS installer creates this entry in the .env file, but does not actually create the wallet entry.

– The variable value is an alias that access the credentials used to create a connection to the database by the purge_cont_labels_to_print_b.sh batch script. It is used to clean up the cont_labels_to_print table after labels are printed from the RWMS application.

– When RWMS_WALLET _LOGON is set to FALSE – this value should be clear text in the .env file.

Oracle Wallet

§ Its purpose is to provide a secure connection string for RWMS in the formsweb.cfg file for automatic forms launching, and executing batch programs via command line or daemon processes.

§ This wallet is setup by RWMS installer.

§ See Appendix: Setting Up an Oracle Wallet for instructions on how to set this up.

WLS Database Credential Store

§ Its purpose is to provide secure credentials to the file system so that the RWMS application can access and write log files.

§ This wallet is setup by RWMS installer.

§ See Setting Up WLS Database Credential Store for instructions on how to set this up or maintain it outside the RWMS installer.

§ It is used by the Manual Script Launch Editor which uses the application.properties to acquire credentials for a file system user that can write log files on the server.

§ The specific in the application.properties are as follows and are case sensitive:

– Cred.store.map=Rwmsmap

– Cred.store.key=rwmskey

Adding Radio Frequency Launch Configurations

The RF Launch Screen is used as an entry point for RF devices to the RWMS application when users first log on to the terminal server. It is how the system knows what type of device is accessing the RWMS application as well as set system variables according to the type of equipment being used. The RWMS installer already sets this up with corresponding formsweb.cfg and .env file entries. It is necessary to know how to set these up however so that other devices can be added.

File Placement

To place files, complete the following steps.

1. On the application server in the forms application server base directory you will need to create /rwms/rf_launch directories in the Forms war file directory.

Example: /u00/webadmin/product/10.3.6/WLS_Forms/user_projects/domains/ClassicDomain/servers/WLS_FORMS/tmp/_WL_user/formsapp_11.1.2 / spn4wj/war/rwms/rf_launch

2. From the pickup directory listed below: Acquire and Place the following files in the directory that was created during previous step.

§ Pickup directory: <STAGING_DIR>/rwms/installer/rwms14/RF_Launch/Source/

§ close.html

Warning: Do not open the close.htm file. It is designed to automatically shut down the computer that opens it. Use a text editor to view the contents as needed.

§ oracle_logo.jpg

§ rwms_rf_menu.html

Update the RF Launch Modules

rwms_rf_menu.html Module

The rwms_rf_menu.html should have been updated by the installer but may be configured to launch additional URL’s based on the names of the URL’s in the formsweb.cfg file. The variables that are updated by the installer are listed below.

§ var hh_device = "http://<Server_Name>:<port>/forms/frmservlet?config=<INSTALLATION_NAME>_hh";:Q

§ var tm_device = "http://<Server_Name>:<port>/forms/frmservlet?config=<INSTALLATION_NAME>_tm";

§ var wr_device = “http:<Server_Name>:<port>/forms/frmservlet?config=<INSTALLATION_NAME>_wr";

§ var exit_script = "http://<Server_Name>:<port>/forms/rwms/rf_launch/close.html";

close.html Module

The Close.html file is designed to close down and log a user out of a Terminal Server session by running the Windows shutdown.exe. In some cases the location specified in the close.html file is different than where it exists and on the Terminal Server and will need to be updated. In addition to that the browser on the terminal server will need to have its security settings adjusted to allow ActiveX controls to run.

1. Below is a line the line of code within the close.html file that may need to be updated.

Note: Running this script on your desktop will shut it down so make sure to test it on the terminal server.

myshell.run( '"c:/WINDOWS/system32/shutdown.exe" "-l"', 1, true );

2. Below are some screen shots of the IE setting that need to be made on the terminal server to allow ActiveX controls to run.

a. Navigate ToolsàInternet Options in IE.

b. On security tab setup the rwms server as a trusted site.

c. Then click Custom Level and follow the screen shots below:

Note: Screen shots below are from Internet Explorer 9.

Update fmrweb.res for Keymapping

The fmrweb.res file is used to specify key-mapping for the radio frequency devices that are set up in the formsweb.cfg file.

1. Depending upon device this file may need to be updated.

2. The installer places a copy in the directory specified in the formsweb.cfg file for each radio frequency URL that is created

3. The fmrweb.res file comes with key-mapping of CTRL+<number> to work for function keys by default.

Client Side Configurations for Java Security Updates

If the client accessing the Enhanced Navigation and Dashboards application is using Java 1.7 u51 or greater with the High security setting (or higher), they will need to perform the following configuration steps to use the application.

Create a Deployment Rule Set

Note: See this page for details on creating a Deployment Rule Set: http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/deployment_rules.html

1. Create a new text file called ruleset.xml. This file should contain a rules for the forms url, the Enhanced Navigation and Dashboards url, and a default rule. An example is provided below that can be used as a template, please replace the Forms and Enhanced Navigation & Dashboards application hostnames and managed server listen ports with the ones in use in your environment.

Example:

<rule>

</rule>

<rule>

</rule>

<rule>

<id />

</rule>

</ruleset>

2. Jar the ruleset.xml into a new jar “DeploymentRuleSet.jar”

3. Sign DeploymentRuleSet.jar

4. If it doesn’t already exist, create the following directory <Windows Directory>\Sun\java\deployment\

Example:

C:\Windows\Sun\Java\deployment\

5. Place the signed DeploymentRuleSet.jar in <Windows Directory>/Sun/java/deployment/

Patching Procedures

Oracle Retail Patching Process

The patching process for many Oracle Retail products has been substantially revised from prior releases. Automated tools are available to reduce the amount of manual steps when applying patches. To support and complement this automation, more information about the environment is now tracked and retained between patches. This information is used to allow subsequent patches to identify and skip changes which have already been made to the environment. For example, the patching process uses a database manifest table to skip database change scripts which have already been executed.

The enhanced product patching process incorporates the following:

§ Utilities to automate the application of Oracle Retail patches to environments.

§ Unified patches so that a single patch can be applied against Database, Forms, Java applications, Batch, etc. installations.

§ Database and Environment manifests track versions of files at a module level.

§ Centralized configuration distinguishes installation types (Database, Forms, Java, Batch, etc.).

§ Patch inventory tracks the patches applied to an environment.

These enhancements make installing and updating Oracle Retail product installations easier and reduce opportunities for mistakes. Some of these changes add additional considerations to patching and maintaining Oracle Retail product environments. Additional details on these considerations are found in later sections.

Supported Products and Technologies

With version 14.1, several additional products and technologies are supported by the enhanced patching process. The utilities, processes and procedures described here are supported with the following products and listed technologies:

Product	Supported Technology
Oracle Retail Merchandising System (RMS)	§ Database scripts § Batch scripts § RETL scripts § Data Conversion Scripts § Forms § BI Publisher Reports
Oracle Retail Warehouse Management System (RWMS)	§ Database scripts § Batch scripts § Forms § BI Publisher Reports
Oracle Retail Price Management (RPM)	§ Database scripts (included with RMS) § Java Application § Batch scripts
Oracle Retail Invoice Matching (ReIM)	§ Database scripts (included with RMS) § Java Application § Batch scripts
Oracle Retail Allocation	§ Database scripts (included with RMS) § Java Application § Batch scripts
Oracle Retail Sales Audit (ReSA)	§ Database scripts (included with RMS) § Java Application
Oracle Retail Analytics (RA)	§ Database scripts
Oracle Retail Advanced Science Engine (ORASE)	§ Database scripts § Batch scripts
Oracle Retail Application Security Role Manager (RASRM)	§ Java Application

Patch Concepts

During the lifecycle of an Oracle Retail environment, patches are applied to maintain your system. This maintenance may be necessary to resolve a specific issue, add new functionality, update to the latest patch level, add support for new technologies, or other reasons.

A patch refers to a collection of files to apply to an environment. Patches could be cumulative, such as the 14.1.0 or 14.1.1 release, or incremental, such as a hot fix for just a few modules. Patches may contain updates for some or all components of a product installation including database, application code, forms, and batch. In a distributed architecture the same patch may need to be applied to multiple systems in order to patch all of the components. For example, if a patch contains both database and application changes, the patch would need to be applied to both the database server and the application server.

The top-level directory for the installation of an Oracle Retail product is referred to as the RETAIL_HOME. Underneath RETAIL_HOME are all of the files related to that product installation, as well as configuration and metadata necessary for the Oracle Retail Patch Assistant to maintain those files. In some cases the runtime application files also exist under RETAIL_HOME. For example, the compiled RMS forms, compiled RMS batch files, or Java Application batch scripts.

Patching Utility Overview

Patches are applied and tracked using utilities that are specifically designed for this purpose. The primary utility is described briefly below and additional information is available in later sections.

Oracle Retail Patch Assistant (ORPatch)

ORPatch is the utility used to apply patches to an Oracle Retail product installation. It is used in the background by the installer when creating a new installation or applying a cumulative patch. It is used directly to apply an incremental patch to an environment.

Oracle Retail Merge Patch (ORMerge)

ORMerge is a utility to allow multiple patches to be combined into a single patch. Applying patches individually may require some steps to be repeated. Merging multiple patches together allows these steps to be run only once. For example, applying several incremental patches to database packages will recompile invalid objects with each patch. Merging the patches into a single patch before applying them will allow invalid objects to be recompiled only once.

Oracle Retail Compile Patch (ORCompile)

ORCompile is a utility to compile components of Oracle Retail products outside of a patch. It allows RMS Forms, RMS Batch, and RWMS Forms to be fully recompiled even if no patch has been applied. It also contains functionality to recompile invalid database objects in product schemas.

Oracle Retail Deploy Patch (ORDeploy)

ORDeploy is a utility to deploy components of Oracle Retail Java products outside of a patch. It allows RPM, ReIM, Allocation and ReSA java applications to be redeployed to WebLogic even if a patch has not been applied. It contains functionality to optionally include or not include Java customizations when redeploying.

Changes with 14.1

Many products and technologies are supported by the enhanced patching process for the first time in 14.1. In those cases all of the content in this chapter is new with 14.1.

MMHOME changed to RETAIL_HOME

For RMS and RWMS, which were previously supported in 14.0, there is a change when using ORPatch and related tools. Previously the MMHOME environment variable was used to refer to the RMS and RWMS installation area. Starting with 14.1, RETAIL_HOME is now used to refer to the installation area. So where previously it was necessary to set MMHOME before executing ORPatch, you must now set RETAIL_HOME.

Note: RMS Batch continues to use MMHOME to refer to the area where batch is installed, and requires it to be set when executing batches. The change to using RETAIL_HOME relates only to ORPatch and related utilities.

Java batch script location

For Java products with batch scripts, starting with 14.1 the location of batch scripts has been changed to $RETAIL_HOME/<app>-batch. Previously batch scripts were stored within the WebLogic domain in the retail directory. Credential store files continue to be stored within the WebLogic domain.

Patching Considerations

Patch Types

Oracle Retail produces two types of patches for their products: cumulative and incremental.

Cumulative Patches

A cumulative patch includes all of the files necessary to patch an environment to a specific level or build a new environment at that level. Examples of cumulative patches would be 14.1.1, 14.1.2, and so on. Cumulative patches come with a standard Oracle Retail installer and so can be applied to an environment with the installer rather than with ORPatch or other utilities.

Incremental Patches

An incremental patch includes only selected files necessary to address a specific issue or add a feature. Examples of incremental patches would be a hot fix for a specific defect. Incremental patches do not include an installer and must be applied with ORPatch.

Incremental Patch Structure

An Oracle Retail incremental patch generally contains several files and one or more subdirectories. The subdirectories contain the contents of the patch, while the individual files contain information about the patch and metadata necessary for patching utilities to correctly apply the patch. The most important files in the top-level directory are the README.txt, the manifest files.

README File

The README.txt file contains information about the incremental patch and how to apply it. This may include manual steps that are necessary before, after or while applying the patch. It will also contain instructions on applying the patch with ORPatch.

Manifest Files

Each patch contains manifest files which contain metadata about the contents of a patch and are used by ORPatch to determine the actions necessary to apply a patch. Patches should generally be run against all installations a product in an environment, and ORPatch will only apply the changes from the patch that are relevant to that installation.

Note: Cumulative patches use a different patch structure because they include a full installer which will run ORPatch automatically.

Version Tracking

The patching infrastructure for 14.1 tracks version information for all files involved with a product installation. The RETAIL_HOME now contains files which track the revision of all files within the RETAIL_HOME including batch, forms, database, Java archives and other files. In addition, records of database scripts that have been applied to the product database objects are kept within each database schema.

Apply all Patches with Installer or ORPatch

In order to ensure that environment metadata is accurate all patches must be applied to the Oracle Retail product installation using patching utilities. For cumulative patches this is done automatically by the installer. For incremental patches ORPatch must be used directly. This is especially important if database changes are being applied, in order to ensure that the database-related metadata is kept up-to-date.

Environment Configuration

A configuration file in $RETAIL_HOME/orpatch/config/env_info.cfg is used to define the details of a specific Oracle Retail environment. This file defines:

§ The location of critical infrastructure components such as the ORACLE_HOME on a database or middleware server.

§ The location of Oracle Wallets to support connecting to the database users.

§ The type of file processing which is relevant to a particular host. For example, if this is a host where database work should be done, or a host where batch compilation should be done, a host where Java applications should be deployed, etc. This allows a single database, forms and batch patch to be run against all types of hosts, applying only the relevant pieces on each server.

§ Other configuration necessary to determine proper behavior in an environment.

Retained Installation Files

The RETAIL_HOME location of an Oracle Retail product installation contains all of the files associated with that installation. This can include database scripts, Java files, Forms, Batch, RETL and Data Conversion files as with previous versions and also includes all database scripts. This allows objects to be reloaded during patching, including any necessary dependencies.

Reloading Content

In order to ensure that database contents and generated files exactly match patched versions, when applying cumulative patches some content is regenerated even if it does not appear to have changed.

On a cumulative patch this includes:

§ All re-runnable database content will be reloaded

– Packages and Procedures

– Database Types (excluding RIB objects)

– Control scripts

– Triggers

– WebService jars and packages

– Form Elements

§ All RMS and RWMS forms files will be recompiled

§ All RMS batch files will be recompiled

When applying incremental patches, only changed files will be reloaded. However this does not apply to RMS batch, which is fully recompiled with any change.

Java Hotfixes and Cumulative Patches

When applying cumulative patches to Java applications components with ORPatch, all hotfixes related to base product ear files included with the patch will be rolled back. This increases the likelihood of a successful deployment because hotfixes may not be compatible with updated product ear files, or may already be included with the ear. Before applying a cumulative patch to Java applications, check the patch documentation to determine which hotfixes are not included in the ear. Then work with Oracle Support to obtain compatible versions of the fixes for the updated ear version. In some cases this may be the same hotfix, in which case it can be re-applied to the environment. In other cases a new hotfix may be required.

Backups

Before applying a patch to an environment, it is extremely important to take a full backup of both the RETAIL_HOME file system and the Oracle Retail database. Although ORPatch makes backups of files modified during patching, any database changes cannot be reversed. If a patch fails which contains database changes, and cannot be completed, the environment must be restored from backup.

Disk Space

When patches are applied to an environment, the old version of files which are updated or deleted are backed up to $RETAIL_HOME/backups/backup-<timestamp>. When applying large patches, ensure there is sufficient disk space on the system where you unzip the patch or the patching process may fail. Up to twice as much disk space as the unzipped patch may be required during patching.

In addition to backups of source files, the existing compiled RMS or RWMS Forms and RMS Batch files are saved before recompilation. These backups may be created during patches:

§ Batch ‘lib’ directory in $RETAIL_HOME/oracle/lib/bin-<timestamp>

§ Batch ‘proc’ directory in $RETAIL_HOME/oracle/proc/bin-<timestamp>

§ Forms ‘toolset’ directory in $RETAIL_HOME/base/toolset/bin-<timestamp>

§ Forms ‘forms’ directory in $RETAIL_HOME/base/forms/bin-<timestamp>

Periodically both types of backup files can be removed to preserve disk space.

Patching Operations

Running ORPatch

ORPatch is used to apply patches to an Oracle Retail product installation. When applying a patch which includes an installer, ORPatch does not need to be executed manually as the installer will run it automatically as part of the installation process. When applying a patch that does not include an installer, ORPatch is run directly.

ORPatch performs the tasks necessary to apply the patch:

§ Inspects the patch metadata to determine the patch contents and patch type.

§ Reads the environment configuration file to determine which product components exist in this installation.

§ Assembles a list of patch actions which will be run on this host to process the patch.

§ Executes pre-checks to validate that all patch actions have the necessary configuration to proceed.

§ Compares version numbers of files from the patch against the files in the environment.

§ Backs up files which will be updated.

§ Copies updated files into the installation.

§ Loads updated files into database schemas, if applicable.

§ Recompiles RMS batch, if applicable.

§ Recompiles RMS forms, if applicable.

§ Constructs updated Java archives and deploys them to WebLogic, if applicable

§ Updates Java batch files and libraries, if applicable

§ Records the patch in the patch inventory.

If a patch does not contain updated files for the database or system, no action may be taken. If a previously failed ORPatch session is discovered, it will be restarted.

Preparing for Patching

Before applying a patch to your system, it is important to properly prepare the environment.

Single Patching Session

It is extremely important that only a single ORPatch session is active against a product installation at a time. If multiple patches need to be applied, you can optionally merge them into a single patch and apply one patch to the environment. Never apply multiple patches at the same time.

Shutdown Applications

If a patch updates database objects, it is important that all applications are shutdown to ensure no database objects are locked or in use. This is especially important when applying changes to Oracle Retail Integration Bus (RIB) objects as types in use will not be correctly replaced, leading to “ORA-21700: object does not exist or marked for delete” errors when restarting the RIB.

Backup Environment

Before applying a patch to an environment, it is important to take a full backup of both the RETAIL_HOME file system and the retail database. Although ORPatch makes backups of files modified during patching, any database changes cannot be reversed. If a patch which contains database changes fails and cannot be completed, the environment must be restored from backup.

Log Files

When applying a patch, ORPatch will create a number of log files which contain important information about the actions taken during a patch and may contain more information in the event of problems. Log files are created in the $RETAIL_HOME/orpatch/logs directory. Logs should always be reviewed after a patch is applied.

After a patch session the log directory will contain at a minimum an ORPatch log file and may also contain other logs depending on the actions taken. The following table describes logs that may exist.

Log File	Used For
orpatch-<date>-<time>.log	Primary ORPatch log file
detail_logs/dbsql_<component>/invalids/*	Details on the errors causing a database object to be invalid
detail_logs/analyze/details	Detail logs of files that will be created/updated/removed when a patch is applied
detail_logs/compare/details	Detail logs of the differences between two sets of environment metadata
orpatch_forms_<pid>_child_<num>.log	Temporary logs from a child process spawned to compile forms in parallel. After the child process completes, the contents are append to the primary orpatch log file
detail_logs/forms/rms_frm_toolset/*	Detail logs of the compilation of each RMS Toolset file
detail_logs/forms/rms_frm_forms/*	Detail logs of the compilation of each RMS Forms file
detail_logs/rmsbatch/lib/*	Detail logs of the compilation of RMS Batch libraries
detail_logs/rmsbatch/proc/*	Detail logs of the compilation of RMS Batch programs
detail_logs/dbsql_rms/rms_db_ws_consumer_jars/*	Detail logs of the loadjava command to install RMS WebService Consumer objects
detail_logs/dbsql_rms/rms_db_ws_consumer_libs/*	Detail logs of the loadjava command to install RMS WebService Consumer libraries
detail_logs/forms/rwms_frm_forms/*	Detail logs of the compilation of each RWMS Forms file
detail_logs/dbsql_rwms/rwms_db_sp _jars/*	Detail logs of the loadjava command to install RWMS SP jars
detail_logs/javaapp_<product>/deploy/*	Detail logs of the deploy of a Java product

Unzip Patch Files

Before executing ORPatch, the patch files must be unzipped into a directory. This directory will be passed to ORPatch as the “-s <source directory>” argument on the command-line when applying or analyzing a patch.

Location of ORPatch

The ORPatch script will be located in $RETAIL_HOME/orpatch/bin.

Command Line Arguments

ORPatch behavior is controlled by several command-line arguments. These arguments may be actions or options. Command and option names can be specified in upper or lower case, and will be converted to upper-case automatically. Arguments to options, for example the source directory patch, will not be modified.

ORPatch command-line actions:

Action	Description
apply	Tells ORPatch to apply a patch, requires the –s option Example: orpatch apply -s $RETAIL_HOME/stage/patch123456
analyze	Tells ORPatch to analyze a patch, requires the –s option Example: orpatch analyze -s $RETAIL_HOME/stage/patch123456
lsinventory	Tells ORPatch to list the inventory of patches that have been applied to this installation
exportmetadata	Tells ORPatch to extract all metadata information from the environment and create a $RETAIL_HOME/support directory to contain it. Requires the –expname option.
diffmetadata	Tells ORPatch to compare all metadata from the current environment with metadata exported from some other environment. Requires the –expname and –srcname options.
revert	Tells ORPatch to revert the files related to a patch, requires the –s option Example: orpatch revert –s $RETAIL_HOME/backups/backup-09302013-153010

Note: An action is required and only one action can be specified at a time.

ORPatch command-line arguments:

Argument	Valid For Actions	Description
-s <source dir>	apply analyze	Specifies where to find the top-level directory of the patch to apply or analyze. The source directory should contain the manifest.csv and patch_info.cfg files.
-new	apply	Forces ORPatch to not attempt to restart a failed ORPatch session
-expname	exportmetadata diffmetadata lsinventory	Defines the top-level name to be used for the export or comparison of environment metadata. When used with lsinventory, it allows an exported inventory to be printed.
-srcname	diffmetadata	Defines the ‘name’ to use when referring to the current environment during metadata comparisons.
-dbmodules	diffmetadata	When comparing metadata at a module-level, compare the dbmanifest information rather than the environment manifest. This method of comparing metadata is less accurate as it does not include non-database files.
-jarmodules	analyze diffmetadata	When used with analyze, requests a full comparison of the metadata of Java archives included in the patch versus the metadata of the Java archives in the environment. This behavior is automatically enabled when Java customizations are detected in the environment. Analyzing the contents of Java archives allows for detailed investigation of the potential impacts of installing a new Java ear to an environment with customizations. When used with diffmetadata, causes metadata to be compared using jarmanifest information rather than the environment manifest. This provides more detailed information on the exact differences of the content of Java archives, but does not include non-Java files.
-selfonly	apply analyze	Only apply or analyze changes in a patch that relate to orpatch itself. This is useful for applying updates to orpatch without applying the entire patch to an environment.
-s <backup dir>	revert	Specifies the backup from a patch that should be reverted to the environment. This restores only the files modified during the patch, the database must be restored separately or the environment will be out-of-sync and likely unusable.

Analyzing the Impact of a Patch

In some cases, it may be desirable to see a list of the files that will be updated by a patch, particularly if files in the environment have been customized. ORPatch has an ‘analyze’ mode that will evaluate all files in the patch against the environment and report on the files that will be updated based on the patch.

To run ORPatch in analyze mode, include ‘analyze’ on the command line. It performs the following actions:

§ Identifies files in the environment which the patch would remove.

§ Compares version numbers of files in the patch to version numbers of files in the environment.

§ Prints a summary of the number of files which would be created, updated or removed.

§ Prints an additional list of any files that would be updated which are registered as being customized.

§ Prints an additional list of any files which are in the environment and newer than the files included in the patch. These files are considered possible conflicts as the modules in the patch may not be compatible with the newer versions already installed. If you choose to apply the patch the newer versions of modules in the environment will NOT be overwritten.

§ If a Java custom file tree is detected, prints a detailed analysis of the modules within Java ear files that differ from the current ear file on the system.

§ Saves details of the files that will be impacted in $RETAIL_HOME/orpatch/logs/detail_logs/analyze/details.

This list of files can then be used to assess the impact of a patch on your environment.

To analyze a patch, perform the following steps:

1. Log in as the UNIX user that owns the product installation.

2. Set the RETAIL_HOME environment variable to the top-level directory of your product installation.

export RETAIL_HOME=/u00/oretail/14.1/tst

3. Set the PATH environment variable to include the orpatch/bin directory
export PATH=$RETAIL_HOME/orpatch/bin:$PATH

4. Set the JAVA_HOME environment variable if the patch contains Java application files.

export JAVA_HOME=/u00/oretail/java_jdk

Note: If the JAVA_HOME environment variable is not specified, the value from RETAIL_HOME/orpatch/config/env_info.cfg will be used.

5. Create a staging directory to contain the patch, if it does not already exist.

mkdir –p $RETAIL_HOME/stage

6. Download the patch to the staging directory and unzip it.

7. Execute orpatch to analyze the patch.

orpatch analyze -s $RETAIL_HOME/stage/patch123456

8. Repeat the patch analysis on all servers with installations for this product environment.

9. Evaluate the list(s) of impacted files.

For more information on registering and analyzing customizations, please see the Customization section later in this document.

Applying a Patch

Once the system is prepared for patching, ORPatch can be executed to apply the patch to the environment. The patch may need to be applied to multiple systems if it updates components that are installed on distributed servers.

To apply a patch, perform the following steps:

1. Log in as the UNIX user that owns the product installation.

2. Set the RETAIL_HOME environment variable to the top-level directory of your product installation.

export RETAIL_HOME=/u00/oretail/14.1/tst

3. Set the PATH environment variable to include the orpatch/bin directory
export PATH=$RETAIL_HOME/orpatch/bin:$PATH

4. Set the DISPLAY environment variable if the patch contains Forms.

export DISPLAY=localhost:10.0

Note: If the DISPLAY environment variable is not specified, the value from RETAIL_HOME/orpatch/config/env_info.cfg will be used.

5. Set the JAVA_HOME environment variable if the patch contains Java application files.

export JAVA_HOME=/u00/oretail/java_jdk

Note: If the JAVA_HOME environment variable is not specified, the value from RETAIL_HOME/orpatch/config/env_info.cfg will be used.

6. Create a staging directory to contain the patch, if it does not already exist.

mkdir –p $RETAIL_HOME/stage

7. Download the patch to the staging directory and unzip it.

8. Review the README.txt included with the patch. If manual steps are specified in the patch, execute those steps at the appropriate time.

9. Shutdown applications.

10. Execute ORPatch to apply the patch.

orpatch apply -s $RETAIL_HOME/stage/patch123456

11. After ORPatch completes, review the log files in $RETAIL_HOME/orpatch/logs.

12. Repeat the patch application on all servers with installations for this product environment.

13. Restart applications.

Restarting ORPatch

If ORPatch is interrupted while applying a patch, or exits with an error, it saves a record of completed work in a restart state file in $RETAIL_HOME/orpatch/logs. Investigate and resolve the problem that caused the failure, then restart ORPatch.

By default when ORPatch is started again, it will restart the patch process close to where it left off. If the patch process should not be restarted, add ‘-new’ to the command-line of ORPatch.

Please note that starting a new patch session without completing the prior patch may have serious impacts that result in a patch not being applied correctly. For example, if a patch contains database updates and batch file changes and ORPatch is aborted during the load of database objects, abandoning the patch session will leave batch without the latest changes compiled in the installation.

Listing the Patch Inventory

After a patch is successfully applied by ORPatch the patch inventory in $RETAIL_HOME/orpatch/inventory is updated with a record that the patch was applied. This inventory contains a record of the patches applied, the dates they were applied, the patch type and products impacted.

To list the patch inventory, perform the following steps:

1. Log in as the UNIX user that owns the product installation.

2. Set the RETAIL_HOME environment variable to the top-level directory of your product installation.

export RETAIL_HOME=/u00/oretail/14.1/tst

3. Set the PATH environment variable to include the orpatch/bin directory

export PATH=$RETAIL_HOME/orpatch/bin:$PATH

4. Execute orpatch to list the inventory.

orpatch lsinventory

Exporting Environment Metadata

ORPatch functionality is driven based on additional metadata that is stored in the environment to define what version of files are applied to the environment, and which database scripts have been applied to database schemas. This environment metadata is used to analyze the impact of patches to environments and controls what actions are taken during a patch. The metadata is stored in several locations depending on the type of information it tracks and in some cases it may be desirable to extract the metadata for analysis outside of ORPatch. For example, Oracle Support could ask for the metadata to be uploaded to assist them in triaging an application problem.

ORPatch provides a capability to export all of the metadata in an environment into a single directory and to automatically create a zip file of that content for upload or transfer to another system. The exact metadata collected from the environment depends on the products installed in the RETAIL_HOME.

ORPatch metadata exported:

Installed Product Component	Exported Metadata	Description
Any	orpatch/config/env_info.cfg orpatch/config/custom_hooks.cfg ORPatch inventory files	ORPatch configuration and settings
Any	All env_manifest.csv and deleted_env_manifest.csv files	Environment manifest files detailing product files installed, versions, customized flags and which patch provided the file
Database Schemas	DBMANIFEST table contents	Database manifest information detailing which database scripts were run, what version and when they were executed
Java Applications	All files from javaapp_<product>/config except jar files	Environment-specific product configuration files generated during installation
Java Applications	Combined export of all META-INF/env_manifest.csv files from all product ear files	Jar manifest information detailing files, versions, customized flags and which patch provided the file
Java Applications	orpatch/config/javaapp_<product>/ant.deploy.properties	Environment properties file created during product installation and used during application deployment
Java Applications	<weblogic_home>/server/lib/weblogic.policy	WebLogic server java security manager policy file
RMS Batch	orpatch/config/rmsbatch_profile	Batch compilation shell profile
RMS Forms	orpatch/config/rmsforms_profile	Forms compilation shell profile
RWMS Forms	orpatch/cofngi/rwsmforms_profile	Forms compilation shell profile

Exports of environment metadata are always done to the $RETAIL_HOME/support directory. When exporting metadata, you must specify the –expname argument and define the name that should be given to the export. The name is used for the directory within $RETAIL_HOME/support and for the name of the zip file.

To extract an environment’s metadata, perform the following steps:

1. Log in as the UNIX user that owns the product installation.

2. Set the RETAIL_HOME environment variable to the top-level directory of your product installation.

export RETAIL_HOME=/u00/oretail/14.1/tst

3. Set the PATH environment variable to include the orpatch/bin directory
export PATH=$RETAIL_HOME/orpatch/bin:$PATH

4. Execute orpatch to export the metadata.

orpatch exportmetadata –expname test_env

This example would export all metadata from the environment to the $RETAIL_HOME/support/test_env directory. A zip file of the metadata would be created in $RETAIL_HOME/support/test_env.zip.

Note: The $RETAIL_HOME/support/<name> directory should be empty or not exist prior to running exportmetadata in order to ensure accurate results.

Comparing Environment Metadata

Once metadata has been exported from an environment, it can be used to compare the environment manifest metadata of two environments. ORPatch provides a capability to compare metadata of the current environment with the exported metadata of another environment. Note that even though there are many types of metadata exported by ORPatch, only environment manifest metadata is evaluated during comparisons. Metadata comparison happens in four phases: product comparison, patch comparison, ORPatch action comparison, and module-level comparison.

Product comparison compares the products installed in one environment with the products installed in another environment. Patch comparison compares the patches applied in one environment with the patches applied in another environment, for common products. This provides the most summarized view of how environments differ. Patches which only apply to products on one environment are not included in the comparison.

Since each patch may impact many files, the comparison then moves on to more detailed analysis. The third phase of comparison is to compare the enabled ORPatch actions between environments. These actions roughly correspond to the installed ‘components’ of a product. For example, one environment may have database and forms components installed while another has only forms. Action comparison identifies components that are different between environments. The final phase of comparison is at the module level for actions that are common between environments. Modules which exist only on one environment, or exist on both environments with different revisions, or which are flagged as customized are reported during the comparison.

Differences between environment metadata are reported in a summarized fashion during the ORPatch execution. Details of the comparison results are saved in $RETAIL_HOME/orpatch/logs/detail_logs/compare/details. One CSV file is created for each phase of comparison: product_details.csv, patch_details.csv, action_details.csv and module_details.csv.

In order to be compared by ORPatch, exported metadata must be placed in the $RETAIL_HOME/support directory. The metadata should exist in the same structure that it was originally exported in. For example, if the metadata was exported to $RETAIL_HOME/support/test_env on another system, it should be placed in $RETAIL_HOME/support/test_env on this system.

When reporting differences between two environments, ORPatch uses names to refer to the environments. These names are defined as part of the diffmetadata command. The
–expname parameter, which defines the directory containing the metadata, is also used as the name when referring to the exported metadata. The –srcname parameter defines the name to use when referring to the current environment. As an example, if you had exported the ‘test’ environment’s metadata and copied it to the ‘dev’ environment’s $RETAIL_HOME/support/test_env directory, you could run “orpatch diffmetadata -expname test_env -srcname dev_env”. The detail and summary output would then refer to things that exist on dev but not test, revisions in the test environment versus revisions in the dev environment, etc.

ORPatch will automatically export the environment’s current metadata to $RETAIL_HOME/support/compare prior to starting the metadata comparison.

To compare two environment’s metadata, perform the following steps:

1. Export the metadata from another environment using orpatch exportmetadata.

2. Transfer the metadata zip from the other system to $RETAIL_HOME/support.

3. Log in as the UNIX user that owns the product installation.

4. Set the RETAIL_HOME environment variable to the top-level directory of your product installation.

export RETAIL_HOME=/u00/oretail/14.1/dev

5. Set the PATH environment variable to include the orpatch/bin directory
export PATH=$RETAIL_HOME/orpatch/bin:$PATH

6. Unzip the metadata zip file.

unzip test_env.zip

7. Execute orpatch to compare the metadata

orpatch diffmetadata –expname test_env –srcname dev_env

This example would compare the current environment against the metadata extracted in $RETAIL_HOME/support/test_env directory.

Note: The $RETAIL_HOME/support/compare directory will be automatically removed before environment metadata is exported at the start of the comparison.

Reverting a Patch

In general it is best to either completely apply a patch, or restore the entire environment from the backup taken before starting the patch. It is important to test patches in test or staging environments before applying to production. In the event of problems, Oracle Retail recommends restoring the environment from backup if a patch is not successful.

Note: Reverting patches in an integrated environment can be extremely complex and there is no fully automated way to revert all changes made by a patch. Restoring the environment from a backup is the recommended method to remove patches.

It is, however, possible to revert small patches using the backups taken by ORPatch during a patch. This will restore only the files modified, and it is still necessary to restore the database if any changes were made to it.

Note: Reverting a patch reverts only the files modified by the patch, and does not modify the database, or recompile forms or batch files after the change.

When multiple patches have been applied to an environment, reverting any patches other than the most recently applied patch is strongly discouraged as this will lead to incompatible or inconsistent versions of modules applied to the environment. If multiple patches are going to be applied sequentially it is recommended to first merge the patches into a single patch that can be applied or reverted in a single operation.

To revert a patch, perform the following steps:

1. Log in as the UNIX user that owns the product installation.

2. Set the RETAIL_HOME environment variable to the top-level directory of your product installation.

export RETAIL_HOME=/u00/oretail/14.1/tst

3. Set the PATH environment variable to include the orpatch/bin directory
export PATH=$RETAIL_HOME/orpatch/bin:$PATH

4. Identify the backup directory in $RETAIL_HOME/backups that contains the backup from the patch you want to restore.

§ The backup directory will contain a patch_info.cfg file which contains the name of the patch the backup is from.

§ It is possible to have two directories for the same patch, if ORPatch was updated during the patch. It is not possible to revert the updates to ORPatch. Select the backup directory that does not contain orpatch files.

§ If it is not clear which backup directory to use, restore the environment from backup

5. Execute orpatch to revert the environment using the contents of the backup directory

orpatch revert –s $RETAIL_HOME/backups/backup-11232013-152059

6. Restore the database from backup if the patch made database changes

7. Use the orcompile script to recompile forms if the patch included RMS or RWMS forms files

orcompile –a RMS –t FORMS

orcompile –a RWMS –t FORMS

8. Use the orcompile script to recompile batch if the patch included RMS batch files

orcompile –a RMS –t BATCH

9. Use the ordeploy script to redeploy the appropriate Java applications if the patch included Java files

ordeploy –a RPM –t JAVA

ordeploy –a REIM –t JAVA

ordeploy –a ALLOC –t JAVA

ordeploy –a RESA –t JAVA

Merging Patches

When patches are applied individually some ORPatch tasks such as compiling forms and batch files or deploying Java archives are performed separately for each patch. This can be time-consuming. An alternative is to use the ORMerge utility to combine several patches into a single patch, reducing application downtime by eliminating tasks that would otherwise be performed multiple times. Patches merged with ORMerge are applied with ORPatch after the merge patch is created.

Source and Destination Directories

ORMerge uses source and destination areas in order to merge patch files. The source area is a single directory that contains the extracted patches to merge. The destination area is the location where the merged patch will be created. If a file exists in one or more source patches, only the highest revision will be copied to the merged patch.

The source and destination directories should exist under the same parent directory. That is, both the source and destination directories should be subdirectories of a single top-level directory.

The source directory must have all patches to be merged as immediate child directories. For example if three patches need to be merged the directory structure would look like this:

Source and Destination Directory Example

ormerge_diagram

In the example above, the manifest.csv and patch_info.cfg files for each patch to be merged must exist in source/patch1, source/patch2, and source/patch3.

ORMerge Command-line Arguments

Argument	Required	Description
-s	Yes	Path to source directory containing patches to merge
-d	Yes	Path to destination directory that will contain merged patch
-name	No	The name to give the merged patch. If not specified, a name will be generated. When the merged patch is applied to a system, this name will appear in the Oracle Retail patch inventory.
-inplace	No	Used only when applying a patch to installation files prior to the first installation. See “Patching prior to the first install” in the Troubleshooting section later, for more information.

Running the ORMerge Utility

To merge patches, perform the following steps:

1. Log in as the UNIX user that owns the product installation.

2. Set the RETAIL_HOME environment variable to the top-level directory of your product installation.

export RETAIL_HOME=/u00/oretail/14.1/tst

3. Set the PATH environment variable to include the orpatch/bin directory
export PATH=$RETAIL_HOME/orpatch/bin:$PATH

4. Create a staging directory to contain the patches.

mkdir –p $RETAIL_HOME/stage/merge/src

5. Download the patches to the staging directory and unzip them so that each patch is in a separate subdirectory.

6. Review the README.txt included with each patch to identify additional manual steps that may be required. If manual steps are specified in any patch, execute them at the appropriate time when applying the merged patch.

7. Create a destination directory to contain the merged patches.

mkdir -p $RETAIL_HOME/stage/merge/dest

8. Execute ORMerge to merge the patches.

ormerge -s $RETAIL_HOME/stage/merge/src –d $RETAIL_HOME/stage/merge/dest –name merged_patch

The merged patch can now be applied as a single patch to the product installation using ORPatch.

Compiling Application Components

In some cases it may be desirable to recompile RMS Forms, RWMS Forms or RMS Batch outside of a product patch. The ORCompile utility is designed to make this easy and remove the need to manually execute ‘make’ or ‘frmcmp’ commands which can be error-prone. ORCompile leverages ORPatch functions to ensure that it compiles forms and batch exactly the same way as ORPatch. In addition ORCompile offers an option to compile invalid database objects using ORPatch logic.

ORCompile takes two required command line arguments each of which take an option. Arguments and options can be specified in upper or lower case.

ORCompile Command Line Arguments

Argument	Description
-a <app>	The application to compile.
-t <type>	The type of application objects to compile

ORCompile Argument Options

Application	Type	Description
RMS	BATCH	Compile RMS Batch programs
RMS	FORMS	Compile RMS Forms
RWMS	FORMS	Compile RWMS Forms
RMS	DB	Compile invalid database objects in the primary RMS schema
RMS	DB-ASYNC	Compile invalid database objects in the RMS_ASYNC_USER schema
ALLOC	DB-ALC	Compile invalid database objects in the Allocations user schema
ALLOC	DB-RMS	Compile invalid database objects in the RMS schema
REIM	DB	Compile invalid database objects in the RMS schema
RME	DB	Compile invalid database objects in the RME schema
ASO	DB	Compile invalid database objects in the ASO schema
RA	DB-DM	Compile invalid database objects in the RA DM schema
RA	DB-RABATCH	Compile invalid database objects in the RA batch schema
RA	DB-RMSBATCH	Compile invalid database objects in the RA RMS batch schema
RA	DB-FEDM	Compile invalid database objects in the RA front-end schema

Note: Compiling RMS type DB, ReIM type DB, and Allocation type DB-RMS, are all identical as they attempt to compile all invalid objects residing in the RMS schema.

Running the ORCompile utility

To compile files, perform the following steps:

1. Log in as the UNIX user that owns the product installation.

2. Set the RETAIL_HOME environment variable to the top-level directory of your product installation.

export RETAIL_HOME=/u00/oretail/14.1/tst

3. Set the PATH environment variable to include the orpatch/bin directory
export PATH=$RETAIL_HOME/orpatch/bin:$PATH

4. Execute orcompile to compile the desired type of files.

orcompile –a <app> -t <type>

ORCompile Examples

Compile RMS Batch.

orcompile -a RMS -t BATCH

Compile RWMS Forms.

orcompile -a RWMS -t FORMS

Compile invalid objects in the RA DM schema.

orcompile -a RA -t DB-DM

Compile invalid objects in the RMS owning schema.

orcompile -a RMS -t DB

Deploying Application Components

In some cases it may be desirable to redeploy Java applications outside of a product patch. For example, when troubleshooting a problem, or verifying the operation of the application with different WebLogic settings. Another situation might include wanting to deploy the application using the same settings, but without customizations to isolate behavior that could be related to customized functionality.

The ordeploy utility is designed to make this easy and remove the need to re-execute the entire product installer when no configuration needs to change. ORDeploy leverages Oracle Retail Patch Assistant functions to ensure that it deploys applications exactly the same way as ORPatch. In addition ORDeploy offers an option to include or not include custom Java files, to ease troubleshooting.

ORDeploy takes two required command line arguments each of which take an option. Arguments and options can be specified in upper or lower case.

ORDeploy Command Line Arguments

Argument	Description
-a <app>	The application to deploy.
-t <type>	The type of application objects to deploy

ORDeploy Argument Options

Application	Type	Description
ALLOC	JAVA	Deploy the Allocations Java application and Java batch files, including any custom Java files.
ALLOC	JAVANOCUSTOM	Deploy the Allocations Java application and Java batch files, NOT including any custom Java files.
REIM	JAVA	Deploy the REIM Java application and Java batch files, including any custom Java files.
REIM	JAVANOCUSTOM	Deploy the REIM Java application and Java batch files, NOT including any custom Java files.
RESA	JAVA	Deploy the RESA Java application, including any custom Java files.
RESA	JAVANOCUSTOM	Deploy the RESA Java application, NOT including any custom Java files.
RPM	JAVA	Deploy the RPM Java application and Java batch files, including any custom Java files.
RPM	JAVANOCUSTOM	Deploy the RPM Java application and Java batch files, NOT including any custom Java files.

Running the ORDeploy utility

To deploy Java applications, perform the following steps:

1. Log in as the UNIX user that owns the product installation.

2. Set the RETAIL_HOME environment variable to the top-level directory of your product installation.

export RETAIL_HOME=/u00/oretail/14.1/tst

3. Set the PATH environment variable to include the orpatch/bin directory
export PATH=$RETAIL_HOME/orpatch/bin:$PATH

4. Execute ORDeploy to deploy the desired Java application.

ordeploy –a <app> -t <type>

ORDeploy Examples

Deploy RPM.

ordeploy -a RPM -t JAVA

Deploy ReIM without including Java customizations.

ordeploy -a REIM -t JAVANOCUSTOM

Maintenance Considerations

The additional information stored within the RETAIL_HOME and within database schemas adds some considerations when performing maintenance on your environment.

Database Password Changes

Oracle wallets are used to protect the password credentials for connecting to database schemas. This includes all database schemas used during an install. If the password for any of these users is changed the wallet’s entry must be updated.

The wallet location is configurable but by default is in the following locations:

Location	Installation Type
$RETAIL_HOME/orpatch/rms_wallet	RMS Database RMS Batch
$RETAIL_HOME/orpatch/rms_wallet_app	RMS Forms
$RETAIL_HOME/orpatch/rwms_wallet	RWMS Database
$RETAIL_HOME/orpatch/rwms_wallet_app	RWMS Forms
$RETAIL_HOME/orpatch/oraso_wallet	ASO Database
$RETAIL_HOME/orpatch/orme_wallet	RME Database
$RETAIL_HOME/orpatch/ra_wallet	RA Database

The wallet alias for each schema will be <username>_<dbname>. Standard mkstore commands can be used to update the password.

For example:

mkstore -wrl $RETAIL_HOME/orpatch/rms_wallet –modifyCredential rms_rmsdb rms01 rmspassword

This command will update the password for the RMS01 user to ‘rmspassword’ in the alias ‘rms_rmsdb’.

The Oracle wallets are required to be present when executing ORPatch. Removing them will prevent you from being able to run ORPatch successfully. In addition the Oracle wallet location is referenced in the RMS batch.profile, and in the default RMS and RWMS Forms URL configuration, so removing them will require reconfiguration of batch and forms. If batch and forms were reconfigured after installation to use other wallet files, it is possible to backup and remove the wallets, then restore them when running ORPatch.

WebLogic Password Changes

Java wallets are used to protect the password credentials used when deploying Java products. This includes the WebLogic administrator credentials, LDAP connection credentials, batch user credentials and any other credentials used during an install. If the password for any of these users is changed the wallet’s entry must be updated, or the Java product installation can be run again.

The wallet location is in the following locations:

Location	Installation Type
$RETAIL_HOME/orpatch/config/javapp_rpm	RPM Java
$RETAIL_HOME/orpatch/config/javapp_reim	ReIM Java
$RETAIL_HOME/orpatch/config/javapp_alloc	Allocation Java
$RETAIL_HOME/orpatch/config/javapp_resa	RESA Java
$RETAIL_HOME/orpatch/config/javaapp_rasrm	RASRM Java

The wallet aliases will be stored in the retail_installer partition. The names of the aliases will vary depending on what was entered during initial product installation.

The dump_credentials.sh script can be used to list the aliases in the wallet.

For example:

cd $RETAIL_HOME/orpatch/deploy/retail-public-security-api/bin

./dump_credentials.sh $RETAIL_HOME/orpatch/config/javapp_alloc

Apapplication level key partition name:retail_installer

User Name Alias:dsallocAlias User Name:rms01app

User Name Alias:BATCH-ALIAS User Name:SYSTEM_ADMINISTRATOR

User Name Alias:wlsAlias User Name:weblogic

The easiest way to update the credential information is to re-run the Java product installer. If you need to manually update the password for a credential, the save_credential.sh script can be used.

For example:

cd $RETAIL_HOME/orpatch/deploy/retail-public-security-api/bin

./save_credential.sh –l $RETAIL_HOME/orpatch/config/javapp_alloc –p retail_installer –a wlsAlias –u weblogic

This command will prompt for the new password twice and update the aslias wlsAlias, username weblogic with the new password.

Infrastructure Directory Changes

The RETAIL_HOME/orpatch/config/env_info.cfg file contains the path to the database ORACLE_HOME on database or RMS Batch installations, to the WebLogic Forms and Reports ORACLE_HOME and ORACLE_INSTANCE on RMS or RWMS Forms installations, and to the WEBLOGIC_DOMAIN_HOME, WL_HOME and MW_HOME on Java product installations. If these paths change, the related configuration variables in the env_info.cfg file must be updated.

DBManifest Table

The table dbmanifest within Oracle Retail database schemas is used to track the database scripts which have been applied to the schema. It is critical not to drop or truncate this table. Without it, ORPatch will attempt to re-run scripts against the database which have already been applied which can destroy a working environment. Similarly, if copying a schema from one database to another database, ensure that the dbmanifest table is preserved during the copy.

RETAIL_HOME relationship to Database and Application Server

The RETAIL_HOME associated with an Oracle Retail product installation is critical due to the additional metadata and historical information contained within it. If a database or application installation is moved or copied, the RETAIL_HOME related to it should be copied or moved at the same time.

Jar Signing Configuration Maintenance

The RPM product installation includes an option to configure a code signing certificate so that jar files modified during installation or patching are automatically re-signed. This configuration is optional, but recommended. If it is configured, the code signing keystore is copied during installation to $RETAIL_HOME/orpatch/config/jarsign/orpkeystore.jks. The keystore password and private key password are stored in a Java wallet in the $RETAIL_HOME/orpatch/config/jarsign directory. The credentials are stored in a wallet partition called orpatch:

Alias	Username	Description
storepass	discard	Password for the keystore
keypass	discard	Password for the private key

The keystore file and passwords can be updated using the product installer. This is the recommended way to update the signing configuration.

If only the credentials need to be updated, the sign_jar.sh script can be used.

5. Log in as the UNIX user that owns the product installation.

6. Set the RETAIL_HOME environment variable to the top-level directory of your installation.

export RETAIL_HOME=/u00/oretail/14.1/tst

7. Change directories to the location of sign_jar.sh
cd $RETAIL_HOME/orpatch/deploy/bin

8. Execute sign_jar.sh

sign_jar.sh changepwd

9. When prompted, enter the new keystore password

10. When prompted, enter the new private key password

Customization

Patching Considerations with Customized Files and Objects

In general, the additional capabilities provided by the ORPatch should make it easier to evaluate the potential impacts of patches to your customizations of Oracle Retail products. However, the additional metadata maintained by the Oracle Retail patching utilities does add some considerations when making customizations.

General Guidelines

It is always preferred to customize applications by extension rather than by direct modification. For example, adding new database objects and forms rather than modifying existing Oracle Retail objects and forms. You can also leverage built-in extension points such as User Defined Attributes, the Custom Flexible Attribute Solution, or seeded customization points in ADF Applications.

It is strongly discouraged to directly modify Oracle Retail database objects, especially tables, as your changes may be lost during patching or may conflict with future updates. When adding or modifying database objects, Oracle Retail recommends that all objects be added with scripts to ensure that they can be rebuilt if necessary after a patch.

Custom Database Objects

When you create new database objects, Oracle Retail recommends placing them in an Oracle database schema specifically for your customizations. You must use synonyms and grants to allow the Oracle Retail product schema owner and other users to access your objects, and use synonyms and grants to allow your customizations to access Oracle Retail objects. A separate schema will ensure that your customizations are segregated from base Oracle Retail code.

ORPatch expects that there will be no invalid objects in the database schemas it manages after a patch is applied. For this reason adding extra objects to the product schema could result in failures to apply patches as changes to base objects may cause custom objects to go invalid until they are updated. In this situation, manually update the custom objects so that they compile, and restart the patch.

Custom Forms

When creating new custom forms, Oracle Retail recommends placing them in a separate directory specifically for your customizations. This directory should be added to the FORMS_PATH of your RMS or RWMS Forms URL configuration to allow the forms to be found by the Forms Server. This will ensure that your customizations are segregated from base Oracle Retail code. If you choose to place customizations in the Forms bin directory, then your custom forms will need to be recopied each time Forms are fully recompiled.

ADF Application Customization

Oracle Retail ADF-based applications such as Allocation and ReSA can be customized using a process called ‘seeded customization’. The customization process involves using JDeveloper in Customizer mode to create changes to product configurations, and then building a MAR archive containing the changes. The generated MAR is deployed to the MDS repository used by the application and applied to the application at runtime. These types of customizations are handled outside of ORPatch and are not reported during patch analysis or tracked by the custom file registration utility. More information can be found in the respective product customization guides.

Custom Compiled Java Code

When customizing Oracle Retail Java-based products such as RPM and ReIM via product source code, ORPatch supports automatically adding compiled customizations into the application ear file prior to deployment. This allows customizations to be applied to the application without directly modifying the base product ear, enabling customizations and defect hotfixes to co-exist when they do not change the same file or a dependent file. See the later “Custom Compiled Java Code” section for additional information and considerations.

Analyze Patches when Customizations are Present

Whenever you have customized a product by directly modifying Oracle Retail files or database objects, it is important to ensure you analyze each the files that will be updated by a patch before applying the patch. This will allow you to identify any customized files which may be overwritten by the patch and either merge your customization with the new version of the file, or re-apply the customization after applying the patch.

Manifest Updates

If you choose to customize Oracle Retail files directly, it is extremely important not to update the revision number contained in the env_manifest.csv. This could cause future updates to the file to be skipped, invalidating later patch applications as only a partial patch would be applied. The customized revision number for modified files will need to be tracked separately.

Registering Customized Files

The ORPatch contains utilities and functionality to allow tracking of files that have been customized through direct modification. This process is referred to as ‘registering’ a customized file. Registration only works for files which are shipped by Oracle Retail. It is not possible to register new files created in the environment as part of extensions or customizations.

When patches are analyzed with ORPatch, special reporting is provided if any registered files would be updated or deleted by the patch. Customized files impacted by the patch are listed at the end of the analysis report from ORPatch. The detail files generated during the analyze will contain a column called ‘customized’ which will have a Y for any files which were registered as customized. This allows easier identification of customizations which will be overwritten by a patch.

All files delivered by Oracle Retail are considered ‘base’ and so when they are applied to an environment any registrations of those files as customized will revert back to un-customized. Each time a patch overwrites customized files, you must re-register the files as customized once you have applied customizations.

To register customized files, use the $RETAIL_HOME/orpatch/bin/orcustomreg script.

The orcustomerg script operates in one of two modes: registration and list.

§ Registration mode registers or unregisters one or more files as customized.

§ List mode lists all files in the environment that are registered as customized.

Command Line Arguments for Registration Mode

Argument	Description
-f <file>	Adds <file> to the list of files that will be registered. Can be specified more than once.
-bulk <file>	Specifies a file to read, containing one filename per line. All filenames listed inside <file> will be registered.
-register	Files specified with -f or -bulk will be registered as ‘customized’
-unregister	Files specified with -f or -bulk will be registered as ‘base’

Notes:

§ At least one of -f or -bulk is required.

§ If neither -register nor -unregister is specified, the default is ‘-register’.

§ File names specified with -f must either be fully-qualified or be relative to RETAIL_HOME. The same is true for filenames specified within a -bulk file.

Command Line arguments for list mode

Argument	Description
-list	List all files in the environment registered as customized

Running the orcustomreg Script

Perform the following procedure to run the orcustomreg script:

1. Log in as the UNIX user that owns the product installation.

2. Set the RETAIL_HOME environment variable to the top-level directory of your product installation.

export RETAIL_HOME=/u00/oretail/14.1/tst

3. Set the PATH environment variable to include the orpatch/bin directory
export PATH=$RETAIL_HOME/orpatch/bin:$PATH

4. Execute orcustomreg script to register the desired file(s).

orcustomreg –register –f <file>

Examples of using the orcustomreg Script

orcustomreg -f dbsql_rms/Cross_Pillar/control_scripts/source/oga.sql

Unregister customizations for $RETAIL_HOME/dbsql_rwms/Triggers/Source/TR_WAVE.trg

orcustomreg –unregister –f $RETAIL_HOME/dbsql_rwms/Triggers/Source/TR_WAVE.trg

Bulk register several files as customized.

echo “$RETAIL_HOME/oracle/proc/src/mrt.pc” > custom.txt

echo “$RETAIL_HOME/oracle/proc/src/saldly.pc” >> custom.txt

echo “$RETAIL_HOME/oracle/proc/src/ccprg.pc” >> custom.txt

orcustomreg –bulk custom.txt

List all files registered as customized.

orcustomreg –list

Custom Compiled Java Code

This functionality is enabled by creating a directory called $RETAIL_HOME/javaapp_<app>/custom, where <app> is the application the customizations apply to. Files stored within this directory will be combined with the base product ear files before the application is deployed to WebLogic. ORPatch will attempt to consider customizations stored within the ‘custom’ directory during patch analysis by triggering more detailed ear file change analysis to assist with identifying which customizations might be impacted by changes in the patches.

Note: It is not possible, nor necessary, to register compiled Java customizations with the orcustomreg tool.

As with other customization techniques for other technologies, Oracle Retail recommends making Java customizations in new files as much as possible, versus overwriting base product or configuration files. In the past it was necessary to build complete replacement product ear files, but this method of customization is no longer required nor recommended. Replacement ear and jar files will not contain the META-INF/env_manifest.csv files which are required in order to be able to apply incremental patches. Instead, compile the specific Java classes being customized and place them along with any custom configuration files in $RETAIL_HOME/javaapp_<app>/custom.

Building Deployable ear files

When constructing the product ear file to deploy to WebLogic, ORPatch applies changes to the ear file in a specific order, with files from later steps overwriting files in earlier steps. The resulting ear is stored in $RETAIL_HOME/javaapp_<app>/deploy, and then deployed to WebLogic.

Sequence for ORPatch Java Product ear file updates

Order	File Type	Location
1	Base product ear	$RETAIL_HOME/javaapp_<app>/base
2	Updated configuration files	$RETAIL_HOME/javaapp_<app>/config
3	Oracle Retail-supplied hotfixes	$RETAIL_HOME/javaapp_<app>/internal
4	Compiled customizations	$RETAIL_HOME/javaapp_<app>/custom

Merging Custom Files

When merging files from the custom directory with the product ear, ORPatch uses the directory path of the files within custom to calculate where the file should be stored within the ear. This allows arbitrary nesting of files, even when placing files within jars stored in jars, stored within the ear. The following examples below use RPM, but apply to adding compiled customizations to any Java-based product.

Custom directory location and product ear location Examples

File path within javaapp_<app>/custom/	Final Ear File Location
rpm14.ear/company/ui/MyCustom.class	In rpm14.ear: /company/ui/MyCustom.class
rpm14.ear/rpm14.jar/company/bc/MyCustom2.class	In rpm14.ear: In rpm14.jar: /company/bc/MyCustom2.class
rpm14.ear/lib/ourcustomlibs.jar	In rpm14.ear /lib/ourcustomlibs.jar
rpm14.ear/WebLaunchServlet.war/lib/ rpm14.jar/company/bc/MyCustom2.class	In rpm14.ear: In WebLaunchServlet.war: In lib/rpm14.jar: /company/bc/MyCustom2.class

Analyzing patches when customizations are present

When analyzing a patch which contains a base product ear and the custom directory contains files, ORPatch will automatically trigger a more detailed analysis of the changes coming in a patch. This includes calculating what files inside the product ear have been added, removed or updated and which files appear to be customized based on the contents of the ‘custom’ directory. The detailed results of the ear file comparison during patch analysis will be saved in javaapp_<app>_archive_compare_details.csv. Any custom files which appeared to be impacted by the patch are saved in javapp_<app>_archive_custom_impacts.csv. Both files will be in the $RETAIL_HOME/orpatch/logs/detail_logs/analyze/details directory.

Note: This detailed analysis is not available when analyzing individual hotfixes, so special care must be taken when applying hotfixes to a customized product installation, to ensure there are no conflicts between customizations and hotfix changes.

Customizations and cumulative patches

By default, when applying a cumulative patch, ORPatch will not include customizations in the deployed product ear, even if they are present in the appropriate directory. This allows verification that the application is functioning properly using base code, before applying customizations. After verifying the initial deployment, use ORDeploy with the “-t JAVA” option to construct and deploy the product ear including customizations.

If customizations need to be removed outside of a patch, use ORDeploy with the “-t JAVANOCUSTOM” option to create and deploy an ear containing only Oracle Retail code. To force ORPatch to include customizations in the deployed ear even when applying a cumulative patch, set JAVAAPP_<app>_INCLUDE_CUSTOM=Y in the $RETAIL_HOME/orpatch/config/env_info.cfg file.

Changing configuration files

It is possible to directly change product configuration files in $RETAIL_HOME/javaapp_<app>/config. These updates can be deployed to the environment using the ORDeploy utility. However, the ‘config’ directory is completely recreated each time the product installer is used. This means that modifications will be lost and must be manually reapplied after each installer run. It is recommended to make configuration changes via the installer where possible, and retain the ant.install.properties file for use in later installer sessions.

Extending Oracle Retail Patch Assistant with Custom Hooks

The default ORPatch actions and processing logic is sufficient to install and patch the base Oracle Retail product code. However there may be situations where custom processing is desired during patching activities such as executing a shell script prior to the start of patching, or running a SQL script at the end of the patch.

ORPatch supports extensions in the form of custom hooks. These hooks allow external scripts to be run at specific points during ORPatch processing.

ORPatch Processing

Action

ORPatch supports a variety of ‘actions’ which define the steps necessary to apply updates to a particular area of the Oracle Retail application. Each action is generally specific to updates to a single technology or logical component of the environment. For example, one action might handle making updates to the RMS database schema, while a separate action is responsible for compiling RWMS forms, and a different action deploys the RPM Java application. These actions are enabled and disabled within the environment configuration file, allowing ORPatch to determine what types of changes to apply to each product installation.

ORPatch Actions

Order	Action Name	Description
1	DBSQL_RMS	Loads RMS and RPM database objects into the primary RMS schema
2	DBSQL_RMSASYNC	Loads database objects into the RMS_ASYNC_USER schema
3	DBSQL_REIM	Loads ReIM database objects into the RMS schema
4	DBSQL_RAF	Loads Retail Application Framework database objects into the RMS schema
5	DBSQL_ALCRMS	Loads Allocation database objects into the RMS schema
6	DBSQL_ALLOC	Loads Allocation database objects into the Allocation user schema
7	DBSQL_RMSDEMO	Used to create demo data in the RMS schema if demo data was selected during initial installation
8	DBSQL_RMSDAS	Loads database objects into the RMS Data Access Schema
9	RMSBATCH	Compiles RMS Batch
10	ORAFORMS_RMS	Compiles RMS Forms, copies RMS reports to $RETAIL_HOME
11	RMSRETLSCRIPTS	Copies Oracle Retail Extract and Load scripts for RMS
12	RMSDCSCRIPTS	Copies Oracle Retail Merchandising System data conversion scripts
13	DBSQL_RWMS	Loads database objects into the primary RWMS schema
14	DBSQL_RWMSADF	Loads database objects into the RWMS ADF user schema
15	DBSQL_RWMSUSER	Loads database objects into the RWMS user schema
16	ORAFORMS_RWMS	Compiles RWMS Forms, copies RWMS batch scripts and reports to $RETAIL_HOME
17	JAVAAPP_RPM	Deploys the RPM Java application and batch scripts
18	JAVAAPP_REIM	Deploys the REIM Java application and batch scripts
19	JAVAAPP_ALLOC	Deploys the Allocation Java application and batch scripts
20	JAVAAPP_RESA	Deploys the ReSA Java application
21	JAVAAPP_RASRM	Deploys the RASRM Java application
22	DBSQL_RARMSBATCH	Loads database objects into the RMS Batch schema for RA
23	DBSQL_RADM	Loads database objects into the RA Data Mart schema
24	DBSQL_RAFEDM	Loads database objects into the RA Front-end schema
25	DBSQL_RABATCH	Loads database objects into the RA Batch schema
26	DBSQL_RASECORE	Loads core database objects into the ORASE schema
27	DBSQL_RASEASO	Loads ASO database objects into the ORASE schema
28	DBSQL_RASECDT	Loads CDT database objects into the ORASE schema
29	DBSQL_RASECIS	Loads CIS database objects into the ORASE schema
30	DBSQL_RASEDT	Loads DT database objects into the ORASE schema
31	DBSQL_RASEMBA	Loads MBA database objects into the ORASE schema
32	RASECOREBATCH	Copies ORASE core batch scripts and libraries
33	RASEASOBATCH	Copies ORASE ASO batch scripts and libraries
34	RASECDTBATCH	Copies ORASE CDT batch scripts and libraries
35	RASECISBATCH	Copies ORASE CIS batch scripts and libraries
36	RASEDTBATCH	Copies ORASE DT batch scripts and libraries
37	RASEMBABATCH	Copies ORASE MBA batch scripts and libraries

Phase

ORPatch processes patches in phases. Each action relevant to a patch and host is provided an opportunity to process the patch for each phase. The standard phases which allow hooks are:

Restart Phase Number	Phase Name	Description
N/A	PRECHECK	Actions verify that their configuration appears complete and correct. This phase and the associated hooks will be run every time orpatch is executed, even if processing will be restarted in a later phase.
10	PREACTION	Actions do processing prior to when files are copied to the environment. Files are deleted during this phase.
20	COPYPATCH	Actions copy files included in a patch into the destination environment and the environment manifest is updated.
30	PATCHACTION	Actions take the more detailed steps necessary to apply the new files to the environment. For database actions in particular, this is the phase when new and updated sql files are loaded into the database.
40	POSTACTION	Actions do processing after files have been copied and PatchActions are completed. The Forms actions, for example, use this phase to compile the forms files as this must happen after database packages are loaded.
50	CLEANUP	Actions do any additional processing. Currently no actions implement activities in this phase.

Configuring Custom Hooks

Custom hooks are configured in a configuration file RETAIL_HOME/orpatch/config/custom_hooks.cfg. The configuration file is a simple text file where blank lines and lines starting with # are ignored and all other lines should define a custom hook.

To define a custom hook, a line is added to the file in the form:

The hook name must be in upper case and is in the form:

The action name is any action name understood by ORPatch. The phase name is one of the five phase names from the table above. The sequence is either ‘START’ or ‘END’. Hooks defined with a sequence of ‘START’ are run before the action’s phase is invoked. Hooks defined with a sequence of ‘END’ are run after the action’s phase is invoked.

Multiple scripts can be associated with a single hook by separating the script names with a comma. If a hook name appears in the configuration file multiple times only the last entry will be used.

The script defined as a custom hook must be an executable shell script that does not take any arguments or inputs. The only environment variable that is guaranteed to be passed to the custom hook is RETAIL_HOME. The script must return 0 on success and non-zero on failure.

If an action is a DBSQL action (i.e. has a name like DBSQL_), the custom hook can optionally be a .sql file. In this case the SQL script will be run against the database schema that the DBSQL action normally executes against. The SQL script must not generate any ORA- or SP2- errors on success. In order to be treated as a database script, the extension of the file defined as the custom hook must be .sql in lower-case. Any other extension will be treated as if it is a shell script. If you have database scripts with different extensions, they must be renamed or wrapped in a .sql script.

When using the PRECHECK phase and START sequence, please note that the custom hook will be executed prior to any verification of the configuration. Invalid configuration, such as invalid database username/password or a non-existent ORACLE_HOME, may cause the custom hook to fail depending on the actions it tries to take. However in these cases, the normal orpatch PRECHECK activities would likely have failed as well. All that is lost is the additional context that orpatch would have provided about what was incorrect about the configuration.

Restarting with Custom Hooks

If a custom hook fails, for example a shell script hook returns non-zero or a sql script generates an ORA- error in its output, the custom hook will be treated as failing. A failing custom hook causes ORPatch to immediately stop the patching session.

When ORPatch is restarted it always restarts with the same phase and action, including any START sequence custom hooks. If the START sequence custom hook fails, the action’s phase is never executed. With an END sequence custom hook, the action’s phase is re-executed when ORPatch is restarted and then the custom hook is re-executed. When an action’s phase is costly, for example the DBSQL_RMS action which does a lot of work, this can mean a lot of duplicate processing.

For this reason it is preferred to use START sequence custom hooks whenever possible. If necessary, use a START sequence hook on a later phase or a later action, rather than an END sequence custom hook.

Patch-level Custom Hooks

In addition to action-specific hooks, there are two patch-level hook points available. These hooks allow scripts to be run before any patching activities start and after all patching activities are completed. The hooks are defined in the same configuration file, with a special hook name.

To run a script before patching, define:

ORPATCH_PATCH_START=<fully qualified script>

To run a script after patching, define:

ORPATCH_PATCH_END=<fully qualified script>

These hooks only support executing shell scripts, database scripts must be wrapped in a shell script. It is also important to note that these hooks are run on every execution of ORPatch to apply a patch, even when restarting a patch application. If the START sequence patch-level hook returns a failure, patching is aborted. If the END sequence patch-level hook returns a failure, it is logged but ignored as all patching activities have already completed.

Please note that the ORPATCH_PATCH_START hook is executed prior to any verification of the configuration. Invalid configuration may cause the custom hook to fail depending on the actions it tries to take. However in these cases, the normal ORPatchactivities would likely fail as well.

Example Custom Hook Definitions

A shell script that is executed prior to the Pre-Action phase of RMS Batch:

RMSBATCH_PREACTION_START=/u00/oretail/prepare_custom_header.sh

A shell script that is executed after RETL script files are copied into the RETAIL_HOME:

RETLSCRIPTS_COPYPATCH_END=/u00/oretail/copy_custom_files.sh

A SQL script that is executed against the RWMS owning schema at the start of the Clean-up Phase:

DBSQL_RWMS_CLEANUP_START=/dba/sql/recompile_synonyms.sql

Troubleshooting Patching

There is not a general method for determining the cause of a patching failure. It is important to ensure that patches are thoroughly tested in a test or staging system several times prior to attempting to apply the patch to a production system, particularly if the patch is a large cumulative patch. After the test application is successful, apply the patch to the production system.

ORPatch Log Files

ORPatch records extensive information about the activities during a patch to the log files in RETAIL_HOME/orpatch/logs. This includes a summary of the actions that are planned for a patch, information about all files that were updated by the patch, and detailed information about subsequent processing of those files. The ORPatch log files also contain timestamps to assist in correlating log entries with other logs.

Even more detailed logs are available in RETAIL_HOME/orpatch/logs/detail_logs for some activities such as forms compilation, invalid database object errors, and output from custom hooks. If the standard ORPatch log information is not sufficient, it might be helpful to check the detailed log if it exists.

Restarting ORPatch

The restart mechanism in ORPatch is designed to be safe in nearly any situation. In some cases to ensure this, a portion of work may be redone. If the failure was caused by an intermittent issue that has been resolved, restarting ORPatch may be sufficient to allow the patch to proceed.

Manual DBManifest Updates

A possible cause for database change script failures is that a database change was already made manually to the database. In this event, you may need to update the dbmanifest table to record that a specific script does not need to be run. Before doing this, it is extremely important to ensure that all statements contained in the script have been completed.

Use the $RETAIL_HOME/orpatch/bin/ordbmreg script to register database scripts in the dbmanifest table.

Command Line Arguments for ordbmreg

Argument	Description
-f <file>	Adds <file> to the list of files that will be registered. Can be specified more than once.
-bulk <file>	Specifies a file to read, containing one filename per line. All filenames listed inside <file> will be registered.
-register	Files specified with -f or -bulk will be registered in the dbmanifest table
-unregister	Files specified with -f or -bulk will be removed from the dbmanifest table

Notes:

§ At least one of -f or -bulk is required.

§ If neither -register nor -unregister is specified, the default is ‘-register’.

§ File names specified with -f must either be fully-qualified or be relative to RETAIL_HOME. The same is true for filenames specified within a -bulk file.

§ Registering a file in the dbmanifest table will cause it to be completely skipped. Before doing so, ensure that all commands contained in it have been completed.

§ Removing a file from the dbmanifest table will cause it to be run again. This will fail if the commands in the script cannot be re-run. For example if they create a table that already exists.

Running the ordbmreg Script

Perform the following procedure to run the ordbmreg script:

1. Log in as the UNIX user that owns the product installation.

2. Set the RETAIL_HOME environment variable to the top-level directory of your product installation.

export RETAIL_HOME=/u00/oretail/14.1/tst

3. Set the PATH environment variable to include the orpatch/bin directory
export PATH=$RETAIL_HOME/orpatch/bin:$PATH

4. Execute ordbmreg script to register the desired file(s).

ordbmreg –register –f <file>

Examples of using the ordbmreg Script

Register $RETAIL_HOME/dbsql_rms/Cross_Pillar/db_change_scripts/source/000593_system_options.sql with the dbmanifest table.

ordbmreg -f dbsql_rms/Cross_Pillar/db_change_scripts/source/000593_system_options.sql

Remove the dbmanifest row for $RETAIL_HOME/dbsql_radm/ra_db/radm/database_change_scripts/000035_s12733240_w_party_per_d.sql.

ordbmreg –unregister –f $RETAIL_HOME/dbsql_radm/ra_db/radm/database_change_scripts/000035_s12733240_w_party_per_d.sql

Bulk register several files in the dbmanifest table.

echo “$RETAIL_HOME/dbsql_rwms/DBCs/Source/000294_container.sql” > dbcs.txt

echo “$RETAIL_HOME/dbsql_rwms/DBCs/Source/000457_drop_object.sql” >> dbcs.txt

ordbmreg –bulk dbcs.txt

Restarting after registration

Once the row has been added to the dbmanifest table, restart ORPatch and the script will be skipped. If the file is not skipped there are several possibilities:

§ The script registered is not the failing script.

§ The file type is not a type that is filtered by the dbmanifest. The only file types that skip files listed in the dbmanifest are:

– Initial install DDL Files

– Installation scripts that cannot be rerun

– Database Change Scripts

Manual Restart State File Updates

Oracle Retail strongly discourages manually updating the ORPatch restart state files. Updating the file improperly could cause necessary steps in the patching process to be skipped or patches to be incorrectly recorded as applied.

DISPLAY Settings When Compiling Forms

When compiling RMS or RWMS forms, it is necessary to have a valid X-Windows Display. ORPatch allows this setting to come from one of two places:

§ DISPLAY environment variable set before executing ORPatch

§ DISPLAY setting in RETAIL_HOME/orpatch/config/env_info.cfg

The DISPLAY variable in the environment overrides the env_info.cfg, if both are set. The destination X-Windows display must be accessible to the user running ORPatch, and for best compilation performance it should be on the network ‘close’ to the server where RMS Forms are installed and compiled. Using a local display or VNC display is preferred. Compiling forms across a Wide-Area Network will greatly increase the time required to apply patches to environments.

JAVA_HOME Setting

When working with Java application jar, ear or war files, it is necessary to have a valid JAVA_HOME setting. ORPatch allows this setting to come from one of two places:

§ JAVA_HOME environment variable set before executing ORPatch

§ JAVA_HOME setting in RETAIL_HOME/orpatch/config/env_info.cfg

The JAVA_HOME variable in the environment overrides the env_info.cfg, if both are set. The specified Java home location must be accessible to the user running ORPatch and be a full Java Development Kit (JDK) installation. The JAVA_HOME must contain the jar utility and if automatic Jar file signing is configured, must also contain the keytool and jarsigner utilities.

Patching Prior to First Install

In some situations, it may be necessary to apply a patch to product installation files before the initial install. For example, if there is a defect with a script that would be run during the install and prevent proper installation. In this rare situation, it may be necessary to apply a patch to the installation files prior to starting installation.

Note: These steps should only be undertaken at the direction of Oracle Support.

Perform the following steps to patch installation files prior to starting an installation. The steps assume an RMS installation, but apply to any product supported by ORPatch:

1. Unzip the installation files to a staging area.

Note: The following steps assume the files are in /media/oretail14.1

2. Locate the patch_info.cfg within the product media. The directory it resides in will be used for later steps.

find /media/oretail14.1/rms/installer –name patch_info.cfg

Output Example:

/media/oretail14.1/rms/installer/mom14/patch_info.cfg

3. Get the PATCH_NAME for the standard product installation. The patch name to use in subsequent steps will be the portion following the “=” sign.

grep “PATCH_NAME=” /media/oretail14.1/rms/installer/mom14/patch_info.cfg

Output Example:

PATCH_NAME=MOM_14_1_0_0

4. Create a directory that will contain the patch that must be applied, next to the directory with the product installation files.

Note: The following steps assume this directory is in /media/patch.

5. Unzip the patch into the directory created in step 2.

Note: This should place the patch contents in /media/patch/<patch num>.

6. Export RETAIL_HOME to point within the installation staging area.

export RETAIL_HOME=/media/oretail14.1/rms/installer/mom14/Build

7. Create a logs directory within the installation staging area

mkdir $RETAIL_HOME/orpatch/logs

8. Ensure the ORMerge shell script is executable.

chmod u+x $RETAIL_HOME/orpatch/bin/ormerge

9. Run ORMerge to apply the patch to the installation media, using a –name argument that is the same as what was found in step 3.

$RETAIL_HOME/orpatch/bin/ormerge -s /media/patch -d /media/oretail14.1/rms/installer/mom14 –name MOM_14_1_0_0 –inplace

Note: The –inplace argument is critical to ensure that the patching replaces files in the mom14 directory.

10. Unset the RETAIL_HOME environment variable.

unset RETAIL_HOME

At this point, the installation files will have been updated with the newer versions of files contained within the patch. Log files for the merge will be in /media/oretail14.1/rms/installer/mom14/Build/orpatch/logs.

Providing Metadata to Oracle Support

In some situations, it may be necessary to provide details of the metadata from an environment to Oracle support in order to assist with investigating a patching or application problem. ORPatch provides built-in functionality through the ‘exportmetadata’ action to extract and consolidate metadata information for uploading to Oracle Support or for external analysis. For more information, see the ORPatch ‘Exporting Environment Metadata’ section.

Appendix: Setting Up Password Stores with wallets/credential stores

As part of an application installation, administrators must set up password stores for user accounts using wallets/credential stores. Some password stores must be installed on the application database side. While the installer handles much of this process, the administrators must perform some additional steps.

Password stores for the application and application server user accounts must also be installed; however, the installer takes care of this entire process.

ORACLE Retail Merchandising applications now have 3 different types of password stores. They are database wallets, java wallets, and database credential stores. Background and how to administer them below are explained in this appendix

About Database Password Stores and Oracle Wallet

Oracle databases have allowed other users on the server to see passwords in case database connect strings (username/password@db) were passed to programs. In the past, users could navigate to ps –ef|grep <username> to see the password if the password was supplied in the command line when calling a program.

To make passwords more secure, Oracle Retail has implemented the Oracle Software Security Assurance (OSSA) program. Sensitive information such as user credentials now must be encrypted and stored in a secure location. This location is called password stores or wallets. These password stores are secure software containers that store the encrypted user credentials.

Users can retrieve the credentials using aliases that were set up when encrypting and storing the user credentials in the password store. For example, if username/password@db is entered in the command line argument and the alias is called db_username, the argument to a program is as follows:

sqlplus /@db_username

This would connect to the database as it did previously, but it would hide the password from any system user.

After this is configured, as in the example above, the application installation and the other relevant scripts are no longer needed to use embedded usernames and passwords. This reduces any security risks that may exist because usernames and passwords are no longer exposed.

When the installation starts, all the necessary user credentials are retrieved from the Oracle Wallet based on the alias name associated with the user credentials.

There are three different types of password stores. One type explain in the next section is for database connect strings used in program arguments (such as sqlplus /@db_username). The others are for Java application installation and application use.

Setting Up Password Stores for Database User Accounts

After the database is installed and the default database user accounts are set up, administrators must set up a password store using the Oracle wallet. This involves assigning an alias for the username and associated password for each database user account. The alias is used later during the application installation. This password store must be created on the system where the application server and database client are installed.

This section describes the steps you must take to set up a wallet and the aliases for the database user accounts. For more information on configuring authentication and password stores, see the Oracle Database Security Guide.

Note: In this section, <wallet_location> is a placeholder text for illustration purposes. Before running the command, ensure that you specify the path to the location where you want to create and store the wallet.

To set up a password store for the database user accounts, perform the following steps:

1. Create a wallet using the following command:

mkstore -wrl <wallet_location> -create

After you run the command, a prompt appears. Enter a password for the Oracle Wallet in the prompt.

Note: The mkstore utility is included in the Oracle Database Client installation.

The wallet is created with the auto-login feature enabled. This feature enables the database client to access the wallet contents without using the password. For more information, refer to the Oracle Database Advanced Security Administrator's Guide.

2. Create the database connection credentials in the wallet using the following command:

mkstore -wrl <wallet_location> -createCredential <alias-name> <database-user-name>

After you run the command, a prompt appears. Enter the password associated with the database user account in the prompt.

3. Repeat Step 2 for all the database user accounts.

4. Update the sqlnet.ora file to include the following statements:

WALLET_LOCATION = (SOURCE = (METHOD = FILE) (METHOD_DATA = (DIRECTORY = <wallet_location>)))

SQLNET.WALLET_OVERRIDE = TRUE

SSL_CLIENT_AUTHENTICATION = FALSE

5. Update the tnsnames.ora file to include the following entry for each alias name to be set up.

<alias-name> =

(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP) (HOST = <host>) (PORT = <port>))

)

(CONNECT_DATA =

(SERVICE_NAME = <service>)

)

In the previous example, <alias-name>, <host>, <port>, and <service> are placeholder text for illustration purposes. Ensure that you replace these with the relevant values.

Setting up Wallets for Database User Accounts

The following examples show how to set up wallets for database user accounts for the following applications:

§ For RMS, RWMS, RPM Batch using sqlplus or sqlldr, RETL, RMS, RWMS, and ARI

For RMS, RWMS, RPM Batch using sqlplus or sqlldr, RETL, RMS, RWMS, and ARI

To set up wallets for database user accounts, do the following.

1. Create a new directory called wallet under your folder structure.

cd /projects/rms14/dev/

mkdir .wallet

Note: The default permissions of the wallet allow only the owner to use it, ensuring the connection information is protected. If you want other users to be able to use the connection, you must adjust permissions appropriately to ensure only authorized users have access to the wallet.

2. Create a sqlnet.ora in the wallet directory with the following content.

WALLET_LOCATION = (SOURCE = (METHOD = FILE) (METHOD_DATA = (DIRECTORY = /projects/rms14/dev/.wallet)) )

SQLNET.WALLET_OVERRIDE=TRUE
SSL_CLIENT_AUTHENTICATION=FALSE

Note: WALLET_LOCATION must be on line 1 in the file.

3. Setup a tnsnames.ora in the wallet directory. This tnsnames.ora includes the standard tnsnames.ora file. Then, add two custom tns_alias entries that are only for use with the wallet. For example, sqlplus /@dvols29_rms01user.

ifile = /u00/oracle/product/11.2.0.1/network/admin/tnsnames.ora

Examples for a NON pluggable db:

dvols29_rms01user =

(DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = tcp)

(host = xxxxxx.us.oracle.com) (Port = 1521)))

(CONNECT_DATA = (SID = <sid_name> (GLOBAL_NAME = <sid_name>)))

dvols29_rms01user.world =

(DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = tcp)

(host = xxxxxx.us.oracle.com) (Port = 1521)))

(CONNECT_DATA = (SID = <sid_name>) (GLOBAL_NAME = <sid_name>)))

Examples for a pluggable db:

dvols29_rms01user =

(DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = tcp)

(host = xxxxxx.us.oracle.com) (Port = 1521)))

(CONNECT_DATA = (SERVICE_NAME = <pluggable db name>)))

dvols29_rms01user.world =

(DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = tcp)

(host = xxxxxx.us.oracle.com) (Port = 1521)))

(CONNECT_DATA = (SERVICE_NAME = <pluggable db name>)))

Note: It is important to not just copy the tnsnames.ora file because it can quickly become out of date. The ifile clause (shown above) is key.

4. Create the wallet files. These are empty initially.

a. Ensure you are in the intended location.

$ pwd
/projects/rms14/dev/.wallet

b. Create the wallet files.

$ mkstore -wrl . –create

c. Enter the wallet password you want to use. It is recommended that you use the same password as the UNIX user you are creating the wallet on.

d. Enter the password again.

Two wallet files are created from the above command:

– ewallet.p12

– cwallet.sso

5. Create the wallet entry that associates the user name and password to the custom tns alias that was setup in the wallet’s tnsnames.ora file.

mkstore –wrl . –createCredential <tns_alias> <username> <password>

Example: mkstore –wrl . –createCredential dvols29_rms01user rms01user passwd

6. Test the connectivity. The ORACLE_HOME used with the wallet must be the same version or higher than what the wallet was created with.

$ export TNS_ADMIN=/projects/rms14/dev/.wallet /* This is very import to use wallet to point at the alternate tnsnames.ora created in this example */

$ sqlplus /@dvols29_rms01user

SQL*Plus: Release 12

Connected to:

Oracle Database 12g

SQL> show user

USER is “rms01user”

Running batch programs or shell scripts would be similar:

Ex: dtesys /@dvols29_rms01user

script.sh /@dvols29_rms01user

Set the UP unix variable to help with some compiles :

export UP=/@dvols29_rms01user

for use in RMS batch compiles, and RMS, RWMS, and ARI forms compiles.

As shown in the example above, users can ensure that passwords remain invisible.

Additional Database Wallet Commands

The following is a list of additional database wallet commands.

§ Delete a credential on wallet

mkstore –wrl . –deleteCredential dvols29_rms01user

§ Change the password for a credential on wallet

mkstore –wrl . –modifyCredential dvols29_rms01user rms01user passwd

§ List the wallet credential entries

mkstore –wrl . –list

This command returns values such as the following.

oracle.security.client.connect_string1

oracle.security.client.user1

oracle.security.client.password1

§ View the details of a wallet entry

mkstore –wrl . –viewEntry oracle.security.client.connect_string1

Returns the value of the entry:

dvols29_rms01user

mkstore –wrl . –viewEntry oracle.security.client.user1

Returns the value of the entry:

rms01user

mkstore –wrl . –viewEntry oracle.security.client.password1

Returns the value of the entry:

Passwd

Setting up RETL Wallets

RETL creates a wallet under $RFX_HOME/etc/security, with the following files:

§ cwallet.sso

§ jazn-data.xml

§ jps-config.xml

§ README.txt

To set up RETL wallets, perform the following steps:

1. Set the following environment variables:

§ ORACLE_SID=<retaildb>

§ RFX_HOME=/u00/rfx/rfx-13

§ RFX_TMP=/u00/rfx/rfx-13/tmp

§ JAVA_HOME=/usr/jdk1.6.0_12.64bit

§ LD_LIBRARY_PATH=$ORACLE_HOME

§ PATH=$RFX_HOME/bin:$JAVA_HOME/bin:$PATH

2. Change directory to $RFX_HOME/bin.

3. Run setup-security-credential.sh.

§ Enter 1 to add a new database credential.

§ Enter the dbuseralias. For example, retl_java_rms01user.

§ Enter the database user name. For example, rms01user.

§ Enter the database password.

§ Re-enter the database password.

§ Enter D to exit the setup script.

4. Update your RETL environment variable script to reflect the names of both the Oracle Networking wallet and the Java wallet.

For example, to configure RETLforRPAS, modify the following entries in
$RETAIL_HOME/RETLforRPAS/rfx/etc/rmse_rpas_config.env.

§ The RETL_WALLET_ALIAS should point to the Java wallet entry:

– export RETL_WALLET_ALIAS="retl_java_rms01user"

§ The ORACLE_WALLET_ALIAS should point to the Oracle network wallet entry:

– export ORACLE_WALLET_ALIAS="dvols29_rms01user"

§ The SQLPLUS_LOGON should use the ORACLE_WALLET_ALIAS:

– export SQLPLUS_LOGON="/@${ORACLE_WALLET_ALIAS}"

5. To change a password later, run setup-security-credential.sh.

§ Enter 2 to update a database credential.

§ Select the credential to update.

§ Enter the database user to update or change.

§ Enter the password of the database user.

§ Re-enter the password.

For Java Applications (SIM, ReIM, RPM, RIB, AIP, Alloc, ReSA, RETL)

For Java applications, consider the following:

§ For database user accounts, ensure that you set up the same alias names between the password stores (database wallet and Java wallet). You can provide the alias name during the installer process.

§ Document all aliases that you have set up. During the application installation, you must enter the alias names for the application installer to connect to the database and application server.

§ Passwords are not used to update entries in Java wallets. Entries in Java wallets are stored in partitions, or application-level keys. In each retail application that has been installed, the wallet is located in <WEBLOGIC_DOMAIN_HOME>/retail/<appname>/config Example:
/u00/webadmin/product/10.3.6/WLS/user_projects/domains/14_mck_soa_domain/retail/reim14/config

§ Application installers should create the Java wallets for you, but it is good to know how this works for future use and understanding.

§ Scripts are located in <WEBLOGIC_DOMAIN_HOME>/retail/<appname>/retail-public-security-api/bin for administering wallet entries.

§ Example:

§ /u00/webadmin/product/10.3.6/WLS/user_projects/domains/REIMDomain/retail/reim14/retail-public-security-api/bin

§ In this directory is a script to help you update each alias entry without having to remember the wallet details. For example, if you set the RPM database alias to rms01user, you will find a script called update-RMS01USER.sh.

Note: These scripts are available only with applications installed by way of an installer.

§ Two main scripts are related to this script in the folder for more generic wallet operations: dump_credentials.sh and save_credential.sh.

§ If you have not installed the application yet, you can unzip the application zip file and view these scripts in <app>/application/retail-public-security-api/bin.

§ Example:

§ /u00/webadmin/reim14/application/retail-public-security-api/bin

update-<ALIAS>.sh

update-<ALIAS>.sh updates the wallet entry for this alias. You can use this script to change the user name and password for this alias. Because the application refers only to the alias, no changes are needed in application properties files.

Usage:

update-<username>.sh <myuser>

Example:

/u00/webadmin/product/10.3.x/WLS/user_projects/domains/RPMDomain/retail/rpm14/retail-public-security-api/bin> ./update-RMS01USER.sh

usage: update-RMS01USER.sh <username>

<username>: the username to update into this alias.

Example: update-RMS01USER.sh myuser

Note: this script will ask you for the password for the username that you pass in.

/u00/webadmin/product/10.3.x/WLS/user_projects/domains/RPMDomain/retail/rpm14/retail-public-security-api/bin>

dump_credentials.sh

dump_credentials.sh is used to retrieve information from wallet. For each entry found in the wallet, the wallet partition, the alias, and the user name are displayed. Note that the password is not displayed. If the value of an entry is uncertain, run save_credential.sh to resave the entry with a known password.

dump_credentials.sh <wallet location>

Example:

dump_credentials.sh location:/u00/webadmin/product/10.3.x/WLS/user_projects/domains/REIMDomain/retail/reim14/config

Retail Public Security API Utility

=============================================

Below are the credentials found in the wallet at the location:/u00/webadmin/product/10.3.x/WLS/user_projects/domains/REIMDomain/retail/reim14/config

=============================================

Application level key partition name:reim14
User Name Alias:WLS-ALIAS User Name:weblogic
User Name Alias:RETAIL-ALIAS User Name:retail.user
User Name Alias:LDAP-ALIAS User Name:RETAIL.USER
User Name Alias:RMS-ALIAS User Name:rms14mock
User Name Alias:REIMBAT-ALIAS User Name:reimbat

save_credential.sh

save_credential.sh is used to update the information in wallet. If you are unsure about the information that is currently in the wallet, use dump_credentials.sh as indicated above.

save_credential.sh -a <alias> -u <user> -p <partition name> –l <path of the wallet file location where credentials are stored>

Example:

/u00/webadmin/mock14_testing/rtil/rtil/application/retail-public-security-api/bin> save_credential.sh -l wallet_test -a myalias -p mypartition -u myuser

=============================================

Retail Public Security API Utility

=============================================

Enter password:

Verify password:

Note: -p in the above command is for partition name. You must specify the proper partition name used in application code for each Java application.

save_credential.sh and dump_credentials.sh scripts are the same for all applications. If using save_credential.sh to add a wallet entry or to update a wallet entry, bounce the application/managed server so that your changes are visible to the application. Also, save a backup copy of your cwallet.sso file in a location outside of the deployment path, because redeployment or reinstallation of the application will wipe the wallet entries you made after installation of the application. To restore your wallet entries after a redeployment/reinstallation, copy the backed up cwallet.sso file over the cwallet.sso file. Then bounce the application/managed server.

Usage

=============================================

Retail Public Security API Utility

=============================================

usage: save_credential.sh -au[plh]

E.g. save_credential.sh -a rms-alias -u rms_user -p rib-rms -l ./

-a,--userNameAlias <arg> alias for which the credentials

needs to be stored

-h,--help usage information

-l,--locationofWalletDir <arg> location where the wallet file is

created.If not specified, it creates the wallet under secure-credential-wallet directory which is already present under the retail-public-security-api/ directory.

-p,--appLevelKeyPartitionName <arg> application level key partition name

-u,--userName <arg> username to be stored in secure

credential wallet for specified alias*

How does the Wallet Relate to the Application?

The ORACLE Retail Java applications have the wallet alias information you create in an <app-name>.properties file. Below is the reim.properties file. Note the database information and the user are presented as well. The property called datasource.credential.alias=RMS-ALIAS uses the ORACLE wallet with the argument of RMS-ALIAS at the csm.wallet.path and csm.wallet.partition.name = reim14 to retrieve the password for application use.

Reim.properties code sample:

datasource.url=jdbc:oracle:thin:@xxxxxxx.us.oracle.com:1521:pkols07

datasource.schema.owner=rms14mock

datasource.credential.alias=RMS-ALIAS

# =================================================================

# ossa related Configuration

# These settings are for ossa configuration to store credentials.

# =================================================================

csm.wallet.path=/u00/webadmin/product/10.3.x/WLS/user_projects/domains/REIMDomain/retail/reim14/config

csm.wallet.partition.name=reim14

How does the Wallet Relate to Java Batch Program use?

Some of the ORACLE Retail Java batch applications have an alias to use when running Java batch programs. For example, alias REIMBAT-ALIAS maps through the wallet to dbuser RMS01APP, already on the database. To run a ReIM batch program the format would be: reimbatchpgmname REIMBAT-ALIAS <other arguments as needed by the program in question>

Database Credential Store Administration

The following section describes a domain level database credential store. This is used in RPM login processing, SIM login processing, RWMS login processing, RESA login processing and Allocation login processing and policy information for application permission. Setting up the database credential store is addressed in the RPM, SIM, RESA, RWMS, and Alloc 14.1 install guides.

The following sections show an example of how to administer the password stores thru ORACLE Enterprise Manger Fusion Middleware Control, a later section will show how to do this thru WLST scripts.

1. The first step is to use your link to Oracle Enterprise Manager Fusion Middleware Control for the domain in question. Locate your domain on the left side of the screen and do a right mouse click on the domain and select Security > Credentials

2. Click on Credentials and you will get a screen similar to the following. The following screen is expanded to make it make more sense. From here you can administer credentials.

The Create Map add above is to create a new map with keys under it. A map would usually be an application such as rpm14. The keys will usually represent alias to various users (database user, WebLogic user, LDAP user, etc). The application installer should add the maps so you should not often have to add a map.

Creation of the main keys for an application will also be built by the application installer. You will not be adding keys often as the installer puts the keys out and the keys talk to the application. You may be using EDIT on a key to see what user the key/alias points to and possibly change/reset its password. To edit a key/alias, highlight the key/alias in question and push the edit icon nearer the top of the page. You will then get a screen as follows:

The screen above shows the map (rpm14) that came from the application installer, the key (DB-ALIAS) that came from the application installer (some of the keys/alias are selected by the person who did the application install, some are hard coded by the application installer in question), the type (in this case password), and the user name and password. This is where you would check to see that the user name is correct and reset the password if needed. REMEMBER, a change to an item like a database password WILL make you come into this and also change the password. Otherwise your application will NOT work correctly.

Managing Credentials with WSLT/OPSS Scripts

This procedure is optional as you can administer the credential store through the Oracle enterprise manager associated with the domain of your application install for RPM, SIM, RESA, or Allocation.

An Oracle Platform Security Scripts (OPSS) script is a WLST script, in the context of the Oracle WebLogic Server. An online script is a script that requires a connection to a running server. Unless otherwise stated, scripts listed in this section are online scripts and operate on a database credential store. There are a few scripts that are offline, that is, they do not require a server to be running to operate.

Read-only scripts can be performed only by users in the following WebLogic groups: Monitor, Operator, Configurator, or Admin. Read-write scripts can be performed only by users in the following WebLogic groups: Admin or Configurator. All WLST scripts are available out-of-the-box with the installation of the Oracle WebLogic Server.

WLST scripts can be run in interactive mode or in script mode. In interactive mode, you enter the script at a command-line prompt and view the response immediately after. In script mode, you write scripts in a text file (with a py file name extension) and run it without requiring input, much like the directives in a shell script.

For platform-specific requirements to run an OPSS script, see http://docs.oracle.com/cd/E21764_01/core.1111/e10043/managepols.htm#CIHIBBDJ

The weakness with the WLST/OPSS scripts is that you have to already know your map name and key name. In many cases, you do not know or remember that. The database credential store way through enterprise manager is a better way to find your map and key names easily when you do not already know them. A way in a command line mode to find the map name and alias is to run orapki. An example of orapki is as follows:

/u00/webadmin/product/wls_apps/oracle_common/bin> ./orapki wallet display –wallet /u00/webadmin/product/wls_apps/user_projects/domains/APPDomain/config/fmwconfig

(where the path above is the domain location of the wallet)

Output of orapki is below. This shows map name of rpm14 and each alias in the wallet:

Oracle PKI Tool : Version 11.1.1.7.0

Requested Certificates:

User Certificates:

Oracle Secret Store entries:

rpm14@#3#@DB-ALIAS

rpm14@#3#@LDAP-ALIAS

rpm14@#3#@RETAIL.USER

rpm14@#3#@user.signature.salt

rpm14@#3#@user.signature.secretkey

rpm14@#3#@WEBLOGIC-ALIAS

rpm14@#3#@WLS-ALIAS

Trusted Certificates:

Subject: OU=Class 1 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US

OPSS provides the following scripts on all supported platforms to administer credentials (all scripts are online, unless otherwise stated. You need the map name and the key name to run the scripts below

§ listCred

§ updateCred

§ createCred

§ deleteCred

§ modifyBootStrapCredential

§ addBootStrapCredential

listCred

The script listCred returns the list of attribute values of a credential in the credential store with given map name and key name. This script lists the data encapsulated in credentials of type password only.

Script Mode Syntax

listCred.py -map mapName -key keyName

Interactive Mode Syntax

listCred(map="mapName", key="keyName")

The meanings of the arguments (all required) are as follows:

§ map specifies a map name (folder).

§ key specifies a key name.

Examples of Use:

The following invocation returns all the information (such as user name, password, and description) in the credential with map name myMap and key name myKey:

listCred.py -map myMap -key myKey

The following example shows how to run this command and similar credential commands with WLST:

/u00/webadmin/product/wls_apps/oracle_common/common/bin>

sh wlst.sh

Initializing WebLogic Scripting Tool (WLST)...

Welcome to WebLogic Server Administration Scripting Shell

wls:/offline> connect('weblogic','password123','xxxxxx.us.oracle.com:17001')

Connecting to t3://xxxxxx.us.oracle.com:17001 with userid weblogic ...

Successfully connected to Admin Server 'AdminServer' that belongs to domain 'APPDomain'.

wls:/APPDomain/serverConfig> listCred(map="rpm14",key="DB-ALIAS")

Already in Domain Runtime Tree

[Name : rms01app, Description : null, expiry Date : null]

PASSWORD:retail

*The above means for map rpm14 in APPDomain, alias DB-ALIAS points to database user rms01app with a password of retail

updateCred

The script updateCred modifies the type, user name, and password of a credential in the credential store with given map name and key name. This script updates the data encapsulated in credentials of type password only. Only the interactive mode is supported.

Interactive Mode Syntax

updateCred(map="mapName", key="keyName", user="userName", password="passW", [desc="description"])

The meanings of the arguments (optional arguments are enclosed by square brackets) are as follows:

§ map specifies a map name (folder) in the credential store.

§ key specifies a key name.

§ user specifies the credential user name.

§ password specifies the credential password.

§ desc specifies a string describing the credential.

Example of Use:

The following invocation updates the user name, password, and description of the password credential with map name myMap and key name myKey:

updateCred(map="myMap", key="myKey", user="myUsr", password="myPassw")

createCred

The script createCred creates a credential in the credential store with a given map name, key name, user name and password. This script can create a credential of type password only. Only the interactive mode is supported.

Interactive Mode Syntax

createCred(map="mapName", key="keyName", user="userName", password="passW", [desc="description"])

The meanings of the arguments (optional arguments are enclosed by square brackets) are as follows:

§ map specifies the map name (folder) of the credential.

§ key specifies the key name of the credential.

§ user specifies the credential user name.

§ password specifies the credential password.

§ desc specifies a string describing the credential.

Example of Use:

The following invocation creates a password credential with the specified data:

createCred(map="myMap", key="myKey", user="myUsr", password="myPassw")

deleteCred

The script deleteCred removes a credential with given map name and key name from the credential store.

Script Mode Syntax

deleteCred.py -map mapName -key keyName

Interactive Mode Syntax

deleteCred(map="mapName",key="keyName")

The meanings of the arguments (all required) are as follows:

§ map specifies a map name (folder).

§ key specifies a key name.

Example of Use:

The following invocation removes the credential with map name myMap and key name myKey:

deleteCred.py -map myMap -key myKey

modifyBootStrapCredential

The offline script modifyBootStrapCredential modifies the bootstrap credentials configured in the default jps context, and it is typically used in the following scenario: suppose that the policy and credential stores are LDAP-based, and the credentials to access the LDAP store (stored in the LDAP server) are changed. Then this script can be used to seed those changes into the bootstrap credential store.

This script is available in interactive mode only.

Interactive Mode Syntax

modifyBootStrapCredential(jpsConfigFile="pathName", username="usrName", password="usrPass")

The meanings of the arguments (all required) are as follows:

§ jpsConfigFile specifies the location of the file jps-config.xml relative to the location where the script is run. Example location: /u00/webadmin/product/wls_apps/user_projects/domains/APPDomain/config/fmwconfig. Example location of the bootstrap wallet is /u00/webadmin/product/wls_apps/user_projects/domains/APPDomain/config/fmwconfig/bootstrap

§ username specifies the distinguished name of the user in the LDAP store.

§ password specifies the password of the user.

Example of Use:

Suppose that in the LDAP store, the password of the user with distinguished name cn=orcladmin has been changed to welcome1, and that the configuration file jps-config.xml is located in the current directory.Then the following invocation changes the password in the bootstrap credential store to welcome1:

modifyBootStrapCredential(jpsConfigFile='./jps-config.xml', username='cn=orcladmin', password='welcome1')

Any output regarding the audit service can be disregarded.

addBootStrapCredential

The offline script addBootStrapCredential adds a password credential with given map, key, user name, and user password to the bootstrap credentials configured in the default jps context of a jps configuration file.

Classloaders contain a hierarchy with parent classloaders and child classloaders. The relationship between parent and child classloaders is analogous to the object relationship of super classes and subclasses. The bootstrap classloader is the root of the Java classloader hierarchy. The Java virtual machine (JVM) creates the bootstrap classloader, which loads the Java development kit (JDK) internal classes and java.* packages included in the JVM. (For example, the bootstrap classloader loads java.lang.String.)

This script is available in interactive mode only.

Interactive Mode Syntax

addBootStrapCredential(jpsConfigFile="pathName", map="mapName", key="keyName", username="usrName", password="usrPass")

The meanings of the arguments (all required) are as follows:

§ map specifies the map of the credential to add.

§ key specifies the key of the credential to add.

§ username specifies the name of the user in the credential to add.

§ password specifies the password of the user in the credential to add.

Example of Use:

The following invocation adds a credential to the bootstrap credential store:

addBootStrapCredential(jpsConfigFile='./jps-config.xml', map='myMapName', key='myKeyName', username='myUser', password =’myPass’)

Quick Guide for Retail Password Stores (db wallet, java wallet, DB credential stores)

Retail app	Wallet type	Wallet loc	Wallet partition	Alias name	User name	Use	Create by	Alias Example	Notes
RMS batch	DB	<RMS batch install dir (RETAIL_HOME)>/.wallet	n/a	<Database SID>_<Database schema owner>	<rms schema owner>	Compile, execution	Installer	n/a	Alias hard-coded by installer
RMS forms	DB	<forms install dir>/base/.wallet	n/a	<Database SID>_<Database schema owner>	<rms schema owner>	Compile	Installer	n/a	Alias hard-coded by installer
ARI forms	DB	<forms install dir>/base/.wallet	n/a	<Db_Ari01>	<ari schema owner>	Compile	Manual	ari-alias
RMWS forms	DB	<forms install dir>/base/.wallet	n/a	<Database SID>_<Database schema owner>	<rwms schema owner>	Compile forms, execute batch	Installer	n/a	Alias hard-coded by installer
RPM batch plsql and sqlldr	DB	<RPM batch install dir>/.wallet	n/a	<rms schema owner alias>	<rms schema owner>	Execute batch	Manual	rms-alias	RPM plsql and sqlldr batches
RWMS auto-login	JAVA	<forms install dir>/base/.javawallet
			<RWMS Installation name>	<RWMS database user alias>	<RWMS schema owner>	RWMS forms app to avoid dblogin screen	Installer	rwms14inst
			<RWMS Installation name>	BI_ALIAS	<BI Publisher administrative user>	RWMS forms app to connect to BI Publisher	Installer	n/a	Alias hard-coded by installer
AIP app	JAVA	<weblogic domain home>/retail/<deployed aip app name>/config							Each alias must be unique
			aip14	<AIP weblogic user alias>	<AIP weblogic user name>	App use	Installer	aip-weblogic-alias
			aip14	<AIP database schema user alias>	<AIP database schema user name>	App use	Installer	aip01user-alias
			aip14	<rib-aip weblogic user alias>	<rib-aip weblogic user name>	App use	Installer	rib-aip-weblogic-alias
RPM app	DB credential store		Map=rpm14 or what you called the app at install time.	Many for app use					<weblogic domain home>/config/fmwconfig/jps-config.xml has info on the credential store. This directory also has the domain cwallet.sso file.
RPM app	JAVA	<weblogic domain home>/retail/<deployed rpm app name>/config							Each alias must be unique
			rpm14	<rpm weblogic user alias>	<rpm weblogic user name>	App use	Installer	rpm-weblogic-alias
			rpm14	<rpm batch user name> is the alias. Yes, here alias name = user name	<rpm batch user name>	App, batch use	Installer	RETAIL.USER
	JAVA	<retail_home>/orpatch/config/javaapp_rpm							Each alias must be unique
			retail_installer	<rpm weblogic user alias>	<rpm weblogic user name>	App use	Installer	weblogic-alias
			retail_installer	<rms shema user alias>	<rms shema user name>	App, batch use	Installer	rms01user-alias
			retail_installer	<reim batch user alias>	<reim batch user name>	App, batch use	Installer	reimbat-alias
			retail_installer	<LDAP-ALIAS>	cn=rpm.admin,cn=Users,dc=us,dc=oracle,dc=com	LDAP user use	Installer	LDAP_ALIAS
ReIM app	JAVA	<weblogic domain home>/retail/<deployed reim app name>/config							Each alias must be unique
			<installed app name, ex: reim14>	<reim weblogic user alias>	<reim weblogic user name>	App use	Installer	weblogic-alias
			<installed app name, ex: reim14>	<rms shema user alias>	<rms shema user name>	App, batch use	Installer	rms01user-alias
			<installed app name, ex: reim14>	<reim webservice validation user alias>	<reim webservice validation user name>	App use	Installer	reimwebservice-alias
			<installed app name, ex: reim14>	<reim batch user alias>	<reim batch user name>	App, batch use	Installer	reimbat-alias
			<installed app name, ex: reim14>	<LDAP-ALIAS>	cn=REIM.ADMIN,cn=Users,dc=us,dc=oracle,dc=com	LDAP user use	Installer	LDAP_ALIAS
	JAVA	<retail_home>/orpatch/config/javaapp_reim							Each alias must be unique
			retail_installer	<reim weblogic user alias>	<reim weblogic user name>	App use	Installer	weblogic-alias
			retail_installer	<rms shema user alias>	<rms shema user name>	App, batch use	Installer	rms01user-alias
			retail_installer	<reim webservice validation user alias>	<reim webservice validation user name>	App use	Installer	reimwebservice-alias
			retail_installer	<reim batch user alias>	<reim batch user name>	App, batch use	Installer	reimbat-alias
			retail_installer	<LDAP-ALIAS>	cn=REIM.ADMIN,cn=Users,dc=us,dc=oracle,dc=com	LDAP user use	Installer	LDAP_ALIAS
RESA app	DB credential store		Map=resa14 or what you called the app at install time	Many for login and policies					<weblogic domain home>/config/fmwconfig/jps-config.xml has info on the credential store. This directory also has the domain cwallet.sso file. The bootstrap directory under this directory has bootstrap cwallet.sso file.
RESA app	JAVA	<weblogic domain home>/retail/<deployed resa app name>/config							Each alias must be unique
			<installed app name>	<resa weblogic user alias>	<resa weblogic user name>	App use	Installer	wlsalias
			<installed app name>	<resa schema db user alias>	<rmsdb shema user name>	App use	Installer	Resadb-alias
			<installed app name>	<resa schema user alias>	<rmsdb shema user name>>	App use	Installer	resa-alias
	JAVA	<retail_home>/orpatch/config/javaapp_resa							Each alias must be unique
			retail_installer	<resa weblogic user alias>	<resa weblogic user name>	App use	Installer	wlsalias
			retail_installer	<resa schema db user alias>	<rmsdb shema user name>	App use	Installer	Resadb-alias
	JAVA	<retail_ home>/orpatch/config/javaapp_rasrm							Each alias must be unique
			retail_installer	<alloc weblogic user alias>	<alloc weblogic user name>	App use	Installer	weblogic-alias
Alloc app	DB credential store		Map=alloc 14 or what you called the app at install time	Many for login and policies					<weblogic domain home>/config/fmwconfig/jps-config.xml has info on the credential store. This directory also has the domain cwallet.sso file. The bootstrap directory under this directory has bootstrap cwallet.sso file.
Alloc app	JAVA	<weblogic domain home>/retail/config							Each alias must be unique
			<installed app name>	<alloc weblogic user alias>	<alloc weblogic user name>	App use	Installer	weblogic-alias
			<installed app name>	<rms schema user alias>	<rms schema user name>	App use	Installer	dsallocAlias
			<installed app name>	<alloc batch user alias>	<SYSTEM_ADMINISTRATOR>	Batch use	Installer	alloc14
	JAVA	<retail_ home>/orpatch/config/javaapp_alloc							Each alias must be unique
			retail_installer	<alloc weblogic user alias>	<alloc weblogic user name>	App use	Installer	weblogic-alias
			retail_installer	<rms schema user alias>	<rms schema user name>	App use	Installer	dsallocAlias
			retail_installer	<alloc batch user alias>	<SYSTEM_ADMINISTRATOR>	Batch use	Installer	alloc14
	JAVA	<retail_ home>/orpatch/config/javaapp_rasrm							Each alias must be unique

retail_installer

App use

Installer

weblogic-alias

SIM app

DB credential store

Map=oracle.retail.sim

Aliases required for SIM app use

<weblogic domain home>/config/fmwconfig/jps-config.xml has info on the credential store. This directory also has the domain cwallet.sso file.

JAVA

<weblogic domain home>/retail/<deployed sim app

name>/batch/resources/conf

oracle.retail.sim

App use

Installer

BATCH-ALIAS

JAVA

<weblogic domain home>/retail/<deployed sim app

name>/wireless/resources/conf

oracle.retail.sim

App use

Installer

WIRELESS-ALIAS

RETL

JAVA

<RETL home>/etc/security

n/a

App use

Manual

retl_java_rms01user

User may vary depending on RETL flow’s target application

RETL

<RETL home>/.wallet

n/a

App use

Manual

User may vary depending on RETL flow’s target application

RIB

JAVA

<RIBHOME DIR>/deployment-home/conf/security

<app> is one of aip, rfm, rms, rpm, sim, rwms, tafr

JMS

jms<1-5>

Integra-
tion use

Installer

jms-alias

WebLogic

rib-<app>-app-server-instance

<rib-app weblogic user alias>

<rib-app weblogic user name>

Integra-
tion use

Installer

weblogic-alias

Admin GUI

rib-<app>#web-app-user-alias

<rib-app admin gui user alias>

<rib-app admin gui user name>

Integra-
tion use

Installer

admin-gui-alias

Application

rib-<app>#user-alias

Integra-
tion use

Installer

app-user-alias

Valid only for aip, rpm, sim

rib-<app>#app-db-user-alias

<rib-app database schema user alias>

<rib-app database schema user name>

Integra-
tion use

Installer

db-user-alias

Valid only for rfm, rms, rwms, tafr

Error Hospital

rib-<app>#hosp-user-alias

<rib-app error hospital database schema user alias>

<rib-app error hospital database schema user name>

Integra-
tion use

Installer

hosp-user-alias

RFI

Java

<RFI-HOME>/retail-financial-integration-solution/service-based-integration/conf/security

rfiAppServerAdminServerUserAlias

App use

Installer

rfiAppServerAdminServerUserAlias

rfiAdminUiUserAlias

App use

Installer

rfiAdminUiUserAlias

rfiDataSourceUserAlias

App use

Installer

rfiDataSourceUserAlias

ebsDataSourceUserAlias

App use

Installer

ebsDataSourceUserAlias

smtpMailFromAddressAlias

App use

Installer

smtpMailFromAddressAlias

Requirement	Version
Operating system	Windows 7, 8
Terminal Server	Windows Server 2012R2
Display resolution	1024x768 or higher
Processor	2.6GHz or higher
Memory	1GByte or higher
Networking	intranet with at least 10Mbps data rate
Oracle (Sun) Java Runtime Environment	1.7.+
Browser	Microsoft Internet Explorer 11 Mozilla Firefox 24.0

Integration Technology	Version
Oracle Retail Integration Bus (RIB)	14.1
Oracle Retail Service Backbone (RSB)	14.1

Field Title	Component Selection.
Field Description	Select the RWMS component(s) you would like to install. Multiple components may be selected. You will not be able to install a component if the preinstall check for that component has failed.

Field Title	Hostname
Field Description	Provide the hostname of the Oracle Database Server.
Examples	dbhostname

Field Title	Oracle SID
Field Description	Oracle system identifier for the database where the RWMS installation will run.
Examples	mydb

Field Title	RWMS schema
Field Description	Provide the RWMS database owner here. The installer logs into the database as this user to create the RWMS schema. This user must already exist in the database when the RWMS database schema installation is run.
Examples	wms01

Field Title	RWMS schema password
Field Description	Database password for the RWMS schema owner.

Field Title	RWMS Runtime User Schema
Field Description	Provide the RWMS runtime database user here. This user must already exist in the database when the RWMS database schema installation is run. This will be used for running the RWMS application.
Examples	wms01user

Field Title	RWMS Runtime User Schema Password
Field Description	Database password for the RWMS Runtime user.

Field Title	RWMS ADF schema password
Field Description	Database password for the RWMS ADF schema (RWMS_ADF_USER). This user must already exist in the database when the RWMS database schema installation is run. This is used for secure integration between ADF and Oracle Forms.

Field Title	RWMS DB RETAIL_HOME
Field Description	The location where the RWMS database scripts will be installed along with the ORPATCH utility.
Example	/path/to/retail_home
Note	If you have selected an existing RETAIL_HOME, and it has been configured to run other components than the ones you have selected for this installation, those components will also be installed regardless of what you selected on the Component Selection screen.

Field Title	Oracle Wallet password
Field Description	This is the password for the wallet that will store the credentials used during the RWMS installation. If you have selected an existing RETAIL_HOME in the previous screens, you will need to enter the password that was used for the wallet in that RETAIL_HOME.
Note	Make sure this password is kept as it will be needed for future upgrades.

Field Title	Application Installation Name
Field Description	The value used to configure and identify a specific forms installation. The Forms URLs for this installation will contain this value.
Example	rwms14inst
Note	The value entered in this field must be identical for the Application (Forms) and Enhanced Navigation & Dashboards installations.

Field Title	Forms WebLogic Admin Port
Field Description	Listen port for the Forms WebLogic Admin server.
Example	7001

Field Title	Forms WebLogic Admin User
Field Description	Username of the admin user for the WebLogic instance to which the Oracle Forms application is already deployed.
Example	weblogic

Field Title	Forms WebLogic Admin Password
Field Description	Password for the WebLogic admin user. You chose this password when you created the WebLogic instance.

Field Title	Enable SSL for RWMS Forms?
Field Description	Choose Yes to install RWMS Forms using a WebLogic environment configured to use SSL. In this case, SSL must be configured and the ports must be enabled for the AdminServer and Oracle Forms managed servers. Choose No to install using a WebLogic environment configured without SSL. In this case the non-SSL ports must be enabled for the AdminServer and for the Oracle Forms managed servers.

Field Title	Configure WebLogic
Field Description	Make the necessary configurations to the WebLogic server to be able to run RWMS forms. If you choose no, the configured WebLogic files will be generated by the installer, but should be applied to WebLogic manually.

Field Title	RWMS Application RETAIL_HOME
Field Description	The location where the RWMS Application (forms and reports) will be installed along with the ORPATCH utility.The RWMS Forms will be installed in a subdirectory of this directory, named base.
Example	/path/to/retail_home
Note	If you have selected an existing RETAIL_HOME, and it has been configured to run other components than the ones you have selected for this installation, those components will also be installed regardless of what you selected on the Component Selection screen.

Field Title	Enable Secure JDBC connection
Field Description	Choose “Yes” to create secured data sources in Weblogic, otherwise choose “No”. A secure data base connection must already be set up if you want to create a secure data source.
Note	Refer to Security Guide for information on how to secure the database connection.

Field Title	Identity Keystore
Field Description	Path to the identity keystore used for a secure connection to the RWMS datasource.
Example	/path/to/.keystore
Note	Refer to the Security Guide for more information.

Oracle Retail VAR Applications

Preinstallation Tasks

Installation Terminology

Check Supported Application Server Requirements

Software Required on Handhelds

References for Configuration:

Database Installation Tasks – Full

Background

Instance Creation Using the Generic Template via DBCA

Create the Schema Owner for RWMS

Run the RWMS Database Schema Installation

Database Installation Tasks – Patch

Placement of Report Templates

Create a Deployment Rule Set

Configure Web Service Security

Oracle Retail Deploy Patch (ORDeploy)

MMHOME changed to RETAIL_HOME

Java batch script location

Cumulative Patches

Incremental Patches

Apply all Patches with Installer or ORPatch

Retained Installation Files

Preparing for Patching

Single Patching Session

Shutdown Applications

Backup Environment

Log Files

Unzip Patch Files

Location of ORPatch

Command Line Arguments

Restarting ORPatch

Reverting a Patch

Source and Destination Directory Example

Running the ORMerge Utility

Running the ORCompile utility

Running the ORDeploy utility

ORDeploy Examples

RETAIL_HOME relationship to Database and Application Server

Field Title	Identity Keystore Type
Field Description	Type of the identity keystore used.
Example	JKS

Field Title	Identity Keystore Password
Field Description	Password used to access the identity keystore defined above.

Field Title	Identity Trustore
Field Description	Path to the identity truststore used for a secure connection to the RWMS datasource.
Example	/path/to/.keystore

Field Title	Identity Truststore Type
Field Description	Type of the identity truststore used.
Example	JKS

Field Title	Identity Truststore Password
Field Description	Password used to access the identity truststore defined above.

Field Title	WebLogic Admin Port
Field Description	Listen port for the Enhanced Navigation & Dashboards WebLogic Admin server.
Example	18001

Field Title	WebLogic Admin User
Field Description	Username of the admin user for the WebLogic instance to which the Enhanced Navigation & Dashboards application will be deployed.
Example	weblogic

Field Title	WebLogic Admin Password
Field Description	Password for the WebLogic admin user. You chose this password when you created the WebLogic instance.

Field Title	RWMS 14 Server/Cluster
Field Description	The Server or the cluster name where the Enhanced Navigation and Dashboards application is to be installed.
Examples	rwms-server

Field Title	Enable SSL?
Field Description	Choose Yes to install Enhanced Navigation & Dashboards to a WebLogic environment configured to use SSL. In this case, SSL must be configured and the ports must be enabled for the AdminServer and RWMS Server/Cluster. Choose No to install to a WebLogic environment configured without SSL. In this case the non-SSL ports must be enabled for the AdminServer and for the RWMS Server/Cluster.