Kill Message from within XLT

While it is not the most efficient, you can simply use ‘SUPPRESS’ as the action when your IF condition is true.  This suppresses the message.

Hope this helps.

Jim Cobane

Henry Ford Health

Put the SUPPRESS at the beginning of the Xlate. In the dialogue following the IF statement, if you want to send the message put a CONTINUE. The message will be killed if you don’t execute the IF.

Put the SUPPRESS at the beginning of the Xlate. In the dialogue following the IF statement, if you want to send the message put a CONTINUE. The message will be killed if you don’t execute the IF.

The Xlate always tries to generate a message.

Even if you do CONTINUE or SEND the Xlate will output one more message unless you do a SUPPRESS.

So what SUPRESS means is kill the message this Xlate would produce (with or without CONTINUE or SEND).

Where you place it is up to you.

If you unilaterally SUPPRESS by placing it a the beginning, then your following logic must use a CONTNUE or a SEND.

If you have your filtering conditions at the beginning and do the SUPPRESS in the true branch and the rest of your logic to define how the mesage should be constructed in the false (else) path no CONTINUE or SEND is necessary.

I believe the actual SUPPRESSION occurs after all of the Xlate logic is completed just before the Xlate is supposed to generate the message.

So having a condition with a SUPPRESS and no else followed by the unconditional building of the message will cause all of those actions to occur andf then the result thrown away.

So if what I believe is true, then using SUPPRESS within a condition but not having a false path to build the message only if the condition is not true is probably a little less efficient.

I also believe that with the enhancements in 5.8 for message parse sharing and stacking of Xlates, the performance of filtering in an Xlate may be improved sufficiently to warrant re-thinking the advantages of pre-xlate filtering versus in Xlate filtering.

One might also be able to have a filter Xlate followed by the actual message build Xlate. The filter Xlate would either SUPPRESS or CONTINUE the message depending on the filter conditions (probably use BULKCOPY or a series of PATHCOPYs to get the entire message passed on).

The messag build Xlate would then actually build the message based on the integration specification to the needs of the receiving system.

This would allow an architecture of having Xlates that build messages without fiiltering logic present (like now when using pre-xlate filtering via Tcl) which can be used when there is different filtering criteria and the filtering criteria would be in whatever filter Xlate was stacked ahead.

D studer,

Did you use SUPPRESS?  If so what was the results you had?

I am looking for a similar solution.

The Xlate always tries to generate a message.

Even if you do CONTINUE or SEND the Xlate will output one more message unless you do a SUPPRESS.

So what SUPRESS means is kill the message this Xlate would produce (with or without CONTINUE or SEND).

Where you place it is up to you.

If you unilaterally SUPPRESS by placing it a the beginning, then your following logic must use a CONTNUE or a SEND.

If you have your filtering conditions at the beginning and do the SUPPRESS in the true branch and the rest of your logic to define how the mesage should be constructed in the false (else) path no CONTINUE or SEND is necessary.

I believe the actual SUPPRESSION occurs after all of the Xlate logic is completed just before the Xlate is supposed to generate the message.

So having a condition with a SUPPRESS and no else followed by the unconditional building of the message will cause all of those actions to occur andf then the result thrown away.

So if what I believe is true, then using SUPPRESS within a condition but not having a false path to build the message only if the condition is not true is probably a little less efficient.

I also believe that with the enhancements in 5.8 for message parse sharing and stacking of Xlates, the performance of filtering in an Xlate may be improved sufficiently to warrant re-thinking the advantages of pre-xlate filtering versus in Xlate filtering.

One might also be able to have a filter Xlate followed by the actual message build Xlate. The filter Xlate would either SUPPRESS or CONTINUE the message depending on the filter conditions (probably use BULKCOPY or a series of PATHCOPYs to get the entire message passed on).

The messag build Xlate would then actually build the message based on the integration specification to the needs of the receiving system.

This would allow an architecture of having Xlates that build messages without fiiltering logic present (like now when using pre-xlate filtering via Tcl) which can be used when there is different filtering criteria and the filtering criteria would be in whatever filter Xlate was stacked ahead.

Jim, I love that idea.  We are not yet on 5.8 but we are rapidly moving in that direction and I can see many instances where this would drastically improve our performance and eliminate the creation of a bunch of extraneous messages that will never be used…

Thanks for that!