[Jim Kosloskey]

There is more regarding the Tcl API for SMATdb here:

docs/clis_2022.09_clfisolh_op_en-us.pdf

Find that file in your /integrator directory path as indicated above. This is what is available in 2209, hopefully it exists in your release. If it does not email me and I will see what I can do.

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

[Jim Kosloskey]

Tim,

I found some help file that indicates:

smatdbdelete smatdbhandle ?deleteCondition?

The deleteCondition is to be an SQL WHERE statement describing the conditions for deletion.

I suspect this module is to be called via another Tcl Proc so you will need to construct the wrapper. Perhaps use Charlie’s code modified to add a deletion option and exploit the other code to get to the point of deletion.

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

[Jim Kosloskey]

The conundrum here for Infor, I suspect, is SMAT is supposed to be the accurate representation of the messages that passed through that Thread. Allowing deletion of entries would open up the question of the accuracy of the SMAT.

What would happen if you had to prove a message you deleted actually traversed the thread? Will you keep another audit repository for that situation? How will that fit into the methodology your shop uses to troubleshoot? You may have already thought of the above so ignore if you want.

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

[Jim Kosloskey]

Charlie Bursell wrote the attached some time ago. I believe this is the latest version.

Attachments:

You must be logged in to view attached files.

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

[Jim Kosloskey]

Jason, did you get this resolved?

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

[Jim Kosloskey]

Each time the scheduled event happens (in your case when the advanced scheduling says it should), the protocol scans the directory specified and creates a list of files found. If there is a DirParse UPoC stack, the first proc in the stack is presented with the list. The proc(s) can then 9if they choose) manipulate that list and return the manipulated list. ONLY the files in the returned list are processed during this scheduled event (in your case, one file).

It would then be your responsibility to make sure all of the files eventually get processed. For example, if you create more than 30 files and there are only 30 days in a particular month, you would not have processed all of the files by the end of the month. But that may be OK in your scenario as the protocol will continue to pick up one file per day. You just need to be aware it will not be precise.

If you want to go into any more detail, let’s take this off-line – email me.

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

[Jim Kosloskey]

Thanks for sharing your results – this will be helpful to others.

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

[Jim Kosloskey]

Have you investigated the DirParse UPoC of the Fileset Protocol?

In the simplest form, if you want only the oldest to be picked up, your DirParse routine would be presented with a list of the files found during directory parse. I believe the default is timestamp order meaning the oldest would be the first in the list (I think). Then simply remove all but the first file in the list and return the list to the engine.

If timestamp is not oldest first, then specify full detail on the parse and now you will get the date/time of each file found (I think) and you can have logic to handle that.

As to timing, use advanced scheduling to have this only run once per day.

• This reply was modified 1 month ago by Jim Kosloskey. Reason: add once per day handling

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

[Jim Kosloskey]

Well, I had a few minutes, and my test shows the results are dependent upon the variant definition. This is not surprising.

In the standard ORU^R01 message the OBR is a required segment in the ORC Group (see layout in an above post). So, when PATHCOPYing @null at the group level, as many empty OBR segments as were created before the PATHCOPY will remain as empty OBR segments. Those can be reused but cannot be removed within the Xlate. The Xlate always outputs required segments even as empty segments.

However, if one makes the OBR segment optional it will be gone after the PATHCOPY.

The relationship between message variants and what wants to be done in the Xlate is essential to accomplish the transformation needs.

 

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

[Jim Kosloskey]

Chaining Xlates is a way to identify filtering is going on in the NetConfig or NetMonitor via Xlates.

The first Xlate does the filtering and only the filtering, the second does any transformation warranted. Naming the first filter something indicating filtering helps.

I have begun experimenting with ‘globalizing’ filter Xlates. The INCLUDE Xlate Action could be instrumental with a few changes to its functionality (some of which I have requested on this forum) along with appropriate variant definitions.

At my last employer before the INCLUDE was available, I accomplished some of this. I was just beginning that work when the employer decided to get rid of Cloverleaf and I departed.

I think it is close to doable, but I do not have any testing to evaluate and describe how-to and impacts.

I also use Tcl for filtering but less and less these days simply because many of my clients do not have the staff to support Tcl beyond very simplistic functionality, but they do understand the Xlate better.

That situation is what drove me to do my evaluation of the performance differences. If they were substantial, it would not be fair to my clients to not recommend Tcl over Xlate.

For the environments where there appeared to be a big difference, I frequently discover an architectural issue like overloaded processes or sites (more frequently overloaded sites).

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

[Jim Kosloskey]

email me and I will send you what I did to evaluate the performance differences between Tcl filtering and Xlate filtering – including chaining for filtering.

I will send you the evaluation and the testing components I used to do the evaluation which you can run on your environment. If you do decide to run the evaluation, I would be interested in your evaluation.

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

[Jim Kosloskey]

Note the Group Address Path does not have the trailing (0). If that is there the PATHCOPY only handles the first ITERATION. Without that (in my example – 1(0).1 – ending with the actual group identifier, all iterations should be affected by the PATHCOPY.

Let me know what you find out. I will try a test here as soon as I get some time.

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

[Jim Kosloskey]

Methods 1 and 2 performance is controlled by the ‘Read Interval’ and ‘Max Messages’ settings of the fileset-local protocol (I am assuming Fileset-local here).

If you ran with the defaults, the performance would be slow. I am not sure what goes on under the covers for method 3 but I am pretty sure you can improve the performance of the other methods with appropriate settings.

Did you try various settings?

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

[Jim Kosloskey]

I will offer that most times I don’t need to ‘clear’ the entire message buffer between multiple message issuances. Especially for results, it is usually the OBR Group or the OBX group that is different the rest of the message is rather static (meaning most of the data in the rest of the message is the same for each of the messages being created).

So, by using a PATHTCOPY Action at the OBR Group level I can clear out only that portion of a message needed to be cleared.

Something like:

@null    PATHCOPY    1(0).1         where…

The OB format is the basic 2.5 ORU^R01 (see attached file).

This will clear all of the ORC group including the OBR segment, and OBX subordinate groups. This section of the message is typically all that changes with the issuance of a new OB message.

If there is only one ORC group and if the OBR changes, I can PATHCOPY @null to the OBR segment and the OBX Group to just clear that part of the buffer. If the OBX Group is all that changes, I can PATHCOPY @null to the OBX Group.

By just clearing the pieces that need clearing, I can avoid the overhead of building the unchanging portions for every created message. Sometimes a ballpeen hammer is more useful than a sledgehammer.

 

• This reply was modified 1 month, 2 weeks ago by Jim Kosloskey. Reason: Typo correction

Attachments:

You must be logged in to view attached files.

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

[Jim Kosloskey]

Yes, the ability to clear the ‘buffer’ in an Xlate is a shortcoming.

Here is how I would consider use Chaining in your circumstance:

1. Chain of 2 Xlates
2. First Xlate –
   1. Place a unilateral SUPPRESS at the top of the Xlate.
   2. Create the Lab OB message
   3. Do a SEND. The difference between SEND and CONTINUE is SEND places the message in the OB thread directly, bypassing post Xlate processing. CONTINUE passes the OB message to the next state (in this case the second chained Xlate).
   4. Do a BULKCOPY with a CONTINUE. This will make a ‘copy’ of the IB message fo the next Chained Xlate.
3. Second Xlate –
   1. Create the Micro messages using SUPPRESS and CONTINUE as needed. As I understand it you would likely have multiple Micro messages.

Just be aware if any post processing of the SEND Lab message is needed, the Tcl code would be placed at the OB thread not the post-xlate. For the Micro messages, post-xlate could be used or at the OB thread.

Of course, another valid method is to use PATHCOPYs at each of the Group (or Segment) level (depending on the message structure) nulling out the Group by Group and Segments outside of Groups. Using the PATHCOPY at the Group level properly.

And lastly, something different…

1. Change the OB format to make the entire message a group (mark the MSH through last Group/Segment as repeating).
2. In your Xlate:
   1. PATHCOPY the MSH segment to the OB and anything else you need to do (the Xlate needs the MSH info in the OB buffer to parse the mesage).
   2. After you have CONTINUEd your message, PATHCOPY @null to the MSH Group (the entire message) this should ‘clear’ the OB buffer.
   3. Don’t forget to have a SUPPRESS (likely unilateral).

 

Jim

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

[Author]

Replies