Business calendar resolve duedate

Flowable Engine
1

We support our own custom business calendars. When resolveDuedate is invoked and cannot resolve to a particular date, we would like to notify the admin to let them know of this issue. I would like to provide information such as the process id, timer id, etc.
The problem is that down in my custom calendar, I do not have access to any of this information. The static TimerUtil.createTimerEntityForTimerEventDefinition() method invokes the business calendar, but again the extra information I need is not available.
Any suggestions on a workaround to provide this type of information that I’m not seeing.
Thanks

2

Hi Stephanie,

When I am thinking about it I see several possibilities (not all of them):

  1. throw BpmnError and catch the error in the process model.
  2. Calendar is evaluated inside of command execution. CommandContext stores involved executions (CommandContextUtil.getInvolvedExecutions(CommandContextUtil.getCommandContext())). This option is not a public API and depends on the engine implementation.
  3. Evaluate calendar before it is used, set variable in the process (e.g. in the listener or service) and catch thrown exception.

Regards
Martin

3

Martin,
Suggestion #2 is really what I’m looking. There is just one problem. Lets say the workflow flows from startEvent-> intermediateCatchEvent1(timer), and startEvent->intermediateCatchEvent2(timer) and startEvent->userTask.

When my business calendar is called to resolve the due date, there are three “involved” executions. I really need to know the exact execution so I can send the appropriate notification to the admin. Is there a way to get the current execution?

4

Hi Stephanie,

I tested an option with parallel gateway fork/join. There were 2 parallel branches. Involved executions contain parent and child execution. It is possible to find execution out. In fact I do not like this option too much. (dependant on the implementation)

Martin

5

I agree that the approach would rely too much on the implementation. The checks would all be different depending on intermediate catch event vs boundary vs user task due date etc… Do you think that the TimerUtil.resolveDuedate could be updated so the execution is passed in?

6

No, but
the option 4. could be to replace timer behaviour (e.g. BoundaryTimerEventActivityBehavior) (how to) with the behaviour which will execute timer->businesscalendar and catch the exception thrown in the calendar.

7

Let me try to provide more details on exactly what we are doing and why. We support custom calendars that allow specifics date(s) or days of week to be excluded. If the resolved date (either due date on user task or timer trigger) is excluded, we do not want to throw an exception or return null as this causes an error in the workflow. Instead, the resolved due date (that is excluded) is increment by 24 hours and evaluated. This is repeated until a valid/non-excluded due date is found. If not found after configured number of attempts, the last timestamp that was evaluated is used. It is at this point, that we want to send a notification to the administrator to let them know the user task’s due date or the timer’s trigger timestamp will not be as they expected, and they might need to manually update the timer/due date as needed. This notification needs to provide enough information so the admin can resolve the issue. This includes process instance id, activityId, original due date that was excluded, the due date that was actually defined, the calendar name and the calendar id.

So we really need the execution/execution id in order to gather up enough information to send the notification.
Thoughts? I dont see how replacing the timer behavior as you mentioned above will help so wanted to provide more details. Thanks again

8

Hi Stephanie,

one possibility:
add an attribute to commandContext (e.g. in the activity behaviour). Attribute could contain processinstance Id, executionId, activityId. Remove the attribute from the command context when leaving the task.

Regards
Martin

9

Thanks Martin. Looking into this approach a little more. Will have to update the CommandContext so an attribute can be removed as not currently available…but testing that change along with mine. Is it necessary for the attribute to be removed?

10

You do not need to remove attribute, but it is a good habit to clean up everything, without any side effects.

Martin