For normal WM flow, we could suspend trigger automatically by configuring trigger to 'Suspend and retry later' with proper resource monitoring service. Anyone know how to implement similar Auto Trigger suspend function n WM model?

Not sure if I got what you wanna do. Suspend as you said is already automatic. Can you explain the use-case you are looking at?

I want to introduce the mentioned auto trigger suspend function in the flow which was designed using WM Modeler. As you know, Modeler will generate trigger for each logical server automatically, no need human intervention to create triggers, and these triggers will invoke some run time elements, which is different with the trigger which was created by us manually. I tested this auto trigger suspend function in both normal trigger and the trigger generated by Modeler, the previous one works fine, but doesn't work for later one.

These triggers are internally managed by PRT. There are few configuration for document retrieval but for your scenario I think what you should be looking at is suspending the process(execution disabled) on error rather than modifying the trigger which is generated automatically.

suspending the trigger would not work. You can use services from WmPRT or WmMonitor package ( dont remember the service name ) to disable the process model...

Thanks for your comments, it's a brand new thinking direction:), but looks like, if I suspended the process, it will be very difficult to active the same process again after the connection was restored, is there any method to realize it?

Jenny Kang Suspending a process instance and disabling a process model are two different things. Do you need to disable the complete process, in which case no other instance can be initiated, or you need to suspend the running process for a while and then wake up later in which case new instances can still be started.

I want to suspend the process when the connection doesn't work, and all follow-up documents could be queued in broker, once the connection was restored, the process could be active automatically,no need human intervention to do resubmission. I'm trying to introduce this function to model process so that we will not get connection failure when there is connection glitch or planned/unplanned destination outage.

Actually, I have an implementation method in hands currently, by copying the last sending step to an isolated package out of the model, when failure happened, model will publish docs to this 'remote' package, then send to destination, I could add auto trigger suspend in this remote package. This implementation method is a bit complicated and not efficient, so want to check if there is any other better solution.

Disabling the process model in this case would not work becuase your documents will get discarded if the model is not enabled. Hence you can suspend each of the process model instance when it is unable to connect to a resource ( database ?? )...the flaw here is that you would still be processing and instantiating the model even if your resource is not available, can be a bit over head. And you can have a seperate resource monitoring service which would resume all the process models that are currently in suspended state...would that work for you ?

try to use - pub.prt.admin:suspendProcesses & pub.prt.admin:resumeProcesses

Resume and suspend process services work at model level and not instance level. So no new instances will be instantiated. Also the main usage for these services are different. I think the only way is to let process instance fail (after retry), then resubmit the process instance and this can automated. Again it should not be blind resubmit of all the failed instances. It should be only for the instances which failed with transient error. Having said that one should also ensure that the steps are retried when there is a transient error.