As stated in the overview document, multiple inbound and outbound clients can be configured to run in a single HL7 Comm. This document explains the implications of this and gives an example of how it might be exploited to perform a more complex integration task.
All inbound clients send messages to exactly the same controller (though, potentually through several threads, so I've taken care to ensure the core code is all thread-safe), where they are acted upon by the logic agent. Assuming the logic agent agrees that the data is acceptable, it is handed to all outbound clients. So, while the logic agent can cause the inbound message to be rejected, it cannot do so selectively for one outbound client versus another (though there's another way to do this, which I'll explain in a bit). There is also no guarantee made of data ordering as it comes into multiple inbound clients. Through a single inbound client, first-in/first-out (FIFO) is maintained, but mixing data from multiples could result in messages being processed in an unexpected order. This is really common-sense if you think about it, but I'll state that here for the record.
To give some examples, let's say that you have two Hl7ThreadServer clients configured to listen on ports for HL7 data and one Hl7Client configured to send data on to another listener. Any data received inbound from either Hl7ThreadServer listener is interleaved and sent out the Hl7Client sender in as close to the same order as it came in as possible. If you have some logic agent (for example you've created a beanshell script that's set to NACK some messages and are running the BshLogicAgentFromFile logic agent on your data in HL7 Comm) it will ACK or NACK the messages as you specify it to do, and messages you send on are sent to the sender client as you expect. Both inbounds are processed by the same script, however, and when the data is being processed by the script there is no way to differentiate which inbound listener it came in on. So if the data can't be differentiated by the content, it's wise not to try and have the data handled differently based upon the receiving handler at this level. A multiple HL7 Comm setup is recommended for this.
To continue the above discussion, if you wished to have each inbound client handle data differently, it is best to put each into its own HL7 Comm and use a third HL7 Comm to aggregate the data after it is processed. (I realize this is a nuissance, so I hope to enable a single HL7 Comm to behave as multiple HL7 Comms at some point in the near future).
This multiple HL7 Comm client may be desired even more when data is multiplexed in the other direction - that is, when a single or multiple inbounds send data on to multiple outbound. From a logic perspective accepting a message and sending it on is an all-or-nothing proposition. Therefore whether one or multiple inbound clients are receiving data it may be sent to all outbound clients or to none.
In this scenario you could take a single HL7 Comm and have it send all data (that is acceptable, of course) to two other HL7 Comms. Those HL7 Comms could decide independently on whether or not to send data on. For example one destination may want both ADT and scheduling transactions, but the other may want only ADT. That second example would employ a beanshell script or other logic agent to discard messages that didn't meet some criteria. Of course, if one of the destination HL7 Comms wanted to accept all data it would simply be passthrough and instead the eventual destination system could be connected to directly using the original HL7 Comm.