This site contains the documentation that is relevant to older WSO2 product versions and offerings.
For the latest WSO2 documentation, visit https://wso2.com/documentation/.

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

The Rule Mediator is used to integrate the WSO2 Rules component to the WSO2 ESB in order to define dynamic integration decisions in terms of rules.



Syntax

<rule>

    <ruleset>
        <source [ key="xs:string" ]>
            [ in-Lined ]
        </source>
        <creation>
            <property name="xs:string" value="xs:string"/>*
        </creation>
    </ruleset>

    <session type="[stateless|stateful]"/>*

    <facts>
        <fact name="xs:string" type="xs:string" expression="xs:string" value="xs:string"/>+
    </facts>

    <results>
        <result name="xs:string" type="xs:string" expression="xs:string" value="xs:string"/>*
    </results>

    [ <childMediators>
        <mediator/>*
      </childMediators> ]

  </rule>

The Main Elements of the Rule Token

<ruleset>

The <source> is the only mandatory element of the <ruleset>. However, the properties required for the creation of the Ruleset can also be specified within <ruleset>. The key attribute is a registry "key", which is to lookup the Rule script from the registry if the rule script is in the registry. The Ruleset can be given as a child node of <source> element. If the Ruleset is non-XML, you may need to wrap it with a CDATA section inside a XML tag. For example,

<X><![CDATA[ native code]]></X>

Note

The key or inline Rule script must be defined. Otherwise, the Rule Mediator configuration will be invalid.

<session>

The Rule Session specifies the stateful or stateless behavior of the Rule engine. If this has value stateful, then the Rule engine will execute Rules in a stateful manner. For any other value, "stateless" is assumed. There are optional properties, which are used when creating the Rule Session.

Tip

Rule Session is optional and the default one is "Stateful."

<facts> / <results>

  • Facts - Specifies the facts being used in Ruleset. It also defines how to formulate facts from the message, etc.
  • Results - Defines how to handle results from the Ruleset execution. Result-adapters usually enrich the message with results. For example, if you are using POJO adapter (i.e. a Java class as the type; the class name of a result), then we transform POJO into an XML and attached to the SOAP message.

The Main Attributes of the <facts> and <results> elements:

  • "name" - The unique name.
  • "value" - Represents any static value.
  • "expression" - XPath expression for extracting data from the message being passed between ESB components.

    Tip

    The default value is the first child of the SOAP Body.

  • type- Defines the type of the input data. There are a few built-in types:
    • Message
    • Context
    • Map
    • POJO
    • Mediator

      Note

      Using the rule-component.conf, you can register new types along with adapters, which are responsible for formulating specified types from the data. If there is no registered adapter for a given type, then, we assume the given type as a valid Java class name and uses POJO adapter to formulate the POJO instance whose class is the given type.


UI Configuration

The parameters available to configure the Rule mediator are as follows:

Parameter NameDescription
  
  
  
  
  
  

 

The Main Elements of the Rule Mediator

Rule Set

A rule script can be given as a registry key or an in-line script. To give rule script as in-lined, you can use the editor.

Rule Set options:

  • URI
  • In-lined - Allows to create or edit the Script of the Rule using the "Rule Script Editor."
  • Registry Lookup - Allows to choose the key from Configuration Registry or Governance Registry.

Tip

Source Format - XML or native.
If the language is XML, then this attribute should be XML. For any other value, the Rule Mediator assumes that the rule script is in native format. If the rule script is in native format, it should be given by wrapping as a CDATA section inside a XML tag. For example, <X><![CDATA[ native code]]></X>.

It is possible to have properties for rules set creation, registration, de-registration. There are add property options for each.

For example, when using the Drool native language (DRL) for rule script, it is necessary to provide a DSL file.This can be done using the attribute named source and value DRL.

<ruleSet>
   <creation>
      <property name="source" value="drl"/>
   </creation>
</ruleSet>

Note

The key or in-lined rule script must be defined. Otherwise the Rule Mediator will be invalid.

Rule Set Creation Properties

Those are used when creating a Rule Set.

Options for Rule Set Creation Properties:

  • Name - The name of the Rule Set property.
  • Value - The type of the property value.
  • Action - Deletes the property.

Rule Session

Session Type - Indicates the stateful or stateless behavior of the Rule engine:

  • Stateful - Rule engine will execute Rules in a stateful manner.
  • Stateless

Rule Session Configuration Properties

Used when creating Rule Session.

Options for Rule Session Configuration Properties:

  • Name - The name of the Rule Set property.
  • Value - The type of the property value.
  • Action - Deletes the property.

Facts and Results

  • Type - This is the only mandatory field. Fact selector can be used to specify any registered fact types.
  • Fact/Result Selector- Allows to select the type of Fact/Result.
    • New Type
    • Build-in Type:
      • message
      • dom
      • content
      • omelement
      • mediator
  • Name -The name of the fact.
  • Fact Source Type - Can be literal, a registry key or an expression.
  • Value - The registry or Message context key. This is used for getting data from either registry or message context.
  • Registry Browser - If the key is a registry resource, the browser selects the resource.
  • NS Editor - You can click this link to add namespaces if you are providing an expression. You will be provided another panel named "Namespace Editor," where you can provide any number of namespace prefixes and URL.
  • Action - Deletes the input/output.

Note

You can configure the Mediator using XML. Click on "switch to source view" in the "Mediator" window.


Example

<rule>
        <ruleset>
        <source key="rule/sample.xml"/>
        </ruleset>
        <facts>
            <fact name="symbol" type="java.lang.String"
                  expression="//m0:getQuote/m0:request/m0:symbol/child::text()"
                  xmlns:m0="http://services.samples"/>
        </facts>
        <childMediators>
            <send>
                <endpoint>
                    <address uri="http://localhost:9000/services/SimpleStockQuoteService"/>
                </endpoint>
            </send>
                <drop/>
        </childMediators>

</rule>

In the above configuration, the Rule script is picked from the registry with key rule/sample.xml. There is one fact and it is a string variable. Its value is calculated from the current SOAP message using an expression. The Rule engine uses these facts to decide what rules should fire.

  • No labels