Oracle® Retail Allocation Installation Guide, Release 13.2.9

Primary Author: Wade Schwarz

Contributors: Nathan Young

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.

This software or hardware and documentation may provide access to or information about content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services unless otherwise set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services, except as set forth in an applicable agreement between you and Oracle.

Value-Added Reseller (VAR) Language

Oracle Retail VAR Applications

The following restrictions and provisions only apply to the programs referred to in this section and licensed to you. You acknowledge that the programs may contain third party software (VAR applications) licensed to Oracle. Depending upon your product and its version number, the VAR applications may include:

(i) the MicroStrategy Components developed and licensed by MicroStrategy Services Corporation (MicroStrategy) of McLean, Virginia to Oracle and imbedded in the MicroStrategy for Oracle Retail Data Warehouse and MicroStrategy for Oracle Retail Planning & Optimization applications.

(ii) the Wavelink component developed and licensed by Wavelink Corporation (Wavelink) of Kirkland, Washington, to Oracle and imbedded in Oracle Retail Mobile Store Inventory Management.

(iii) the software component known as Access Via™ licensed by Access Via of Seattle, Washington, and imbedded in Oracle Retail Signs and Oracle Retail Labels and Tags.

(iv) the software component known as Adobe Flex™ licensed by Adobe Systems Incorporated of San Jose, California, and imbedded in Oracle Retail Promotion Planning & Optimization application.

You acknowledge and confirm that Oracle grants you use of only the object code of the VAR Applications. Oracle will not deliver source code to the VAR Applications to you. Notwithstanding any other term or condition of the agreement and this ordering document, you shall not cause or permit alteration of any VAR Applications. For purposes of this section, "alteration" refers to all alterations, translations, upgrades, enhancements, customizations or modifications of all or any portion of the VAR Applications including all reconfigurations, reassembly or reverse assembly, re-engineering or reverse engineering and recompilations or reverse compilations of the VAR Applications or any derivatives of the VAR Applications. You acknowledge that it shall be a breach of the agreement to utilize the relationship, and/or confidential information of the VAR Applications for purposes of competitive discovery.

The VAR Applications contain trade secrets of Oracle and Oracle's licensors and Customer shall not attempt, cause, or permit the alteration, decompilation, reverse engineering, disassembly or other reduction of the VAR Applications to a human perceivable form. Oracle reserves the right to replace, with functional equivalent software, any of the VAR Applications in future releases of the applicable program.

Contents

Send Us Your Comments......................................................................................... ix

Preface..................................................................................................................... xi

Audience................................................................................................................................................ xi

Related Documents............................................................................................................................. xi

Customer Support................................................................................................................................ xi

Review Patch Documentation.......................................................................................................... xi

Improved Process for Oracle Retail Documentation Corrections......................................... xii

Oracle Retail Documentation on the Oracle Technology Network..................................... xii

Conventions......................................................................................................................................... xii

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

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

Check Supported Database Server Requirements....................................................................... 1

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

Verify Single Sign-On........................................................................................................................... 5

Check Supported Client PC and Web Browser Requirements................................................. 5

Configure Mozilla Firefox ESR31+.......................................................................................... 5

Supported Oracle Retail Products.................................................................................................... 6

Supported Oracle Retail Integration Technologies..................................................................... 6

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

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

3 Allocation Database.............................................................................................. 9

4 Application Installation Tasks............................................................................. 11

Install Managed Server in WebLogic............................................................................................ 11

Install Node Manager................................................................................................................ 14

Start the Managed Servers........................................................................................................ 18

Oracle Configuration Manager....................................................................................................... 19

Expand the Oracle Retail Allocation Application Distribution........................................... 19

Clustered Installations – Preinstallation Steps......................................................................... 20

Run the Oracle Retail Allocation Application Installer.......................................................... 20

Resolving Errors Encountered During Application Installation......................................... 21

Clustered Installations – Post-Installation Steps...................................................................... 21

Backups Created by Installer........................................................................................................... 21

Test the Oracle Retail Allocation Application........................................................................... 21

Modify allocation.properties........................................................................................................... 22

Calculation Server and Algorithms............................................................................................... 22

Allocation Batch Scripts................................................................................................................... 23

Online Help.......................................................................................................................................... 23

Single Sign-On..................................................................................................................................... 23

A Appendix: Oracle Retail Allocation Application Installer Screens........................ 25

B Appendix: Installer Silent Mode.......................................................................... 35

C Appendix: URL Reference................................................................................... 37

JDBC URL for a Database................................................................................................................. 37

JNDI Provider URL for an Application........................................................................................ 37

D Appendix: Common Installation Errors............................................................... 39

Unreadable buttons in the Installer............................................................................................... 39

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

ConcurrentModificationException in Installer GUI................................................................. 39

Warning: Could not find X Input Context................................................................................... 40

Installer Fails because of missing .jar in $ORACLE_HOME/utils/ccr/lib...................... 40

GUI screens fail to open when running Installer...................................................................... 40

"java.security.AccessControlException: access denied" Exception While Logging Into Allocation Application 41

Installer fails with sun.security.validator.KeyStores exception............................................ 41

Allocation Getting stuck at calculating status for HP-UX platform.................................... 42

E Appendix: Setting Up Password Stores with Oracle Wallet.................................. 43

About Password Stores and Oracle Wallet................................................................................. 43

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

Setting Up Wallets for Database User Accounts....................................................................... 45

For RMS, RWMS, RPM Batch, RETL, RMS, RWMS, and ARI........................................ 45

For Java Applications (SIM, ReIM, RPM, Alloc, RIB, RSL, AIP, RETL)....................... 47

How does the Wallet relate to the Application?........................................................................ 50

How does the Wallet relate to java batch program use?......................................................... 50

Setting up RETL Wallets................................................................................................................... 50

Quick Guide for Retail Wallets....................................................................................................... 53

F Appendix: Oracle Single Sign-On for WebLogic.................................................. 59

What Do I Need for Oracle Single Sign-On?............................................................................... 59

Can Oracle Access Manager Work with Other SSO Implementations?............................. 59

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

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

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

Installation Overview........................................................................................................................ 63

User Management............................................................................................................................... 64

G Appendix: Oracle 11g Database Parameter File................................................... 67

H Appendix: Oracle 12cR1 Database Parameter File............................................... 69

I Appendix: Configuring Listener and Tnsnames.................................................. 71

J Appendix: Installation Order............................................................................... 75

Enterprise Installation Order.......................................................................................................... 75

Preinstallation Tasks

This chapter explains the tasks required prior to installation.

Note: Oracle Retail product installations are tightly integrated with their technical configuration. After installation the application server hostname, database name and hostname, and other technical configuration is embedded within the installation of the Oracle Retail product. It is not recommended to attempt to copy an installation to a server with a different hostname for the purposes of environment cloning. The easiest and safest way to reconfigure applications on another server is to reinstall the applications using the Oracle Retail installers.

Requesting Infrastructure Software

If you are unable to find the necessary version of the required Oracle infrastructure software (database server, application server, WebLogic, etc.) on the Oracle Software Delivery Cloud, you should file a non-technical ‘Contact Us’ Service Request (SR) and request access to the media. For instructions on filing a non-technical SR, see My Oracle Support Note 1071023.1 – Requesting Physical Shipment or Download URL for Software Media.

Check Supported Database Server Requirements

General requirements for a database server running Oracle Retail Allocations include the following:

Supported on:	Versions Supported:
Database Server OS	OS certified with Oracle Database 11gR2 (11gR2) and 12cR1 (12.1.0.2) Enterprise Edition. Options are: § Oracle Enterprise Linux 5, 6 for x86-64 (Actual hardware or Oracle virtual machine). § Red Hat Enterprise Linux 5, 6 for x86-64 (Actual hardware or Oracle virtual machine). § AIX 6.1 (Actual hardware or LPARs) § AIX 7.1 (Actual hardware or LPARs) § Solaris 10, 11 Sparc (Actual hardware or Oracle VM Server for SPARC). § HP-UX 11.31 Integrity (Actual hardware or HPVM)
Database Server 11gR2	Oracle Database Enterprise Edition 11gR2 (11.2.0.4) with the following specifications: Components: § Oracle Partitioning § Examples CD (Formerly the companion CD) Oneoff Patches: § 18465025: MERGE REQUEST ON TOP OF 11.2.0.4.0 FOR BUGS 18016963 18302329. Other components: § Perl compiler 5.0 or later § X-Windows interface
Database Server 12cR1	Oracle Database Enterprise Edition 12cR1 (12.1.0.2) with the following specifications: Components: § Oracle Partitioning § Examples CD Oneoffs: § Patch 19623450: MISSING JAVA CLASSES AFTER UPGRADE TO JDK 7 § 20406840: PROC 12.1.0.2 THROWS ORA-600 [17998] WHEN PRECOMPILING BY 'OTHER' USER § 20925154: ORA-39126: WORKER UNEXPECTED FATAL ERROR IN KUPW$WORKER GATHER_PARSE_ITEMS JAVA § 18760297: DUMP IN QERTRCROWP WHEN TRACING WITH OPERAND LENGTH CHECK § 21614112: ORA-01732 ON DML ON A PARTITIONED TABLE RAC only: § 21260431: APPSST 12C : GETTING ORA-4031 AFTER 12C UPGRADE § 21373473: INSTANCE TERMINATED AS LMD0 AND LMD2 HUNG FOR MORE THAN 70 SECS Other components: § Perl interpreter 5.0 or later § X-Windows interface § JDK 1.7

Check Supported Application Server Requirements

General requirements for an application server capable of running the Oracle Retail Allocations application include the following.

Note: Files required for OCM (Oracle Configuration Manager) are removed after OPatch is used to patch the WebLogic server. This will cause the product installers and OCM installation to fail. To work around this issue, back up the content of the $ORACLE_HOME/utils/ccr/lib directory prior to applying a patch using OPatch, and recopy the content back after you apply any patches. ORACLE_HOME is the location where WebLogic Server has been installed.

Note: If using an OPatch on Linux 64-bit platforms, see Installer Fails because of missing .jar in $ORACLE_HOME/utils/ccr/lib in Appendix: Common Installation Errors.

Supported on:	Versions Supported:
Application Server OS	OS certified with Oracle Fusion Middleware 11g Release 1 (11.1.1.9). Options are: § Oracle Linux 5.x for x86-64 (Actual hardware or Oracle virtual machine). § Red Hat Enterprise Linux 5.x for x86-64 (Actual hardware or Oracle virtual machine). § 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.9) Components: § Oracle WebLogic Server 11g Release 1 (10.3.6) § Java: JDK 1.7.0+ 64 bit IMPORTANT: If there is an existing WebLogic installation on the server, you must upgrade it to WebLogic 10.3.6. All middleware components associated with WebLogic server should be upgraded to 11.1.1.9. Back up the weblogic.policy file ($WLS_HOME/wlserver_10.3/server/lib) before upgrading your WebLogic server, because this file could be overwritten. Copy over the weblogic.policy backup file after the WebLogic upgrade is finished and the post patching installation steps are completed. Optional (SSO required) § Oracle WebTier 11g (11.1.1.9) § Oracle Internet Directory 10gR3 (10.1.4) optionally with Oracle Single Sign-On 10gR3 (10.1.4) or § Oracle Identity Management 11gR1 (11.1.1.9) optionally with Oracle Single Sign-On 10gR3 (10.1.4) or § Oracle Identity Management 11gR1 (11.1.1.9) optionally with § Oracle Access Manager 11gR1 (11.1.2.3) using osso Agent. Must have separate WebLogic 10.3.6 for Oracle Access Manager 11g. or § Oracle Identity Management 11gR1 (11.1.1.9) optionally with Oracle Access Manager 11gR2 (11.1.2.3) using webgate 11gR2 (11.1.2.3) agent. Must have separate WebLogic 10.3.6 for Oracle Access Manager 11g.

Supported on:

Versions Supported:

Application Server OS

OS certified with Oracle Fusion Middleware 11g Release 1 (11.1.1.9). Options are:

§ Oracle Linux 5.x for x86-64 (Actual hardware or Oracle virtual machine).

§ Red Hat Enterprise Linux 5.x for x86-64 (Actual hardware or Oracle virtual machine).

§ 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.9)

Components:

§ Oracle WebLogic Server 11g Release 1 (10.3.6)

§ Java:

JDK 1.7.0+ 64 bit

IMPORTANT: If there is an existing WebLogic installation on the server, you must upgrade it to WebLogic 10.3.6. All middleware components associated with WebLogic server should be upgraded to 11.1.1.9.

Back up the weblogic.policy file ($WLS_HOME/wlserver_10.3/server/lib) before upgrading your WebLogic server, because this file could be overwritten. Copy over the weblogic.policy backup file after the WebLogic upgrade is finished and the post patching installation steps are completed.

Optional (SSO required)

§ Oracle WebTier 11g (11.1.1.9)

§ Oracle Internet Directory 10gR3 (10.1.4) optionally with Oracle Single Sign-On 10gR3 (10.1.4)

§ Oracle Identity Management 11gR1 (11.1.1.9) optionally with Oracle Single Sign-On 10gR3 (10.1.4)

§ Oracle Identity Management 11gR1 (11.1.1.9) optionally with

§ Oracle Access Manager 11gR1 (11.1.2.3) using osso Agent. Must have separate WebLogic 10.3.6 for Oracle Access Manager 11g.

§ Oracle Identity Management 11gR1 (11.1.1.9) optionally with Oracle Access Manager 11gR2 (11.1.2.3) using webgate 11gR2 (11.1.2.3) agent. Must have separate WebLogic 10.3.6 for Oracle Access Manager 11g.

Verify Single Sign-On

If Allocation will not be deployed in a Single Sign-On environment, skip this section.

If Single Sign-On is to be used, verify the Oracle Internet Directory 10gR3 version 10.1.4 or Oracle Identity Management 11gR1 version 11.1.1.9 has been installed along with the components listed in the above Application Server requirements section. Verify the Oracle WebTier Server is registered with the Oracle Access Manager 11gR1 as a partner application.

Note: Oracle Application Server (OAS) 10.1.4 Single Sign-On is only supported for existing installations, this support may be dropped in a future 13.2.X patch release.

Check Supported Client PC and Web Browser Requirements

Requirement	Version
Operating system	Windows 7
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.0+
Browser	Microsoft Internet Explorer 9 or 11 Mozilla Firefox ESR 31+

Configure Mozilla Firefox ESR31+

If you are using Firefox ESR31+, you need to configure the browser to display the list of values pop ups correctly.

1. Open your Firefox browser and type in your address bar as follows:

about:config

2. A warning dialog is displayed. Accept the warning.

A list of configuration values is displayed.

3. Locate the browser.link.open_newwindow property, right-click on it, and select Modify.

4. Change the value to 2.

5. Close and re-start the browser.

Supported Oracle Retail Products

Requirement	Version
Oracle Retail Active Retail Intelligence (ARI)	13.2
Oracle Retail Merchandising System (RMS)/Oracle Retail Trade Management (RTM)/Oracle Retail Sales Audit (ReSA)	13.2.9
Oracle Retail Price Management (RPM)	13.2.9
Oracle Retail Curve (part of the Oracle Retail Demand Forecasting product)	13.4.9
Oracle Retail Size Profile Optimization	13.4.9
Oracle Retail Assortment Planning	13.4.9

Supported Oracle Retail Integration Technologies

Requirement	Version
Oracle Retail Extract, Transform and Load (RETL)	13.2.5
Oracle Retail Service Layer (RSL)	13.2.9

UNIX User Account Privileges to Install the Software

A UNIX user account is needed to install the software. The UNIX user that is used to install the software should have write access to the WebLogic server installation files.

For example, oretail.

Note: Installation steps will fail when trying to modify files under the WebLogic installation, unless the user has write access.

Application Installation Tasks

Before proceeding, you must install Oracle WebLogic Server 11g Release 1 (10.3.6) and patches listed in the Chapter 1 of this document.

The Oracle Retail Allocation application is deployed to a WebLogic Managed server within the WebLogic installation. It is assumed Oracle database has already been configured and loaded with the appropriate RMS and Oracle Retail Allocation schemas for your installation.

If Oracle Forms 11g has been installed in the same WebLogic being used for this application, a domain called ClassicDomain is installed. Installing a separate domain under the same WebLogic server is recommended. It can be called APPDomain (or something similar) and will be used to install the non-ORACLE Forms managed servers. Applications such as RPM, SIM, Allocation, ReIM, RIB, AIP, and RSL can be installed in the APPDomain.

IMPORTANT: If there is an existing WebLogic installation on the server, you must upgrade WebLogic to WebLogic 10.3.6. All middleware components associated with WebLogic server should be upgraded to 11.1.1.9.

Install Managed Server in WebLogic

Important Note: Skip this section if a managed server already exists for Allocation.

Before running the application installer, you must install the managed server in WebLogic if it was not created during the domain install.

1. Log in to the admin console.

2. Click Lock & Edit.

3. Navigate to Environment > Servers and select new tab of the servers on the right side.

4. Set the following variables:

§ Server Name: These should be some name specific to your application targeted (for example, alloc-server or adf_MS).

§ Server Listen Address: <weblogic server> (i.e. redevlv0072.us.oracle.com)

§ Server Listen Port: A free port; you should check for availability.

A suggestion is to increment the AdminServer port by two and keep incrementing by two for each managed server (for example, 17003, 17005, 17007, 17009, and so on).

5. Click Next.

6. Click Finish.

7. Click Activate Changes on the left side.

Install Node Manager

Install Node Manager if it was not created during domain install. The node manager is required so that the managed servers can be started and stopped through the admin console. Only one node manager is needed per WebLogic installation.

1. Log in to the admin console.

2. Click Lock & Edit and navigate to Environments > Machines.

3. Click New.

4. Set the following variables:

§ Name: Logical machine name

§ Machine OS: UNIX

5. Click OK.

6. Click on the machine created.

7. Click on the Node manager tab and update the details below.

§ Type: Plain

§ Listen Address: redevlv0072.us.oracle.com

§ Listen Port: Node manager will be assigned a default port (for example, 5556).

8. Click Save.

9. Click Activate Changes.

10. Click Lock & Edit.

11. Navigate to Environments > machines. Click on the machine name and select the Servers tab.

12. Add the managed servers that need to be configured with the Node Manager. Save the changes.

13. Click Add.

14. Set the following variables:

§ Server: alloc-server

15. Click Next. Click Finish.

16. Click Activate Changes.

Note: In order to activate changes the server needs to be stopped:

$WLS_HOME/user_projects/domains/<domain_name>/bin/stopManagedWebLogic.sh ${server_name}:${server_port}

Start NodeManager from the server using the startNodeManager.sh at $WLS_HOME/wlserver_10.3/server/bin

17. Edit the nodemanager.properties file at the following location with the below values:

$WLS_HOME/wlserver_10.3/common/nodemanager/nodemanager.properties

§ SecureListener=false

§ StartScriptEnabled=true

§ StartScriptName=startWebLogic.sh.

18. NodeManager must be restarted after making changes to the nodemanager.properties file.

Note: The nodemanager.properties file is created after NodeManager is started for the first time. It will not be available before that point.

Start the Managed Servers

To start the managed servers, complete the following steps.

1. Start the Node Manager from the command line. If not already done in the “Install Node Manger” section before this.

$WEBLOGIC_HOME/wlserver_10.3/server/bin/startNodeManager.sh

After the Node Manager is started, the managed servers can be started via the admin console.

2. Navigate to Environments > Servers. Select <app-server> and click the Control tab.

3. Export WEBLOGIC_DOMAIN_HOME=<WLS_HOME>/user_projects/domains/<domain_name>

4. Update <WLS_HOME>/server/lib/weblogic.policy file with the below.

Note: If copying the following text from this guide to UNIX, ensure that it is properly formatted in UNIX. Each line entry beginning with "permission" must terminate on the same line with a semicolon.

Note: <WEBLOGIC_DOMAIN_HOME> in the following example is the full path of the Weblogic domain; <managed_server> is the Allocation managed server created; and <context_root> correlates to the value entered for the application deployment name/context root of the application that you will supply during installation. See the example. There should not be any spaces after file: in the following line:
file:<WEBLOGIC_DOMAIN_HOME>

grant codeBase "file: <WEBLOGIC_DOMAIN_HOME>/servers/<app>-server/tmp/_WL_user/<context_root>/-" {
permission java.security.AllPermission;
permission oracle.security.jps.service.credstore.CredentialAccessPermission "
credstoressp.credstore", "read,write,update,delete";
permission oracle.security.jps.service.credstore.CredentialAccessPermission "
credstoressp.credstore.*", "read,write,update,delete";

};

An example of the full entry that might be entered is:

grant codeBase "file:/u00/webadmin/product/10.3.x/WLS/user_projects/domains/APPDomain/servers/alloc-server/tmp/_WL_user/alloc01/-" {permission java.security.AllPermission;permission oracle.security.jps.service.credstore.CredentialAccessPermission "credstoressp.credstore", "read,write,update,delete";permission oracle.security.jps.service.credstore.CredentialAccessPermission "credstoressp.credstore.*", "read,write,update,delete";};

5. Restart the WebLogic admin server after making changes to the weblogic.policy file in the previous step.

Oracle Configuration Manager

The Oracle Retail OCM Installer packaged with this release installs the latest version of OCM.

The following document is available through My Oracle Support Access My Oracle Support at the following URL:

https://support.oracle.com

Oracle Configuration Manager Installer Guide (ID 1071030.1)

This guide describes the procedures and interface for the Oracle Retail Oracle Configuration Manager Installer that a retailer runs at the beginning of the installation process.

OCM Documentation Link

http://www.oracle.com/technology/documentation/ocm.html

Note: OCM is not supported on AIX 7.1

Expand the Oracle Retail Allocation Application Distribution

To expand the Oracle Retail Allocation application distribution, complete the following steps.

1. Log into the UNIX server as the user who owns the WebLogic installation. Create a new staging directory for the Oracle Retail Allocation application distribution (alloc13application.zip). There should be a minimum of 350 MB disk space available for the application installation files.

Example: /u00/webadmin/media/alloc

This location is referred to as INSTALL_DIR for the remainder of this chapter.

2. Copy alloc13application.zip to INSTALL_DIR and extract its contents.

Example: unzip alloc13application.zip

Clustered Installations – Preinstallation Steps

Skip this section if you are not clustering the application server.

1. Make sure that you are able to start and stop the managed servers that are part of the Allocation Cluster from the WebLogic Admin Console.

2. Insert into $WEBLOGIC_HOME/wlserver_10.3/server/lib/weblogic.policy file, the same entries for Java security permissions you entered on the main server (see the section, “Start the Managed Servers.”

There are no additional steps before running the installer for Allocation.

Run the Oracle Retail Allocation Application Installer

Once you have a managed server that is configured and started, you can run the Oracle Retail Allocation application installer. This installer configures and deploys the Oracle Retail Allocation application. It also configures, installs, and starts the calculation server.

Note: See Appendix: Oracle Retail Allocation Application Installer Screens for details about every screen and field in the application installer.

Note: It is recommended that the installer be run as the same UNIX account which owns the application server ORACLE_HOME files.

Note: If you are using AIX 7.1, the "retail-OCM-withAnt.zip" file present in the INSTALL_DIR/alloc must be renamed or removed, before running the installer. See Appendix: Common Installation Errors for more information.

1. Change directories to INSTALL_DIR/alloc/application.

2. Set the ORACLE_HOME, JAVA_HOME, and WEBLOGIC_DOMAIN_HOME environment variables. ORACLE_HOME should point to your WebLogic installation. JAVA_HOME should point to the Java 7.0+. WEBLOGIC_DOMAIN_HOME should point to the full path of the domain into which Allocation will be installed.

3. If you are using an X server such as Exceed, set the DISPLAY environment variable so that you can run the installer in GUI mode (recommended). If you are not using an X server, or the GUI is too slow over your network, unset DISPLAY for text mode.

4. Run the install.sh script. This launches the installer. After installation is completed, a detailed installation log file is created (alloc13install.<timestamp>.log). See Appendix: Oracle Retail Allocation Application Installer Screens for illustrations of installer screens and details about what information needs to be entered on each screen.

Resolving Errors Encountered During Application Installation

If the application installer encounters any errors, it halts execution immediately. You can run the installer in silent mode so that you do not have to re-enter the settings for your environment. See Appendix: Installer Silent Mode in this document for instructions on silent mode.

See Appendix: Common Installation Errors in this document for a list of common installation errors.

Because the application installation is a full reinstall every time, any previous partial installations are overwritten by the successful installation.

Clustered Installations – Post-Installation Steps

If you are installing the Oracle Retail Allocation application to a clustered WebLogic environment, extra steps are required to complete the installation. In these instructions, the application server node with the ORACLE_HOME you used for the Oracle Retail Allocation installer is referred to as the master node. All other nodes are referred to as remote nodes.

1. The Oracle Retail Installation creates security, calc server, and configuration files in the $WEBLOGIC_DOMAIN_HOME/retail/<alloc_application_name>/ directory. Copy this directory to each remote node of the cluster, matching the full path of the location of this directory on the master node.

2. The calculation server processes must be started separately on each remote node.
The calculation server process on the master node is automatically started by the Oracle Retail Allocation application installer.

Backups Created by Installer

The Oracle Retail Allocation application installer backs up a previous calc server installation by renaming it from calc to calc.<timestamp>. This is done to prevent the removal of any custom changes you might have. These backup directories can be safely removed without affecting the current installation.

Example: calc.200605011726

Test the Oracle Retail Allocation Application

After the application installer completes you should have a working Oracle Retail Allocation application installation. To launch the application, open a web browser and go to http://host:httpport/contextroot/index.jsp

Example: http://redevlv0072.us.oracle.com:17005/alloc01/index.jsp

Oracle Retail provides test cases that allow you to smoke test your installation. See the My Oracle Support document, Oracle Retail Merchandising Installation Test Cases (ID 1277131.1). The default, preloaded user supplied by the application to use in testing this installed application is RETEK; the password is retek. This information is stored in the database table, alc_users.

Modify allocation.properties

The allocation.properties file contains most of the settings for the Allocation application. Many properties in this file are set by the installer to get a working application up and running, but you may want to modify other settings in this file.

See the Oracle Retail Allocation Operations Guide for information about the settings in allocation.properties.

To modify settings in the properties file, you must redeploy the Alloc application. The properties values are stored in the templates/allocation.properties file, which is in the directory where you expanded the Alloc installer files (for example, <INSTALL_DIR>/alloc/application/templates/properties, where <INSTALL_DIR> is the directory in which the application installer was unzipped).

Edit the allocation.properties file to set the properties to the desired values then re-run the installer to deploy Allocation.

Calculation Server and Algorithms

The application installer configures and starts the Oracle Retail Allocation calculation server. The algorithm files are installed under <domain home>/retail/<alloc application name>/calc.

Note: The AIX algorithm was built for a 32-bit JRE. The 64 bit java release is not supported. Attempts to utilize the 64 bit release will cause calculation errors. The Allocation application installer sets the JAVA_HOME variable in <domain_name>retail/alloc132/calc/set.sh. This JAVA_HOME should point to a 32-bit 1.7 JDK.

The libstdc++ library must be installed on your system. The set.sh script looks for this library under /usr/local/bin by default. If you have this library in a different location you must modify LD_LIBRARY_PATH (Solaris), LIBPATH (AIX) in set.sh so that this file is found. libstdc++ 5.0.5 or later is required.

There is a known issue with calculation algorithm on HP-UX. Attempts to use calculation algorithm on HP-UX will result in calculation errors. Please refer Appendix: Common Installation Errors for more information on the issue.

The JAVA_HOME used by the calculation server is configured in the set.sh script by the Oracle Retail Allocation application installer using the JAVA_HOME of the installer.

For SUN OS

§ For SUN JDK 1.7, update set.sh with the JAVA_HOME of version JDK 1.7+64bit) or version JDK (1.7+) based on your OS. Make sure to verify queue.sh has –d64 option set for Java as follows.

command="$JAVA_HOME/bin/java -d64 -cp $CLASSPATH com.retek.alloc.queue.QueueProcess Queue -recalculation -prepack -standard_calculation -approval_stores -approval_next_destination $2"

The option, -d64, is required only for SUN OS.

For Linux OS

§ For SUN JDK 1.7, update set.sh with the JAVA_HOME of version JDK (1.7+64bit) or version JDK (1.7+64bit) based on your operating system.

command="$JAVA_HOME/bin/java -d64 -cp $CLASSPATH com.retek.alloc.queue.QueueProcess Queue -recalculation -prepack -standard_calculation -approval_stores -approval_next_destination $2"

To start and stop the calculation queue, respectively, run the following commands in <domain home>/retail/<alloc application name>/calc:

./queue.sh start 1

./queue.sh stop 1

To check the status of the calculation queue, run the following command in <domain home>/<alloc application name>/calc:
./queue.sh status 1

Allocation Batch Scripts

The Allocation application installer configures and installs the batch scripts under <domain home>/retail/alloc13/batch (for example, u00/webadmin/product/10.3.6/WLS/user_projects/domains/APPDomain/retail/alloc13/batch).

You must run the batch script with a Java wallet in the form of allocbatchscript.sh <dsAlias>, where <dsAlias> is the alias given in “Database Source details” screen of the installer, while installing Allocation application. This alias is a Java wallet name tied to an existing Allocation Database Source user (for example, dsAlias is tied to the user=rms01app). See “Appendix: Setting Up Password Stores with Oracle Wallet” for how to build a Java wallet).

For example: ./allocbatchscript.sh dsAlias

Note: Make sure that JAVA_HOME is set to the appropriate Java JDK (the same jdk which has been used by WebLogic Server) before running the Allocation batch programs.

Online Help

The application installer automatically installs Online Help to the proper location. It is accessible from the help links within the application.

Single Sign-On

Skip this section if Oracle Retail Allocation is not used within an Oracle Single Sign-On environment.

Note: This section assumes the Oracle WebLogic Server has already been registered with the Oracle Single Sign-On server via the regsso.sh script. See the Oracle Single Sign-On documentation for details.

If you are using Oracle Retail Allocation in an Oracle Single Sign-On environment using OSSO agent, then the Allocation context root must be protected. Modify the following files.

§ mod_wl_ohs.conf located in <WEBLOGIC_HOME>/Oracle_WT1/instances/instance1/config/OHS/ohs1

LoadModule weblogic_module "<WEBLOGIC_HOME>/Oracle_WT1/ohs/modules/mod_wl_ohs.so"

<IfModule weblogic_module>
      WebLogicHost host name
      WebLogicPort admin port number
      MatchExpression *.jsp
</IfModule>
<Location /allocation_sso >
     SetHandler weblogic-handler
</Location>

§ mod_osso.conf located in <WEBLOGIC_HOME>/Oracle_WT1/instances/instance1/config/OHS/ohs1/moduleconf

LoadModule osso_module "<WEBLOGIC_HOME>/Oracle_WT1/ohs/modules/mod_osso.so"

<IfModule mod_osso.c>
    OssoIpCheck off
    OssoIdleTimeout off
    OssoSecureCookies off
    OssoConfigFile <WEBLOGIC_HOME>/Oracle_WT1/instances/instance1/config/OHS/ohs1/osso/osso.conf
<Location /allocation_sso >
      WebLogicHost host name
      WebLogicPort port number of managed server
      require valid-user
      AuthType Osso
   </Location>
</IfModule>

If you are using Oracle Retail Allocation in an Oracle Single Sign-On environment using the Webgate agent then the Allocation context root must be protected. Modify the following files.

In the Webtier/Webgate http server, set the mod_wl_ohs.conf file to redirect the http call to the where the Alloc application has been deployed.

§ mod_wl_ohs.conf located in <WEBLOGIC_HOME>/Oracle_WT1/instances/instance1/config/OHS/ohs1

LoadModule weblogic_module "${ORACLE_HOME}/ohs/modules/mod_wl_ohs.so"

</IfModule>

WebLogicHost <weblogichostname>

WebLogicPort <AdminServerPort>

SetHandler weblogic-handler

</Location>

WebLogicHost <weblogichostname>

WebLogicPort <Allocserverport>

SetHandler weblogic-handler

</Location>

Note: In the above, modify ‘alloc13’ with the context root name used for installing Allocation application.

Appendix: Oracle Retail Allocation Application Installer Screens

You need the following details about your environment for the installer to successfully deploy the Oracle Retail Allocation application. Depending on the options you select, you may not see some screens or fields.

Screen: Application Server Details

Field Title	Hostname
Field Description	Hostname of the application server
Example	redevlv0072

Field Title	WebLogic Admin Port
Field Description	Port number of the WebLogic AdminServer
Example	17001

Field Title	WebLogic Admin User
Field Description	Username of the admin user for the WebLogic instance to which the Allocation application is being 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 or when you started the instance for the first time.

Field Title	WebLogic Admin User Security Alias
Field Description	An alias for the WebLogic admin user.
Example	wlsAlias
Note	This alias must be unique. Do not use the same value for any other alias fields in the installer. If the same alias is used, entries in the wallet can override each other and cause problems with the application.

Screen: Application Deployment Details

Field Title	Allocation App Deployment Name
Field Description	Name by which this Allocation application is identified in the application server. This name must match the <context_root> added to the weblogic.policy file when the managed server was created for Allocation.
Example	alloc01

Field Title	Allocation Context Root
Field Description	Path under the HTTP URL that is used to access the Allocation application. For example, a context root of alloc results in the application being accessed at http://host:port/alloc/index.jsp. This path must match the <context_root> added to the weblogic.policy file when the managed server was created for Allocation.
Example	alloc01

Field Title	Allocation Server/Cluster
Field Description	The name of the Allocation 13 WebLogic managed server or cluster.
Example	alloc-server

Screen: Data Source Details

Field Title	Alloc/RMS 13 JDBC URL
Field Description	URL used by the Allocation application to access the Allocation database schema. See Appendix C: URL Reference for expected syntax.
Destination	allocation.properties
Example	jdbc:oracle:thin:@redevlv0072:1521:csols13 For pluggable database : jdbc:oracle:thin:@<dbhostname>:<port>/<servicename>

Field Title	Allocation Schema User
Field Description	Database schema user of the Allocation application. This value should match what was given in the Allocation database schema field of the Allocation database installer. This is where the Allocation temporary tables and temporary views reside, with synonyms to other Allocation objects that are in the RMS main schema.
Destination	allocation.properties
Example	rms01app

Field Title	Allocation Schema Password
Field Description	Password for the Allocation schema user. This should match what was given in the Allocation 13 schema to create field of the Allocation database installer.
Destination	allocation.properties

Field Title	Database User Security Alias
Field Description	An alias for the Database user.
Destination	allocation.properties
Example	dsAlias

Field Title	RMS 13 Schema Owner
Field Description	RMS schema user into which the Allocation schema user has synonyms. This should match the RMS schema that was given during execution of the Allocation database schema installer. This is the RMS main schema, where the Allocation non temporary tables and objects are stored.
Destination	allocation.properties
Example	rms01
Note	This alias must be unique. Do not use the same value for any other alias fields in the installer. If the same alias is used, entries in the wallet can override each other and cause problems with the application.

Screen: Other Oracle Retail Applications

Field Title	RPM Application Name
Field Description	Application deployment name for RPM. This is the application deployment name/context root you used to install RPM.
Example	rpm13

Field Title	RPM Secure User
Field Description	Secure RPM Application login user Alias in the RPM wallet. This is a user alias used to tie the Allocation application to RPM for calls to things like future retail. This value is added to the allocation.properties file. This value is sent to RPM as a call from Allocation and uses the Java wallet name to call the RPM wallet alias, which would then have a real RPM application user/password as part of the RPM wallet.
Example	RETAIL.USER1 (RPM wallet alias names are upper case so this entry must be upper case)

Screen: Oracle Retail Application URLs

Field Title	RPM JNDI provider URL (optional)
Field Description	URL which Allocation uses to find the RPM application. See Appendix C: URL Reference for expected syntax. RPM is not a requirement for Allocation. It is optional, but it is recommended for most customers.
Destination	jndi_providers.xml
Example	t3//redevlv0072.us.oracle.com:17011/rpm13

Field Title	RSL for RMS JNDI provider URL (optional)
Field Description	URL which Allocation uses to find the RSL application. See “Appendix: URL Reference” for expected syntax. RSL is not a requirement for Allocation. It is optional, but it is recommended for most customers.
Destination	jndi_providers.xml
Example	t3//redevlv0072.us.oracle.com:17013/rsl-rms

Appendix: Common Installation Errors

This section provides some common errors encountered during installation of Oracle Retail Allocation.

Unreadable buttons in the Installer

If you are unable to read the text within the installer buttons, it could mean that your JAVA_HOME is pointed to an older version of the JDK that is supported by the installer. Set JAVA_HOME to a valid java java 1.7.0 jdk.

Warning: Could not create system preferences directory

Symptom

The following text appears in the installer Errors tab:

May 22, 2006 11:16:39 AM java.util.prefs.FileSystemPreferences$3 run

WARNING: Could not create system preferences directory. System preferences are unusable.

May 22, 2006 11:17:09 AM java.util.prefs.FileSystemPreferences checkLockFile0ErrorCode

WARNING: Could not lock System prefs. Unix error code -264946424.

Solution

This is related to Java bug 4838770. The /etc/.java/.systemPrefs directory may not have been created on your system. See http://bugs.sun.com for details.

This is an issue with your installation of Java and does not affect the Oracle Retail product installation.

ConcurrentModificationException in Installer GUI

Symptom

In GUI mode, the errors tab shows the following error:

java.util.ConcurrentModificationException

at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:448)

at java.util.AbstractList$Itr.next(AbstractList.java:419)

… etc

Solution

You can ignore this error. It is related to third-party Java Swing code for rendering of the installer GUI and does not affect the retail product installation.

Warning: Could not find X Input Context

Symptom

The following text appears in the console window during execution of the installer in GUI mode:

Couldn't find X Input Context

Solution

This message is harmless and can be ignored.

Installer Fails because of missing .jar in $ORACLE_HOME/utils/ccr/lib

Symptom

The jar file expected by the installer (emocmclnt.jar) is overwritten after the OPatch patch 6880880 is applied, and any other patch is applied afterwords using that OPatch. If you try running the installer after patching, as outlined in the installation guides, the installer fails. All applications that are installed in the same WebLogic server that hosts any of the forms applications will be affected by this issue. This is because of required Oracle patches for Linux 64-bit systems that are applied to the forms server.

Solution

Back up the content of the $ORACLE_HOME/utils/ccr/lib directory prior to applying OPatch patch 6880880, and recopy the content back after you apply any patches using that opatch.

GUI screens fail to open when running Installer

Symptom

When running the installer in GUI mode, the screens fail to open and the installer ends, returning to the console without an error message. The ant.install.log file contains this error:

Fatal exception: Width (0) and height (0) cannot be <= 0
java.lang.IllegalArgumentException: Width (0) and height (0) cannot be <= 0

Solution

This error is encountered when Antinstaller is used in GUI mode with certain X Servers. To work around this issue, copy ant.install.properties.sample to ant.install.properties and rerun the installer.

"java.security.AccessControlException: access denied" Exception While Logging Into Allocation Application

Symptom

After installation and upon login to the application, login fails and an Internet Explorer Error 500 is prompted. The following error is noted in alloc-server.out:

.... com.oracle.retail.integration.common.security.credential.CredentialStoreManager getUserName
SEVERE: Unable to obtain the userName for the given key/userNameAlias(dsAlias).
java.security.AccessControlException: access denied (oracle.security.jps.service.credstore.CredentialAccessPermission context=SYSTEM,mapName=alloc13,keyName=dsAlias read)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:374)

Solution

1. Shut down the Admin Server.

2. Modify file: $/wlserver_10.3/server/lib/weblogic.policy to comment out

//
// For standard extensions directories
// grant codeBase "file:/patch_wls1036/patch_jars/-" {
permission java.security.AllPermission;
};

Note: The path must be changed to reflect the absolute path to ${MW_HOME}/${wlspatch}/patch_jars/

3. Restart the Admin Server.

Installer fails with sun.security.validator.KeyStores exception

Symptom

Installer first throws the error:

Exception in thread "main" java.lang.NoClassDefFoundError: sun.security.validator.KeyStores

Then, on continuing, aborts with the same error.

Solution

OCM does not work on AIX 7.1. The workaround after facing this exception is to recreate the INSTALL_DIR and then delete the "retail-OCM-withAnt.zip" file present in INSTALL_DIR/alloc directory, before running the installer.

Allocation Getting stuck at calculating status for HP-UX platform

Symptom

When allocation is calculated for rules other than manual in HP-UX platform, the calculation stuck at calculating status with errors in the calculation queue log:

**** About to load Calc Engine Library ****

**** Error: Calc Engine not loaded due to UnsatisfiedLinkError :

Solution

Currently there is a known open issue in HP-UX platform which is obstructing the successful calculation of allocation. Please contact Oracle support to get the latest update/resolution on this issue.

Appendix: Setting Up Password Stores with Oracle Wallet

As part of an application installation, administrators must set up password stores for database user accounts using Oracle Wallet. These 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.

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

About Password Stores and Oracle Wallet

Oracle databases have allowed other users on the server to see passwords when 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, then the argument to a program would be the following:

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 two different types of password stores or wallets. One type is for database connect strings used in program arguments (such as sqlplus /@db_username). The other type is 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, RETL, RMS, RWMS, and ARI

§ For Java Applications (SIM, ReIM, RPM, Alloc, RIB, RSL, AIP, RETL)

For RMS, RWMS, RPM Batch, 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/rms13.2/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/rms13.2/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.4/network/admin/tnsnames.ora

dvols29_rms01user =

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

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

(CONNECT_DATA = (SID = dvols29) (GLOBAL_NAME = dvols29)))

dvols29_rms01user.world =

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

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

(CONNECT_DATA = (SID = dvols29) (GLOBAL_NAME = dvols29)))

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/rms13.2/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/rms13.2/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 11

Connected to:

Oracle Database 11g

SQL> show user

USER is “rms01user”

Running batch programs or shell scripts is 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 value of the entry:

rms01user

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

Returns value of the entry:

passwd

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

For Java application, 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:
mspdv351:[1036_WLS] /u00/webadmin/product/10.3.x/WLS/user_projects/
domains/132_mck_soa_domain/retail/reim13/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:

mspdv351:[1036_WLS] /u00/webadmin/product/10.3.x/WLS/user_projects/
domains/132_mck_soa_domain/retail/reim13/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 application 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:

mspdv351:[1036_WLS] /u00/webadmin/reim/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:

mspdev71:[1036WLS] /u00/webadmin/product/10.3.x/WLS/user_projects/domains/java_domain/retail/rpm132test/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.

mspdev71:[1036WLS] /u00/webadmin/product/10.3.x4/WLS/user_projects/domains/java_domain/retail/rpm132test/retail-public-security-api/bin>

dump_credentials.sh

dump_credentials.sh is used to retrieve information from the 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/132_mck_soa_domain/retail/reim13/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/132_mck_soa_domain/retail/reim13/config

=============================================

Application level key partition name:reim13
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:rms132mock
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:

mspdv351:[1036_WLS] /u00/webadmin/mock132_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 update a wallet entry, bounce the application/managed server so the changes are visible to the application. Also, save a backup copy of the cwallet.sso file in a location outside of the deployment path, because a redeployment/reinstallation of the application will wipe out the wallet entries you made after the application was installed. To restore wallet entries after a redeployment or 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 = reim13 to retrieve the password for application use.

Reim.properties code sample:

datasource.url=jdbc:oracle:thin:@mspdv349.us.oracle.com:1521:pkols07

datasource.schema.owner=rms132mock

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/132_mck_soa_domain/retail/reim13/config

csm.wallet.partition.name=reim13

Note:

For Pluggable database REIM code sample:

datasource.url=jdbc:oracle:thin:@mspdv349.us.oracle.com:1521/pkols07s

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 dsAlias maps through the wallet to dbuser rms01app, already on the database. To run a Alloc batch program the format would be: allocbatchpgmname dsAlias <other arguments as needed by the program in question>

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.2.0

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

§ JAVA_HOME=/usr/jdk1.7..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
$MMHOME/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.

Quick Guide for Retail Wallets

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 (MMHOME)>/.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 app	DB	<RPM batch install dir>/.wallet	n/a	<rms schema owner alias>	<rms schema owner>	Execute batch	Manual	rms-alias
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	rwms13inst
			<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
			aip13	<AIP weblogic user alias>	<AIP weblogic user name>	App use	Installer	aip-weblogic-alias
			aip13	<AIP database schema user alias>	<AIP database schema user name>	App use	Installer	aip01user-alias
			aip13	<rib-aip weblogic user alias>	<rib-aip weblogic user name>	App use	Installer	rib-aip-weblogic-alias
RPM app	JAVA	<weblogic domain home>/retail/<deployed rpm app name>/config							Each alias must be unique
			rpm13	<rpm weblogic user alias>	<rpm weblogic user name>	App use	Installer	rpm-weblogic-alias
			rpm13	<rms shema user alias>	<rms shema user name>	App, batch use	Installer	rms01user-alias
			rpm13	<rpm application user one alias>	<rpm application user one name>	App use	Installer	user1-alias
			rpm13	<rpm application user two alias>	<rpm application user two name>	App use	Installer	user2-alias
			rpm13	<rpm batch user alias>	<rpm batch user name>	App, batch use	Installer	rpmbatch-alias
			rpm13	<rib-rpm weblogic user alias>	<rib-rpm weblogic user name>	App use	Installer	rib-rpm-weblogic-alias
ReIM app	JAVA	<weblogic domain home>/retail/<deployed reim app name>/config							Each alias must be unique
			<installed app name>	<reim weblogic user alias>	<reim weblogic user name>	App use	Installer	weblogic-alias
			<installed app name>	<rms shema user alias>	<rms shema user name>	App, batch use	Installer	rms01user-alias
			<installed app name>	<reim webservice validation user alias>	<reim webservice validation user name>	App use	Installer	reimwebservice-alias
			<installed app name>	<reim batch user alias>	<reim batch user name>	App, batch use	Installer	reimbatch-alias
Alloc app	JAVA	<weblogic domain home>/retail/<deployed alloc app name>/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 shema user alias>	<rms shema user name>	App use	Installer	rms01user-alias
			<installed app name>	<rsl for rms weblogic user alias>	<rsl for rms weblogic user name>	App use	Installer	rsl-rms-weblogic-alias
RSL app	JAVA	<RSL INSTALL DIR>/rsl-rms/security/config							Each alias must be unique
			rsl-rsm	<rsl weblogic user alias>	<rsl weblogic user name>	App use	Installer	weblogic-alias
			rsl-rsm	<rms shema user alias>	<rms shema user name>	App use	Installer	rms01user-alias
SIM app	JAVA	<weblogic domain home>/retail/<deployed sim app name>/config
			rpm	<rpm weblogic user alias>	<rpm weblogic user name>	App use	Installer	rpm-weblogic-alias
			rms	<rsl for rms weblogic user alias>	<rsl for rms weblogic user name>	App use	Installer	rsl-rms-weblogic-alias
			rib-sim	<rib-sim weblogic user alias>	<rib-sim weblogic user name>	App use	Installer	rib-sim-weblogic-alias
RETL	JAVA	<RETL home>/etc/security	n/a	<target application user alias>	<target application db userid>	App use	Manual	retl_java_rms01user	User may vary depending on RETL flow’s target application
RETL	DB	<RETL home>/.wallet	n/a	<target application user alias>	<target application db userid>	App use	Manual	<db>_<user>	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>	<jms user alias> for jms<1-5>	<jms user name> for jms<1-5>	Integration use	Installer	jms-alias
Weblogic			rib-<app>-app-server-instance	<rib-app weblogic user alias>	<rib-app weblogic user name>	Integration use	Installer	weblogic-alias
Admin GUI			rib-<app>#web-app-user-alias	<rib-app admin gui user alias>	<rib-app admin gui user name>	Integration use	Installer	admin-gui-alias
Application			rib-<app>#user-alias	<app weblogic user alias>	<app weblogic user name>	Integration use	Installer	app-user-alias	Valid only for aip, rpm, sim
DB			rib-<app>#app-db-user-alias	<rib-app database schema user alias>	<rib-app database schema user name>	Integration 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>	Integration use	Installer	hosp-user-alias

Appendix: Oracle Single Sign-On for WebLogic

Single Sign-On (SSO) is a term for the ability to sign onto multiple Web applications via a single user ID/Password. There are many implementations of SSO. Oracle currently provides two different implementations: Oracle Single Sign-On (OSSO), and Oracle Access Manager (provides more comprehensive user access capabilities).

Most, if not all, SSO technologies use a session cookie to hold encrypted data passed to each application. The SSO infrastructure has the responsibility to validate these cookies and, possibly, update this information. The user is directed to log on only if the cookie is not present or has become invalid. These session cookies are restricted to a single browser session and are never written to a file.

Another facet of SSO is how these technologies redirect a user’s Web browser to various servlets. The SSO implementation determines when and where these redirects occur and what the final screen shown to the user is.

Most SSO implementations are performed in an application’s infrastructure and not in the application logic itself. Applications that leverage infrastructure managed authentication (such as deployment specifying Basic or Form authentication) typically have little or no code changes when adapted to work in an SSO environment.

What Do I Need for Oracle Single Sign-On?

The nexus of an Oracle Single Sign-On system is the Oracle Identity and Access Management installation. This consists of the following components:

§ An Oracle Internet Directory (OID) LDAP server, used to store user, role, security, and other information. OID uses an Oracle database as the back-end storage of this information.

§ An Oracle Access Manager (OAM) 11g Release 1 server and administrative console for implementing and configuring policies for single sign-on.

§ A Policy Enforcement Agent such as Oracle Access Manager 11g Agent (WebGate) or Oracle Single Sign-On Plug-in, used to authenticate the user and create the Single Sign-On cookies. Some Retail products require a WebGate agent and others require an OSSO plug-in. Both can interoperate in a single OAM environment.

§ The Delegated Administration Services (DAS) application in Oracle Forms Services 11g Release 2 and Oracle Directory Services Manager (ODSM) application in OIM11g, used to administer users and group information. This information may also be loaded or modified via standard LDAP Data Interchange Format (LDIF) scripts.

§ Additional administrative scripts for configuring the OAM system and registering HTTP servers.

Additional WebLogic managed servers will be needed to deploy the business applications leveraging the Single Sign-On technology.

Can Oracle Access Manager Work with Other SSO Implementations?

Yes, Oracle Access Manager has the ability to interoperate with many other SSO implementations, but some restrictions exist.

Oracle Single Sign-on Terms and Definitions

The following terms apply to single sign-on.

Authentication

Authentication is the process of establishing a user’s identity. There are many types of authentication. The most common authentication process involves a user ID and password.

Dynamically Protected URLs

A Dynamically Protected URL is a URL whose implementing application is aware of the Oracle Access Manager environment. The application may allow a user limited access when the user has not been authenticated. Applications that implement dynamic protection typically display a Login link to provide user authentication and gain greater access to the application’s resources.

Oracle Identity Management (OIM) and Oracle Access Manager (OAM) for 11g

Oracle Identity Management (OIM) 11g includes Oracle Internet Directory and ODSM. Oracle Access Manager (OAM) 11g should be used for SSO using WebGate or OSSO agents depending on the application. Oracle Forms 11g contains Oracle HTTP server and other Retail Applications will use WebTier11g for HTTP.

MOD_OSSO

mod_osso is an Apache Web Server module an Oracle HTTP Server uses to function as a partner application within an Oracle Access Manager environment. The Oracle HTTP Server is based on the Apache HTTP Server.

MOD_WEBLOGIC

mod_WebLogic operates as a module within the HTTP server that allows requests to be proxied from the Apache HTTP server to the WebLogic server.

Oracle Access Manager 11g Agent (WebGate)

Oracle WebGates are policy enforcement agents which reside with relying parties and delegate authentication and authorization tasks to OAM servers.

Oracle Internet Directory

Oracle Internet Directory (OID) is an LDAP-compliant directory service. It contains user ids, passwords, group membership, privileges, and other attributes for users who are authenticated using Oracle Access Manager.

Partner Application

A partner application is an application that delegates authentication to the Oracle Identity Management Infrastructure. One such partner application is the Oracle HTTP Server (OHS) supplied with Oracle Forms Server or WebTier11g Server if using other Retail Applications other than Oracle Forms Applications. OHS or WebTier uses the MOD_OSSO module to configure this functionality.

All partner applications must be registered with Oracle Access Manager (OAM) 11g. An output product of this registration is a configuration file the partner application uses to verify a user has been previously authenticated.

Realm

A Realm is a collection users and groups (roles) managed by a single password policy. This policy controls what may be used for authentication (for example, passwords, X.509 certificates, and biometric devices). A Realm also contains an authorization policy used for controlling access to applications or resources used by one or more applications.

A single OID can contain multiple Realms. This feature can consolidate security for retailers with multiple banners or to consolidate security for multiple development and test environments.

Statically Protected URLs

A URL is considered to be Statically Protected when an Oracle HTTP server is configured to limit access to this URL to only SSO authenticated users. Any attempt to access a Statically Protected URL results in the display of a login page or an error page to the user.

Servlets, static HTML pages, and JSP pages may be statically protected.

Note: Dynamically Protected URL and Statically Protected URL are within the context of the Oracle Software Security Assurance (OSSA). The static protection for URLs is a common JEE feature.

What Single Sign-On is not

Single Sign-On is NOT a user ID/password mapping technology.

However, some applications can store and retrieve user IDs and passwords for non-SSO applications within an OID LDAP server. An example of this is the Oracle Forms Web Application framework, which maps Single Sign-On user IDs to a database logins on a per-application basis.

How Oracle Single Sign-On Works

Oracle Access Manager involves several different components. These are:

§ The Oracle Access Manager (OAM) server, which is responsible for the back-end authentication of the user.

§ The Oracle Internet Directory LDAP server, which stores user IDs, passwords, and group (role) membership.

§ The Oracle Access Manager Agent associated with the Web application, which verifies and controls browser redirection to the Oracle Access Manager server.

§ If the Web application implements dynamic protection, then the Web application itself is involved with the OAM system.

About SSO Log In Processing with OAM Agents

1. The user requests a resource.

2. Webgate forwards the request to OAM for policy evaluation

3. OAM:

a. Checks for the existence of an SSO cookie.

b. Checks policies to determine if the resource is protected and if so, how?

4. OAM Server logs and returns the decision

5. Webgate responds as follows:

§ Unprotected Resource: Resource is served to the user

§ Protected Resource:
Resource is redirected to the credential collector.
The login form is served based on the authentication policy.
Authentication processing begins

6. User sends credentials

7. OAM verifies credentials

8. OAM starts the session and creates the following host-based cookies:

§ One per partner: OAMAuthnCookie set by 11g WebGates using authentication token received from the OAM Server after successful authentication.
Note: A valid cookie is required for a session.

§ One for OAM Server: OAM_ID

9. OAM logs Success of Failure.

10. Credential collector redirects to WebGate and authorization processing begins.

11. WebGate prompts OAM to look up policies, compare them to the user's identity, and determine the user's level of authorization.

12. OAM logs policy decision and checks the session cookie.

13. OAM Server evaluates authorization policies and cache the result.

14. OAM Server logs and returns decisions

15. WebGate responds as follows:

§ If the authorization policy allows access, the desired content or applications are served to the user.

§ If the authorization policy denies access, the user is redirected to another URL determined by the administrator.

SSO Login Processing with OAM Agents

Authentication and authorization processes

Installation Overview

Installing Oracle Single Sign-On using OAM11g requires installation of the following:

1. Oracle Internet Directory (OID) ldap server and the Oracle Directory Services Manager. They are typically installed using the Installer of Oracle Identity Management 11gR1 (11.1.1.9). The ODSM application can be used for user and realm management within OID.

2. Oracle Access Manager 11gR1 (11.1.2.3) has to be installed and configured.

3. Additional midtier instances (such as Oracle Forms 11g) for Oracle Retail applications based on Oracle Forms technologies (such as RMS). These instances must be registered with the OAM installed in step 2.

4. Additional application servers to deploy other Oracle Retail applications and performing application specific initialization and deployment activities must be registered with OAM installed in step 2. For additional information on SSO 11g installation, see the Oracle Access Manager and Single Sign-On Whitepaper (My Oracle Support Doc ID 1492047.1).

Infrastructure Installation and Configuration

The Infrastructure installation for Oracle Access Manager (OAM) is dependent on the environment and requirements for its use. Deploying Oracle Access Manager (OAM) to be used in a test environment does not have the same availability requirements as for a production environment. Similarly, the Oracle Internet Directory (OID) LDAP server can be deployed in a variety of different configurations. See the Oracle Identity Management Installation Guide11g.

OID User Data

Oracle Internet Directory is an LDAP v3 compliant directory server. It provides standards-based user definitions out of the box.

Customers with existing corporate LDAP implementations may need to synchronize user information between their existing LDAP directory servers and OID. OID supports standard LDIF file formats and provides a JNDI compliant set of Java classes as well. Moreover, OID provides additional synchronization and replication facilities to integrate with other corporate LDAP implementations.

Each user ID stored in OID has a specific record containing user specific information. For role-based access, groups of users can be defined and managed within OID. Applications can thus grant access based on group (role) membership saving administration time and providing a more secure implementation.

OID with Multiple Realms

OID can be configured to support multiple user Realms. Each realm is independent from each other and contains its own set of user IDs. As such, creating a new realm is an alternative to installing multiple OID and Infrastructure instances. Hence, a single Infrastructure OAS can be used to support development and test environments by defining one realm for each environment.

Realms may also be used to support multiple groups of external users, such as those from partner companies. For more information on Realms, see the Oracle Internet Directory Administrators Guide.

User Management

User Management consists of displaying, creating, updating or removing user information. There are two basic methods of performing user management: LDIF scripts or Oracle Directory Services Manager (ODSM) available for OID11g.

ODSM

Oracle Directory Services Manager (ODSM) is a Web-based application used in OID11g is designed for both administrators and users which enables you to configure the structure of the directory, define objects in the directory, add and configure users, groups, and other entries. ODSM is the interface you use to manage entries, schema, security, adapters, extensions, and other directory features.

LDIF Scripts

Script based user management can be used to synchronize data between multiple LDAP servers. The standard format for these scripts is the LDAP Data Interchange Format (LDIF). OID supports LDIF script for importing and exporting user information. LDIF scripts may also be used for bulk user load operations.

User Data Synchronization

The user store for Oracle Access Manager resides within the Oracle Internet Directory (OID) LDAP server. Oracle Retail applications may require additional information attached to a user name for application-specific purposes and may be stored in an application-specific database. Currently, there are no Oracle Retail tools for synchronizing changes in OID stored information with application-specific user stores. Implementers should plan appropriate time and resources for this process. Oracle Retail strongly suggests that you configure any Oracle Retail application using an LDAP for its user store to point to the same OID server used with Oracle Access Manager.

Appendix: Oracle 11g Database Parameter File

###############################################################################

# Oracle 11.2.0.x Parameter file

# NOTES: Before using this script:

# 1. Change <datafile_path>, <admin_path>, <utl_file_path>, <diag_path> and <hostname>

# values as appropriate.

# 2. Replace the word SID with the database name.

# 3. Size parameters as necessary for development, test, and production environments.

# ------------------------------------------------------------------------

# MAINTENANCE LOG

# Date By Parameter Old/New Notes

# +------+ +---------+ +-----------------+ +-------------+ +-------------+

###############################################################################

# -------------------------------------------------------------------------------

# The policy is to give 60% for sga and 40% for PGA out of Memory Target at startup

# -------------------------------------------------------------------------------

memory_target = 2000M

# --------------------------------------------------------------------------------

audit_file_dest = <admin_path>/adump

compatible = 11.2.0

control_files = (<datafile_path>/control01.ctl

,<datafile_path>/control02.ctl)

db_block_size = 8192 # Default is 2k; adjust before db creation, cannot change after db is created

db_file_multiblock_read_count = 16 # Platform specific (max io size)/(block size)

db_name = SID

diagnostic_dest = '<diag_path>'

java_pool_size = 100M

job_queue_processes = 5 # Oracle Retail required; number of cpu's + 1

local_listener = "(ADDRESS=(PROTOCOL=TCP)(HOST=<hostname>)(PORT=1521))"

nls_calendar = GREGORIAN

nls_date_format = DD-MON-RR # Oracle Retail required; if RDW database see later entry for proper format

nls_language = AMERICAN # Default

nls_numeric_characters = ".," # Should be explicitly set to ensure all users/batch get the same results

nls_sort = BINARY # Should be explicitly set to ensure all sessions get the same order

nls_territory = AMERICA # Default

open_cursors = 900 # Oracle Retail required (minimum=900); default is 50

plsql_optimize_level = 2 # 10g change; use this setting to optimize plsql performance

processes = 2000 # Max number of OS processes that can connect to the db

query_rewrite_enabled = TRUE # Oracle Retail required for function-based indexes

session_cached_cursors = 900 # Oracle Retail required;

undo_management = AUTO

undo_retention = 1800 # Currently set for 30 minutes; set to avg length of transactions in sec

undo_tablespace = undo_ts

user_dump_dest = <admin_path>/udump

utl_file_dir = <utl_file_path>

workarea_size_policy = auto # Should be set to auto when pga_aggregate_target is set

# *** Set these parameters for Oracle Retail Data Warehouse (RDW) database ***

#nls_date_format = DD-MON-RRRR # Required by MicroStrategy

#query_rewrite_integrity = TRUSTED

#star_transformation_enabled = TRUE

#utl_file_dir = <Windows_utl_file_path>, <UNIX_util_file_path>

# *** Archive Logging, set if needed ***

#log_archive_dest_1 = 'location=<admin_path>/arch/'

#log_archive_format = SIDarch_%r_%s_%t.log

#log_buffer = 10485760 # Set to (512K or 128K)*CPUs

#log_checkpoint_interval = 51200 # Default:0 - unlimited

#log_checkpoint_timeout = 7200 # Default:1800 seconds

Appendix: Configuring Listener and Tnsnames

Note: This example illustrates the listener configuration for External procedures, container and non-container databases. . It does not include environment specific settings that may be needed. Consult Oracle Net Services guides for additional information

#################################################################

# File: listener.ora

# Desc: Oracle Net8 listener file.

# Notes: Modify <hostname>

#################################################################

LISTENER =

(DESCRIPTION_LIST =

(DESCRIPTION =

(PROTOCOL_STACK =

(PRESENTATION = TTC)

(SESSION = NS))

(ADDRESS =

(PROTOCOL = tcp)

(HOST = <hostname>)

(PORT = 1521))

(ADDRESS =

(PROTOCOL = IPC)

(KEY = extproc_key))

)

SID_LIST_LISTENER =

(SID_LIST =

(SID_DESC =

(PROGRAM = extproc)

(SID_NAME = extproc_agent_1521)

(ORACLE_HOME = /u00/oracle/product/12.1.0.2)

(ENVS='EXTPROC_DLLS=ANY')

)

(SID_DESC =

(SID_NAME = prod_sid1)

(ORACLE_HOME = /u00/oracle/product/12.1.0.2)

(ENVS='TNS_ADMIN=/dba/network/extproc_1521')

)

Note: This example illustrates the configuration of net services for External procedures, container and non-container databases. It does not include environment specific settings that may be needed. Consult Oracle Net Services guides for additional information

#################################################################

# File: tnsnames.ora

# Desc: Net Services configuration file.

# Note: Change these values: <service_name>, <oracle_sid>, <hostname>,

# <global_name>

#################################################################

EXTPROC_CONNECTION_DATA =

(DESCRIPTION =

(ADDRESS_LIST = (ADDRESS = (PROTOCOL = IPC)(Key = extproc_key)))

(CONNECT_DATA = (SID = extproc_agent)))

EXTPROC_CONNECTION_DATA.world =

(DESCRIPTION =

(ADDRESS_LIST = (ADDRESS = (PROTOCOL = IPC)(Key = extproc_key)))

(CONNECT_DATA = (SID = extproc_agent)))

< Connect_string> =

(DESCRIPTION =

(ADDRESS_LIST = (ADDRESS = (PROTOCOL = tcp)(host = <hostname>)(Port = 1521)))

(CONNECT_DATA = (Service_Name = <Service_Name>) (GLOBAL_NAME = <global_name>)))

<Connect_String>.world =

(DESCRIPTION =

(ADDRESS_LIST = (ADDRESS = (PROTOCOL = tcp)(host = <hostname>)(Port = 1521)))

(CONNECT_DATA = (Service_Name = <Service_Name> >) (GLOBAL_NAME = <global_name>)))

< Connect_string> = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = tcp)(host = server_01)(Port = 1521))) (CONNECT_DATA = (SERVICE_NAME = <Service_Name>))))

<Service_Name>.world = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = tcp)(host = server_01)(Port = 1521))) (CONNECT_DATA = (SERVICE_NAME = <Service_Name>))))

Example:

EXTPROC_CONNECTION_DATA =

(DESCRIPTION =

(ADDRESS_LIST = (ADDRESS = (PROTOCOL = IPC)(Key = extproc_key)))

(CONNECT_DATA = (SID = extproc_agent)))

EXTPROC_CONNECTION_DATA.world =

(DESCRIPTION =

(ADDRESS_LIST = (ADDRESS = (PROTOCOL = IPC)(Key = extproc_key)))

(CONNECT_DATA = (SID = extproc_agent)))

Database configuration for tnsnames entries (Container and Non-container):

prod_sid1 =

(DESCRIPTION =

(ADDRESS_LIST = (ADDRESS = (PROTOCOL = tcp)(host = server_01)(Port = 1521)))

(CONNECT_DATA = (Service_Name = prod_sid1) (GLOBAL_NAME = prod_sid1.world)))

prod_sid1.world =

(DESCRIPTION =

(ADDRESS_LIST = (ADDRESS = (PROTOCOL = tcp)(host = server_01)(Port = 1521)))

(CONNECT_DATA = (Service_Name = prod_sid1) (GLOBAL_NAME = prod_sid1.world)))

Pluggable Database configuration for tnsnames entries:

pdb1 = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = tcp)(host = server_01)(Port = 1521))) (CONNECT_DATA = (SERVICE_NAME = pdb1)))

pdb1.world = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = tcp)(host = server_01)(Port = 1521))) (CONNECT_DATA = (SERVICE_NAME = pdb1)))

Oracle Retail VAR Applications

Configure Mozilla Firefox ESR31+

References for Configuration:

Application Installation Tasks

OCM Documentation Link

For SUN OS

For Linux OS

Appendix: Oracle Retail Allocation Application Installer Screens

Screen: Application Server Details

Screen: Application Deployment Details

Screen: Data Source Details

Screen: Other Oracle Retail Applications

Screen: Oracle Retail Application URLs

Appendix: Installer Silent Mode

Appendix: URL Reference

Appendix: Common Installation Errors

Symptom

Solution

Symptom

Solution

Symptom

Solution

Installer Fails because of missing .jar in $ORACLE_HOME/utils/ccr/lib

Symptom

Solution

Symptom

Solution

Symptom

Solution

Appendix: Setting Up Password Stores with Oracle Wallet

For RMS, RWMS, RPM Batch, RETL, RMS, RWMS, and ARI

Additional Database Wallet Commands

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

update-<ALIAS>.sh

dump_credentials.sh

save_credential.sh

Usage

Appendix: Oracle Single Sign-On for WebLogic

Authentication

Dynamically Protected URLs

Oracle Identity Management (OIM) and Oracle Access Manager (OAM) for 11g

MOD_OSSO

MOD_WEBLOGIC

Oracle Access Manager 11g Agent (WebGate)

Oracle Internet Directory

Partner Application

Realm

Statically Protected URLs

About SSO Log In Processing with OAM Agents

SSO Login Processing with OAM Agents

Infrastructure Installation and Configuration

OID User Data

OID with Multiple Realms

LDIF Scripts

User Data Synchronization

Enterprise Installation Order