CE 7.30: Boundary event for human activity

[Former Member]

Hi there,

one quick question:

I have a approve/reject WDJ screen linked to a human activity.

To avoid having too many ExclusiveChoice gateways in my BPM, I tried to use the WDJ error event as boundary event in my BPM.

This event is fired when the user clicks on the reject button.

But if you do so, the user gets the following message on the screen:

Modeled error event triggered by embedded application: Corresponding error handling started for this task

Is that always the case when I use a boundary event in a human activity?

If so, that's not nice for the users to see that error message after rejecting a request.

So the only way to handle rejections in BPM properly is to use Exclusive Choice gateways?

Thanks in advance!

[stefan_henke · Accepted solution]

Hi,

this is a known issue. Howver, I cannot say when and how exactly this will be addressed. So, unfortunately for you it is the way howfiring boundary events get displayed to a user.

Regards,

Stefan

[Former Member · Accepted solution]

Hi Stefan,

thanks for answering.

I've found a simple workaround for that issue:

In my main process I call a referenced sub-process "Approval step" which includes my human activity together with an exclusive choice gateway "Approved?".

This gateway has two gates: "Yes" goes to normal end event, "No" goes to an error event.

If the user rejects, the sub process runs into an error event, which can be handled in my main process as a boundary event.

The only tricky thing is in my opinion the creation of the service interface/message trigger for that referenced sub-process.

You have to make sure that the service interface has a fault message, so that the referenced sub-process can have a boundary event.

[Former Member · Accepted solution]

The only problem that I see with the referenced sub-process is the following:

When the user displays the project flow, she/he only sees the sub-process, but not the main process, so the main process history is not visible for the user...

[Former Member · Accepted solution]

Unfortunately there's another weak point for using referenced sub-processes:

When an approver adds a note to his task, then the next approver doesn't see this note, because it's nother process instance of the sub-process.

So infact, if users want to have an overview about process' history, you have to model everything in one single process?

Is that right?

That can be quite confusing because of the size of the process.

[ch_loos · Accepted solution]

Yes, this is the case. It might also be not desired for task owners to see the full process, i.e. for security reasons.

In that case a references subflow can restrict the visibility.

For keeping your process model manageable you can use the embedded subflow as container and expand/collapse as needed.

[Former Member]

Maybe somebody else knows a better solution...