Inbound feed blank messages

[Brandon Grudt]

I have recently implemented a new feed that routes eMDs charges to Aprima for one of our offsite providers.  The problem that I run into is eMDs is sending up to 30-40 blank messages per day.  These messages do not hurt anything.  The engine catches them and errors them out, so Aprima does not see any of them.  I’ve verified that we get complete records into Aprima as well.  The one thing this does affect is my error reporting.  My error rates have jumped due to this.

So how can I filter off these bad messages before they throw a tcl error?  Should I wrap my entire tcl script in an if statement?

if { string length $msg > 0 } {

    run script

} else {

   kill message

}

Is there an easier way to do this?  I haven’t encountered blank messages like this before.

Thanks in advance.

Topic

[Russ Ross]

It is common to have charge files have all kinds of variations and a blank line between each message is not all that uncommon as a visual aid from some vendors.

Another common thing is one segment per line.

So whatever the variation is, having what I call a pre-proc step to make the file xlate friendly is part on my batch design, which is what you are talking about.

My difference is that my pre-proc step is a stand alone script outside cloverleaf that I run on the file before I put it in the cloverleaf load directory, but doing the pre-proc in a TPS stack pre-xlate is another way to go like you are talking about.

Russ Ross
RussRoss318@gmail.com

[Jim Kosloskey]

Brandon,

One way to handle them might be to add an static raw route at the end of your routes and apply hcitpsmsgkill to the pre-raw UPoC.

Of course that means if there are any other anomolies in the TrxID you won’t know about them. You could also static raw route to a fileset local so you have the offending messages trapped.

I am sure others have some input.

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Brandon Grudt]

So my tcl error is located in the IB data TPS, which indicates that the “create_ack” script may be the one erroring this out?  In that case, would a “kill_blank_messages” script placed prior to the “create_ack” script in the TPS Inbound Data fix this?

[Jim Kosloskey]

Brandon,

I did not realize you were getting a Tcl error – I assumed TrxID so my suggestion is of no use.

Yes you could stack a Tcl proc to KILL any message of zero length PRIOR to your ack Tcl proc – or you could modify your ack proc to accomodate the zero length message (could even send a nak back to the source system to dump the issue in their laps – let them manage the noise  😀 ).

Obviously the sending system does not consider the empty messages to be messages or they would not send another message if they did not get an ack. Of course, maybe they are not even using the ack you do send – that could be an entirely different can of worms.

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Brandon Grudt]

It would appear that the script that I placed on the IB feed worked to resolve the issue.  I’m not NAKing the blanks.  I know that the sender does queue when I stop my side of the interface, so I guess they either don’t know or don’t care about the blanks.  Thanks for the help.

[Author]

Replies