One of my recent client engagements posed a quite interesting requirement. Below is a full description on how I solved it with advice from other team members.
Client Requirement:
In a recent BPM project, we had a requirement to implement Batch Process such that it runs every day at a certain time. But another requirement along with that was, the time to run the batch process should be changeable. For example, a batch processes is set to run at 12.00 am every day as per the present requirement; however, after 3 months we might need to run them at 3.00 am everyday instead of 12.00 am.
For this project, we were using IBM Business Process Manager V8.0.1 Advanced.
Challenges in Designing Solution:
- One of the obvious solutions I thought of was to use Time-Elapsed UCA assuming it will allow us to change the trigger time at the run-time. However, there is no way to change the trigger time of the Time Elapsed UCA at the runtime. It needs to be changed using Process Designer and deployment needs to happen across all the environments before finally promoting the change to Production environment.
- Another option was to use WAS Scheduler to run the Batch jobs. However, it needed some learning curve to develop a solution and would have hampered the timeline. Another challenge was that the client wanted to use the IBM BPM (Process Designer) capabilities to develop a solution which will be easily supported by the client.
Solution Description:
Here is the high-level design for implementing above requirement for the Batch Process.
- A batch process will run systematically once every day at a specific time.
- Use Singleton design pattern such that at any point of time one and only one batch process instance will be running in BPM which will set off every day at a certain time.
- At any point, if the time for the batch process needs to be changed, we should be able to do it by doing following step:
- Check if there is an existing instance of the BPM Batch Process and terminate/delete it.
- Create a new instance with new time to run the batch processes.
- On a specified time, this process instance will invoke multiple batch process use-cases. For example Batch Process UseCase 1 and Batch Process UseCase 2 and so on as in the High Level Diagram below.
Advantages:
- It is a generic solution which can be implemented once and then batch process use-cases can be added at any time.
- It is not performance heavy. Even though there is always an instance in the background, it will consume resources only when it is executing at the batch process time and will release them while it is in wait state.
- It uses Process Designer capabilities with no java components, schedulers and properties files.
- It avoids any complications of running multiple schedulers at different server locations and on multiple nodes.
Disadvantages:
- A new instance needs to be created by the Admin when a change in time is proposed either by running scripts, using Human Service URL or Process Portal.
Implementation Details using Process Designer
“BPM Batch Process” Business Process Diagram:
Here is the implementation of the “BPM Batch Process” BPD which is exposed to be accessed by Admins. This BPD helps get the time for the batch job execution using SetBatchProcessTime Human Service and then every day it invokes multiple batch process use-cases at that time.
This implementation is based on Singleton design pattern i.e.at any given time only one Process Instance of this BPD should be active in BPM. If we want to change the time of batch job, then we need to call SetBatchProcessTime human service which will terminate the old instance and then create a new one with new time.
“SetBatchProcessTime” Human Service:
“SetBatchProcessTime” human service is used to set the batch process time such that it will run every day at the same time. This human service will be started with “batchDateTime” as the input. This will help to change the batch process time whenever required.
Since there can be only one instance of BPM Batch Process running at any point when a new time is being set for batch process, it will make sure there are no instances running beforehand. If there are then it will terminate it before creating a new instance for BPM Batch Process with new time.
Here is the implementation of the Human Service “SetBatchProcessTime”
Batch Process Use Cases:
Batch Process Use Cases can be different implementations in order to achieve any business relevant goals like changing a status of certain business cases, terminating business process instances, sending emails, and so on to name a few. These use cases can be any type of implementation, like a BPD, a General System Service, an Integration Service or any other Process Designer specific artifacts.
Invoking Batch Process
There are multiple ways to invoke this Batch Process via SetBatchProcessTime Human Service.
The SetBatchProcessTime Human Service will accept the trigger time for the batch process to be triggered every day. This Human Service will in turn instantiate BPM Batch Process BPD.
This Human Service can be invoked in number of ways as listed below.
1. Using SetBatchProcessTime Human Service URL
SetBatchProcessTime can be invoked by the administrators who are part of “Admins” group using the URL as mentioned below:
http://{hostname}:{portnumber}/teamworks/executeServiceByName?processApp=SPA&serviceName=SetBatchProcessTime
where:
SPA = Process App Acronym
SetBatchProcessTime = Name of Human Service
2. Using SetBatchProcessTime REST URL
The REST URL which can be used for invoking SetBatchProcessTime Human Service using POST method call is:
http://{hostname}:{portnumber}/rest/bpm/wle/v1/service/SPA@SetBatchProcessTime?action=start¶ms=%7B%22batchDateTime%22:%222014-02-27T00:00:00Z%22%7D&createTask=false&parts=all
where:
SPA = Process App Acronym
SetBatchProcessTime = Name of Human Service
batchDateTime = Batch Process Time parameter (%22 stands for quotes “”)
3. Using Process Portal
SetBatchProcessTime Human Service can be invoked using Process Portal by exposing it as Startable Service.
Process Portal:
For this particular solution, I exposed it as REST URL to be invoked using REST API in the deployment scripts to automate creation of the process instance instead of doing it manually.
Conclusion:
Yes, I was able to successfully achieve the client requirement by designing and implementing a solution but the significance of this experience is how thinking out-of-the-box helped me come up with an entire analysis while designing and implementing a solution. Not only was the Singleton design pattern used to design this solution but also it was generic along with flexibility to change the batch process trigger time in the future; there by sticking to the guidelines around good practices which is equally important in a solution.
Acknowledgements:
I would like to thank the following individuals:
- Soundarajan Mannathan for his advice.
- Salem Hadim for his advice and approvals.
- Eva Khalil for her valuable inputs on this blog piece.
Want to learn more about Prolifics?
- Visit www.prolifics.com
- Learn about our presence at IBM Impact
- Connect with Jimit:
 |
Jimit Sukkawala is a Consultant in BPM and Connectivity LoB in Prolifics specializing in Service Oriented Architecture, System Integration & Business Process Management. He has been with Prolifics for past 5 years and worked across different industry domains like Financial Services and Leisure & Hospitality. He has worked on projects through different phases of software development cycle and most of them making to Production. His main expertise is in WebSphere Process Server, WebSphere ESB and IBM BPM. He holds a master’s degree in Management Information System from University at Buffalo and bachelor’s degree in Information Technology from University of Mumbai.
 |
