[Joe Baranski]

Charlie Bursell wrote:

Can’t see all of the code. Is there a chance that dispList was set with the original message? Instead of lappend dispList “CONTINUE $mh” try set dispList “CONTINUE $mh”

The displist was set at the start of the proc and not referenced until the end of the swap.  I tried your suggestion of changing it to a set instead of lappend and got this error with the Testing Tool

[0:TEST] ‘CONTINUE’ (returned by ‘tonic_siu_from_adt_build_db ‘) does not match { <key> <value> }
[0:TEST] ‘message0’ (returned by ‘tonic_siu_from_adt_build_db ‘) does not match { <key> <value> }

[Joe Baranski]

David Barr wrote:

The code looks fine to me, and if the testing tool says that it works, then your actual interface is probably still running the old code. I think you can “reload procedure” through the gui to apply your change, but I always just restart the process where the proc is getting run.

Jason Russell wrote:

Did you restart your process fully? Is the tclproc fully saved and showing up in the list? Just seems like the new code hasn’t been updated in memory.

This proc is active on the route; there’s a line of code to update a ProcessedFlag field on the db table that gets set to 1 when it updates/swaps-in the SIU and that functions when resending messages.

[Joe Baranski]

Partly because I’m far more knowledgeable with TCL than Xlates; my last site was 100% TCL and this new one is 100% Xlate.  And partly because Infor had recommended it due to Xlates being a little more top-heavy with resources.  We’ve had issues where some of the heavy-traffic interfaces with Xlate filtering would spike to 100% CPU usage and choke out our entire prod server.  We’ve already taken steps to fix that.  Not everything can be converted due to the complexity.  And things get even more complex when field length limitations impact the data.  Like Pt Type comes out of our EMR is 6 characters but the output format has 2 characters allowed for that field.

[Author]

Replies