Altering the messages before saving to smatdb

[Ken Lambert]

We have been implementing several interfaces lately which are base64 encoded files being sent to our Document Management System. Those are obviously incredibly huge messages. We decided that we really don’t want to save those messages in their entirety, but would still like to save the non-base64 encoded parts of the message. I’m trying to figure out what the best way to do that is.

I feel like I could pretty easily do this in a separate smatdb, but I’d prefer to do this so its identical to all the other threads and saving into the db specified in thread properties. I’m not seeing a way to do that easily. I’m wondering if I can ‘manually’ save it in a tcl proc and then jump the message past the point where Cloverleaf would normally save it. The other option I see is to have a post-save tcl proc that would query the message out of the smatdb, then remove it, edit it and save it back in. We would want to do this on both inbound and outbound messages.

Has anyone attempted anything similar to this that could provide some pointers?

We are on Cloverleaf 19.1.2

Topic

[Rob Abbott]

I think your best bet is to do the following:

• enable SMAT for the thread in question and enter the filename you want
• save NetConfig
• disable SMAT for the thread, leave the filename alone
• save NetConfig

Now you have a configuration with a SMAT file named, but it won’t save anything.

 

Then in the UPoC you can use the smatdb* commands to write the modified messages to SMAT.

You can get the inbound/outbound SMAT file names as follows (put this in the start mode and cache the filename(s) in a tcl global)

netconfig load

set conn_data [netconfig get connection data $HciConnName]

set infile [keylget conn_data SAVEMSGS.INFILE]

set outfile [keylget conn_data SAVEMSGS.OUTFILE]

 

 

• This reply was modified 3 years, 3 months ago by Rob Abbott.

Rob Abbott
Cloverleaf Emeritus

[Peter Heggie]

That is useful info and design.. thanks

Peter

Peter Heggie

[Rob Abbott]

Note – the smatdb* commands are a new feature in 20.1 so you would need to upgrade to take advantage of this.  You may be able to roll your own in earlier releases by using tclsqlite.

Rob Abbott
Cloverleaf Emeritus

[Jeff Eastman]

We have essentially the same issue, and this approach sounds great. I’m wondering though, do we need to programmatically handle the rolling of the SMAT file(s) if we take this approach?

[Ken Lambert]

I’m using SMATdb and those files are automatically cycling just fine. Of coures, when you strip off the base64 data these are tiny messages, so they haven’t cycled a ton.

[Author]

Replies