SUPPRESS question

I am guessing your IF is failing to operate properly.

The SUPPRESS absolutely does suppress a message. If it is executed unconditionally then it always suppresses (because it always gets executed), if it is executed as part of a condition, then it will only suppress if the condition set properly functions.

As an aside to anyone interested, in Cloverleaf(R) 5.6 the Xlate has a Deactivate feature.

Apparently that feature does not really deactivate the SUPPRESS when the SUPPRESS is inside an IF Action (at least in my testing).

Hmmm maybe I should post that as a different topic.

First off, let me say, that probably 99% of our filtering of messages is done in the IB TPS stack.  However, there are times, when we do need to kill the message in the Xlate based on certain criteria.   Since some of our interfaces are one to many, we don’t necessarily want to use a tcl proc.  In this case, we will use a SUPPRESS within the xlate.   Two general rules I follow (for my own peace of mind) when using a SUPPRESS:

1.  The SUPPRESS is always the last line in the xlate.   If, as they say, all of the xlt code is executed anyway, it makes sense to put it there.

2.  I always put an echo to place into the log file some information about the message and the reason for the suppression.   That way, if someone comes behind me and has some trouble figuring out why the message isn’t passing through as it should, they can see in the log file or the testing tool the suppress echo comment.   Also, if a downstream user says they don’t have a certain message, we can check the log file to see if it was suppressed.

Hope this helps…

Tom Rioux

I will offer a technique I use regarding the SUPPRESS.

First we do not filter in Xlates – we have a reusable filtering proc that is argument driven and can accomplish whatever we need. We achieve the granularity we want by filtering on the route.

However, we do sometimes produce multiple messages from an Xlate. That requires the use of the CONTINUE and the SUPPRESS.

In this case, I place the SUPPRESS at the top of the Xlate as a visual reminder to me right at the beginjing that I am probably creating multiple messages from this Xlate.

Since we use field-by-field Xlates some of our Xlates look very long (even though we use a ‘Table of Contents’ stolen unabashedly and with permission from James McPheron) so I use the top of the Xlate to give me visual clues.

The SUPPRESS does get deactivated when inside an IF Action.

What bit me is the known bug in Cloverleaf(R) 5.6 that sometimes the changes you make with an IF do not take effect even though they look fine.

I closed the Xlate and reopened it then redid the SUPPRESS test and it worked fine.

Grrr  😡

So ignore the part about the SUPPRESS deactivation inside an Xlate.

We use the same kind of thing here with tcl procs.  We have various filtering procs that are argument driven to filter messages.   However, in our quest to install a new HIS system, we are finding that not all of the scenario’s will fit in the box of those tcl procs.   It would take an overhaul of the procs (which are already in use in a lot of places) to make it workable.   Also, since we are probably only talking about 1% (if that), of all the messages we recieve each day, it is more efficient to put in a SUPPRESS.

With that being said and with the fact that now knowing that I no longer need to have the SUPPRESS at the bottom, it does make sense to put the SUPPRESS at the top.   No need to go through the whole translation only to suppress the message.

Jim, we also do field Xlates here with some Pathcopy’s thrown in.  I’d love to see an example of the “Table of Contents” you spoke of…with James permission of course.

Thanks….

Tom Rioux

RE: If action failure in Xlate for 5.6 (and 5.7).

Jim and company,

I had reported this as a problem and the R & D folks were able to recreate it and come up with a fix.  See comments gleaned from their response to us next:  – hope this helps (CASE #77414):

(From R & D)

In 5.8, the problem is fixed by the implementation of new feature for copy/paste across different xlate files.

This problem occurs after pasting an IF action containing ITERATE. In 5.6 and 5.7, the workaround would be to save and close the xlate file after pasting the IF action. And reopen it to do further modification.

Putting SUPPRESS at the bginning of an Xlate does not alter the fact that it only takes effect after the outbound message is built. In other words, the Xlate still creates a message it just does not emit it.

What placing it at the beginning does for me is to give me a visual reminder there is exceptional processing going on.

The ‘Table of Contents’ is really quite simple.

Normally we are going HL/7 to HL/7 so I will use that as an example.

I tend to build my Xlate in the order of the outbound message structure following the segments and groups in the order they are configured for the outbound message.

So when I am doing the work for the MSH for example I put an  IF Action like this:

IF =MSH eq =MSH

  do all of the MSH related stuff inside here…

Of course theat will alwyas be equal as written so what is it’s purpose?

Well prior to Cloverleaf 5.6 there were 2 purposes:

  1. Create a look of a ‘Table of Contents’.

  2. Allow for me to deactivate a segment or group by simply changing the IF so it is not equal.

So let’s say we have MSH PID PV1 NK1 OBX for the outbound message with lots of logic in each segment/group using the IF as outlined, this is what the Xlate would look like upon first opening it:

IF =MSH eq =MSH

IF =PID eq  =PID

IF =PV1 eq =PV1

IF =NK1 eq =NK1

IF =OBX eq =OBX

That ius pretty concise and to find out what I need to know regarding the PV1 for example, all I have to do is to expand that IF.

Try it on your next Xlate. I kind of like it.

Thanks Jim for the TOC reply.  We are already doing that here.  One of our Cloverleafers was an ex Healthvision employee, so I guess that is where it got picked up from.   It does make it look nice and neat.

I thought maybe it was something else.

Tom

Nope that is it.

Pretty simple and straightforward – and like you said makes things more desirable to read and neater.

We just began to use the ‘Table of Contents’ lanel to describe the technique because it kind of looks like a TOC and we really did not find any better way to describe it succinctly.

We’ve been using the TOC style ever since Jim told me about it a couple years ago. Certainly makes life a lot easier. We think of it as being in that “sliced bread” category.

Bob,

The interresting thing with this IF is I did not Copy and Paste when I had the issue (that is why I did not think it was that issue).

I built the IF with a SUPPRESS in it from scratch.

Based on the response you got – maybe there are more issues with IF than they think.