I haven’t taken the time to write much on this blog. Full Stop. More so, I’ve not taken the time to write anything about my career which is working for BP3 a BPM consulting company. I’m going to try to change that and use this as a place to write up some of the more long winded responses that I post to the BPM forum on developer works.
This post has to do with “Taskless” Services.
I mentioned this in passing in one thread 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
When you create a human service in IBM BPM you have the option to expose that service in the overview tab of the service –
I
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.
The Problem
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.
Possible Solutions
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.
Future options
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.
