SYSPRO 8 Rules Data Service

Exploring

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

  • The default location for this service is:

    Program Files > SYSPRO > SYSPRO 8 Rules Data Service

Rules consist of conditions and actions.

A condition is evaluated and (if true) the SYSPRO Rules Engine initiates the defined actions.

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.

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).

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.

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:

  • SchemaName
  • TableName
  • Operation
  • ChangedFields
  • TransactionDate
  • RuleId
  • LevelId
  • LevelValue
  • MessageId
  • BatchIndex
  • SystemWideDb

Var

Variables that begin with this property packet are custom variables that have been defined in the Variables pane of the Rules Administrator program.

Overview topic

SYSPRO Services

Topics

SYSPRO Rules Engine

SYSPRO Harmony

Programs

Rules Administrator

SYSPRO Harmony

Custom Configuration Options

Custom Configuration

PDF and Video Resources

Feature Guides

Install Guides

Starting

  • 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 Setup Options program of SYSPRO 8.

  • This service is installed using the SYSPRO Installer Application.

Solving


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.

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.

You can start, stop, restart and configure this service using the Services function in Windows:

(Control Panel > System and Security Administrative Tools > Services)

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.

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.

Service operators are created by SYSPRO and are used by SYSPRO services to obtain information about SYSPRO.

The service operator code starts with a double underscore to differentiate them from other operators. A default company code must be assigned to each service operator within the Operator Maintenance program, as we use the company code to log in the service operator via e.net .

The following is a list of service operators and their function within SYSPRO:

  • The __ADSYNC service operator is used by the SYSPRO 8 Active Directory Sync Service to push Microsoft Active Directory (AD) information into SYSPRO for Active Directory managed operators.

  • The __BOT service operator is used by the SYSPRO 8 Bot Service.

  • The __DFM service operator is used by the SYSPRO 8 Document Flow Manager Folder Poller and SYSPRO 8 Document Flow Manager Queue Poller to monitor folders, send files to the queue and process files.

  • The __ESP service operator is used by the following services:

    • SYSPRO 8 Espresso Service,

    • SYSPRO 8 Espresso Notification Service,

    • SYSPRO Espresso Development Plugin and the

    • SYSPRO Avanti Web Service to obtain information for the password reset and forgot password functionality.

  • The __POS service operator is used by the SYSPRO 8 Point of Sale Services to determine and validate the setup options and required credentials at start up, update the required databases and post to SYSPRO (if the Point of Sale operator doesn't have access to SYSPRO).

  • The __RUL service operator is used by the SYSPRO 8 Rules Engine Service and the SYSPRO 8 Rules Data Service.

  • The __SA service operator is used by the SYSPRO 8 Analytics service to make business object calls.

  • The __SAI service operator is used by the SYSPRO 8 Machine Learning service.

  • The __SRS service operator is used by the SYSPRO 8 Reporting Host Service and the SYSPRO 8 Cognitive Service to manage client-side report printing.

  • Only specific services use service operators to log in via e.net.

  • SYSPRO creates service operators by copying the ADMIN operator. If the ADMIN operator record doesn't exist (i.e. it may have been deleted), then the current operator is used when saving system details from the Setup Options program.

Service operators are signed in by a SYSPRO service and are used for any functionality that is required by the service to obtain information about SYSPRO.

Normal operators sign in to SYSPRO with a username and password. They access certain programs and functions to perform specific tasks.

For example:

the __SRS service operator is used by the SYSPRO 8 Reporting Host Service to obtain information about the companies in an environment, but it isn't used by the business object to retrieve the data for a report, as that would be the specific normal operator that submits the request for the report.

Referencing

You should only update this file for temporary debugging purposes (i.e. not as a method to update values for the service).

Any temporary changes made to the configuration files are reset to their original installation values when this application is next updated. Because these temporary changes are not carried forward, forgetting that you made them could hamper troubleshooting efforts if unexpected issues arise.

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:

  • SleepInterval = 5000ms
  • NapInterval = 500ms

SubscriberRefreshInterval (milliseconds)

This service has the following subscribers:

  • SYSPRO Rules Engine.

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.