Charge Interface – How can I be doing this better?

[Courtney Bush]

I have a need to build a charge interface that has some tricky requirements.  I have a build that works, but I can’t get away from the feeling that there is a much, much better way to do this.

The sending system (McK Horizon Lab) will be sending charges to the engine once a day, without a header or footer – only TCPIP DFT messages.  The receiving PA system (IDX) can only accept the batch of TCPIP messages that have a header (BHS message), followed by the DFTs, and then a footer (BTS) message.  I have no way of telling that the first DFT coming over is the first message of the batch of messages and no way of knowing that the last DFT is the last DFT of the batch of messages.

The current build I have is lengthy:  

Thread 1 – TCPIP for DFTs from sending system

Thread 2 – Writes to file (with xlate)

Thread 3 – Reads file with inbound TPS that creates a different file that has BHS, DFTs, and BTS

Thread 4 – Reads output file from Thread 3 and send to Thread 5

Thread 5 – TCPIP out to receiving system

I’ve read a post that mentioned making the thread to the receiving system with a protocol of upoc, I don’t believe that will work for me because there are four other threads sending to that receiving system.

Any thoughts?

Topic

[Richard Hart]

Hi Courtney.

It is very difficult for anyone to make a judgement call on the methods of completing a task without background etc.  If there is no easy way to identify all messages from a batch, then I believe you are on the right track.

One thing that I have done with saving information in files and later using this is to have one thread that reads and writes files. I use the fileset-local protocol and use TCL code on outbound to set the file information (metadata DRIVERCTL) for writing and then scheduling and TCL code for reading.

This may simplify the setup.

[Robert Kersemakers]

Hello Courtney,

I have written a Directory Parse proc, which checks whether the incoming file has changed during the last x seconds. If so, the file will not be read. In your example this can be used in thread 3 to make ‘reasonably’ sure that the file contains all DFTs. There will be some delay though, but normally with batches this will not be a problem.

Zuyderland Medisch Centrum; Heerlen/Sittard; The Netherlands

[Scott Lee]

Courtney,

Another option, perhaps the easiest to implement, is to put each message into it’s own batch.  Every message coming in gets a header and footer attached to it and sent on to the recieving system.  Every batch sent would have only one message.  

Scott

[Author]

Replies