How to design Data Syncronization solution to sync data from one Source system to three Target S ...

I am trying to design an integration solution where we want to sync Customer Data from one Source system to three target systems (using JDBC adapters and Broker) using one IS 6.5 + Broker configuration.

I can do that by getting Customer data using JDBC adatapter on Source and publishing the Canonical document and creating Triggers for each of the Target Systems. However our requirement is if one Target System is down, we want the document for that target system to queue in Broker and when the Target System is up, data needs to be sent to the Target System. Becauese of Maintenance reason we don’t want to create multiple brokers/Integration Server solution

Is there any way to Stop (not disable) a specific Trigger, if a Target system is down (we have heart beat rotuines on our target systems to find if a Target is up or down) and restart the trigger once the Target is up.

There is a fix from webMethods available for suspending and resuming the Triggers.The fix is IS_6-1_Fix22.It was available in 6.1.I am not sure about 6.5 version but they might have included it in WmPublic package in 6.5.You can check it out.This can help you in your solution as you can suspend and resume document retrieval from broker Queue using this.


Puneet Verma

Thanks for your response.

Spoke with WebMethods support team and they pointed me to the Resources page in IS Administrator web page. In 6.5 platform, there are DSP pages that list all available triggers and here we can selectively suspend Triggers.

However I noticed one issue. When we suspend a trigger and Integration server is shutdown and started, all the suspended trigger will be made active and they start processing the document that were help in the queue. I wanted last status of the trigger to me maintained through the bounces of Integration Server (I way schedulers work). I will talk to Support team on this.

The Built-in Services reference for 6.5 has the services listed to suspend and resume trigger retrieval and processing


I’d recommend incorporating these into your heartbeat service since they give you the ability to persist the change across server restarts and package reloads.