How to specify 'OR' condition in Extended Creteria for a TN Processing Rule

, ,
1

Wondering if someone had a crack on this.
I have an extended field “MessageType” from a generic doc type.

I want to invoke a specific processing rules if the MessageType = X or Y.

TN does not allow specifying multiple value in the extended creteria.
It will also not allow you to specify an ‘OR’ condition?

That leaves me to create multiple Processing rules which I dont want to create.

Can anyone point me to the correction direction?

2

As you said, the obvious way to handle this requirement is to use two TN processing rules, the first which matches MessageType == ‘X’, the second which matches MessageType == ‘Y’.

Another way would be to check the attribute’s value in code in your own TN bizdoc processing service, but this would mean all documents regardless of MessageType would need to be processed by the TN processing rule that called your service. That may or may not suit you, depending on your needs.

The only other way I can think of doing this with the one processing rule, and by far the trickiest, would be to use a custom transformation service on the extracted attribute to convert it to a boolean, so that you only have to check the one value in the TN processing rule’s extended criteria. I’d actually recommend leaving the existing MessageType extracted attribute alone, and creating a new one that you can transform to a boolean called something like MessageTypeXorY.

Have a read of Chapter 13, Defining and Managing TN XML Document Types, in the Trading Networks Administration Guide, which describes how to use attribute transformation services (both built-in and custom). Unfortunately it doesn’t really tell you how to build your own.

I’ve actually created a custom transformation service in my open-source TundraTN package ([url]https://github.com/Permafrost/TundraTN[/url]) which you could use to transform your MessageType attribute to a boolean using a regular expression such as /[XY]/.

// Trading Networks string transformer which returns whether the given Trading Networks document (bizdoc) 
// attribute value/s match the given regular expression pattern (arg).
//
// Refer to <http://docs.oracle.com/javase/6/docs/api/java/util/regex/Pattern.html> for more information
// on regular expression use in Java.
tundra.tn.document.attribute.string:match(values[], arg);

Here’s how you would use this TundraTN regular expression matching transformer:

  1. Create a new STRING Document Attribute in TN called MessageTypeXorY (Edit the Document Type, and click the Document Attributes button on the Extract tab and then click the New… button to create a new Attribute)
  2. On the Document Type, extract the new attribute MessageTypeXorY with the same XPath query as the existing MessageType attribute
  3. Choose a Custom Transformation using the service TundraTN/tundra.tn.document.attribute.string:match on the new attribute
  4. Set the Custom Transformation input arg to a regular expresssion such as [XY] which returns true for the required values of MessageType
  5. Save the changes to the Document Type
  6. Edit the Extended Criteria on your Processing Rule, select the new MessageTypeXorY attribute and set it to be equal to ‘true’
1 Like
3

Yet another way to do this: split your one generic document type into three mutually exclusive document types.

Given the following XML:

<message>
  <type>X</type>
  ...
</message>

You could:

  1. Create a MessageX document type, which includes an identifying query of “/message[0]/type[0]” matching a value of “X”
  2. Create a MessageY document type, which includes an identifying query of “/message[0]/type[0]” matching a value of “Y”
  3. Create a generic Message document type, which includes an identifying query of
    “/message[0]/type[0]!=‘X’ and /message[0]/type[0]!=‘Y’” matching a value of “true”
  4. Create a processing rule to process the MessageX and MessageY document types
  5. Create another processing rule to only process the generic Message document type
4

Thanks mate, that was really helpful.

I will try out the TundraTN stuff.
The processing rule 1 should be able to handle MessageX or Y, rule 2 should be able to handle Message A or B and so on.

I guess i can do it with this.

5

Below process can also help you…

You can have a custom attribute say ProcessMessageType in the TN doc type and write a custom service that contains logic to check the message type and mount the atrribute to true(if x or y) or false.

You can then have a processing rule that has an enxtended criteria ProcessMessageType equals true…

I hope this should work… :smiley: