How can I save ACK messages into a file

[ronald kalmeijer]

Hi,

I want to save the ACK messages into a file.

We have version 19.1 and the SMAT messages are saved in a SQL DB. Before that we could search in de SMAT files.
Is there a proc that save the ACK message into a file?

Greetings

Ronald

Topic

[James Cobane]

If you turn on the ‘Save Inbound’ on your outbound thread, your ACKs (inbound messages) should be saved in the SMAT DB you specify, just like your outbound.

Hope that helps.

[ronald kalmeijer]

Hi James,

I turn on the ‘Save Inbound’ allready, so the ACK are saved in the DB.
The ACK messages that I want to saved into a file is for searching through the messages.

Greetings

Ronald

[Jim Kosloskey]

Doesn’t the SmatDB provide a method for searching for messages then extracting those messages to a file?

I don’t have hands on experience or a Cloverleaf environment at hand but I think the User Doc combined with some ‘poking around’ should confirm that.

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

[Charlie Bursell]

Jim:

I would have to check or test that.  ACK messages are received as ack messages not IB messages.  If you enable OB ONLY on an outbound thread, it blocks IB messages but still receives ACKs.

Not where CL readily available now.  How about you test it and let me know?

[Jim Kosloskey]

Charlie,

I think acknowledgments are still logged to the SMAT (at least it was with the SMAT file not sure about SMAT DB). even with Outbound only set on the OB Thread.

I recall needing that information on a few Integrations. If my memory has not gotten too bad the OB thread was Outbound Only and Await Replies.

Like you, I do not have access to CL to test.

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

[Paul Stein]

What I do when I need to find a reply(ack) sent back to me for a message I sent OB:

On 19.1 with SMATDB turned on:

Right click on your OB thread->SMAT->Open Inbound(i.e. for IB replies)

There you can search message content and metadata, such as Control ID

To save to a file:

Select the messages that met your search criteria then select the ‘resend marked messages’ button

Change the ‘resend Selected messages To:’ from ‘thread’ to ‘file’

Give it a file name, format and directory to send to, then hit apply

[ronald kalmeijer]

The reason for saving the ACK messages into a file is as follow.

Cloverleaf is running on Linux. We want to search in the files with a script. So no actions in Cloverleaf are needed. We have set Retries -1.

 

[Paul Stein]

I don’t really follow your use case or completely understand what you’re trying to do. Maybe you can explain a little further. I have the same set up and am not sure why you would need a script to search in the ack files when you can use the IDE.

Users are very generous with script help here so I am sure someone can help once we understand better.

[Rob Abbott]

The SMAT DBs are sqlite databases.  So if you want to search with a script, you can use queries from the “sqlite3” command line that’s shipped with Cloverleaf.

Rob Abbott
Cloverleaf Emeritus

[Rob Lindsey]

There are a few ways to be able to search a SMATDB file with smat msgs saved.  I have written a script for our company that works really well from the command line.   I believe somewhere in the Forums that Charlie put some code out there.  I used some logic from his programming to add to mine to make it better (thanks Charlie).

Using sqlite from the linux command line and choosing your SMATDB file, you can use something like this:

select MessageContent,DestConn,DriverCtl,UserData,SourceConn,Time,TimeIn,TimeOut from smat_msgs where UPPER(MessageContent) like ‘%$whatToFind%’;

Of course if you have your SMATDB files encrypted, that will present some other challenges.

[ronald kalmeijer]

Here is the case.
Sending ADT messages and receiving ACK messages.
Some ADT messages give a NAK message.
Before 19.1 the ACK/NAK messages were saved in a file.
With scripting you can search in the file for a NAK message.
In 19.1 the ACK/NAK messages are only saved in a DB.
Now I want to save the ACK/NAK messages also in a file, so I can search in the file by scripting.
Result is ACK/NAK messages in DB and in file.

[Jim Kosloskey]

Why not use Tcl to check the acknowledgment and if it is a NAK flip the message over to the IB side and route the ACK (now a message) to a Fileset Protocol to save it (could also send an email indicating a NAK was received).

Or in the Tcl reply handling proc save to a file directly (still sending an email so you know right away a NAK occurred).

I realize the methodology is ingrained to use SMAT but this is an opportunity to rethink the situation.

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

[ronald kalmeijer]

Thanks Jim
I think both solutions are good enough for saving ACK messages.
Do you have an example of these solutions.
At the end we must know if NAK occurred. Besides we can save the message an email is also useful.

 

[Jim Kosloskey]

Unfortunately I do not have an exact example. I do have a proc that will OVER the message and another proc set that is very generic in nature for handling replies of any message structure. If you think either of those procs are of interest, email me and I will send them to you along with their User Doc.

Something to consider regarding the email: If the NAK is likely to occur frequently, an email with each NAK might prove to be more annoying than it is worth.

If indeed the NAKs can happen frequently, I would spend a fair amount of time trying to resolve the issue to reduce the frequency so that it becomes a true exception.

So what you might look at (if routing the reply as a message to a Fileset Protocol thread) is to see if anything in the Alerts for that Fileset thread will allow you to trigger the occurrence reliably once (you can also send an email with the Alert trigger) and then reset the Alert once the issue has been addressed.

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

[Jim Kosloskey]

In 19.x of CL I think you can now reliably route replies to destinations other than the original source. If that is the case, there would not be a need to OVER the message.

You could also route the reply (if 19.1 allows that) or OVER’d message to a Fileset Protocol and filter out the positive acknowledgments. Then if the Alerts will allow you to fire an alert once when the first message is written to the Fileset file (and send an email) you would not need to interrogate the reply via Tcl at the OB thread.

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

[ronald kalmeijer]

ronald kalmeijer wrote:

Thanks Jim I think both solutions are good enough for saving ACK messages. Do you have an example of these solutions (the second one is what I want). At the end we must know if NAK occurred. Besides we can save the message the email is also useful.

[Charlie Bursell]

Am I missing something here?  If you are worried about receiving a NAK the existing cl_check_ack in $HCIROOT/tclprocs/recover.tcl should handle this for you.

The proc will check for a NAK and attempt to resend the message three times.  If it still fails the message is sent to the ERROR DB with the error message from the NAK, if any, in the user metadata field.

If you need more. simply copy the proc, rename it to whatever, and modify it.  You could modify it to send email or whatever else you need.  The message that was NAKed is in the ERROR DB for you to handle as you see fit.

[Author]

Replies