SYSPRO 8 Rules Data Service
Exploring
Where it fits in?
This service monitors your SYSPRO transaction log in real time (e.g. inserts, updates or deletes) and extracts specific information required for current and active rules.
The data extracted is then persisted in the SYSPRO database, which enables the SYSPRO 8 Rules Engine Service to process the data without intervention so that it can execute the actions required by each configured rule.
The information extracted includes before and after values (e.g. if a stock code's description is changed from 'Bike' to 'Mountain Bike', both values are stored).
This is useful with regard to delete-type transactions as you have access to the whole record deleted, not just the key.
This service is used by:
- SYSPRO Rules Engine
- SYSPRO Harmony
Terminology
Rule
Rules consist of conditions and actions.
A condition is evaluated and (if true) the SYSPRO Rules Engine initiates the defined actions.
Rule action
Actions are executed when the conditions of a rule are met.
For example:
These actions range from displaying a Harmony message, to creating a log file in a specific location, or tracking the history of a specific database column.
Rule condition
Conditions act as triggers that initiate a specific action according to how they have been configured.
They let you fine-tune a rule with the records to be excluded and when certain actions must be performed (i.e. they act as a set of conditional expressions that must be met before any rule actions are performed).
Rule target
A rule target indicates the database table to which a rule applies, as well as the operation on that table (e.g. All, Insert, Update or Delete).
Targets can be set as company-specific or system-wide.
Rule variable
Variables are used to define or manipulate any values required in the conditions or actions of a rule. The different property packets of a variable include the following:
| Variable | Description |
|---|---|
|
New |
Variables that begin with this property packet contain the new values of a record after an insert or update occurs. They are only available for Insert or Update type operations. |
|
Old |
Variables that begin with this property packet contain the previous value of a record before an update or delete occurs. They are only available for Update or Delete type operations. |
|
Current |
Variables that begin with this property packet contain the current value of a record. This is useful if the record has changed since the SYSPRO 8 Rules Data Service flagged the transaction. Most of the time these values are the same as the New variables. We recommend using the New property packet, as Current variables have a slight overhead. |
|
Global |
Variables that begin with this property packet are values related to the transaction, such as:
|
|
Var |
Variables that begin with this property packet are custom variables that have been defined in the Variables pane of the Rules Administrator program. |
Starting
Prerequisites
-
Microsoft .NET Framework 4.6
-
SYSPRO 8 Service Upgrade Manager
-
SYSPRO 8 e.net Communications Load Balancer
A valid endpoint must be configured in the System Setup program of SYSPRO 8.
Installation considerations
-
This service is installed using the SYSPRO Installer.
Solving
Debugging and DiagnosticsService Config.exe file
You can debug this service by editing the associated config file in elevated mode (i.e. with administrator privileges).
The SYSPRO.DataService.exe.config file is located in the in the folder to which you installed the service.
Windows Event Viewer function
You can view monitoring and troubleshooting messages about this service using the Event Viewer function in Windows:
(Control Panel > System and Security Administrative Tools > Event Viewer > Applications and Service Logs)
This service outputs an event log to the SYSPROSDS file.
Windows Services function
You can start, stop, restart and configure this service using the Services function in Windows:
(Control Panel > System and Security Administrative Tools > Services)
FAQs
How do I address log contention?
Log contention refers to a scenario where one process or thread attempts to acquire a lock held by another process or thread, but has to wait until the lock is released. This can reduce the throughput by hindering the concurrency of a program.
In certain workloads, just reading the transaction log can itself cause log contention.
If this situation arises, an administrator can use the BatchSize, SleepInterval, and NapInterval settings to throttle the service and reduce the load on SQL Server.
Why was the rules data service developed?
In the era of big data, companies need to be able to track changes to their data. These changes could be stored for analysis, or they could trigger a business process.
For example:
A sales order for an important customer could trigger an email to an expeditor, so that the order can be given a higher level of customer service and delivered on time.
The standard way of accomplishing this type of database monitoring in Microsoft SQL Server, is to use database events, which can monitor database operations and store them to other database tables.
However, database events usually involve severe performance degradation (verified by our own in-house testing). The effect is amplified for highly transactional systems, like SYSPRO ERP.
The SYSPRO 8 Rules Data Service provides an alternative approach to monitoring the database - it monitors the SQL transaction log. This is the ledger SQL Server uses internally to ensure the consistency of the database and to recover from errors in case of corruption.
Reading the transaction log results in better overall performance when compared to using database events.
Referencing
Configuration file
You should only edit this file for debugging purposes.
Don't use this as a method to update values for the service. This is because a wizard installation updates the system registry, which is what is read when using the service. A fresh installation overwrites these values, which may cause problems when you next run the service.
| Key | Description |
|---|---|
|
CommandTimeout (milliseconds) |
This indicates the timeout that is used for commands against the database. This corresponds to an ADO.net command timeout. The default is 300ms. |
| BatchSize |
This controls contention on the transaction log by throttling how many transactional records are read and written in each batch. The default is 750 records. |
|
SleepInterval (milliseconds) & NapInterval (milliseconds) |
These settings assist in controlling the service throttling. The service checks the transaction log for changes every SleepInterval. If changes are detected, the service then reads the BatchSize records, and then waits NapInterval. This step is repeated until there are no more records available. Once all records are read, the service waits for SleepInterval again before checking for more changes. The defaults are:
|
|
SubscriberRefreshInterval (milliseconds) |
This service has the following subscribers:
Subscribers can subscribe to specific events. For example: Only notify inserts and deletes on the InvMaster table. Subscribers can also change this at any time. For example: You no longer require changes from the InvMaster table, but rather changes on the InvMovements table. A subscriber notifies the SYSPRO 8 Rules Data Service of the events it is interested in by posting a message to a message queue, such as a new rule created by the SYSPRO Rules Engine. The service then checks for this message every SubscriberRefreshInterval. Therefore, changing the configuration in the SYSPRO Rules Engine, may not see events come through until this message is read. The default is 30 000ms. |
|
VersionCheckTime (hh:mm) |
This indicates when to check the SYSPRO 8 Service Upgrade Manager to perform an automatic service update. This should be scheduled during a low transaction time (e.g. shift change). The default is 05:00. |
|
BaseDir (text) |
This indicates the SYSPRO instance to use when connecting to the SYSPRO 8 e.net Communications Load Balancer service. The default is 0. |