Messages routed to this connection treated as inbound

I have not used that but I can tell you what I would use it for.

Consider there are 2 sites. The first site has (for sake of argument) ADT messages coming in. Let’s also accept that there are 5 systems which want those messages.

One architecture is to have the first site receive the ADT and immediately route them un-modified, un-filtered to the second site.

The first site would have 2 threads. One IB and one OB.

Previous to inter-site routing the OB thread above would be a TCP/IP Localhost connection and have a corresponding thread in the second site.

The corresponding thread is IB listening on localhost same port as the OB in Site 1.

Then routing, filtering, transformation, etc. would take place in the second site to the 5 destinations.

When inter-stie routing was offered the thread in the second site was defined by default as OB. There were tricks one could deploy to cause the messages to be routed from there but it was not very clean or obvious.

With this new feature we can now specify intersite routing where the thread in the second site acts as an IB thread. Thus giving the smae architecture as before intersite routing and inheriting the advantages (and disadvantages) of inter-site routing.

Feel free to email me if you would like amore in depth discussion of the above described architecture.

We have this box checked on an inbound thread. The inbound that has it checked receives ADT messages from our registration system. The registration messages are routed to quite a few other systems.

But recently, another system needed to send ADT messages also. We send these new ADT messages to our registration system but the registration system doesn’t generate outbound messages when it receives messages. So we also send these new messages to the registration inbound thread using an “Inter-Site Routing Port” in Cloverleaf. This gets these registration messages routed to all the ancillaries that receive ADT from the main registration system.

Bill,

Did you also define the IB thread as multi-user as well?

Jim,

If you mean multi-server, no.

I think that we didn’t need to because we set up the inter-site routing port on the ib. There is a “normal” connection from the registration system to the ib. Then there is a connection to the inter-site port from a destination thread in another Cloverleaf process.

Another way to have done it would have been to set up the ib as multi-server and made 2 “normal” connections. Probably the only reason I didn’t do it that way was that I wanted to try out the new features in Cloverleaf.

One factor to consider… When doing the inter-site port/Messages routed to this connection treated as inbound method, the messages that come this path don’t end up in the ib SMATDB. We have them in a SMATDB on a different thread. Sometimes, this is what we want. But sometimes you really would like all the ADT messages all in the same SMATDB.

Bill

Interesting.

I would have thought that under the covers, the Inter-site routing was using tcpip and multi-server would be necessary just as with any other ‘client’ to avoid lockouts etc.

So I once again learn something new here.

Interesting.

I would have thought that under the covers, the Inter-site routing was using tcpip and multi-server would be necessary just as with any other ‘client’ to avoid lockouts etc.

So I once again learn something new here.