Trading Networks 10.3 | Administering and Monitoring B2B Transactions | Service Development Help | Conditional Expressions | Rules for Use of Expression Syntax with the Broker
 
Rules for Use of Expression Syntax with the Broker
When you create filters for webMethods Messaging Triggers that receive documents from Broker, keep in mind that some syntax that is valid on Integration Server is not valid on Broker. When you save a webMethods Messaging Trigger, Integration Server and Broker evaluate the filter to make sure that it uses proper syntax. If the syntax is valid on Broker, Broker saves the subscription and the filter. If the syntax is invalid on Broker, Integration Server automatically removes the filter before the Broker saves the subscription. The filter will only be saved on Integration Server.
Broker saves as much of a filter as possible with the subscription. For example, suppose that a filter consists of more than one expression, and only one of the expressions contains syntax Broker considers invalid. Broker saves the expressions it considers valid but does not save the expression containing invalid syntax. (Integration Server saves all the expressions.)
Note:webMethods Broker is deprecated.
Keep the following points in mind when writing filters for webMethods Messaging Triggers:
*Expressions that specify field names that contain syntax, characters, symbols, or words the Broker considers restricted or reserved will not be saved on the Broker.
*All expressions must contain a relational (comparison) operator.
*Use lexical relational operators (such as L_EQUALS, L_LESS_THAN) to compare fields of type String.
*Use standard relational operators (such as =, ==, !=, <, >, <= and >=) to compare fields that are not of type String.
*Use the =, ==, <>, or != operators to compare a value with an Object constrained as a Boolean.
*You can use My webMethods to view the filters (expressions) saved with a subscription. If the expression does not appear with the subscription on the Broker, then the expression contains invalid syntax.
The following table identifies syntax that the Broker considers invalid. Expressions with this syntax will be saved on Integration Server but not on the Broker.
Broker considers expressions invalid when they contain....
Examples
Field names with syntax, characters, symbols, or words the Broker considers restricted or reserved
eventtype L_EQUALS “addEmployee”tax% < 5
Although Broker considers a field name that contains the % symbol to be invalid, you can use the % symbol to enclose field names in the expression.
No comparison operators
"fieldName" "!fieldName"
A standard relational operator to compare fields of type String
%myString% < "yourString"
A lexical relational operator to compare fields that are not of type String
%price% L_LESS_THAN 50
A field of type String compared with a numeric value
"stringName" > 12
Operators other than =, ==, !=, or <> to compare an Object constrained as a Boolean with a value
myBoolean <= "true"
An Object constrained as a Boolean compared with a field of type String
myBoolean = "stringFieldName"
Note:
Expressions that check an Object constrained as a Boolean for a true or false value should include “true” or “false” as part of the filter. The string constant in the expression (“true” or “false”) is case insensitive.
A $null token
%fieldName% = $null
Regular expressions that contain back references
fieldName = /^(a|b)\1$/
Regular expressions that use quantifiers other than +, ?, and *
/a{1}/ /a{1,5}/
Regular expressions that use extended metacharacters
fieldName = /\w/