distibute one message to one of many receiving ports

[Anonymous]

Scenario:

One inbound thread has to distribute short HL7 ORU messages from 30 (or 60 or 90) patient monitors to different receiving ports of the same host (1:1 mapping between patient monitor and receiving port). Each monitor sends his messages with a period of 1 minute. (The ward and bed information is part of the HL7 message.)

Question:

What option should be prefered

(1) creating 30 (or 60 or 90) outbound threads each thread with the configured port number for that specific patient monitor, or

(2) creating a single outbound thread and performing the port mapping in a TPS using drivercontrol?

PRO for (1)

There is no need to re-establish the connection and close the connection after message was sent.

Contra for (1)

The number of (outbound) threads in the process is very high!

Is GUI able to handle/view that hughe number?

Pro for (2)

Simple to configure, part/bed mapping can be done in a lookout table; table is simple to extend

Contra for (2)

There could be a time issue, if re-establishing of connections to each port has to be performed (connect to port, send message, disconnect port – 30, or 60, or 90 times per minute).

Is there another option available?

Thanks in advance for any comment.

Topic

[Richard Hart]

You could create a TCL write UPoC.  The proc reads the config tables and opens all ports at startup and then parses the message and communicates through the port.  TCL is event driven, so it shouldn’t be too hard.

You will lose visibility.

On the other hand, you could create the 90 thread site with multiple processes.  It would take a while to start, but provide the usual visual for error checking etc.

[Anonymous]

Many thanks Richard. I would prefer your first option, as it is more simple to add or remove ports.

Is there a write UPoC I could use as a base for it or as a sample?

[David Barr]

Richard’s first idea doesn’t address what you do when one of your receiving interfaces is down. It also doesn’t address monitoring of the connections. I’d be interested in how those issues would be addressed.

I’m not sure how I’d handle this myself, but creating separate threads for each connection is probably the most straightforward  solution. You could probably put them in a dedicated site so that they don’t clutter up your main site.

[Author]

Replies