| Oracle® Retail Store Inventory Management Operations Guide Release 15.0 E65670-03 |
|
 Previous |
 Next |
| Oracle® Retail Store Inventory Management Operations Guide Release 15.0 E65670-03 |
|
Previous |
Next |
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 key system parameters, logging settings, and exception handling.
For information about integration compatibility for this release and for requirements for SIM's client, servers, and database, see the Oracle Retail Store Inventory Management Installation Guide.
For many SIM retailers, a corporate server is located in a different time zone than the stores connected to that corporate server. When a transaction is processed at these respective locations, there is timestamp information associated with these transactions. SIM has the ability to reconcile these time zone differences.
System administration options enable you to specify the time zone to use when timestamps are published to or received from the Oracle Retail Integration Bus (RIB).
For detailed descriptions of list of GMT Parameter, see the Oracle Retail Store Inventory Management Implementation Guide, Volume 1, section ”Setup and Configuration”.
|
Note: When Enable GMT is set to ”Yes”, the dates published to the RIB will be in GMT, and incoming timestamps in RIB messages will also be read as GMT; When the value is set to ”No”, timestamps are published to the RIB in the store time zone, and incoming timestamps in RIB messages will be read as the store time zone.When integrate with systems which dates are not in GMT or not time zone specific, then the enable GMT configuration must be set to ”No”. |
SIM provides GUI screens for administrators to set some of the system and store configuration settings. For details, see the Oracle Retail Store Inventory Management Implementation Guide, section ”System and Store Administration”.
Key system configuration parameters are described in this section. Key client-defined configurations for SIM are described in this section. The system parameters contained in these files are also detailed. Many parameters have been omitted from this section because retailers should not have to change them. Most of the configuration settings are set by SIM installer when retailers install SIM.
SIM configuration files are packaged as various resources jars, this section list the most commonly used configuration files.
Some settings in the files are configurable. Thus, when retailers install SIM into an environment, they must update these values to their specific settings.
|
Note: When manually making configuration file changes, the updated .ear files must be redeployed. |
The JNDI property file allows you to specify the properties to be used during client (SIM PC client, SIM wireless client, SIM batch client) looks up SIM server. The jndi.cfg is packaged in sim-client-resources.jar, sim-batch.zip, and sim-wireless.zip distributions.
|
Note: Within configuration files (and, thus, in some of the examples from those following files), a # sign that precedes a value in the file signifies that what follows is a comment and is not being utilized as a setting. |
Example 3-1 web-launch.properties
# SIM Web Launch Configuration initializers=oracle.retail.sim.weblaunch.bootstrap.WebLaunchInitializer finalizers= context.handler=oracle.retail.sim.weblaunch.core.DefaultWebLaunchContextHandler token.codebase_url=@deploy.client.codebase.url@ token.jndi_url=@jndi.naming.server.url@ security.sso.enabled=@security.sso.enabled@ security.sso.header.user=OAM_REMOTE_USER security.sso.header.groups=OAM_REMOTE_USER_GROUPSsecurity.sso.filter.groups=sim_server_users,sim_mps_users,sim_admin_users,sim_security_users,sim_batch_users,sim_integration_users security.sso.token.expiration=3600 security.sso.token.encryption.provider=oracle.retail.sim.weblaunch.security.SimTokenEncryptionProvider security.sso.token.key.generate=true security.sso.token.key.alias=sso-token-key security.sso.token.key.algorithm=HmacSHA256 security.sso.token.random.algorithm=SHA1PRNG security.sso.token.cipher.algorithm=AES/CBC/PKCS5Padding security.sso.token.cipher.key.size=128 security.sso.token.cipher.iv.length=16 security.sso.token.mac.algorithm=HmacSHA256 security.sso.token.mac.key.size=256 security.sso.token.mac.salt.length=32
Batch configuration files contain configuration settings for SIM batch programs. The batch configuration files are packaged in sim-batch.zip distribution.
SIM batch currently supports three (3) return codes
success = 0
failure = 1
warning = 2
The batch.cfg file contains the number of threads in pool.
Example 3-2 batch.cfg File
# The number of threads that execute concurrently to get batch work done when #SimBatch.executeBatchCallables is used. BATCH_NUM_THREADS_IN_POOL=5 # Time in seconds to wait when checking the status of an asynchronous batch job BATCH_ASYNC_DELAY=60 # The maximum number of times to check the status of an asynchronous batch job BATCH_ASYNC_LIMIT=10 # by default, exit code calculation warnings are ignored, the exit code will be 0. if set to false, and if EXITCODE_IGNORE_WARNING is set to false, if just warnings occurred during a batch run, the exit code will be 2PRICE_IMPORT_EXITCODE_IGNORE_WARNING=true
This file contains identity store provider configuration.
For details, see the Oracle Retail Store Inventory Management Implementation Guide, section ”Oracle Software Security Assurance (OSSA)”.
This file is used for changing the logging level for SIM batch programs. For details, see the section ”Changing Logging Levels”.
The configuration files which are common to both client code and server code.
Common configuration files are packaged in sim-common-resources.jar distribution.
|
Note: If a configuration file is changed, all client side jars containing Java code must be signed with the same signature. |
The following keys define the implementation to classes that instantiate objects in SIM through the factory pattern:
BO_FACTORY_IMPL
CLIENT_COMMAND_FACTORY_IMPL
CLIENT_SERVICE_FACTORY_IMPL
Where:
BO – Business Objects
The common.cfg file also includes server caching refresh rates for various services.
Example 3-3 common.cfg File
# These keys define the implementation to classes that instantiate objects in SIM via the factory pattern # BO = Business Objects, WSO = Web Service Objects, DEO = Data Exchange ObjectsBO_FACTORY_IMPL=oracle.retail.sim.common.business.BOFactoryImplCLIENT_COMMAND_FACTORYIMPL=oracle.retail.sim.common.business.ClientCommandFactoryImplCLIENT_SERVICE_FACTORY_IMPL=oracle.retail.sim.service.core.ClientServiceFactoryImpl# Default currency type for non-specified currencyCURRENCY_DEFAULT_TYPE=USD # Indicates the maximum number of lines that will be handled by authorization process at one time.# In other words, authorization of stock count will loop on total line items and only process 5000# line items within each loop. STOCK_COUNT_MAX_AUTH_LINES=5000 # These mask factories determine the implementation responsible for instantiating the money, phone masks (parsing/formatting). MONEY_MASK_FACTORY=oracle.retail.sim.common.format.MoneyMaskFactoryImpl PHONE_MASK_FACTORY=oracle.retail.sim.common.format.PhoneMaskFactoryImpl # The implementation of the credential store providerCREDENTIAL_STOREPROVIDER=oracle.retail.sim.common.security.JpsCredentialStoreProvider # Map name used for accessing the credential store CREDENTIAL_STORE_MAP=oracle.retail.sim # Cache Refresh Rates Of Commonly Cached Information. # Value is in milliseconds. 30000=30 seconds 300000=5 minutes 3600000=1 hour # The default setting is 1 hour unless configured here # JNDI context cache for sessions and remote objects (milliseconds) REFRESH_RATE_JNDI_CONTEXT=900000# Reason Codes for inventory adjustments cached on handheld server and PC Client (milliseconds) REFRESH_RATE_ACTIVE_INV_ADJ_REASON=180000 # Differentiator information cached on handheld server (milliseconds) REFRESH_RATE_WIRELESS_ITEM_DIFF=180000
Client configuration files are package in sim-client-resources.jar distribution.
|
Note: If a configuration file is changed, all client side jars containing Java code must be signed with the same signature. |
The client.cfg file contains the following:
STARTUP_DISPLAY – this class must be StartupDisplayer or a sub-class of StartupDisplayer.
INITIALIZERS – comma-delimited class name list that is executed upon SIM PC client startup.
FINALIZERS – comma-delimited class name list that needs to be executed when the client exits.
NATIVE.COMMANDS – comma-delimited list of native commands that display in stats area.
CLIENT_LOCK_PORT – the port used to lock the client application.
SHUTDOWN – shutdown command line.
Screen components used by application main frame:
GUI.APPFOLDER
GUI.MAINFRAME
GUI.GLOBALBAR
GUI.APPTOOLBAR
GUI.LOGGERFACTORY
GUI.STATUSDISPLAYER
GUI.DEFAULT_SCREEN
GUI.EXIT
NORMAL
SPIN
DISSOLVE
SHRINK
REPORTING_SERVICE_BROWSER_LAUNCHER –Reports Browser launcher.
REPORTS_EXECUTABLE – this value holds the executable for displaying the reports portal.
HELP_EXECUTABLE – this value holds the executable for displaying help.
Example 3-4 client.cfg File
# This class must be StartupDisplayer or a sub-class of StartupDisplayer
STARTUP_DISPLAY=oracle.retail.sim.client.application.StartupDisplayer
# A comma delimited class name list that is executed upon SIM PC client startup
# Each entry must be an implementation of oracle.retail.sim.closed.common.Initializer.
INITIALIZERS=oracle.retail.sim.client.bootstrap.SimClientInitializer
# FINALIZERS: A comma delimited class name list that needs to be executed when the client exits.# Each entry must implement oracle.retail.sim.common.Finalizer.FINALIZERS=oracle.retail.sim.client.bootstrap.SimClientFinalizer# Listener class for handling client single instance behavior, implements interface javax.jnlp.SingleInstanceListener.SINGLE_INSTANCE_LISTENER=oracle.retail.sim.client.application.JnlpSingleInstanceListener# This class provides client data caching, implements interface oracle.retail.sim.client.configutil.ClientCacheProvider.CLIENT_CACHE_PROVIDER=oracle.retail.sim.client.configutil.JnlpClientCacheProvider # Comma delimited list of native commands that will show up in stats area.
NATIVE.COMMANDS=
# The port which is used to lock the client application. This port will be checked on each client invocation to make sure only one instance of this application is running.
CLIENT_LOCK_PORT=51803
# Shutdown command line
SHUTDOWN=RESTART_CLIENT
# Screen components used by application main frame
GUI.APPFOLDER=sim
GUI.MAIN_FRAME=oracle.retail.sim.client.core.SimApplicationFrame
GUI.GLOBALBAR=oracle.retail.sim.client.core.SimStatusBar
GUI.APPTOOLBAR=oracle.retail.sim.client.core.SimToolbar
GUI.LOGGER_FACTORY=oracle.retail.sim.client.core.SimLoggerFactory
GUI.STATUS_DISPLAYER=oracle.retail.sim.client.core.SimStatusDisplayer
GUI.DEFAULT_SCREEN=oracle.retail.sim.client.login.MainScreen
GUI.LOGOUT_SCREEN=oracle.retail.sim.client.screen.login.LogoutScreenGUI.TABLE_FACTORY=oracle.retail.sim.client.core.ClientTableFactoryImplGUI.WRAPPER_FACTORY=oracle.retail.sim.client.core.ClientWrapperFactoryImpl
GUI.ADDRESS_FACTORY=oracle.retail.sim.client.locale.ClientAddressFactoryImpl
GUI.NAV_LISTENER_FACTORY=oracle.retail.sim.client.core.SimScreenNavigationListenerFactoryImpl
# Screen Exit Options are NORMAL, SPIN, DISSOLVE, SHRINK
GUI.EXIT=NORMAL
# Reports Browser launcher
REPORTING_SERVICE_BROWSER_LAUNCHER=oracle.retail.sim.client.report.launcher.bipublisher.BIPublisherBrowserReportLauncher
# This value holds the executable for displaying the reports portal.
# Need a different executable for Linux
REPORTS_EXECUTABLE=cmd /c start {0}
# This value holds the executable for displaying help.
# Available parameters: {0} - the absolute path of the URL which should display
# the help documentation.
HELP_EXECUTABLE=cmd /c start {0}
This file defines the date format configuration.
This file contains Java format pattern strings for several different types of dates defined in the system. These pattern strings follow the rules defined in Java for SimpleDateFormat. The key for the date is defined as language and country followed by the pattern key where xxXX is the two-letter ISO language code plus country code. Both language and country must be present. Additional language/country combinations can be added as desired. For example, enAU.entryDate is the entry format for dates in English for Australia.
The pattern keys are:
entryDate–used for date entry in calendar editor
shortDate–format for short length date - this is the most commonly used
mediumDate–format for medium length date
longDate–nearly complete date format
fullDate–fully written-out date format
monthPattern–formats month and day only
wirelessInput–defines entry for wireless device
wirelessOutput–defines the format of dates on the wireless device
wirelessDisplay–defines the exact text string to display to the user at the entry location
firstDayOfWeek – the first day of the week to display on calendar pop-up
The file must be changed and then placed in the classpath.
Valid days of week values are:
1 = Sunday
2 = Monday
3 = Tuesday
4 = Wednesday
5 = Thursday
6 = Friday
7 = Saturday
The enUS represents the language (en=english) and country (US=United States) of the user logged in. There are examples for many other countries already provided in the date.cfg file.
Example 3-5 date.cfg File
# Date formats are in standard JAVA pattern definition strings # First Day of Week: 1 = Sunday....7 = Saturday # ENGLISH - UNITED STATES #enUS.firstDayOfWeek=1 #enUS.entryDate=M/d/yy enUS.shortDate=M/d/yyyy #enUS.mediumDate=MMM d, yyyy #enUS.longDate=MMMM d, yyyy #enUS.fullDate=EEEE, MMMM d, yyyy enUS.monthPattern=MM-dd enUS.wirelessInput=MM-dd-yy,MMddyy enUS.wirelessOutput=MM-dd-yy enUS.wirelessDisplay=mm-dd-yy # FRENCH - BELGIUM #frBE.firstDayOfWeek=1 #frBE.entryDate=d/MM/yy #frBE.shortDate=d/MM/yy #frBE.mediumDate=dd-MMM-yyyy #frBE.longDate=d MMMM yyyy #frBE.fullDate=EEEE d MMMM yyyy frBE.monthPattern=MM-dd frBE.wirelessInput=dd-MM-yy,ddMMyy frBE.wirelessOutput=dd-MM-yy frBE.wirelessDisplay=dd-mm-yy
This file is used for changing the logging level for SIM client programs. For details, see section ”Changing Logging Levels.”
SIM server configuration files are packaged in sim-server-resources.jar distribution.
This file contains various configuration parameters for connecting to an LDAP server. The SIM installer should have set all values.
Additional context properties (specific to the context factory implementation) may be set if needed, see the comments for examples.
The configuration allows for customizations of the LDAP schema for object context, object class names, attribute names.
Example 3-6 ldap.cfg File
# LDAP Configuration # Initial context factory implementation (java.naming.factory.initial)initial.context.factory=com.sun.jndi.ldap.LdapCtxFactory # Provider URL (java.naming.provider.url) provider.url.primary=@ldap.url@�provider.url.backup=� �# Security authentication (java.naming.security.authentication)�security.authentication=simple��# Security protocol (java.naming.security.protocol)�security.protocol=��# Security credentials�security.user.alias=ldap-user��# Connection pool (com.sun.jndi.ldap.connect.pool)�connection.pool=true��# Additional context environment properties (context.env.*)�#context.env.com.sun.jndi.ldap.connect.timeout=�#context.env.com.sun.jndi.ldap.read.timeout=��# Base DN�base.dn=@ldap.base.dn@��# Store schema�schema.store.context=cn=SIMStores�schema.store.objectclass=simStore�schema.store.attribute.store.id=storeId��# Role schema�schema.role.context=cn=SIMRoles�schema.role.objectclass=simRole�schema.role.attribute.role.name=roleName�schema.role.attribute.type=type�schema.role.attribute.description=description��# User schema�schema.user.context=cn=Users�schema.user.objectclass=simUser�schema.user.attribute.username=uid�schema.user.attribute.superuser=superUser�schema.user.attribute.status=empStatus�schema.user.attribute.language=preferredLanguage�schema.user.attribute.country=preferredCountry�schema.user.attribute.first.name=givenName�schema.user.attribute.middle.name=middleName�schema.user.attribute.last.name=sn�schema.user.attribute.email=mail�schema.user.attribute.phone=telephoneNumber�schema.user.attribute.external.id=externalId�schema.user.attribute.supervisor=supervisor�schema.user.attribute.comments=description�schema.user.attribute.create.date=createTimestamp�schema.user.attribute.start.date=startTimestamp�schema.user.attribute.end.date=endTimestamp�schema.user.attribute.default.store=defaultStore�schema.user.attribute.user.stores=userStores��# User store schema�schema.user.store.context=cn=Users�schema.user.store.objectclass=simUser�schema.user.store.attribute.username=uid�schema.user.store.attribute.user.stores=userStores��# User role schema�schema.user.role.context=cn=Users�schema.user.role.objectclass=simUserRole�schema.user.role.attribute.role.name=roleName�schema.user.role.attribute.user.role=userRole�schema.user.role.attribute.user.role.stores=userRoleStores�
schema.user.role.attribute.start.date=startTimestamp schema.user.role.attribute.end.date=endTimestamp� # User group schema schema.user.group.context=cn=Groups schema.user.group.objectclass=groupOfUniqueNames schema.user.group.attribute.group.name=cn schema.user.group.attribute.user.group.users=uniqueMember
The server.cfg file contains server side configurations. For details, see the example server.cfg file.
Example 3-7 server.cfg File
# INITIALIZERS: A comma delimited class name list that needs to be executed when the #sim server starts. # Each entry must implement oracle.retail.sim.common.core.Initializer. INITIALIZERS=oracle.retail.sim.server.bootstrap.SimServerInitializer# FINALIZERS: A comma delimited class name list that needs to be executed when the sim #server stops. # Each entry must implement oracle.retail.sim.common.Finalizer. # For an example of what could be done, see oracle.retail.sim.tests.TestFinalizer FINALIZERS=oracle.retail.sim.server.bootstrap.SimServerFinalizer # Enable when deployed in a clustered environment to allow for cluster specific features. CLUSTERED=@deploy.clustered@ # The name the application's DataSource is registered under. DB_JNDI_NAME.BUSINESS=@datasource.business.jndi.name@ DB_JNDI_NAME.ADMIN=@datasource.admin.jndi.name@ DB_JNDI_NAME.MPS=@datasource.mps.jndi.name@ DB_JNDI_NAME.SECURITY=@datasource.security.jndi.name@ # The name the application's MailSession is registered under. MAIL_JNDI_NAME=mail/SimMailSession # Time in seconds to wait on database locks DB_LOCK_WAIT_TIME=60 DB_LOCK_WAIT_TIME_STOCK_COUNT=300 # Maximum number of parameters allowed in a database batch statement DB_BATCH_MAX_PARAM=5000 # Default database fetch size for batch processes BATCH_FETCH_LIMIT_DEFAULT=100 # Default pos transaction max size POS_TRANSACTION_MAX_SIZE=500 # Default item image request timeout in milliseconds ITEM_IMAGE_REQUEST_TIMEOUT=25000 # These keys define the implementation to classes that instantiate objects in SIM via #the factory pattern DEO_FACTORY_IMPL=oracle.retail.sim.server.integration.deo.DEOFactoryImpl RECORD_FACTORY_IMPL=oracle.retail.sim.server.business.RecordFactoryImpl # Server cache refresh rates. Time is in milliseconds. 30000=30 seconds 300000=5 minutes REFRESH_RATE_DATABASE_CLOCK=10800000 # The implementation of the internal security password encryption providerINTERNAL_PASSWORD_ENCRYPTION PROVIDER=oracle.retail.sim.server.security.SimPasswordEncryptionProvider # The algorithm name for random number generation used for internal security INTERNAL_PASSWORD_RANDOM_ALGORITHM=SHA1PRNG # The credential store alias for accessing the internal security password encryption keyINTERNAL_PASSWORD_KEY_ALIAS=internal-password-key # Enables initial automatic generation of the internal security password encryption key INTERNAL_PASSWORD_KEY_GENERATE=true # The algorithm name for internal security password encryption key generation INTERNAL_PASSWORD_KEY_ALGORITHM=HmacSHA256 # The MAC algorithm name used for internal security password encryption INTERNAL_PASSWORD_MAC_ALGORITHM=HmacSHA256 # The size of the MAC encryption key used for internal security password encryption (bits) INTERNAL_PASSWORD_MAC_KEY_SIZE=256 # The length of the salt generated for internal security password encryption (bytes) INTERNAL_PASSWORD_MAC_SALT_LENGTH=32 # This corresponds to a row in the message processing system configuration tableMPS_CONFIG_ID=1
SIM wireless configuration files are packaged in sim-wireless.zip distribution.
This file contains configuration used by the Wireless Server:
INITIALIZERS_CLIENT – comma-delimited class name list that is executed upon wireless client startup.
INITIALIZERS_SERVER – comma-delimited class name list that is executed upon wireless server startup.
Wireless Port – port the wireless server runs on, and clients connect to.
Example 3-8 wireless.cfg File
# INITIALIZERS_CLIENT: A comma delimited class name list that is executed upon wireless client startup # Each entry must be an implementation of oracle.retail.sim.common.core.Initializer. INITIALIZERS_CLIENT=oracle.retail.sim.wireless.bootstrap.SimWirelessClientInitializer # INITIALIZERS_SERVER: A comma delimited class name list that is executed upon wireless server startup # Each entry must be an implementation of oracle.retail.sim.common.core.Initializer. INITIALIZERS_SERVER=oracle.retail.sim.wireless.bootstrap.SimWirelessServerInitializer # Wireless Port - This is the port that the wireless server runs on, and clients connect to. PORT=@wireless.port@
This file contains identity store provider configuration.
For details, see the Oracle Store Inventory Management Implementation Guide, section ”Oracle Software Security Assurance (OSSA)”.
This file is used for changing the logging level for SIM wireless programs. For details, see the section ”Changing Logging Levels”.
External services configuration files contain configurations for SIM to be able to send requests to external services. External service configuration files are packaged in sim-ext-services-resources.jar distribution.
Configuration details for the following external services can be provided in the ext-services.cfg file:
ReportingExternalService
TicketPrintingExternalService
StoreOrderExternalService
PriceChangeExternalService
PriceInquiryExternalService
ManifestExternalService
FulfillmentOrderExternalService
An example of ext-services.cfg is as follows:
Example 3-9 ext-services.cfg File
# SIM External Services Configuration # ReportingExternalService ReportingExternalService.wsdl.url= ReportingExternalService.decorator= ReportingExternalService.user.alias=report-user ReportingExternalService.client.keystore.alias=report-client-keystore ReportingExternalService.client.key.alias=report-client-key ReportingExternalService.server.key.name= ReportingExternalService.bip.enabled=true # StoreOrderExternalService StoreOrderExternalService.wsdl.url= StoreOrderExternalService.decorator= StoreOrderExternalService.user.alias=rms-user StoreOrderExternalService.client.keystore.alias=rms-client-keystore StoreOrderExternalService.client.key.alias=rms-client-key StoreOrderExternalService.server.key.name=
RIB integration configuration files contain configurations for SIM integrates with Retail Products through Retail Integration Bus. RIB configuration files are packaged in sim-int-rib-resources.jar distribution.
This file contains the remote service lookup configuration to invoke RIB remote EJBs for publishing messages to RIB.
The SIM installer configures the configurable entries at SIM installation time. The SIM Installer also creates the security authentication wallet file and deploys to the SIM application server.
Example 3-10 remote_service_locator_info_ribclient.xml
<?xml version="1.0" ?><remote_service_locator_info> <!-- This is for JNDI --> <provider id="rib-sim" map-name="oracle.retail.sim" csm-wallet="@security.credstore.path@" > <context-property name="java.naming.factory.initial" value="weblogic.jndi.WLInitialContextFactory" /> <context-property name="java.naming.provider.url" value="@integration.rib.url@" /> <encrypted-context-property name="java.naming.security.principal" key="rib-user" value-type="PC_USERNAME" /> <encrypted-context-property name="java.naming.security.credentials" key="rib-user" value-type="PC_PASSWORD" /> </provider> </remote_service_locator_info>
where
@security.credstore.path@: The location where the security authentication wallet file is located
@integration.rib.url@: The RIB-SIM server's JNDI URL.
For example:
t3://rib-sim-serverxxxx:19106
Or
t3://rib-sim-serverxxxx:19106/rib-sim
|
Note: See the Oracle Retail Store Inventory Management Installation Guide for wallet location and configuration details. |
This file contains mappings for RIB message injector handler class and RIB incoming message family/type.
By default, this file should not be modified.
Example 3-11 injectors.xml
<?xml version="1.0" encoding="UTF-8"?><mps-boot xmlns="http://www.oracle.com/retail/sim/server/mps/bootstrap"> <!-- Message Families --> <importEnum class="oracle.retail.sim.common.integration.CoreSimMessageFamily"/> <!-- Message Types --> <importEnum class="oracle.retail.sim.common.integration.CoreSimMessageType"/> <!-- Core Consumers --> <!-- Integration Service Consumers --> <consumer type="ExternalItemImage" class="oracle.retail.sim.server.integration.consumer.items.ExternalItemImageConsumer"/> <!-- Ignored Consumers --> <consumerIgnore type="ASNInDel"/> <!-- Core Publishers --> <publisher type="EmailNotification" class="oracle.retail.sim.server.integration.publisher.notification.EmailNotificationPublisher"/> <!-- Payload Mappers --> <mapper source="com.oracle.retail.integration.base.bo.asnindesc.v1.ASNInDesc" class="oracle.retail.sim.intrib.mapper.ASNInDescMapper"/> <!-- DEO Mappers --> <mapper source="oracle.retail.sim.server.integration.deo.asn.AsnOutDeo" class="oracle.retail.sim.intrib.mapper.ASNOutDescMapper"/></mps-boot>
The SIM PC and handheld clients require a number of ports to be open on the SIM server in order to communicate. That means these ports will have to be opened on any firewalls between the SIM clients and the SIM server.
The following types of ports are required to be open by SIM:
WLS HTTP port (to download the SIM client)
WLS RMI ports (to make RMI calls from the SIM client to the SIM server)
Wavelink server port (for the handheld devices to communicate with the Wavelink server)
The Wavelink port is defined in wavelink-startup.sh and wireless_services.cfg. See the "Wireless Server Port in wavelink-startup.sh and wireless_services.cfg" section of the "SIM Configuration Files" appendix of the Oracle Retail Store Inventory Management Installation Guide for more information.
The Weblogic Application Server controls the HTTP and RMI ports. The HTTP port is a single port, but the RMI ports are defined as a range of ports. These port numbers can be changed if necessary. Refer to the following documentation for descriptions and instructions on how to change the ports:
Weblogic Application Server Administrator's Guide
Section D.2 Port Numbers (Sorted by Port Number) - Shows the port ranges assigned by default.
http://download.oracle.com/docs/cd/B25221_04/core.1013/b25209/portnums.htm#i688124
This section describes how to change settings for transaction timeout.
A transaction timeout is the maximum duration, in seconds, for transactions on the application server. If the specified amount of time expires, the transaction is automatically rolled back.
The WebLogic Server EJB container automatically sets the transaction timeout if a timeout value is not defined in the deployment descriptor. The container uses the value of the Timeout Seconds configuration parameter which has default value of 30 seconds.
The default transaction timeout settings may not be sufficient for some of SIM's processes, especially batch processes.
To change the transaction timeout setting on SIM domain server, open the WebLogic Server Console, go to the JTA page for the domain SIM is installed in, and change the value in the Timeout Seconds field.
In addition to change transaction timeout at domain level, user can also modify SIM EJB deployment descriptor file to set transaction timeout on EJB level. SIM deployment descriptor (weblogic-ejb-jar.xml) has specified transaction timeout settings for following EJBs:
Example 3-12 weblogic-ejb-jar.xml
<?xml version="1.0" encoding="UTF-8"?>
<weblogic-ejb-jar xmlns="http://xmlns.oracle.com/weblogic/weblogic-ejb-jar"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-ejb-jar http://xmlns.oracle.com/weblogic/weblogic-ejb-jar/1.5/weblogic-ejb-jar.xsd">
<weblogic-enterprise-bean>
<ejb-name>BatchServiceClientBean</ejb-name>
<transaction-descriptor>
<trans-timeout-seconds>3600</trans-timeout-seconds>
</transaction-descriptor>
</weblogic-enterprise-bean>
<weblogic-enterprise-bean>
<ejb-name>StockCountServiceClientBean</ejb-name>
<transaction-descriptor>
<trans-timeout-seconds>300</trans-timeout-seconds>
</transaction-descriptor>
</weblogic-enterprise-bean>
<weblogic-enterprise-bean>
<security-role-assignment>
<role-name>AUTHENTICATED</role-name>
<principal-name>@security.group.authenticated@</principal-name>
</security-role-assignment>
<security-role-assignment>
<role-name>SERVER</role-name>
<principal-name>@security.group.server@</principal-name>
</security-role-assignment>
<run-as-role-assignment>
<role-name>SERVER</role-name>
<run-as-principal-name>@server.user.name@</run-as-principal-name>
</run-as-role-assignment>
</weblogic-ejb-jar>
One of the first places to look for information concerning a problem in SIM is in the log files. Stack traces and debugging information can be found within the log files.
The log files are configured to roll over once they reach a certain size (currently 10 MB). Once a log file reaches the configured size, it will be renamed (for example, sim.log will be renamed to sim.log.1) and new log messages will be written to a new file (for example, sim.log). If there are already rolled-over logs, they will be also be renamed for example, sim.log.1 becomes sim.log.2, sim.log.2 becomes sim.log.3, and so forth). Only ten files are kept. If ten files already exist and the current file rolls over, the oldest log file is deleted.
The following describes the default location of the server log files and the client log files.
The server log file location can be changed by changing the value of the File parameter in the sim.appender appender log4j.xml file. See Configuration Files for log4j.xml locations.
Client-side log files are put in a directory called log, which is put wherever user.dir is defined in your system. For example, if you launched the Web start client with Firefox, user.dir is the directory where Firefox is installed. This means (depending on where you have Firefox installed) your logs could be in: C:\Program Files\Mozilla Firefox\log\sim.log.
To find the location of user.dir, double-click on the status bar at the bottom of the SIM PC client to bring up the Client Information dialog. Click the Version tab; one of the entries in the table is for the System Property user.dir. The value in the Version column shows the location of user.dir on the current client's system.
Sometimes it is useful to change the amount of information that the SIM server logs. There are two ways to change logging levels: editing the log4j.xml file, or using the Oracle Enterprise Manager Application Server Control user interface.
It is possible to change the level of any logger in the log4j.xml file. It is also possible to add new loggers if you want a certain SIM class to log more information. For more detail about loggers and logging levels, see the Log4J documentation at http://logging.apache.org/log4j/2.x/index.html.
|
Note: After changing a log level in log4j.xml the SIM server must be bounced before the change will take effect. |
Activity locking has been designed to be controlled from within SIM. The following example illustrates the logic of activity locking. A user becomes involved with a warehouse delivery that includes containers with multiple items in containers; that is, a significant amount of back and forth processing between screen and server is occurring. From the GUI, a call is made to the activity lock that instructs the system that the user is working with a container in the warehouse delivery. If some other user has the lock for the container, the system asks the user whether he or she wishes to break it and take over. A yes response to the prompt implies that former owner of the lock left the lock dangling without a good reason (left to get lunch and so on). A no response to the prompt implies that the former owner of the lock continues to legitimately need it in place in order to finish processing.
