IBM BPM and Taskless Services
- June 25, 2013
- 0 Comments
[Editor’s Note: Taskless services are the kind of feature in IBM BPM that prospective customers don’t have the context to evaluate. Essentially, IBM BPM has two execution layers- the BPD layer, and the service layer. Taskless services combine the two in a powerfully efficient manner, while the default behavior is a “task service”. In our experience as consultants, having the option to configure behavior at a task level is just one of many examples where IBM BPM accommodates design choices that other vendors don’t provide.
For example, some vendors simply don’t provide two separate layers of execution at all. The separation between process and implementation of a task blurs…
This week Andrew Paier is contributing a guest post on the use of Taskless Services – one of those powerful unsung features of IBM BPM – in this post the focus is on a use case outside of a BPD entirely… ]
This post has to do with “Taskless” Services.
I mentioned this in passing in one thread [on developerworks] and it seemed to cause a good bit of confusion. To be specific what we are concerned with here are Human services that are not part of a process. These are frequently used for things like administrative screens or other simple UI required to support a process solution.
Like many things in life, these things are not harmful if used in moderation, but when abused I have seen them cause significant problems including system crashes and outages. So, first lets get some clarity on what we are talking about, then lets discuss how this causes a problem, finally lets look at the options to avoid this problem.
What we are talking about
if you select any option other than “Startable Service” you have allowed the creation of a “taskless” Human service. That is the human service will be executed without an underlying task the user can come back to if they want to continue with that service’s execution.
If the thing the user is doing with this service is very light weight, or isn’t done very often this will not cause you a problem. However, if this is a service that contains a lot of data and is likely to be executed very frequently, we have a problem. Each time the user clicks the link to run the service they will spin up a new instance of that service into the server’s memory. If they leave the service in some way (close the window, go to another URL, click on some other link in the portal) the server has no way of knowing it should “retire” that service from memory because it is no longer being used.
This is not as large a problem with task based human services for 2 reasons. First the user will come back eventually and run the same task, allowing the server to either use or reclaim the memory allocated to that server. Secondly tasks will always eventually route to an end allowing the server to retire the service’s execution.
This problem happens most frequently with customers that create their own service to behave as the user’s inbox. These services are designed to be run very often by many users and typically contain a lot of data. Additionally since they generally are used to redirect the browser to run tasks, many of them are designed so that the user’s main usage will wind up causing the browser to re-direct to another URL meaning the service never reaches an end point.
There are a few possible solutions to this problem. The first is to simply design your service so that it does execute to an end point (or postpone) so that the server can reclaim its memory. The easiest way to do this would be to put in an alert on the “onbeforeunload” event so that you user will be told “Please use button X to save your data and close this window.” This will help reduce the number of orphaned service executions.
The above does require that you design your service with logical exit or postpone points (note that a truly taskless execution will not be able to be postponed). Sometimes this is not doable.
Another solution is to deliver this piece of the UI in a different technology that is capable of handling the use case in question. A JSP for example will not cause a bunch of memory to be allocated on the server to retain the user’s state. So if you were creating a replacement inbox you might think about creating a small web app that uses the REST API to display the information your users need to see.
I have some of our team looking into other approaches that may be able to avoid these problems for IBM BPM developers without requiring too much planning or creation of UIs external to the Process Designer. As we make headway on these initiatives I hope to find ways to roll these solutions out to the community.
[Original Post can be found here, where Andrew will likely be posting a regular series based on his work on developerworks and other forums – and we’ll do our best to keep them cross-posted on the BP3 blog as well!]