2 Backend System Administration and Configuration

This chapter of the operations guide is intended for administrators who provide support and monitor the running system.

The content in this chapter is not procedural, but is meant to provide descriptive overviews of the key system parameters.

Supported Environments

See the Oracle Retail Price Management Installation Guide for information about requirements for the following:

• RDBMS operating system

• RDBMS version

• Middle tier server operating system

• Middle tier

• Compiler

Exception Handling

The two primary types of exceptions within the RPM system are the following:

• System exceptions

  For example, server connection and/or database issues are system exceptions. System exceptions can bring the system to a halt. For example, the connection to the server is lost.

• Business exceptions

  This exception indicates that a business rule has been violated. Most exceptions that arise in the system are business exceptions. For example, a user tries to approve a price change that causes a negative retail.

Configuration Files

Key system configuration parameters are described in this section. Many parameters have been omitted from this section that retailers should not have to change. When retailers install RPM into an environment, they must update these values to their specific settings.

rpm.jnlp

The Java Network Launching Protocol (JNLP) launch file is an XML document for Java Web Start. This file describes various locations of code and dynamically downloads updates. This file includes the web server information that is hosting port(s). This file also includes the RMI port on which the application server communicates. For example, if a retailer were to change a host name or change the port that the web server is running on, the retailer would make applicable changes to this file.

Data Source Configuration in Container

RPM application installer configures all data source settings for the RPM application. To change the data source settings for the RPM application after it has been deployed, complete the following steps:

1. Log into the WebLogic Server 11g Administration Console. Navigate to JDBC -> Data Sources.

2. The data sources listed are RPMNonXADataSource and RPMXADataSource.

3. Click RPMNonXADataSource.

4. Go to the Connection Pool tab.

5. Make any necessary changes to the JDBC URL and user name. Click Save.

6. Repeat the same steps above for RPMXADataSource.

7. If you are changing the schema owner, you must also make this change in the rpm.properties file in the deployment. Log in to the UNIX server and change directories to:

   <ORACLE_HOME>//user_projects/domains/soa_domain/servers/rpm-server/tmp/_WL_user/<rpm_app_name>/<encrypted_folder>/conf

   Modify the rpm.properties file with the new schema_owner value. This value must be in all capital letters. Save the file.

8. Restart the managed server instance running RPM.

rib_user.properties

There must be a rib_user.properties file located in conf/retek. This properties file is used to log on to the system at the beginning of each injector. Any data changes that happen as a result of the RIB has this user listed if users are tracked with regard to create/update/approve actions. The file is populated with the value shown below. For more information about the RIB, see Chapter 5, "RPM and the Oracle Retail Integration Bus (RIB)," and RIB documentation.

• rib.user=valid user for the system

security.properties

There must be a security.properties file located in conf/retek. This properties file is used to configure the embedded Oracle Retail Security Manager (RSM). See "Application Security" in Chapter 6, "Functional Design."

The file is populated with the values below.

Wallet Settings

The following properties pertain to wallet setup.

• csm-wallet.path = <ORACLE_HOME>/user_projects/domains/soa_domain/retail/<application_name>/config

• csm-wallet.partition = rpm13

For LDAP Authentication

These values are used for the configuration of the authentication process as it is run through LDAP. Once an LDAP schema is established, a retailer enters applicable LDAP properties to point to that schema.

ldap.initialcontextfactory

This internal Java-specific setting should not change from its initial value.

For example:

ldap.initialcontextfactory=com.sun.jndi.ldap.LdapCtxFactory

ldap.authenticationprovider.url

This value represents the authentication provider's URL. In a production environment, this setting would contain the retailer's address for its directory server.

For example:

ldap.authenticationprovider.url=ldap://64.238.67.60:379/

ldap.user.basedn

The values in this entry must correspond to entries in the LDAP server. DN stands for distinguished name. The top level of the LDAP directory tree is the base, referred to as the "base DN." This value represents the user base DN property.

For example:

lldap.user.basedn=cn=users,dc=us,dc=oracle,dc=com

ldap.authenticationmode

This value represents the authentication mode property. LDAP uses various ways to authenticate against a directory server, and the method of authentication can be set up. For almost all environments integrated with RSM, the value should be simple.

For example:

ldap.authenticationmode=simple

ldap.securityprotocol

Note: This setting is currently not used by RSM.

This value represents RSM's encryption protocol. SSL stands for secure socket layer (SSL). SSL is a protocol developed for private transmissions. SSL works by using a private key to encrypt data that's transferred over the SSL connection.

For User Search

These settings provide the "behind the scenes" login information for the system to connect to the directory server. For example, when an RSM user wishes to search on the directory server for a user, the RSM system must have a user name and password to log in to the directory server to enable the search to occur. The password for the LDAP server is maintained in the wallet. RSM uses the useralias to obtain the password from the wallet. The filter property value represents the directory server-specific way of filtering user information by attribute (when the directory server is finding users and then limiting the results). Because various directory servers use different attributes to represent a user name, this value must be updated if the retailer were to change directory servers. For example:

ldldap.usersearch.user=cn=RPM.ADMIN,cn=users,dc=us,dc=oracle,dc=comldap.usersearch.useralias=RPM.ADMIN ldap.user.filter=(&(objectCategory=person)(objectClass=user) %v)

For Audit Logging

For audit logging, the audit.logger setting is used. This setting allows you to direct security audit information to a specific Log4J logger. This value must match a logger/appender in the RSM server log4j.xml file. If a match does not occur, the root logger and appender are used.

For example:

audit.logger=Security.Audit.Logger

Single Sign-On with Oracle Technology

For single sign-on, the enable.oracle.sso setting is used. The value for this setting should always be false. For example:

enable.oracle.sso=false

LoginModule Configuraton Information

This setting configures RSM to point to the applicable user repository (such as a directory server or xml file) for authentication. The login modules defined in the application server can be found in rpm_jaas.config. See the Oracle Retail Price Management Installation Guide for detailed information pertaining to login module configuration. For example:

loginmodule=Oracle.LoginModule

The following example illustrates the entry in rpm_jaas.config for an authentication against an LDAP compliant directory server

Oracle.LoginModule{
com.retek.rsm.domain.security.dao.LDAPLoginModule required debug=true

The following example illustrates the entry in rpm_jaas.config for an authentication against the RSM users XML file:

Oracle.LoginModule{
com.retek.rsm.domain.security.dao.XMLLoginModule required debug=true

Note: This setting must correspond with the user DAO implementation setting in the dao_rpm.xml. If the XMLLoginModule is used, users must be added to the file, users_rsm.xml.

For Mapping LDAP to Directory Schema

The table below contains directory server-specific attributes concerning user information. Various directory servers use different attributes to represent user information. If a retailer were to change directory servers, these values must be configured to reflect the new directory server.

Element	Definition
ldap.firstname.attrname	LDAP first name attribute name property
ldap.lastname.attrname	LDAP last name attribute name property
ldap.username.attrname	LDAP user name attribute name property

User Signature Information

To facilitate single sign on functionality, a user signature may be passed to the RSM-embedded RPM. The following steps describe how the user signature is created and could be used:

1. When a user first logs in to RPM secured by RSM, it sends RSM the user and password data required for authentication.

2. RSM calls the retailer's LDAP compliant directory service to authenticate the user name and password data. Once a user is authenticated, RSM creates an encrypted user signature, which is returned to the calling Oracle Retail application.

3. When the user launches RPM, for example, the user signature is passed to RPM. The RPM application accepts the user signature and calls RSM to determine whether the signature is valid. If the validation step is successful, the user accesses RPM without having to go through the RPM login screen.

user.signature.cipher.algorithm

RSM uses an algorithm to generate a user signature. A retailer may change this algorithm and configure this property value to reflect the different algorithm being used.

For example:

user.signature.cipher.algorithm=HmacSHA1

user.signature.secretkey

To generate user signatures, the algorithm needs a secret key. Oracle Retail recommends that the retailer updates this value on a regular basis. A retailer can change this secret key if a compromise in security has occurred.

For example:

user.signature.secretkey=gjgh6382nEDmxMLc3DSkhYP0ah347495

user.signature.salt

The system uses the salt value to avoid dictionary attacks. Salt adds characters to what is being created (in this case, a user signature). Because of the salt value, for example, the encrypted value might have 100 digits rather than 10 digits. Breaking the encryption thus becomes more difficult.

For example:

user.signature.salt=¥!asdfghlll©ñ¤?#¥³1966

User Authentication Information

The following details the user authentication information.

user.max.allowable.authentication.failures

This value represents the maximum number of times that a user can fail authentication before the user's account is locked.

For example:

user.max.allowable.authentication.failures=5

user.max.time.lock.useraccount

This value represents the maximum number of hours a user's account remains locked. If the account is locked and over the maximum time value, the next time that user logs onto the system, the lock releases.

For example:

user.max.time.lock.useraccount=30

dao_rpm.xml

There must be a dao_rpm.xml file located in conf/retek. This configuration file is used to configure the mapping between DAO interfaces and their implementation. Generally there is no need to make changes to this file except if there is a need to configure the user repository that is used by RSM for user searches. The default value is to use an LDAP compliant directory server as the user repository. Besides LDAP, XML file based searches are also supported. To switch between LDAP and XML, comment or uncomment the "impl package" tags (shown below).

Note: This setting should correspond with the LoginModule configuration information found in the rpm_jaas.config file.

For example:

<dao-config> <customizations>             <!-- There can only be one impl per interface.  Use the XMLImpl to xml file(s) as the user repository.  -->          <interface package="com.retek.rsm.domain.security.dao.user">                  <impl  package="com.retek.rsm.domain.security.dao.impl.user" prefix="" suffix="LDAPImpl"/>              <!--         <impl  package="com.retek.rsm.domain.security.dao.impl.user" prefix="" suffix="XMLImpl"/>               -->         </interface>     </customizations></dao-config>

users_rsm.xml

There is a users_rsm.xml file located in conf/retek. This XML configuration is used for authentication and user searching, this file is used as the repository for the users. This file must contain the user names, first names, last names of all valid users. The corresponding password for the user is sourced from the wallet file. This file is located in the conf/retek directory within the RPM ear file.

Note: If LDAP is used for authentication and user searching, this file is ignored.

For example:

<<users>  <user username="Valid.User" firstname="Valid" lastname="User" />        <user username="JoeUser" firstname="Joe" lastname="User" /></users>

Configuration for Oracle Retail Service Layer (RSL) with services_rpm.xml

RPM's service factory configuration file, services_rpm.xml, specifies the mapping between RPM's application and its application services interfaces and their associated implementations. Within this file are flavorsets, which are used to configure the ServiceFactory. RSL requires a flavorset of businesslogic, which is used to distinguish the correct implementation of business logic to use for RPM. For more information about RSL, see Chapter 5, "RPM and the Oracle Retail Service Layer (RSL)."

The following example illustrates how the businesslogic flavorset is indicated in the service factory configuration file.

retek/services_rpm.xml:<?xml version="1.0" encoding="UTF-8"?><services-config>       <customizations>             <interface package="com.retek.rsl.rpm">                       <impl package="com.retek.rpm.app.core.service" />             </interface> </customizations></services-config>retek/service_flavors.xml:<?xml version="1.0" encoding="UTF-8"?><services-config>   <flavors set="businesslogic">         <flavor name="java" locator="com.retek.platform.service.SimpleServiceLocator" suffix="Java"/>   </flavors></services-config>

Logging

Logging within RPM takes place in a number of ways, as described below.

Jakarta Commons Logging

The API that RPM components work with is built using Jakarta's Commons Logging package. Commons logging provides "an ultra-thin bridge between different logging libraries," enabling the RPM application to remain reasonably "pluggable" with respect to different logger implementations. Objects in RPM that require logging functionality maintain a handle to a Log object, which adapts logging requests to the (runtime configurable) logging provider.

In RPM, Log4j is the library under commons logging.

Additional information about Jakarta Commons Logging can be found at the following websites:

• http://jakarta.apache.org/commons/logging/

• http://jakarta.apache.org/commons/logging/api/index.html

Log4j.xml

The logging mechanism that is used for RPM is log4j.xml, which is the same as the server's flat text log file. This logging mechanism reveals errors and other significant events that occur during the system's runtime processing. In most cases, business exceptions and system exceptions rise to the user interface. If an exception is displayed, it is logged. Log4j.xml is an open source product.

Significant application server logging occurs in RPM that should also be configured and monitored. See applicable application server documentation for more information.

Additional information about log4j can be found at the following website:

• http://jakarta.apache.org/log4j/docs/index.html

log4j.xml for RPM is found in the following location:

<ORACLE_HOME>/user_projects/domains/soa_domain/servers/<rpm_server>/tmp/_WL_user/<rpm_app_name>/<encrypted_folder>/conf

Logging Levels

The level setting established in log4j.xml instructs the system to log that level of error and errors above that level. The logging levels are the following:

• Fatal

• Error

• Warning

• Info

• Debug

Note: In a production environment, the logging setting should be set to Error or Warn, so that system performance is not adversely impacted.

The level is established in the log4j.xml file.

For example:

<!-- ======================= -->  <!-- Setup the loggers       -->  <!-- ======================= -->  <logger name="com.retek">    <level value="ERROR"/>  </logger>

Output Files

RPM logging output is sent to the console and written to files by the application server. In a default configuration, the output is written to a file in this format RPM.log under <ORACLE_HOME>/user_projects/domains/sso_domain/servers/RPM132_MS/logs. You can also configure to write logs to a different location and to roll them according to file size. For instructions related to this procedure, see the WebLogic Configuration and Administration Guide.

Hibernate Logging

Hibernate's internal logging setting is established in log4j.xml. The commons-logging service directs output to log4j. To use log4j, the log4j.properties file must be in the classpath. An example properties file is distributed with Hibernate. The class to be logged and the logging level can be specified. For a general description of Hibernate, see Chapter 3, "Technical Architecture."

For example:

!-- ====================================================== -->  <!-- Hibernate trace at this level to log SQL parameters    -->  <!-- ====================================================== -->  <logger name="net.sf.hibernate.engine.QueryParameters">    <level value="TRACE"/>  </logger>

Transaction Timeout and Client Inactivity Timeout

This section describes how to establish settings for a transaction timeout. A transaction timeout is the maximum duration, in seconds, for transactions on the application server. Any transaction that is not requested to complete before this timeout is rolled back.

To set up these timeouts, please follow these steps:

1. Log in to the WebLogic Server 11g Administration Console.

2. Under Services, click JTA.

3. Click the Configuration tab.

4. Under JTA, set the Timeout Seconds (for example, 600 seconds).

RPMTaskMDB

RPMTaskMDB is a message driven bean used to facilitate RPM's asynchronous processing capability. Message driven beans act as listeners to specified queues for messages. As soon as a message arrives in the queue, the container triggers execution of this bean.When a background task is created by RPM, a message is published to the queue as a trigger to start processing of tasks.

EJBs Used by RPMTaskMDB

com.retek.rpm.app.task.service.RPMTaskAppServiceBmtEjb

Tables Used by RPMTaskMDB

• RPM_TASK, RPM_CONFLICT_CHECK_TASK, RPM_LOCATION_MOVE_TASK

  Current, past, and pending tasks to be executed.

• ALERTS, ALERT_RECEIVER, ALERT_STATUS, ALERT_STATUS_DSC

  Tables used for sending alerts to users about task status.

RPMChunkMDB

RPMChunkMDB is a message driven bean used for RPM's "chunking" functionality. Chunking refers to the breaking up of large price events (such as department level promotions) into smaller subsets. When chunking is required, the system publishes a message to the RPM chunk queue. Messages received by the chunk queue are processed through RPMChunkMDB.

Tables Used by RPMChunkMDB

RPM_CHUNK_CC_TASK and RPM_TASK

Multi-threading of MDB

Multi-threading for RPMTaskMDB and RPMChunkMDB is configured by the weblogicdeployment descriptor, weblogic-ejb-jar.xml.

To configure the number of threads, complete these steps:

1. Update the MDB descriptor in weblogic-ejb-jar.xml to add the following

   <pool>
                 <max-beans-in-free-pool>10</max-beans-in-free-pool>
          </pool>
   

   For example, for RPMTaskMDB it will be:

   <message-driven-descriptor>
         <pool>
                 <max-beans-in-free-pool>10</max-beans-in-free-pool>
          </pool>
            <destination-jndi-name>jms/taskQueue</destination-jndi-name>
   ...
   </message-driven-descriptor>
   

2. Note that <pool> tag should be the first tag after <message-driven-descriptor>.

Configuring RPM without the RIB

RPM integrates with RMS through the RIB. However, depending on the type of data being passed, the RIB is not always required. A single system option, RPM_IND, determines first whether integration between RPM and RMS is required by the retailer and, second, whether the RIB is required for each data flow. Setting RPM_IND to Y indicates only that an interface with RPM and RMS is necessary; the system then decides whether the RIB is needed. See the Oracle Retail Merchandising System Installation Guide for additional information on setting the value of the system_options table.

1. Log in to the UNIX server as the user who has write access under ORACLE_HOME.

2. Change directories to <ORACLE_HOME>/user_projects/domains/sso_domain/config

3. Make a backup of oconfig.xml and edit the file. Locate the managed server running the RPM application.

4. Under the managed server, under <server-start>-> <arguments>, add the following value:

    -Dretek.no.rib=true
   

   For example:

   <<server-start>      <class-path>…</class-path>      <arguments>… -Dretek.no.rib=false</arguments>    </server-start>
   

5. To publish price events using the Publish/Export batches, add the following property/value to rpm.properties on the server:

   delete_staged_rib_payloads=false
   

6. The following triggers need to be enabled so that data is written to the staging table for RMS-RPM integration:

   • RMS_TABLE_RPM_DEP_AIR (on DEPS table)

   • RMS_TABLE_RPM_ITL_AIUDR (on ITEM_LOC table)

   They can be enabled with the following syntax:

   ALTER TRIGGER [schema.]trigger ENABLE
   

No RIB Publishing

RPM has three configuration options regarding RIB publishing:

1. Delete_staged_rib_payloads=true|false (default is true): configured in rpm.properties

2. retek.no.rib=true|false (default is false): configured via JVM system property

3. retek.no.rib.publish=true|false (default is false): configured via JVM system property

This is how RPM will work with each combination of these properties. (The first row is default settings):

delete_staged_rib_payloads	retek.no.rib	retek.no.rib.publish	Receive messages from RIB	Publish messages to RIB	Data remains in staging tables
TRUE	FALSE	FALSE	Yes	Yes	No
TRUE	FALSE	TRUE	Yes	No	No
TRUE	TRUE	<ANY>	Yes	No	No
FALSE	FALSE	FALSE	Yes	Yes	Yes
FALSE	FALSE	TRUE	Yes	No	Yes
FALSE	TRUE	<ANY>	Yes	No	Yes

This is how to set the options for the different results:

• Publish messages to RIB: retek.no.rib=false AND retek.no.rib.publish=false

• Leave data in staging tables: delete_staged_rib_payloads=false

Configurable RIB Batch Program Notes

When the RIB is used for exchanging all messages between RMS and RPM, then the following batch programs need to be turned off from the integrated batch schedule.

• NewItemLocBatch

• ItemLocDeleteBatch

The RPM is configured as the following:

1. The enabling of RIB or enabling of triggers on ITEM_LOC will only insert records into RPM_STAGE_ITEM_LOC.

2. NewItemLoc batch has to be run once for inserting records from RPM_STAGE_ITEM_LOC to RPM_FUTURE_RETAIL.

3. If RIB and triggers are both disabled, then NewItemLocbatch has to run twice for the records to be populated into RPM_FUTURE_RETAIL.

RMS—RPM Integration

The following triggers must be enabled so that data is written to the staging table for RMS—RPM integration:

• RMS_TABLE_RPM_DEP_AIR (on DEPS table)

• RMS_TABLE_RPM_ITL_AIUDR (on ITEM_LOC table)

They can be enabled with the following syntax:

ALTER TRIGGER [schema.]trigger ENABLE

Disabling RIB Publishing in RPM

Set the system option, Publish messages to RIB: RPM_SYSTEM_OPTIONS.PUBLISH_PRICE_EVENTS_TO_RIB=0. Additionally, another system option, RPM_SYSTEM_OPTIONS. CC_DIRECT_PAYLOAD_POPULATION, will determine if payload data should be created as part of conflict checking or delayed. The following combinations of these two system options are allowed.

PUBLISH_PRICE_EVENTS_TO_RIB	CC_DIRECT_PAYLOAD_POPULATION
1	1
0	0
0	1

When RPM_SYSTEM_OPTIONS.CC_DIRECT_PAYLOAD_POPULATION = 0, all payload data will be staged. See priceEventPayloadPopulationBatch Design in Chapter 8, ”Java and RETL Batch Processes,” for details about processing from these staging tables.

Configuring RPM with RIB

Set the system option, Publish messages to RIB: RPM_SYSTEM_OPTIONS.PUBLISH_�PRICE_EVENTS_TO_RIB=1 and RPM_SYSTEM_OPTIONS. CC_DIRECT_PAYLOAD_POPULATION=1.�

To publish price events using the Publish/Export batches, add the following� property/value to rpm.properties on the server: delete_staged_rib_payloads=false�(default is true).�

If delete_staged_rib_payloads=True, the payload data is deleted after publishing to� RIB, and it will not be available for processing publish/export batches.�

RMS--RPM Integration

The following triggers must be enabled so that data is written to the staging table for� RMS—RPM integration:�

• RMS_TABLE_RPM_DEP_AIR (on DEPS table)

• RMS_TABLE_RPM_ITL_AIUDR (on ITEM_LOC table)

They can be enabled with the following syntax:�

ALTER TRIGGER [schema.]trigger ENABLE

Internationalization

Internationalization is the process of creating software that can be translated more easily. Changes to the code are not specific to any particular market. RPM has been internationalized to support multiple languages. This section describes configuration settings and features of the software that ensure that the base application can handle multiple languages.

Translation

Translation is the process of interpreting and adapting text from one language into another. Although the code itself is not translated, components of the application that are translated include the following:

• Graphical user interface (GUI)

• Error messages

The following components are not translated:

• Documentation (online help, release notes, installation guide, user guide, operations guide)

• Batch programs and messages

• Log files

• Configuration tools

• Reports

• Demonstration data

• Training materials

The user interface for RPM has been translated from U.S. English into the following languages:

• Chinese (simplified)

• Chinese (traditional)

• Croatian

• Dutch

• French

• German

• Greek

• Hungarian

• Italian

• Japanese

• Korean

• Polish

• Portuguese (Brazilian)

• Russian

• Spanish

• Swedish

• Turkish

Set the Client Operating System to the Applicable Locale

For a client machine to use the translated interface, set the operating system to the appropriate locale. Below is the procedure for setting a Microsoft Windows XP OS to a particular language. For other operating systems, consult the operating system's guide.

Note: The required language must be installed according to Microsoft instructions before setting regional and language options.

1. From the Control Panel, select Regional and Language Options. The Regional and Language Options window is displayed.

2. Select the required language from the Standards and formats drop-down field.

3. Click OK.

Resources_xx.properties

The text in the .properties file below is translated so that the interface functions in local settings. When a country code other than the default is used, the retailer populates the _xx.properties files below, where the applicable country equals xx. Much of what is locale-specific in RPM has been pulled ou tof hte code and placed into the following files.

• messages.properties and messages_xx.properties

• resources.properties and resources_xx.properties

• codes.properties and codes_xx.properties

• worksheet_column_names.properties and worksheet_column_names_xx.properties (contains the labels from the worksheet details table columns)

Modify the following files in \rpm13.ear\lib\rpm_server_properties.jar:

• \rpm-server\conf\retek\messages_rpm_xx.properties

• \rpm-server\conf\retek\application_definition_rpm_messages_xx.properties

In the two files listed above, change three strings from:

• departmentDescription=Department

• classHierDescription=Class Hierarchy

• subclassDescription=Subclass

To:

• departmentDescription=Family

• classHierDescription=Group

• subclassDescription=SubGroup

Save the changes, process a build, and go to the RSM section of RPM to ensure the labels are properly displayed.

As shown below, the properties files can be found in rpm_client_properties.jar and rpm_server_properties.jar.

• rpm_client_properties.jar

  • rpm13-ui/src/com/retek/rpm/gui/Resources.properties

  • rpm13-ui/src/com/retek/rpm/gui/worksheet/Worksheet_column_names.properties

• rpm_server_properties.jar

  • rpm13-server/conf/retek/messages.properties

  • rpm13-server/conf/retek/codes.properties

  • rpm13-server/conf/retek/application_definition_rpm_messages.properties

• RPM resides on platform code that has its own resource bundles. They are in the platform-resources.jar file.

Adjusting the Default Font from Settings to Ensure Proper Display of Asian Characters

Within the RPM application, Asian characters do not display correctly when the font setting, Verdana, is used. This condition exists for clients who use mixed language sets, where the user interface is in a European language (for example, English) and data field values are in an Asian language.

To ensure proper display of Asian characters, the font setting must be set to Dialog. The font setting is found in the Resources.properties file (for English language defaults) and in the Resources._xx.properties file (for all other European language defaults).

Adjust the Default Font Settings

Adjusting the default font settings requires modification of the Resources.properties (or Resources_xx.properties) file in platform-resources.jar. The following skills and tools are necessary to complete the modification:

• Thorough knowledge of the RPM application

• Thorough knowledge of Java programming

• Java programming toolkit

The platform-resources.jar must be updated in both of the following locations :

• For Client: $ORACLE_HOME/user_projects/domains/sso_domain/servers/<managed_server>/tmp/_WL_user/<rpm_instance>/<encrypted_folder_name>/war/client/lib folder

• For Server: $ORACLE_HOME/user_projects/domains/sso_domain/servers/<managed_server>/tmp/_WL_user/<rpm_instance>/<encrypted_folder_name>/lib folder

Note: To complete the steps below, you must have a Java executable in your PATH to use the jar and jarsigner commands. To confirm that it is there, enter the command, "which java," and note whether a valid Java executable file returns.

The following are the steps required to modify the Resources.properties (or Resources_xx.properties) file in the platform-resources.jar:

1. Back up the original platform-resources.jar file (for example, $ cp platform-resources.jar platform-resources.jar.ORIG).

2. Make a temporary directory (for example, $mkdir jar_temp).

3. Move the original platform-resources.jar file into the temporary directory (for example, mv platform-resources.jar jar_temp/).

4. Using a command such as jar -xvf platform-resources.jar, extract the platform-resources.jar.

5. Modify the Resources.properties (or Resources_xx.properties) file as follows:

   
   

   Note: When changing the font to Dialog, clients may opt to turn off bolding within the user interface. Bolded field labels can sometimes be hard to read, because the characters become crowded on the form. Unbolded characters can be easier to read. Settings for both options are provided here.

   
   

   • Option 1: Change the font to Dialog, without bolding.

     Modify the properties as follows:

     defaultFontName=dialog
     defaultBoldFontName=dialog
     defaultBoldFontStyle=0
     defaultSmallFontName=dialog
     defaultSmallBoldFontName=dialog
     defaultSmallBoldFontStyle=0
     defaultLargeBoldFontName=dialog
     defaultLargeBoldFontStyle=0
     menuAcceleratorFontName=dialog
     

   • Option 2: Change the font to Dialog, with bolding.

     Modify the properties as follows:

     defaultFontName=dialog
     defaultBoldFontName=dialog
     defaultBoldFontStyle=1
     defaultSmallFontName=dialog
     defaultSmallBoldFontName=dialog
     defaultSmallBoldFontStyle=1
     defaultLargeBoldFontName=dialog
     defaultLargeBoldFontStyle=1
     menuAcceleratorFontName=dialog
     

6. Changing the font style from Verdana to Dialog may also require changing the font size. Update the following font size properties as needed:

   defaultFontSize
   defaultBoldFontSize
   defaultSmallFontSize
   defaultSmallBoldFontSize
   defaultLargeBoldFontSize
   menuAcceleratorFontSize
   

7. Unsign the platform-resources.jar file by removing the following ORACLE* files from the extracted jar file:

   • META-INF/ORACLE_C.SF

   • META-INF/ORACLE_C.RSA

8. Using a command such as jar -xvf platform-resources.jar, jar the remaining files in the extracted file.

9. Place the newly modified platform-resources.jar in the location of the original jar file.

10. Re-sign the client jar file. For information on how to sign the platform-resources.jar, see the section, "Sign the RPM Client Configuration Jar File," in the Oracle Retail Price Management Installation Guide.

    
    

    Note: All client-side jars containing Java code must be signed with the same signature.

    
    

11. Restart the application server.

Price Management Status Page

Because RPM is dependent upon a number of servers, and a number of Oracle Retail products are dependent on RPM, a status page helps the retailer determine quickly whether RPM and the servers upon which it depends are up and running correctly. The privileges to this page can be set in Oracle Retail Security Manager and these privileges are typically reserved for administrators.�

The status page system check will answer the following questions:�

• Is the RPM/RMS_Database up and running?

• Is the RPM JMS Server up and running?

• Is RSM up and running?

• Can the application get access to the RPM service?

• Can the application log in to RPM?

• Can RPM data be retrieved?

• Can RMS data be retrieved?

• Is the application able to publish to RIB each message type?

The status page data integrity check will check the following:�

• Missing department aggregations—When departments are created in RMS, a row should be inserted into the RPM_DEPT_AGGREGATION table.�

• Missing primary zone groups—Each merchandise hierarchy (department or lower) should have a row in the RPM_MERCH_RETAIL_DEF table.�

• Missing item/locations —When an item is ranged to a location in RMS, a row should be inserted into the RPM_ITEM_LOC table.�

The status page application can also be used to for two specific data validity checks:�

• Duplicate future retail—There should only be one row in the RPM_FUTURE_RETAIL, RPM_PROMO_ITEM_LOC_EXPL, and RPM_CUSTOMER_SEGMENT_PROMO_FR tables per item, diff_id, location, zone_node_type and action date�.�

• Missing future retail timelines—Timelines should match up between the RPM_FUTURE_RETAIL, RPM_PROMO_ITEM_LOC_EXPL, and RPM_CUSTOMER_SEGMENT_PROMO_FR tables.�

Command Usage

The command usage is as follows. Terms in <angle brackets> are required user inputs. Terms in [brackets] are optional.

1. statusPageCommandLineApplication.sh <userAlias> [phase-choice] [max-rows-choice]�

2. statusPageCommandLineApplication.sh <userAlias> duplicate [dept=<department>[class=<class> [subclass=<subclass>]]]�

3. statusPageCommandLineApplication.sh <userAlias> missing [dept=<department>[class=<class> [subclass=<subclass>]]]�

�To answer the questions from above one of the following valid values for [phase-choice] should be used. Or if no option is given the Both (B) option will be used. �

S	System check only
D	Data integrity check only
B (default	Both

The value specified for max-rows-choice is the maximum row count for the query. By default, the query is run for the full count.�

To search for duplicate or missing data use the second or third option of the command usage. An optional Department/Class/Subclass hierarchy can be entered to narrow the search. If no hierarchy is given all data is checked.

Sample Output

The text below represents a sample output using the System Check Only (S) option. The example represents a case in which the questions from above have all been answered in the affirmative. The output will be different for each of the different command usages.

For example: