In Business/Scientific work-flows, activities like invoking a partner service end-point could failed due to several reasons like network inconsistencies(non-deterministic), erroneous configurations(deterministic) etc. So the work-flow administrator should be able to retry and cancel those activities.
The administrator can retry activity any number of times, so the business logic related to the particular activity gets repeated until the particular process instance leads to “completed” or “fault” state.
Or the administrator can cancel the failed activity, so the particular process instance leads directly to “fault” state.
BPEL activity recovery is an in-build feature comes with WSO2 BPS and at the moment the implementation supports for failed <invoke/> activities. So a process administrator can monitor activity states via the BPEL visualization and retry or cancel them based on their preference.
The administrator can retry activity any number of times, so the business logic related to the particular activity gets repeated until the particular process instance leads to “completed” or “fault” state.
Or the administrator can cancel the failed activity, so the particular process instance leads directly to “fault” state.
BPEL activity recovery is an in-build feature comes with WSO2 BPS and at the moment the implementation supports for failed <invoke/> activities. So a process administrator can monitor activity states via the BPEL visualization and retry or cancel them based on their preference.
 |
| An screenshot of a failed <invoke/> activity named “InvokeCreditRating” and its recovery options... |
No comments:
Post a Comment