IBM Integration Bus, Version 10.0.0.17 Operating Systems: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS


Example rules that are created from a message instance and schema

Business rules and their parameters depend on a schema.

The following example demonstrates how the incoming message and XML schema relate to the parameters that are passed into business rules. The example also shows the business logic that the rules apply to the message data.

Consider the following example of a schema.
<?xml version="1.0" encoding="UTF-8"?><xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <xsd:element name="purchase" type="purchseType"/>
  <xsd:complexType name="purchaseType">
    <xsd:sequence>
      <xsd:element name="items" type="orderType"/>
      <xsd:element name="company" type="xsd:string"/>
    </xsd:sequence>
  </xsd:complexType>

  <xsd:complexType name="orderType">
    <xsd:sequence>
      <xsd:element maxOccurs="unbounded" minOccurs="1" name="nextitem" type="sale"/>
    </xsd:sequence>
  </xsd:complexType>

  <xsd:complexType name="sale">
    <xsd:sequence>
      <xsd:element name="title" type="xsd:string"/>
      <xsd:element name="price" type="xsd:decimal"/>
      <xsd:element name="quantity" type="xsd:integer"/>
    </xsd:sequence>
  </xsd:complexType>
</xsd:schema>
The following input message uses the preceding schema.
<purchase xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="simple.xsd">
  <items>
    <nextitem>
      <title>one</title>
      <price>1.0</price)
      <quantity>1</quantity>
    </nextitem>
    <nextitem>
      <title>two</title>
      <price>2.0</price>
      <quantity>2</quantity>
    </nextitem>
  </items>
  <company>the company</company>
</purchase>
The <items> element in the message instance contains a repeating element, <nextitem>. A rule that is written to change an element in that repeating structure (for example, the value in the field "price") must use a business rules construct that can access a repeating element. You can use the "for each" construct with the "if...then" condition to access the repeating element, as shown in the following example:
if <condition met> then
for each <object> [called <variable>,] in <list>:
  - <action>;*
In this example, "object" is the current object (in this case, the repeating element), and "list" is the parent of the repeating element.
If this example contains one input parameter (with the default verbalization of "parameter") that is the root element type "purchaseType", a rule can be written that changes the price in each repeating element:
if the company of parameter contains "the" then
for each sale in the items of parameter : 
  - set the price of this sale to 99; 
(For a detailed reference guide to the Business Action Language (BAL), which is used to author business rules, see IBM® Operational Decision Manager product documentation online.)
In this example, one input parameter is provided that has the message root type. Two parts of the message are used in this rule: the name of the company and the price of each item that is ordered. Therefore, instead of passing in one parameter, which is the whole message, you can pass in two parameters: The rule can be constructed as shown in the following example.
if 'the name of the company' contains "the" then
for each sale in the nextitems of parameter : 
  - set the price of this sale to 55;  
This example also demonstrates how to pass in a simple type as a parameter, rather than a complex type. In the Data location field of the parameters table for the DecisionService node, you would add the following XPath expressions for each parameter:

The choice of whether to pass a single parameter or multiple parameters depends to some extent on the size of the message. Business rules are based on a schema, therefore the parameters are formed as XML instance documents, and are then passed to the rules for evaluation. If a parameter is defined as a complex type that can contain large content, this content is serialized and parsed again for the rules evaluation. If the rules evaluate only part of the content, performance and memory usage can be improved if the parameters target the specific nested structures.

Also consider that a change that you make to a nested structure can be overwritten by a change to the parent structure. Therefore, when you add data location XPath expressions, avoid accessing parent and child nested fields in a message tree.

When you create business rules, you are considering the business objects to which to apply your rule. Therefore, if you have a schema that describes a customer order, pass in the order type for the order, rather than the individual components of the order (such as the customer order, and items ordered). However, you must also consider message size. If the message is large, you might try to reduce processing time by passing in types that define a small part of the message rather than the whole message.

XML formatting

For each parameter in a rule, the DecisionService node creates an XML instance document, which is passed to the rules for evaluation. When all rules have been evaluated, the DecisionService node receives XML documents back for each parameter. The DecisionService node then parses the XML for each parameter and populates the output message tree, replacing the existing XML structure that was passed into the rule set. However, parts of the XML structure that are classed as formatting are not preserved. Therefore, if the DecisionService node processes an XML message that sources decision service parameters, formatting and content that are not related to the XML schema might be lost.

Consider the following structure:
Person:
 - FirstName
 - Surname
 - DateofBirth
 - Address
 - AdditionalInfo
When you create a decision service to work with this XML structure, you might pass in one parameter, "Person", then use the fields for this parameter. Alternatively, you could pass in the 5 parameters for "FirstName", "Surname", "DateofBirth", "Address", and "AdditionalInfo".
You might expect XML messages in the following form:
<Person>
 <!-- The following is the name of the person -->
 <FirstName>John</FirsName>
 <!-- The following is the surname of the person -->
 <Surname>Smith</Surname>
 <!-- The following is the date of birth in the form dd/mm/yyyy -->
 <DateofBirth>01/01/1970</DateofBirth>
 <!-- The following is the address of the person -->
 <Address>123 High Street, London</Address>
 <AdditionalInfo></AdditionalInfo>
</Person> 
In this case, if you pass in "Person" as a single parameter, you lose the comments and extra white space between the tags. However, to preserve the comments, pass in the 5 child parameters.

bc23820_.htm | Last updated 2019-07-13 08:13:27