Hello,
I have a requirement to set a certain set of BPM instances - that have failed due to an irrecoverable error - to Stopped/Cancel.
I tried using both services:
a. pub.prt.admin:changeProcessStatus
b. pub.monitor.process.instanceControl:changeInstanceStatus
but no success.
Looks like one can’t change the status of a Failed instance (Not sure though).
Don’t want to update the underlying database tables.
Please suggest if someone has any insight/experience around such requirement.
Regards,
Manoj
Hi Manoj,
what exactly is your requirement here?
Failed status is considered a final status for the process instance as well as Stopped and Completed.
Instances with these status are considered during archiving/deletion of process instances.
Regards,
Holger
Hello Holger,
Thanks for the quick response.
Requirement is to stop some of the failed instances.
Failed is not a final status. We set instances to Failure in case of any business/technical error which can be recovered.
Once the resolved, support analyst can recover the case by resubmitting the step.
In some of the case where the issue is not recoverable we intend to set the status to ‘Stopped’ so that clear demarcation is possible as to which one to recover and which one to ignore.
As for archival/deletion we only archive Completed/Stopped instances not Failed.
Regards,
Manoj
Hi Manoj,
in this case I suggest to suspend the affected instances, which is not considered by Archiver.
You can then review these instances like you currently do with your failed instances and either resubmit or stop(cancel) them as per the outcome of the review.
If they still fail automatically, then this indicates something extraordinary which needs to be investigated.
But when running archiving service with Status “COMPLETED-FAILED” from IS Admin UI, this will consider Completed, Failed and Stopped instances when they match the select time frame.
See Monitor Users Guide for further informations about status and archiving.
Regards,
Holger
There are two types of failures…
Failed with Escalate Failure set to ‘true’ - This option should be chosen when the error is not recoverable. Example, like data issue.
Failed with Escalate Failure set to ‘false’ - This option should be chosen when the error is recoverable and the process instance can be resubmitted.
The failed instances which you have in your environment, do you know which option they used? I believe it should be the first one…
what is the version of webMethods suite, along with MWS, PRT, and Monitor fix levels?
-Senthil
Hello Holger,
Thanks for your reply.
I agree with the approach you suggested and have already gone ahead and did a small PoC. Thorough validation is in progress.
Will share the detailed implementation shortly.
A small tweak in the PE Storage Cleaner would suffice the need.
Regards,
Manoj
Hello Senthil,
In my opinion and understanding escalate failure to ‘true’ is useful when we have Sub-Process/Reference Process kind of implementation.
We escalate failure from the child process so that parent process can handle the failure/success accordingly.
Regards,
Manoj
If you have Process wide error handler in your process model, then Escalate failure plays a role in your process model even though if you do not have sub-process or reference process.
-Senthil