> SYSPRO Workflow Services (64-bit)

SYSPRO Workflow Services (64-bit)

This service allows any client or server application to communicate with workflows executing on the server.

The workflows and their endpoints are exposed as SOAP and REST endpoints. This simplifies developing and integrating applications to SYSPRO Workflow.

Applications using this service

  • SYSPRO Workflow

Getting Started

Prerequisites

  • SYSPRO e.net Communications Service.

Installing

  1. Run the SYSPROWorkflowServices.exe executable.

    You can obtain the file from the Ports and Downloads section of the InfoZone. Otherwise, contact your local reseller for more information.

    After any port updates, we recommend you restart the service to release any e.net business objects which may be held by the service.

    Reinstalling a service is typically only required if an updated and/or improved version of the service is released.

  2. During the installation you will be required to configure settings for the service.

    Installation field Description
    Service Configuration  
    Service Soap Port This is the port that the service will use to host the SOAP endpoint. If set, SOAP communication must be performed using an address that includes the port number (e.g. http://localhost:{PortNumber}/SYSPROWCFService/Soap).
    Service Rest Port This is the port that the service will use to host the REST endpoint. You must add the REST port to the firewall manually.
    Add SOAP port to firewall This adds the SOAP port automatically to the firewall.
    SYSPRO Application Server Instance This indicates the default instance of SYSPRO with which the service will communicate. SYSPRO instances are reflected in your Windows Registry to identify the Base folder of your SYSPRO install where the necessary .dll and .exe files are located.
    SYSPRO e.net WCF Service Endpoint This is the TCP-based network protocol (net.tcp://) that points to your SYSPRO e.net WCF Service installation (e.g. net.tcp://localhost:30000/SYSPROWCFService).

Troubleshooting

Debugging and diagnostics

You can troubleshoot errors or failures when using this service by editing the associated config file in elevated mode (i.e. with administrator privileges).

The SYSPROWorkflowHostService.exe.config file is located in the folder to which you installed the service and defaults to: C:\Program Files\SYSPRO\SYSPRO Workflow.

[Note]

You should only edit this file for debugging purposes.

Don't use this as a method to update values for the service. The reason for this is that a wizard installation updates the system registry, which is what is read when using the service. A fresh installation will overwrite these values, which may cause problems when you next run the service.

key Description
servicebaseaddress This defines the address at which the SYSPRO Workflow Service will be hosted. This excludes any ports that are used and is simply the name of the address.
serviceexternalbaseaddress This is the external base address and is used for external calls into the workflow such as links from emails.
servicesoapbinding The communication binding for the service to use for SOAP communication
servicerestport This is the port that the service will use to host the REST endpoint. You must add the REST port to the firewall manually.
servicesoapport This is the port that the service will use to host the SOAP endpoint. If set, SOAP communication must be performed using an address that includes the port number (e.g. http://localhost:{PortNumber}/SYSPROWCFService/Soap).
instancekey This indicates the default instance of SYSPRO with which the service will communicate. SYSPRO instances are reflected in your Windows Registry to identify the Base folder of your SYSPRO install where the necessary .dll and .exe files are located.
disabledcompanies This defines the companies (separated by a semi-colon) that should be ignored on startup by the SYSPRO Workflow Service (e.g. companies that do not have workflows deployed or do not use workflow).
persistencedelay This defines how long a workflow can be idle before it is persisted to the database. An idle workflow includes workflows waiting in delay activities, receive activities and even long running activities such as those calling business objects or sending emails. Lowering this value will increase the load on SQL.
notificationtemplate This defines the file path relative to the service install of the html template of email notifications sent by the workflow service. By changing this file or file path, the notification emails can be changed to use company-specific branding and formatting of messages.
sysprooutputtransform These define the filepath relative to the service install of XSL transform files used to transform raw XML returned by the workflow service REST API into user friendly html. These transforms can be changed to use company-specific branding and customized formatting of outputs from the REST API for lists of workflows, workflow instances, tracking data and all other workflow outputs such as Message sent to workflow successfully.
sysprolistoutputtransform This defines the xsl transform to use when generating output from the service when opened from a browser or email link.
sysprotrackingtransform This defines the xsl transform to use when generating output from the service when opened from a browser or email link.
sysproinstancestransform This defines the xsl transform to use when generating output from the service when opened from a browser or email link.
safemode This puts the SYSPRO Workflow Service into safe mode (i.e. prevent workflows that could possibly cause the workflow service to crash on startup from starting or deploying). The administrator can then manually start each of these workflows in order to diagnose which workflow is at fault. Use with extreme caution at a live site.
faultedretrydelay This allows workflows to automatically restart versions of workflows that have faulted due to unstable network conditions. Faulted retry delay sets the time taken between a workflow faulting and trying to restart it.
faultedretryattempts This sets the number of times the workflow service should try to restart the faulted workflow version. Sometimes workflow versions may be unable to restart initially depending on whether network conditions are still a problem. It is therefore important to tune this settings based on the type of environment, the regularity with which workflow is called and the overall stability of the system.
sqlcommandtimeout This sets the time that every workflow SQL command (specifically to the workflow database) can take before timing out. This can be useful in environments with unstable SQL connections where it may exceed the default one minute in certain instances.
usewcf This is the SYSPRO e.net WCF Service address that the SYSPRO Workflow Service will use to connect to SYSPRO.

Service logging

The SYSPRO Workflow Service outputs an event log to the SYSPROSWS file (Control Panel->Administrative Tools->Event Viewer->Applications and Service Logs) which you can review for diagnosing any problems encountered.

If you add a <DetailedLog> setting with a value of true, then this switches on logging for the workflow service. This records all calls to the workflow service as well as the workflow service's interaction with SYSPRO itself. This can be extremely useful when debugging whether calls reached workflow, whether workflows are starting up correctly and any other unexpected errors.

A SYSPROWorkflowHost.dll.log and a SYSPROWorkflowHostWrapper.dll log file is created in the SYSPRO Workflow Services install directory. The SYSPROWorkflowHost log will include all workflow service calls made and the SYSPROWorkflowHostWrapper log will include details about workflows starting up, becoming faulted, retiring, deploying and restarted.