Please click here for full reference on Process Utils DSC.
By: Lachlan Aldred
Using Avoka's Process Utils DSC
Scenario
A CRM process sends an eform to a user. It gets emailed back when submitted. An email receive task need to constantly check for the email's arrival before progressing the case to the next step.
The problem is that with hundreds, or possibly thousands of users, the level of traffic would be insurmountable if each process instance polled the email server for the presence of its email message. Therefore we split the process in two, so to speak. One process handles the users case, and the other is a singleton process whose job is to intermittently poll the mail server for any incoming messages. When the message arrives (the business event) the singleton process extracts a correlation-id out of the email and uses this to find the waiting process. It must then write the email data into the process instance, and 'unpause' the process instance.
Some obvious questions or challenges arise:
- How does the singleton process find the right user process instance, given just a correlation token in the email?
- How does the singleton process write the data in the email into the appropriate process instance?
- Having written the data, how does the singleton process continue the paused user process instance?
The Process Pattern
Rather than show the full implementation of the pattern we will show just the core elements of it.
The above process contains the user task 'Wait for other process'. This task is essentially designed to be started, and to wait. It gets completed, or rather interrupted , by the singleton process shown below. This process below is also not a complete process, but rather is reduced down to show the core elements of the approach. A complete version would use a looping structure around the process tasks, and poll for emails each time around the loop. Adding these, however, should be relatively straightforward.
As shown in the close-up (below) of the singleton process, the first task seeks to find the right instance of the user process. It does this by using the process name (in this case 'UserProcess') a correlation variable name (transactionID) and a correlation value (found inside the local process variable 'idCorrelate'). Put another way; the task matches the local variable 'idCorrelate' against the remote process variable 'transactionID' and when it finds an instance of 'UserProcess' with a matching variable value it returns that process'es ID.
Next the task "Find Running Task By Name" essentially finds the waiting user task in the other UserProcess given the process id and the name of the waiting user task.
Then "Update Process Data Value" writes some data into the UserProcess. Finally the task "Force Task Completion with Routing" causes the User task in the UserProcess to stop waiting and even selects which route the remote process ought to take.
A copy of the User process can be found here UserProcess-13-12-2007-1407.lca; and a copy of the singleton process can be found here SingletonProcess-13-12-2007-1407.lca.
