Want SMAT to differ from data sent

[Daniel Lee]

Using 5.8.4

I have an interface where I want the data logged in the SMAT to be different than the data that was actually sent to the receiving system.  Is that possible?

The reason is because we’re encoding a huge PDF document in the OBX-5 and the individual SMAT messages get so large that we can’t open them in the SMAT gui.  We still want the SMAT for troubleshooting (not resending) but don’t want the OBX-5 because of the size of the SMAT files.

As a work around I tried creating a proc that removes the encoded .pdf from the .msg file after the fact but it ends up corupting the SMAT because of all of the length and offset data in the .idx file.

I’m about to trudge down the path of modifying the .msg along with the data in the .idx but any ideas would be welcome.

p.s.  Creating an additional thread to do the SMAT isn’t an option for us.

Topic

[Robert Kersemakers]

No, it’s not possible to have the message in SMAT differ from the message that was actually sent. For me, it’s the purpose of SMAT to have an exact copy of the sent/received message.

Using another thread would be my first option, as you get the message in SMAT then, so you can use SMAT functionality. You will have to get rid of the sent messages though, maybe writing to a file in /dev/null?

Another option would be to use a tcl-proc and write the message, without OBX-5, to a local file. Or only send certain fields to this file (with a separator per line) so you could easily extract information from it.

Another option would be to use a small SQL-table and write certain fields to this table (never done this: we are on 5.5/5.7).

Poking at the .msg and .idx file is an option as well, which you have already tried. You could build your own SMAT-files based on the original SMAT, except without OBX-5, which means buitlding a new .idx file as well.

Just brainstorming here. No easy solution.

Zuyderland Medisch Centrum; Heerlen/Sittard; The Netherlands

[Daniel Lee]

Thanks Robert.  I was hoping there was a way but I very well understand the importance of the SMAT reflecting the message sent and understand why it was designed that way.

I have been trying to manipulate the smat but there’s extra spaces in the list elements that do not lend itself to TCL very well.  For example, {OFFSET 34543                       } turns into {OFFSET 34543} when I try to do a keylset to put the value back into the keyed list.  I can’t tell if that’s the reason why my SMAT is corrupt when I put it back together or not because this difference causes the “diff” output to be too overwhelming to see what’s going on.  I’m about to abandon treating the .idx as a keyed list and instead use regular expressions to put it back together to avoid this issue.

[Robert Kersemakers]

I have never played around with the SMAT .idx and .msg files, but I know others on this forum have.

Quickly checked and I can’t see an offset like {OFFSET 34543          } in a (non-manipulated) .idx file; I only see {OFFSET 34543}. Weird that you have that; could it be the OS? We are on HP-UX.

Zuyderland Medisch Centrum; Heerlen/Sittard; The Netherlands

[Daniel Lee]

That leads me to believe that it’s not the lack of extra spaces that are the problem and there’s something else going wrong when I’m putting the .msg and .idx files back together.  I’ll take that into consideration, thanks.

[David Barr]

Technically it is possible for the data in SMAT to differ from what was sent. If you don’t add the PDF contents to the message until the pre-write TPS proc, then the message logged to the saved message file won’t contain the PDF data.

[Daniel Lee]

Thanks David.  That confirms what a co-worker has noticed as well.  We’ll keep that into consideration as we’re evaluating our options.

[Author]

Replies