4 Backend System Administration and Configuration

This chapter covers options for configuring Back Office, Central Office, Returns Management, and Point-of-Service normally carried out by an administrator before the system goes into general use. It covers the following topics:

Parameters
Running Back Office or Central Office
Establishing a Store Hierarchy in Central Office or Returns Management
Point-of-Service Devices
Scheduling Post Processors in Back Office
Data Management in Central Office
Help Files in Point-of-Service
Reason Codes in Point-of-Service
Configuring Transaction ID Lengths
Configuring RMI Timeout Intervals in Point-of-Service
System Settings in Point-of-Service
Configuring Logging in Point-of-Service

Note:

The Oracle Retail POS Suite Security Guide describes specific security features and implementation guidelines for the POS Suite products.

Parameters

The following information is about parameters in the Oracle Retail POS Suite applications.

Parameters in Back Office and Central Office

For more information about importing an initial set of parameters, see the Oracle Retail Back Office Installation Guide and Oracle Retail Central Office Installation Guide.

For information on specific parameters, see the Oracle Retail POS Suite Configuration Guide.

Parameters in Point-of-Service

Parameters are used to control flow, set minimums and maximums for data, and allow flexibility without recompiling code. A user can modify parameter values from the UI without changing code. Parameter values can be modified by Point-of-Service, or the changes can be distributed by other Oracle Retail applications. For example, the maximum cash refund allowed and the credit card types accepted are parameters that can be defined by Point-of-Service. To configure parameters, you need to understand the parameter hierarchy, define the group that the parameter belongs to, and define the parameter and its properties.

Parameter Hierarchy

Parameters are defined in XML files that are organized in a hierarchy. Different XML files represent different levels in a retail setting at which parameters may be defined. Understanding the parameter hierarchy helps you define parameters at the appropriate level.

Table 4-1 lists the parameter directories, XML filenames, and file descriptions.

Table 4-1 Parameter Directories, Files, and Descriptions

Directory	Parameter-Related XML File	Description
application	application.xml	Default parameter information provided by the base product
corporate	corporate.xml	Company information
store	store.xml	Local store information
register	workstation.xml	Register-level information
user role	operator.xml	User-level information

Higher-level parameters by default are overridden by lower-level parameter settings. For example, store-level configuration parameters override application-level parameters. The FINAL element in a parameter definition signifies whether the parameter can be overridden. Example 4-1 is an excerpt from <source_directory>\applications\pos\deploy\client\config\technician\PosParameterTechnican.xml, showing the order of precedence from highest level to lowest level.

Example 4-1 Default Parameter Settings

<SELECTOR name="defaultParameters">
        <SOURCE categoryname="application" alternativename="application">
        <SOURCE categoryname="corporate" alternativename="corporate">
        <SOURCE categoryname="store" alternativename="store">
        <SOURCE categoryname="register" alternativename="workstation">
        <SOURCE categoryname="userrole" alternativename="operator">
</SELECTOR>

The categoryname specifies the directory name and the alternativename specifies the name of the XML file. All parameter subdirectories reside in config\parameter.

Parameter Group

Each parameter belongs to a group, which is a collection of related parameters. The groups are used when modifying parameters within the UI. The user selects the group first, then has the option to modify the related parameters that belong to that group. Examples of groups are Browser, Customer, Discount, and Employee.

Adding a parameter requires adding it to the proper group. The following excerpt from application.xml shows the Tender group and a parameter definition inside the group. The hidden attribute indicates whether or not the group is displayed in the UI.

Example 4-2 Definition of Tender Group

 
<GROUP name="Tender" hidden="N">
      <PARAMETER name="MaximumCashChange"
         ...
      <PARAMETER>
...
<GROUP>

Parameter Properties

Each parameter file contains parameter definitions organized by group. The following shows an example of two parameter definitions from config/parameter/application/application.xml.

Example 4-3 Parameter Definitions From application.xml

<PARAMETER name="CashAccepted"
         type="LIST"
         default="USD"
         final="N"
         hidden="N">
         <VALIDATOR class="EnumeratedListValidator"
            package="oracle.retail.stores.foundation.manager.parameter">
            <!-- Use ISO 3 letter currency code -->
            <PROPERTY propname="member" propvalue="None" />
            <PROPERTY propname="member" propvalue="USD" />
            <PROPERTY propname="member" propvalue="CAD" />
         </VALIDATOR>
         <VALUE value="USD"/>
         <VALUE value="CAD"/>
 
<PARAMETER name="MaximumCashChange"
         type="CURRENCY"
         final="N"
         hidden="N">
         <VALIDATOR class="FloatRangeValidator"
            package="oracle.retail.stores.foundation.manager.parameter">
            <PROPERTY propname="minimum" propvalue="0.00" />
            <PROPERTY propname="maximum" propvalue="99999.99" />
         </VALIDATOR>
         <VALUE value="25.00"/>
      </PARAMETER>

The FINAL attribute indicates whether the property definition is final, meaning it cannot be overridden by lower-level parameter file settings. The VALUE element is the current setting of the parameter. If multiple values are set, that means the value of the parameter is a list of values.

Table 4-2 lists the four types of VALIDATOR classes.

Table 4-2 Validator Types

Validator	Description
EnumeratedListValidator	Determines whether a value supplied is one of an allowable set of values
FloatRangeValidator	Ensures that the value lies within the specified minimum and maximum float range
IntegerRangeValidator	Ensures that the value of a parameter lies within the specified minimum and maximum integer range
StringLengthValidator	Ensures that the value's length lies within the specified min and max length

Running Back Office or Central Office

Do the following to run Back Office or Central Office:

Verify that the application is running in the application server environment.
Access the following URL from a browser, specifying the application server host name and port number where indicated:

https://<app-server-hostname>:<port number>/<application>/

Where <application> is backoffice or centraloffice.

<port number> is 7002.

Running Returns Management

Do the following to run Returns Management:

Verify that the application is running in the application server environment.
Access the following URL from a browser, specifying the application server host name and port number where indicated:
```
https://<app-server-hostname>:<app-server-port number>/returnsmanagement/
```

Establishing a Store Hierarchy in Central Office or Returns Management

Use the Data Import module to import store hierarchy information.

The store hierarchy defines where stores fit in the retailer's enterprise. The store hierarchy is defined in an XML file. Whenever any changes are made to the store hierarchy, the XML file is edited, and that file is then imported to Central Office or Returns Management. The Data Import (DIMP) Subsystem enables the importing of the store hierarchy. For information on using DIMP, see the Oracle Retail POS Suite /Merchandising Operations Management Implementation Guide.

Note:

After importing the store hierarchy into the database, the admin user created with the installer needs to be linked to the correct store group.

If a new store hierarchy is imported after the initial install, the admin user needs to be linked to the correct store group.

Importing Data in Returns Management

Within Returns Management, select Data Management to display a list of data import options. You can import data immediately or schedule an import for later. See the Oracle Retail Returns Management User Guide.

The following types of data can be imported:

RM Customer Data
Application Parameters

Application parameters are specific to Returns Management.

Note:
Application parameters are imported as part of the install process. See the Oracle Retail Returns Management Installation Guide for more information.

Point-of-Service Devices

Point-of-Service devices are configured with the PosDeviceTechnician.xml file, device-specific property files, and other JavaPOS configuration files. The device vendor typically provides a JavaPOS configuration file to support the JavaPOS standards. If necessary, you can create your own configuration file to meet your device requirements and replace the XML configuration file name for DeviceTechnician in ClientConduit.xml. Interaction of the Point-of-Service application with devices is managed by the Device Manager and Device Technician.

Set Up the Device

To configure a device to work with Point-of-Service, first consult the user manual for that device for specific setup requirements. Set up the device drivers and configuration file so the device is available to applications.

Test the Device

Use the POStest application at http://www.javapos.com to determine if a device adheres to existing JavaPOS standards. POStest is a GUI-based utility for exercising Point-of-Service devices using JavaPOS. Usually this requires adding the device to the jpos.xml file that is in the Point-of-Service classpath. Currently it supports the following devices: POSPrinter, MICR, MSR, Scanner, Cash Drawer, Line Display, Signature Capture, and PIN Pad. Do the following to use POStest:

Configure the classpath for JavaPOS. This means that the classpath should include the location of POStest, jpos.jar, jcl.jar and the JavaPOS services for the devices.
To build POStest, compile the classes in <location of POStest>/upos/com/jpos/POSTest.
To run POStest, enter the following at a command line:
```
java com.jpos.POStest.POStest
```

Sometimes, the hardware vendor provides test utilities that come with the JavaPOS implementation. You should test with these tools as well.

Create a Session and ActionGroup

In Point-of-Service code, devices require a Session and an ActionGroup. If you need to interact with a new JavaPOS device, you must create a new Session and ActionGroup.

Sessions capture input for the application. In UI scripts, device connections are defined that allow the application code to receive input from a device by connecting the Session with the screen specification. The Session listens to JavaPOS controls on the device.

ActionGroups provide the actions that can be performed with the device. ActionGroups are instantiated by Tour code. When a method on an ActionGroup is called in Tour code, the DeviceTechnician talks to JavaPOS controls on the device.

To create or modify a Session and ActionGroup:.

Configure the Session and ActionGroup in config\technician\PosDeviceTechnician.xml

To do this, enter the name of the Session and ActionGroup in PosDeviceTechnician.xml. You must specify the name of the object, its class and its package. In addition, you can set some attributes available in the corresponding class in PosDeviceTechnician.xml. This file creates a hash table of ActionGroups and Sessions, which are part of the DeviceTechnician. Below is a definition of an ActionGroup and Session from posdevices.xml.
Example 4-4 ActionGroup Configuration
```
 <ACTIONGROUP name="LineDisplayActionGroupIfc"
            class="LineDisplayActionGroup"
            package="oracle.retail.stores.pos.device"/>
```
Example 4-5 Session Configuration
```
 <SESSION name="ScannerSession"
            devicename = "defaultScanner"
            class="ScannerSession"
            package="oracle.retail.stores.foundation.manager.device"
            defaultmode = "MODE_RELEASED"
            />
```
Define a Session class to get input that extends InputDeviceSession or DeviceSession.

Each type of device has a Session class defined in <source_directory>\applications\pos\src\oracle\retail\stores\pos\device. A device session like CashDrawerSession would extend DeviceSession, whereas an input device session like a ScannerSession would extend InputDeviceSession.

Sessions are not instantiated in Tour code but are accessed by UI scripts in device connections.
Define an ActionGroupIfc interface that extends DeviceActionGroupIfc.

This class should also be located in <source_directory>\applications\pos\src\oracle\retail\stores\pos\device. The following line of code shows the header of the CashDrawerActionGroupIfc class.
```
public interface CashDrawerActionGroupIfc extends DeviceActionGroupIfc
```
Create the ActionGroup class. This class should be located in <source_directory>\applications\pos\src\oracle\retail\stores\pos\device, and its purpose is to define specific device operations available to Point-of-Service. The following line of code shows the header of the CashDrawerActionGroup class.
```
public interface CashDrawerActionGroup extends CashDrawerActionGroupIfc
```
If one does not already exist, create a device connection in the UI Subsystem file. Device connections in the UI Subsystem files allow the application to receive input data from the Session.

The DeviceSession class is referenced in the device connections for the relevant screen specifications. For example, the following code is an excerpt from <source_directory>\applications\pos\src\oracle\retail\stores\pos\services\tender\tenderuicfg.xml.
Example 4-6 Example of Device Connection
```
<DEVICECONNECTION
             deviceSessionName="ScannerSession"
             targetBeanSpecName="PromptAndResponsePanelSpec"
             listenerPackage="java.beans"
             listenerInterfaceName="PropertyChangeListener"
             adapterPackage="oracle.retail.stores.foundation.manager.gui"
             adapterClassName="InputDataAdapter"
             adapterParameter="setScannerData"
             activateMode="MODE_SINGLESCAN">
```
Access the device manager and input from the Session in the application code.

Using the bean model, data from the Session can be accessed with methods in the device's ActionGroupIfc.
Example 4-7 ActionGroup in Tour code
```
POSDeviceActions pda = new POSDeviceActions((SessionBusIfc) bus);
pda.clearText();
pda.displayTextAt(1,0,displayLine2);
```

Simulate the Device

It is often practical to simulate devices for development purposes until the hardware is available or the software is testable. Switching to a simulated device is easily accomplished by editing config\technician\PosDeviceTechnician.xml. In fact, when you install Point-of-Service and choose the option to run in Simulated mode, PosDeviceTechnician.xml is modified accordingly. By default, unselected devices are set up as simulated. The following code samples show the difference between a normal device configuration and a simulated device configuration. Note the class name and device name are changed.

Example 4-8 Normal Device Configuration

<SESSION name="PrinterSession"
devicename = "defaultPrinter"
class="PrinterSession"
package="oracle.retail.stores.foundation.manager.device"
defaultmode = "MODE_RELEASED"
/>

Example 4-9 Simulated Device Configuration

<SESSION name="SimulatedPrinterSession"
            devicename = "defaultPrinter"
            class="SimulatedPrinterSession"
            package="oracle.retail.stores.foundation.manager.device"
            defaultmode = "MODE_RELEASED"
            />

Scheduling Post Processors in Back Office

Schedule post processor jobs after installing Back Office. See the Oracle Retail Back Office User Guide for more information.

Scheduling Post Processors in Returns Management

After installation, you must schedule postprocessor jobs as part of the configuration process. Post processors create summary data for use in reporting. See the Oracle Retail Returns Management User Guide for more information.

Data Management in Central Office

Within Central Office, select the Data Management tab to display a list of data import and export options. You can import or export data immediately or schedule an import or export for later. The following types of data can be imported or exported:

POSlog
EJournal
Store parameters and Central Office application parameters (see "Parameters in Back Office and Central Office")

Help Files in Point-of-Service

The Point-of-Service application includes help files to provide information to assist the end-user. When the user chooses F1 from the global navigation panel, a help browser appears in Point-of-Service to describe the current screen. An index is provided on the left so the user may choose additional topics to view. The help is implemented as JavaHelp and includes these components:

One HTML help file for each screen. The product help files are Microsoft Word files saved as HTML. They can be edited with Word, an HTML editor or a text editor.
A Table of Contents file that defines the index that displays on the left.
A properties file that associates overlay screen names with the corresponding HTML filenames.

For more information on JavaHelp, refer to: http://javahelp.java.net/.

Note:

If the base product help files are modified, upgrades for help files are not available. You will not be able to take advantage of updates provided with future maintenance releases of the application.

Modifying Help Files in Central Office, Back Office and Returns Management

Online help is created using Oracle Online Help for the web. Information on this technology is available at: http://www.oracle.com/technetwork/topics/index-083946.html

The online help is generated from the application user guide. Each chapter in the user guide is divided into sections. You can look at the Table of Contents for the user guide to see how each chapter is structured. When the user guide is converted into online help, each section is converted into an html help file.

Some help files contain specific information for a screen. Other help files have the background or topic information that is contained in the user guide. For screen help, the name of the file includes the name of the screen. For background help, the name of the file is based on the section in the user guide. For example, the help file for the User Details screen is named userdetailshelp.htm. The information in the Working with Transactions section is in the workwithtransactionshelp.htm file.

For example, in Central Office, the centraloffice.ear file contains the centraloffice-help.war. The war file contains the following:

helpsets folder    
    co_olh folder
        dcommon folder (definitions for styles, gif files for buttons)
        img folder (any images included in the online help from the user guide)
        help files

To update a help file:

Locate the help file to be changed.
Edit the help file.
Replace the updated file in the helpset and in centraloffice.ear.
Redeploy centraloffice.ear or backoffice.ear.

Modifying Help Files in Point-of-Service

To modify Help Files in Point-of-Service, do the following:

Locate the name of the help file associated with the overlay screen name that needs to be modified. The help file names are defined in helpscreens.properties located in <source_directory>\applications\pos\deploy\client\config\ui\help.
Example 4-10 JavaHelp—helpscreens.properties
```
REFUND_OPTIONS                        refundoptionshelp.htm
```
Locate the help file in the config\ui\help directory. Open the file in Microsoft Word or an HTML editor and edit the content. If you are using Word to edit, be sure to save the file as HTML when the edits are complete.
If the index location or text descriptions needs to be modified, change toc.xml located in <source_directory>\applications\pos\locales\en\config\ui\help. The order of the items in the index is also defined by this file.
Example 4-11 JavaHelp—toc.xml
```
  <tocitem target="REFUND_OPTIONS"    text="Refund Options" />
```

Reason Codes in Point-of-Service

Reason codes are items offered to the end user as choices in lists, for example, the set of possible reasons for a price override. These choices normally vary for each retailer, and they must be configured to suit your local requirements and policies. The system comes with a predetermined set of reason code groups; within each group, you can add, remove, and modify the list of codes, all from within the Point-of-Service interface. For information on working with reason codes, see the Oracle Retail Point-of-Service User Guide.

Configuring Transaction ID Lengths

Point-of-Service allows for some configuration of the length of the Transaction ID. These changes affect every aspect of the software and should not be undertaken lightly. Changes should only be performed before Point-of-Service is installed. Changes to these settings can require substantial custom code and testing to establish that no problems result from the change.

Note:

Only the default values for these parameters were tested in the integration to Point-of-Service. Changing the values of the Point-of-Service Transaction ID settings without changing the supporting configuration for Central Office and Returns Management could cause the integration to not work correctly.

Understanding Transaction IDs

A transaction ID is a composite key made from the store number, register number, and sequence number. When combined, these attributes create a unique number for each transaction. Transaction IDs can also include an eight-digit date to ensure that they are unique. For example, if you restart your sequence numbers on a daily basis, the date value prevents transaction ID repetition.

Key points about the transaction ID and related properties:

You can change the length of the store, register, and sequence numbers which contribute to the transaction ID. You cannot directly configure the length of the transaction ID itself.
System-generated unique layaway numbers, special order numbers, and web order numbers are not affected by changes to the transaction ID rules.
A maximum of 20 digits of transaction ID can be printed on receipts using Point-of-Service current barcode format.
If the value of a store, register, or sequence number has fewer than the specified number of digits, Point-of-Service uses leading zeroes to pad the number to the required number of digits; a four-digit sequence number whose value is 22 shows up within the transaction ID as 0022.
Dates can be used in transaction IDs to help ensure unique IDs. If they are used, they are expressed as an 8-digit number; this is set by the TransactionIDBarcodeDateFormat property in the domain.properties file. The only valid values for this property are no value and yyyyMMdd. The date format does not vary from one locale to another.
You can set the transaction sequence start number in the database.
When you enter a transaction ID manually, the trailing date is optional.

Changing Transaction ID Format

Changing the format of the transaction ID requires many steps and requires additional testing and possibly custom code to support the merchant's desired format. See Configuring Transaction ID Lengths for more information. The base format is divided into three sections:

Store ID
Workstation ID
Sequence number

See "Understanding Transaction IDs" for more information about these sections.

Example 4-12 Transaction ID Configuration in domain.properties

# Transaction ID
TransactionIDStoreIDLength=5
TransactionIDWorkstationIDLength=3
TransactionIDSequenceNumberLength=4
CustomerIDSequenceNumberLength=6
#TransactionIDBarcodeDateFormat=yyyyMMdd
TransactionIDBarcodeDateFormat=
TransactionIDSequenceNumberSkipZero=false
TransactionIDSequenceNumberMaximum=9999
CustomerIDSequenceNumberMaximum=999999

Do the following to change the default length of the sequence number:

Change the length in the domain.properties in the Point-of-Service server and client:
- TransactionIDSequenceNumberMaximum=99999
- TransactionIDSequenceNumberLength=4
Update the parameters under group TransactionID in centraloffice.xml with the required length.
Change the regular expression format in validation.properties for TransactionNumber in Central Office. The file is in <source_directory>\installer\templates:
```
Validator.TransactionNumber=^[a-zA-Z0-9]{5}[a-zA-Z0-9]{3}[0-9]{4}$
```

Do the following to change the default length of the store ID and workstation ID:

Update the table definitions for the columns ID_STR_RT and ID_WS to the required length. By default, they are defined as:
- store ID = 5 characters
- workstation ID = 3 characters
Change the length in domain.properties in the Point-of-Service client and server:
- TransactionIDStoreIDLength=5
- TransactionIDWorkstationIDLength=3
Update the parameters under group TransactionID in centraloffice.xml with the required length.
Change the format in validation.properties for TransactionNumber in Central Office. The file is in <source_directory>\installer\templates.

Note:

Be sure to test the Point-of-Service, Central Office, or Returns Management integration, and all screens where search by transaction ID is found.

Configuring the Purchase Date Field for Returns and Voids

You must configure Point-of-Service to display the Purchase Date field in the Receipt Info screen when conducting a return or a void.

To do this, you must modify the domain.properties file in the config folder. Uncomment the following field:

TransactionIDBarcodeDateFormat=yyyyMMdd

By default, this field in domain.properties contains no defined date format. This prevents the Purchase Date field from being displayed in the Receipt Info screen.

Configuring RMI Timeout Intervals in Point-of-Service

You can configure remote method invocation (RMI) timeout intervals at two levels:

The JVM level (Linux installs only)
The level of managers and technicians

If you are performing a Linux installation, configure the JVM as described in "Setting the RMI Timeout Interval for the JVM Under Linux". If you determine that RMI connections are timing out, you can use one of the other procedures in this section, "Setting the RMI Timeout Interval for All Manager and Technician Calls" or "Setting the RMI Timeout Interval for a Specific Technician".

Setting the RMI Timeout Interval for the JVM Under Linux

Oracle Retail has found it useful to change the RMI timeout interval for the JVM under Linux. To do this, change the command that launches the JVM, adding the JVM flag:
Dsun.rmi.transport.connectionTimeout=<X> where <X> represents the time-out period in milliseconds.

This tells the JVM to time out socket connections used by RMI after X milliseconds of inactivity. Linux quickly notifies the JVM when a socket connection cannot be established. Linux is slow, however, to notify the JVM when an open socket connection has been broken. By setting the connection time-out low, you can cause the sockets to disconnect quickly after each RMI call, thereby requiring a connect for each subsequent RMI call.

Modifying the TCP Connection Timeout on Linux

Sometimes, Linux keeps the tcp connection active even after Point-of-Service determines that the socket has timed out. There are three OS level settings that work together to determine how long to keep the tcp connection open, which affects the observed system performance. To modify these level settings, at a Linux command line, enter:

sysctl –w net.ipv4.tcp_keepalive_time=<value> 
sysctl –w net.ipv4.tcp_keepalive_intvl=<value> 
sysctl –w net.ipv4.tcp_keepalive_probes=<value>

where <value> is an interval you specify.

Setting the RMI Timeout Interval for All Manager and Technician Calls

You can change the RMI timeout interval values for connections and reads in the <source_directory>\applications\pos\deploy\<Client or Server>\bin\comm.properties file. The value for the following properties apply to all manager and technician calls, unless overridden by a communication scheme for a specific call.

comm.socket.connectTimeout - Specifies how long to wait for a socket connection to succeed. The value is in milliseconds.
comm.socket.readTimeout - Specifies how long to wait before a read times out. The value is in milliseconds. This property causes the read to time out even if the socket is alive and well and transmitting data.

Note:

These values control the application timeout when trying to establish a socket connection or read from a socket.

Setting Application Timeout Values on Linux

Do the following when configuring the application timeout values for Point-of-Service on Linux:

Set the socket timeout values in the comm.properties file:

comm.socket.readTimeout=25000comm.socket.connectTimeout=25000

Set the RMI property values in the startup script, for example, in ClientConduit.sh:

JAVA_OPTIONS=${JAVA_OPTIONS}"-Dsun.rmi.transport.tcp.responseTimeout=5000"

Other possible values include the following:

-Dsun.rmi.transport.tcp.logLevel=VERBOSE
-Dsun.rmi.transport.tcp.responseTimeout=5000
-Dsun.rmi.transport.logLevel=VERBOSE
-Dsun.rmi.transport.tcp.readTimeout=1500
-Dsun.rmi.transport.tcp.handshakeTimeout=5000
-Dsun.rmi.transport.proxy.connectTimeout=10000
-Dsun.rmi.transport.connectionTimeout=15000

Set the Linux tcp property values.

There are three operating system-level settings that work together to determine how long to keep the tcp connection open, which affects the observed system performance. At the Linux command line, type the following:
```
sysctl –w net.ipv4.tcp_keepalive_time=<value>
sysctl –w net.ipv4.tcp_keepalive_intvl=<value>
sysctl –w net.ipv4.tcp_keepalive_probes=<value>
```
Additional information can be found at

http://www.ibdeveloper.com/issue1/ibmag.pdf

Setting the RMI Timeout Interval for a Specific Technician

To set the time-out for a specific technician, edit the <source_directory>\applications\pos\deploy\<Client or Server>\bin\comm.properties file and the conduit script as follows:

Add a new communication scheme to the comm.properties file. The following lines provide an example:
```
comm.rmi_longread.readTimeout=120000
comm.rmi_longread.connectTimeout=1000
```
These lines establish a new communication scheme called rmi_longread with a read time-out of 120 seconds and a connect time-out of one second (since the values are in milliseconds).
Add the following property to the appropriate technician definition in the conduit script:
```
<PROPERTY propname="commScheme" propvalue="rmi_longread"/>
```
This sets the communication time-outs for all managers that connect to this technician. A manager who is sending a valet to this technician times out if the valet fails to complete within 120 seconds. It only attempts to connect to the technician for 1 second before giving up.

System Settings in Point-of-Service

System settings are values set in the Oracle Retail database. Changes to these settings must be made in the database by a database administrator or an application developer.

System settings can have significant effects on Point-of-Service system; do not make changes unless you are confident that you understand the effects. For a description of all available system settings, see the Oracle Retail POS Suite Configuration Guide.

Configuring Logging in Point-of-Service

Point-of-Service logging uses the Log4J tool. Configure Log4J by editing <source_directory>\applications\pos\deploy\shared\config\log4j.xml. See the Apache documentation for Log4J at http://logging.apache.org/log4j. For more information, a Log4j XML Configuration Primer can be found at ://wiki.apache.org/logging-log4j/Log4jXmlFormathttp.

Returns Management Environment Entries in ejb-jar.xml

This section describes the <env-entry> section in the Returns Management ejb-jar.xml file. These entries enable manipulation of some aspects of the system.

Return Ticket Formatting Entries

The return ticket table is indexed using a composite key. This key is comprised of store number, workstation, business date, and a sequence number. To make this key end-user legible, it is formatted using the returnTicketIdPattern rather than passed as discrete data elements. The default pattern is sssss-www-MMdd-yyyy-nnnnnnnnn.

Table 4-3 Return Ticket Table

Data Element	Description
sssss	Marks the store ID.
www	Marks the workstation ID.
nnnnnnnnn	Marks the sequence number.
MMdd-yyyy	Marks the business date.

This <env-entry> element must be in sync with the other <env-entry> elements as follows:

ID divider: If you want to use a different divider, then the value returnTicketIdDivider must be changed to reflect the new divider used.
Date format: If this format is changed, other than the divider character, the value returnTicketIdDatePattern must be changed to reflect this.
Store pattern: If the store retrieved from the database is shorter than the value in returnTicketStoreIdPersistPattern, it is padded on the left hand side with the value in returnTicketPersistPad (default is 0).
Sequence pattern: If the sequence number is smaller than the length of returnTicketSeqNumberPersistPattern, then it is padded with the value from returnTicketIdPad (default is 0).
ReturnTicketMaxSequenceValue: No effect.
ReturnTicketBusinessDate: Ignore. This is used in an unused method in the ReturnTicketKeyFormatter class and can be safely ignored.

Table 4-4 defines the return ticket format elements.

Table 4-4 Return Ticket Format <env-entry>

Entry	Default
returnTicketIdPattern	sssss-www-MMdd-yyyy-nnnnnnnnn
returnTicketIdDivider	NA
returnTicketIdDatePattern	MMddyyyy
returnTicketStoreIdPersistPattern	sssss
returnTicketWorkstationIdPattern	www
returnTicketSeqNumberPersistPattern	nnnnnnnnn
returnTicketIdPad	0
returnTicketPersistPad	0
returnTicketMaxSequenceValue	999999999
returnTicketBusinessDate	yyyy-MM-dd

Auditing Entries

Table 4-5 identifies audit target format elements.

Table 4-5 Audit Target <env-entry>

Entry	Default
journalDataPath	1

This integer value tells Returns Management where to send audit log messages. Valid values are:

0 – no audit log
1 – send log messages to a JMS queue (found using JNDI lookup at java:comp/env/jms/JournalingMessage)
2 – send log messages directly to the EJB interface of the Journaling Service.

Any other value results in no audit log being created and an error message logged.

Defining Security with Roles

In Point-of-Service, you specify user access to the application by assigning a role to each user. Each role contains a list of the security access points of the application, specifying which access points that role is allowed to use. You can create as many roles as you need.

Roles are typically named for job titles; by creating a manager role and a clerk role, for example, you define two classes of employees with different access to Point-of-Service functions. All clerks, however, would have the same access rights.

For information on how to modify and add roles, see the Oracle Retail Point-of-Service User Guide. For a list of security access points, see "Secured Features".

Secured Features

The following table lists all of the functions within Point-of-Service for which security access points exist. When a user attempts to use a function protected by one of these security access points, the system checks whether the user's role allows that function.

Table 4-6 identifies Point-of-Service security access points.

Table 4-6 Security Access Points

Access Point	Access Point	Access Point	Access Point
Accept Invalid DL Format	Administration	Override of Soft Declined Check	Back Office
Bank Deposit	Override Call Referral Accept for check, credit, or gift card	Override Call Referrals	Cancel Transaction
Close Register	Close Till	Reprint Gift Receipt	Customer - Add/Find
Customer Delete	Daily Operations	Reprint Receipt	Discount Rule Add/Modify
Discount rule End	Electronic Journal	E-mail	Employee - Add/Find
Employee Time Maintenance	End of Day	Training Mode - Enter/Exit	Item Maintenance
Item/Transaction Discounts	Item/Transaction Gift Registry	Item/Transaction Sales Associate	Item/Transaction Tax Modifications
Job Queue	Kit Maintenance	Layaway Delete	Modify Layaway Fees
Modify Markdowns	No Sale	Open Register	Open Till
Orders	Override Declined Check	Override Declined Credit	Override Restocking Fee
Override Tender Limits	Parameters Add/Modify	Launch Browser	POS
Price Change	Price Override	Price Promotion	Queue Management
Reason Codes	Reentry On/Off	Transaction Details	Register Reports
Reset Hard Totals	Return	Role - Add/Find	Schedule Jobs
Service Alert	Start of Day	Parameter Groups Access	Start of Day
Till Pay-in	Till Pay-out	Till Pickup/Loan	Reconcile Till
Redeem	Void	Web Store	Add Temp Employee
Cancel Order	Clock In Out	Customer Discount	Money Order
Override Denied Return Item	Inventory Inquiry	Price Adjust	Print VAT Receipt
Reset Employee Password	Override Refund Tender	NA	NA

Security Implementation—Warnings and Advice

Oracle Retail is committed to providing our customers software, that when combined with overall system security, is capable of meeting or exceeding industry standards for securing sensitive data. By maintaining solutions based on standards, Oracle Retail provides the flexibility for retailers to choose the level and implementation of security without being tied to any specific solution.

Each retailer should carefully review the standards that apply to them with special emphasis on the Payment Card Industry (PCI) best practices. The Oracle Retail applications represent one portion of the entire system that must be secured; therefore, it is important to evaluate the entire system including operating system, network, and physical access.

The following are required by Visa:

Do not use database or operating systems administrative accounts for application accounts. Administrative accounts and any account that has access to sensitive data should require complex passwords as described below. Always disable default accounts before use in production.
Assign a unique account to each user. Never allow users to share accounts. Users that have access to more than one customer record should use complex passwords.
Complex passwords should have a minimum length of seven characters, contain both numeric and alphabetic characters, be changed at least every 90 days, and not repeat for at least four cycles.
Unused accounts should be disabled. Accounts should be temporarily disabled for at least 15 minutes after six invalid authentication attempts.
If sensitive data is transmitted over a wireless network, the network must be adequately secure, usually through use of WPA, 802.11i, or VPN.
Never store sensitive data on machines connected to the internet. Always limit access using a DMZ and/or firewall.
For remote support, be sure to use secure access methods such as two-factor authentication, SSH, SFTP, and so on. Use the security settings provided by third-party remote access products.
When transmitting sensitive data, always use network encryption such as SSL.

Following these recommendations does not necessarily ensure a secure implementation of the Oracle Retail products. Oracle recommends a periodic security audit by a third-party. For additional information, review the PCI standards.

Configuring Security in Returns Management

Returns Management has many individual security access points. This enables you to control the functionality to which any particular end user has access. You can also control workflow through approval permissions, enabling some employees to schedule tasks which others must approve.

For more information about security roles, see the Oracle Retail Returns Management User Guide.