I am stuck trying to model the following process, and hope that someone here can help me on my way.
The context: we are developing an application to improve childhood vaccination rates (in rural Africa) by sending SMS reminders to young mothers for upcoming vaccinations for their baby.
The process is this: given a target vaccination date, the application sends an SMS reminder some days before. It then waits (receive task) for a notification of vaccination. This comes in when the mother visits the vaccination clinic: staff send an SMS with a unique code to the system. This triggers the receive task, and the (sub)process completes. If the mother does not show up, the receive task eventually times out and a human task is created for a phone call to reschedule the vaccination.
This is all straightforward. What I’m struggling with is that the mother may come to the clinic before the SMS reminder is due. This means that the system may receive a notification that pre-empts the wait and the “send reminder” task, yet should be handled by the receive task. How should I model this ‘cleanly’ (without coding against the API)? Am I thinking about the problem in the right way?
Another question: when a vaccination is rescheduled, is it better to complete or cancel the current (sub)process and start a new one, or to change timer values and “loop back” to an earlier point in the process?
It sounds like you’ve got two distinct paths in the process definition, either:
the steps as described above are followed (sms → wait → get notification → stop)
no sms needs to be sent, no wait has to happen
To model it, you can have a receive task that’s active immediately after starting the process instance, active at the same time there is the timer counting down to send the sms. When that pre-empted notification comes in, the receive task receives it and cancels the scheduled timer to send the sms message (probably by putting them together in a subprocess). Further on, the whole ‘wait’ subprocess doesn’t need to happen (simply set a variable when the receive task receives a notification and don’t go into the subprocess if the variable is set).
That’s more a business decision, wrt how you want the audit data to look like. Starting a new one at the end of the old one gives you a nice yearly overview. Looping back gives you the same, but in a different format. Depends on how you’d like to query it.
Feel free to use this project as a reference. Flowable has multiple advantages for us: open source so low costs and good support (QED), but also relatively “code-free” so maintainable without requiring a full-on programmer. These are desirable properties in a resource-constrained setting.
Thanks, that’s the trick! I was thinking of successive steps (send reminder, then wait for notification), but actually the wait is the core activity of the process, and the SMS is an “on the side” which happens iff the wait is still there one week before the vaccination’s due date. Same for the human task, which occurs if the wait is still there some time after the due date. I guess I could also model these as non-interrupting boundary timers on the receive task. Will give it a try.
One thing: IIUC, I can use process variables to set the expiry times on the boundary timers. I could set these variables in an execution listener on the event where the vaccination due date is set. Do I need to resort to Java code here (to do the java.util.Date maths), or is there a way to do this with scripting?