IFS Workflow Scheduler Design

Introduction

The IFS Workflow Scheduler is used to listen for data changes within a product by making use of REST/SOAP GET webservices on staging tables. The scheduler will start once a day and stay active for 24 hours, the scheduler will expire, and a new case begins. During these 24 hours, the scheduler will call the GET requests available, determine if data exists and create various workflow cases automatically.

Design

Figure 1 displays the current design of the Workflow Scheduler within IFS Workflow.

Open

The case expiration is controlled by:

• Two DateTime objects

• Date and time the scheduler started

• Current time of the system when checking for expiration 

When the difference between these two DateTimes is a day (this is customizable) the scheduler will expire, ending the case. Since we begin a new scheduler every day at a specific time, the scheduler will expire at the same time a new one begins.

When the scheduler is not expired, it will continuously call the product’s webservice to determine if there is any data available. If there is, cases are created based on each record that was retrieved. If there is no data available, the create cases step is skipped and we wait 5 minutes (this is customizable) to check again. This process will continue for the entirety of the scheduler’s life time.

Why did we go with this?

The order of events has been thought about very carefully. If changed, several bugs could be introduced depending on the web services being used. We check for expiration as the very first task, so there are never two schedulers running at the same time. If we checked for product data first, then there is a chance that the GET webservice will modify the data being retrieved to say that the specific piece of data has been retrieved from an outside source (depending on the implementation of the webservice). This has been made apparent when working with IFS Merrick, as their data changes once it has been retrieved by a GET service. This means that if the case is expired, the data will be checked (changing the data) and then the scheduler would expire. The new scheduler that starts will no longer be able to obtain that data, causing it to, essentially, be lost in the system. Once we know the scheduler is not expired, we can safely check for data and create cases as needed, without fear of “losing data”.

This design provides increased auditability, such as how many cases and what cases have been created daily. It also increases maintainability and scalability by allowing IFS Workflow to store Integration Workflow information (Process name, UID, etc…) in a table and query on the table to determine which workflow needs to be created based on the data coming in (the workflow code – REVBKG [Revenue Bookings], INITDV [Initial Division Order], etc…). This will replace the current mechanism of hardcoding process information within the create cases step, which would cause that trigger to become increasingly larger with each new workflow created.