We have TCP/IP Socket servers(Java Services) on Integration Servers. Integration Server’s (2 nos) are in an Active-Active cluster. We use a Broker(1 no).
The scenario is, IS1 or IS2 (based on load balancing) picks info from source and publishes to Broker. Trigger calls service in IS1 or IS2 (based on load balancing) to send information to target using TCP/IP Socket connection.
The issue is, only one IS will be connected to the TCP/IP client and if the other IS receives the doc, it will be lost.
We cannot have 1 tcp client connected to IS1 and one tcp client connected to IS2, as the client has to make sure he doesnt send duplicate values to us, and he has to take care of fail over too, like if IS1 is down, he should send the doc to IS2 only. Getting these additinal things done by TCP client(thrid party) is not possible.
Partial solution we know is, have the TCP/IP Server service update a configuration file mentioning which IS is the active TCP/IP Server so the pub service can get active IS TCP/IP Server info from config file and publish doc with a vairable (eg. tgtIS). Using trigger filters, the doc can be picked by active TCP/IP Server IS. The issue here is, if active TCP/IP server shifts from IS1 to IS2, then the docs in queue will be lost as they will still have IS1 as value for tgtIS.
One more option is to disable trigger in runtime based on the client connection to enable only the active IS TCP Server to pick doc from broker. But I believe, we cannot disable/enable triggers in runtime. Can we? and can we take information from the config file and have it as a dynamic filter condition in trigger, which should be updated based on the value when the doc is picked by the trigger?
Please let us know if there is any other way to have TCP/IP Socket Servers in IS Active-Active Cluster.
Hi Aara Amudhan,
As far as your question regarding “disable/enable” triggers in runtime is concerned, I suggest you look at the following fix and see if it is of any help to you. I believe with this fix, you can use to suspend/resume document retrieval for triggers.
If you plan to use these services in runtime, I suggest you do extensive QA to ensure that it runs perfectly in high volume production environment.
Here are the details for the fix and ask webM support (open a SR) to get the fix.
HTH,
Saurabh.
[i]
IS_6-1_Fix22 – Trigger Management/Quiescing: Suspend/Resume Public
services to better manage individual trigger behavior.
Suspend/resume document retrieval and document processing for individual
triggers.
The Integration Server provides controls that you can use to decrease,
suspend, or resume document retrieval or document processing for all
triggers at one time. This fix provides built-in services that you can use to suspend/resume document retrieval or document processing for specific triggers. The following services have been added to the WmPublic package:
Triggers can be modified at runtime by using API com.wm.app.b2b.server.PackageManager, there is considerable risk involved in it and is not recommended unless absolutely necessary.
All you do is over-write the node file which represents the trigger and reload the package.
If I understood your problem description, you can let the IS which publishes your doc process it through your trigger->Socket. Filter on the IS server which publishes. Since all you are doing is a send on your socket, you can have your socket process/thread running on both IS i.e no bind error problems here.
All you need to do is make send-socket a mutex event.
