I think it may be not quite correct. Subscription trigger starts new process instances, but transition trigger drives the existing processes. So if you just disable the subscr. triggers, your existing instances will continue to run. And if the “app outage” means that some backend systems are not available, then your processes will run into errors.
Hence you may have to suspend trans. triggers as well.
Just an alternate sol. I think it must, when the package is disabled it is unloaded from IS (no code hence no transactions) and the triggers will not appear “Settings > Messaging > webMethods Messaging Trigger Management”
Yes this would be helpful, currently we are suspending the notifications and broker trigger which calls main flow service, this mainflow service is the one which publishes document to subscription trigger.
In above case we are fine.
But how about the case where update or insert notifications are present in the same package where triggers are present.
Can you write your flow in steps starting from Notification up-to invoking subscription trigger. As per your information there should be a easy and feasible way to handle the outage.
Yes I echo with fml2 as well and to handle such kind of outages it’s the way of disable all the associated trigger’s so that queued data will be paused and once the system is back it can be processed of course human intervention is required in any case to make sure the data is not lost and guaranteed reached to the destination (safe point).