Prism Services
The following sections list settings for the various services used by Prism. Most of the services can be configured either by directly editing the service's .ini file or by editing the service's configuration in Tech Toolkit Service Manager. Most of the .ini files for the services are in the \ProgramData\RetailPro\Server\Conf folder. A few of the services listed here cannot be edited.
When changes to config settings take effect
Config key labels indicate which config settings require a service restart to take effect. In summary, the following protocols apply:
1. All config settings for Prism services that do not pertain to Log settings, require a service restart to take effect, except as noted in 2.
2. Config changes for PrismScheduling and PrismTechToolkit services, other than thread counts, timeouts, and reconnect delay, take effect within 60 seconds of making the change.
3. Edits to log config settings take effect immediately, without a service restart, with the exception of "Alternate Log Folder". Log folder changes require a restart of all "Retail Pro Prism" services to take effect.
| Service | Description |
|---|---|
| OracleServiceRProODS | This service facilitates the replication of data between Prism and the RIL Oracle database. This service will establish the connection with the OracleODS12cr1TNSListener so that the Prism and Oracle databases can communicate. This service runs as a dependency of the PrismMQ service. |
| Apache | Every application that sends data across the Internet requires a web server to make the HTTP/S calls. To use Prism, the Apache service must be running. You can verify whether the service is running by launching Apache Monitor from the taskbar. When making configuration changes, if you need to reboot the service, be sure to stop the service, wait for it to shut down, then use the Start button to restart the service. Do not use the Restart button to restart the Apache service. |
| RabbitMQ | The RabbitMQ service handles tasks related to RabbitMQ messaging and messagequeues |
| PrismBackOffice | PrismBackOffice.exe facilitates operations related to inventory, adjustments, physical inventory and other back-office tasks. You can make api calls via the api/backoffice path |
| PrismCommonService | The PrismCommon service is an 'Auxiliary' service, a service that is used by many modules/functions throughout Prism. |
| PrismPOSV1Service |
This service handles POS-related tasks, Physical Inventory and a few other inventory-related tasks. The POSv1Service handles the RPC Methods and REST Resources that are listed in the RPSRESTSERVICEMODULE area of the Prism API Explorer. This service has settings related to thread counts and timeouts. The purpose of these entries is to control how much memory is allocated to a given RPS instance. Since we have a 32 bit architecture, each instance is limited to a max of 2 GB of memory. Transform is a very heavy resource and has a defined limit that we feel should be adequate for most circumstances. Auth threads are only applicable to the primary instance and define how many auth requests can happen simultaneously |
| PrismResiliencyService | This service facilitates the continued operation of central credit and central gift cards when the connection to the Centrals server goes down. The PrismResiliencyServer.exe facilitates offline processing and sending of those offline transactions to the processor when the connection is restored. |
| PrismLicSvr | Although licensing is not yet implemented in Prism, the PrismLicSvr service must be running for Prism to run. You will receive an error message when trying to launch Prism if this service is not running. |
| PrismMQService |
This service plays an important role in the replication of data between servers. You can configure PrismMQ with various options, including max number of senders/receivers and compression thresholds. |
| PrismSchedulingService | The Scheduling Service facilitates the running of tasks that you have defined in Tech Toolkit, as well as Prism built-in tasks (e.g. building customer history and subsidiary modeling). At the scheduled time, the service makes the necessary API calls to run the task(s). Tsks handled by the PrismSchedulingService include: Customer History daily process Customer History initialization process Markdown processing Subsidiary Modeling Scheduling service housekeeping task (1x per day) |
| PrismTechToolkitService | The TechToolKit Service supports the web-based version of Prism TechToolKit. |
| PrismReplicationService | The PrismMQService.exe works in conjuction with PrismMQConsumer.exe and PrismMQProducer.exe to replicate data between Prism servers.. |
| PrismDRSService | This service assists with the replication of data between Prism and an RIL Oracle database |
RabbitMQService
Note: This service is found in C:\Program Files (x86)\erl9.3\erts-9.3\bin\erlsrv.exe
This service cannot be configured; however, you can start/stop the service as needed.
PrismBackOfficeService
PrismBackOffice.exe facilitates operations related to inventory, purchasing, transfers and other back-office tasks. You can make api calls via the api/backoffice path. The GETLIMIT section enables you to restrict the total number of records returned by a GET request for the following: in.ventorylist, transferslip, invnlot, inventory, document, adjustment and invnserial.
PrismCommonService
This service helps with tasks that are performed in multiple areas (e.g. customer lookups).
The GETLIMIT section restricts the total number of records returned by a GET request for customer and customerlist records (default = 100).
PrismPOSV1Service
This service handles POS-related tasks, Physical Inventory and a few other inventory-related tasks. The POSv1Service handles the RPC Methods and REST Resources that are listed in the RPSRESTSERVICEMODULE area of the Prism API Explorer. This service has settings related to thread counts and timeouts. The purpose of these entries is to control how much memory is allocated to a given RPS instance. Each instance is limited to a max of 2 GB of memory. Transform is a very heavy resource and has a defined limit that we feel should be adequate for most circumstances. Auth threads are only applicable to the primary instance and define how many auth requests can happen simultaneously.
PrismResiliencyService
The PrismResiliencyService enables retailers to continue to make central credit and central gift card transactions when the connection to the Centrals server goes down. The PrismResiliencyServer.exe facilitates offline processing and sending of those offline transactions to the processor when the connection is restored.Settings for resiliency service. Note that the database type and location are taken from RPSLicensing.ini file.
| Property | Notes |
|---|---|
| DBRETRYSECONDS | The number of seconds between checks to see if the connection to the Centrals server has been restored. Default = 10 seconds. This means that if the connection to the Centrals Server is lost, the PrismResiliencyService.exe will wait 10 seconds and then check if the Centrals server is available. If not available, the PrismResiliencyService.exe will wait another 10 seconds and then check again if the Centrals Server is available, etc. |
| DATABASECONNECTDELAY | Number of seconds to wait before trying to connect to database (to prevent crashing Oracle during startup). Default = 30. |
| UDPPORTIN | Keep default 8432 Incoming port number for receiving commands. Used for centrals resiliency |
| UDPPORTOUT | Keep default 8433 Outgoing port number for sending responses to commands. Used for centrals resiliency |
PrismLicenseService
Although licensing is not yet implemented in Prism, the PrismLicSvr service must be running for Prism to run. You will receive an error message when trying to launch Prism if this service is not running.
Prism Scheduling Service
This service coordinates running of the following predefined tasks: Customer History daily process, Customer History initialization process, Markdown processing, Subsidiary Modeling and Scheduling service housekeeping task (1x per day)
[SCHEDULER]
| Property | Possible Values | Default | Notes |
|---|---|---|---|
| DEFAULT_INTERVAL | |||
| RUN TASKS ENABLED | If True, scheduled tasks are run. If False, no scheduled tasks will be run. |
||
| MAXALLOWEDTASKS | Determines the maximum number of tasks that can be chained together to run at one time. | ||
| RPSUSERNAME | Encrypted username | N/a | Username. |
| RPSPASSWORD | Encrypted password | N/A | Password for the specified username |
PrismTechToolkitService
This service monitors system settings and services. You can view or edit the settings for the TechToolkit service in the Service Manager tool of Tech Toolkit, or by editing the PrismTechToolkit.ini file (located in …\ProgramData\RetailPro\Server\Conf folder).
| Setting | Description |
|---|---|
| System Monitor Enabled | The System Monitor, when enabled, checks available diskspace, memory, and other system attributes. Default = Disabled |
| HealthCheck Run Interval (seconds) | The service will check Prism services' status every 60 seconds and restart any Prism-related services that have stopped or are not running. Enter the number of seconds between each health check. Default = 60. |
| Service Monitor Service Exclusions | If there is a Prism service you do not want the Monitor to restart, enter its exact name (as shown in the ToolKit's Service Manager listing) in the "Service Monitor-Service Exclusions" edit box. By default, all services are monitored. |
| Service Monitor Restart All Services | If selected, all services are restarted automatically during a full Prism restart. Default = Enabled |
| Service Monitor Enabled | The Service Monitor, when enabled, checks Prism services' status every 60 seconds and restarts any Prism-related service that has stopped or did not start. Default = Disabled |
| Thread Count | Number of threads used for monitoring services. |
| Available Diskspace Alert Percent | When available disk space reaches the specified percentage, an alert is sent. Default = 10. Important: The alert is not displayed to the end user; the alert is written to TechToolkitService log file. |
PrismReplicationService (PrismMQService)
The PrismMQService has key settings related to data replication. This file also has the [LOG] section (see end of this document for info about [LOG]).
[Prism]
This section only is present when PrismDRS is installed; therefore, it is not present on MySQL systems.
| Property | Possible values | Default | Notes |
|---|---|---|---|
| Initialization Batch Size | 25KB | How many messages to read from the database and process at a time. Also affects the logging or progress, as a log entry is only written as each batch is processed (Set to high and memory issues could ensue) | |
| Initialization Max Senders | 1 | Number of sender threads that can be spun up simultaneously. By default, the setting is set to 1. This setting helps prevent the server from being overwhelmed. If you change the setting, be careful not to set it so high that the server or RabbitMQ are overwhelmed. If you exceed this number, for example by trying to initialize a server while another server's initialization is in progress, the initialization will fail and an error message is written to the log | |
| Day-to-Day Max Retries | 5 | Number of threads that can run simultaneously receiving data for Day to day | |
| Preserve Successful Records | True, False | False | Determines whether users will see successful records and errors, or only errors (for both initialization and Day to day). The default value is False, meaning that successful records are not preserved. Keeping the default value of False is important for customers with large data sets. If set to true, large quantities of unneeded data (sometimes millions of rows) could be preserved. If set to False, when you run initialization and everything is successful, you will see the completed message in the V9 Status screen but no success records |
| Pub Update Interval | 105 | How often (in seconds) to scan 1st level DRS logs to catch changes coming from the RIL Oracle side | |
| Initialization Guaranteed Message Delivery | True, False | True | See the Resume Initialization at Startup section |
[PRISM]
| Property | Possible values | Default | Notes |
|---|---|---|---|
| Initialization Threads Per Sender | positive integer | 5 | Set the Initialization Threads Per Sender to 5 or the number of cores you have allocated if you allocate more than 5. |
| Initialization Max Senders | positive integer | 1 | Number of threads that can run simultaneously sending data for initialization. |
| Initialization Max Receivers | positive integer | 20 | Number of threads that can run simultaneously receiving data for initialization. |
| Initialization Batch Size | positive integer | 25KB | How many messages to read from the database and process at a time. Also affects the logging or progress, as a log entry is only written as each batch is processed (Set to high and memory issues could ensue). |
| Day to Day Max Receivers | positive integer | 5 | Number of threads that can run simultaneously receiving data for Day to day. |
| Day to Day Max Retries | positive integer | 5 | Maximum number of retries before failing |
| Day to Day Producer Interval | positive integer | 10 | How often (in seconds) to scan data event queues on Prism side for outgoing changes |
| Preserve Success Records | True, False | False | Determines whether users will see successful records and errors, or only errors. The default value is False, meaning that successful records are not preserved. Keeping the default value of False is important for customers with large data sets. If set to true, large quantities of unneeded data (sometimes millions of rows) could be preserved. When you run initialization, and everything is successful, but the property is set to false, you will see the completed message in the Status screen but you will not see success records |
| Initialization Guaranteed Message Delivery | True, False | True | See the Resume Initialization at Startup section after the tables. |
| Resume Initialization at Startup | True, False | True | See the Resume Initialization on Startup note following the tables. |
[GENERAL]
| Property | Possible Values | Default | |
|---|---|---|---|
| ReceiveTimeoutSeconds | 5 | Time to wait between receives | |
| MessageType | JSON, BINARY, XML | BINARY | Message Body format. Binary is fastest, JSON also supported. XMLis not supported. |
| CompresionThreshold | Size in kilobits | 100KB | The threshold above which large files will be compressed for easier replication. Only available if Message Type is set to JSON. (See the Compression Timeout section) |
| UserName | RabbitMQ Credential | ||
| Password | RabbitMQ Credential | ||
| HostName | RabbitMQ Credential |
Compression Threshold
The PrismMQService.ini file has a Compression Theshold parameter that helps avoid problems when replicating large files, such a large Promotions file. The Compression Theshold parameter only works with text (JSON) payloads (binary payloads do not benefit much from compression). By default, Prism replicates data in Binary format and thus does not use the Compression Theshold parameter. Therefore, a user must change the Message Type setting in the PrismMQService.ini file on each server from BINARY to JSON. After changing configuration, remember to stop the service and then start the service again. Another example of when the user must change the Message Type value is on a double-byte character OS such as Japanese, Korean or Chinese. The Compression Theshold parameter has a default setting of 100KB. This means that any payload greater than 100KB will be compressed. Setting the parameter to "0" will turn off compression. A typical 10MB file will compress to about 200KB.
Resume Initialization at Startup
If you set ResumeInitOnStartup to true, then if a consumer does down during an initialization, when the consumer is restarted it will resume initialization automatically. VERY IMPORTANT: In tandem with this property the user must also set the INIGUARANTEEDMESSAGEDELIVERY to true on the sending server for the desired initialization type (RIL to Prism, or Prism to Prism) to guarantee that if RabbitMQ goes down, no messages are lost. For example, if you start an initialization and realize the consumer's 20-thread default is too low for the power of the machine. You can now pause that consumer, change the thread count and then resume the consumer and it will pick up where it left off with the new thread count. Also, if a consumer goes down for some reason or stops responding for some reason, when PrismMQ restarts Initialization can resume either automatically or manually by the user.
IF GMD is False then some messages may be lost in the event of a RabbitMQ Failure (not just a PMQ failure) and even a restart of initialization will likely get stuck and not finish, and then have to be cancelled and restarted from the last completed resource.
NOTE: YOU CANNOT PAUSE THE SENDER, BUT EACH DOWNSTREAM CONSUMER SYSTEM CAN NOW BE PAUSED AND OR RESUMED.
These properties are therefore, all defaulted to True at this point so that out of the box going forward this will just work. There is one issue with this in that turning on GMD for a system that has both sender and consumer on same system (RIL and Prism installed together on same system) will slow down initialization somewhat for this system and any others that might be included in an initialization batch with this system. If these properties are set to False, then pausing and resuming initialization will still work if RMQ on a given consumer does not go down.
Retail Pro Prism DRS Service
The only setting you can adjust for this service is the Thread Count (default = 5).
Special Config Settings
This section has additional information about some of the configuration settings that provide special functionality.
- ClaimAtStartup
- PRESERVESUCCESSRECORDS
- GETLIMIT
ClaimAtStartup
Current Proxy functionality allows multiple proxies to access the same cash drawer on a POS workstation.
A new option has been introduced. Now the Cash Drawer plugin (OPOSCshDrwr.DLL) will read an additional optional field from the OPOSConf.ini file, called ClaimAtStartup.
Example:
[CshDrwr1]
LDN=A798-1
ClaimTimeout=10
Actv=1
ClaimAtStartup=1
If this value is 1, the Proxy claims the cash drawer at proxy startup time, and holds it until the proxy terminates. This allows faster response to drawer open and status requests. If this value is 0, or the field is not present (as in the field for current users), the Proxy claims the cash drawer at each drawer open or status request and releases it again. This allows multiple proxies to access the same cash drawer, if required. Note: You must manually enter this option and its parameter in the OPOSConf.ini file under the cash drawer section.
PRESERVESUCCESSRECORDS
The PRESERVERSUCCESSRECORDS setting in the PrismMQService.ini file determines whether users will see successful records and errors, or only errors. In Prism MQ, the default value is False, meaning that successful records are not preserved. Keeping the default value of False is important for customers with large data sets. If set to true, large quantities of unneeded data (sometimes millions of rows) could be preserved. When you run initialization, and everything is successful, but the property is set to false, you will see the completed message in the V9 Status screen but you will not see success records.
[V9]
INITSENDTHREADCNT=1
MESSAGEBATCHSIZE=25
D2DRECVTHREADCNT=5
D2DMAXRETRIES=5
INITHIGHTHRESHOLD=10000
INITLOWTHRESHOLD=5000
INITRESTARTTIMEOUT=10
PRESERVESUCCESSRECORDS=False or True
[PRISM]
INITRECVTHREADCNT=20
INITMAXRETRIES=20
D2DRECVTHREADCNT=5
D2DMAXRETRIES=5
PRESERVESUCCESSRECORDS=False or True
GETLIMIT
A protection feature for out-of-memory errors is available for the RPS, BackOffice and Common services. Now, technicians can limit the number of rows that the web client (or customization) can request when making unfiltered GET REST requests. Such requests force the server to load ALL rows into memory. This can cause the server (Apache or one of the Prism services) to crash with "out of memory" errors.
This protection is TURNED OFF by default. Turn on the protection in any or all of the following configuration files when the system is suffering from these "out of memory" errors for a particular resource:
- RPS module - RPSRestServiceModule.ini
- BackOffice service - PrismBackOffice.ini
- Common service - PrismCommon.ini
[GETLIMIT]
# what to do if no SID or filter is passed for top-level resource:
# >0: limit number of rows fetched (up to 10000)
# 0: no limit (default)
customer=100
document=100
inventory=100
Limits are applicable to the top-level resource only (for example, applicable for document, but not applicable on document items or tenders). Limits are set for each resource individually. Limits are applied when the GET request asks for more than one record of top-level resource when pagination parameters are not specified in request parameters.
If a resource is not listed or is listed with 0 limit (zero) - the protection is turned OFF. A positive number enforces a hard limit on the number of rows that will be loaded from the database.
Use Negative Numbers for Troubleshooting
Negative numbers are meant to be used during development or troubleshooting:
# -1 - server will try to load all rows that are requested, but will log a warning message to the log file (even on log level 1)
# -2 - server will NOT try to load any row from the database and will log a warning message (same as (a), but will avoid potential "out of memory" errors)
# -3 - server will return an error to the client instead of loading rows from the database (useful for early detection of unexpected unfiltered requests during development)
If a warning needs to be logged, it will be in a format similar to this - if you need to locate it in the logs look for "record limit problem detected" phrase:
2017.05.25.13.57.33.019 [2212] - WARNING - Record limit problem detected for resource inventory: GetList called with no pagination or SID - limit reached