8.6. Knowledge Services

Knowledge Services are SwitchYard services that leverage Knowledge, Innovation and Enterprise (KIE) and provide knowledge based content as outputs. The Knowledge Services leverage Drools and jBPM. Drools and jBPM are tightly integrated under KIE, and hence both SwitchYard's BPM component and Rules component share most of their runtime configuration.

When you invoke a SwitchYard operation, it results in the execution of the corresponding Action. Actions are how Knowledge Services know how to map service operation invocations to their appropriate runtime counterparts. For example, when you invoke a method myOperation, it may result in execution of actions like execute some business rules or start a business process. Here is an example of Actions attribute illustrating myOperation method and an action of type ACTION_TYPE:

<actions>
 <action id="myId" operation="myOperation" type="ACTION_TYPE">
  <globals>
   <mapping/>
  </globals>
  <inputs>
   <mapping/>
  </inputs>
  <outputs>
   <mapping/>
  </outputs>
 </action>
</actions>

Here, the placeholder ACTION_TYPE can hold values for the actual ActionTypes specific to the BPM or Rules components.

You can use Mappings to move data in or out of the action for an operation. You can specify as many mappings as you like for an action. The mappings are categorized as global, input, and output mappings:

The mappings support a default expressionType called MVEL. You can use following variables with MVEL: Here are some examples of the expressions using default variables:

expression="message.content" - This is the same as message.getContent().
expression="context[‘foo’]" scope="IN" - This is the same as context.getProperty("foo", Scope.IN).getValue(), in a null-safe manner.

Note

Specify the scope attribute only if you use the context variable inside your expression. If you do not specify a scope, the default Context access is done with Scope.EXCHANGE for global mappings, Scope.IN for input mappings, and Scope.OUT for output mappings.

It is important to specify a global variable for a rule, or a process variable to put into (or get out of) a BPM process. However, if you need to use the result of an expression as facts for rule session insertion, then you need not specify a variable name. Here is an XML example of how you can specify variable name:

 <mapping expression="theExpression" expressionType="MVEL" scope="IN" variable="theVariable"/>

Drools support the use of Channels that are the exit points in your Drools Rule Language (DRL) file. Channels must implement org.kie.runtime.Channel. Here is an example illustrating the use of channels in a method:

package com.example
rule "example rule"
    when
        $f : Foo ( bar > 10 )
    then
        channels["Bar"].send( $f.getBar() );
end

The following example illustrates use of channels in XML:

<channels>
    <channel class="com.example.BarChannel" name="Bar"/>
</channels>

SwitchYard provides an out-of-the-box channel called SwitchYard Service channel, which allows you to invoke (one-way) other SwitchYard services directly and easily from your DRL. Here is an example:

<channel name="HelloWorld" reference="HelloWorld" operation="greet"/>

Here,

You can use Listeners to monitor specific types of events that occur during Knowledge execution. For example, you can use listeners to audit a BPM process and save the audit details into a database while the process progresses. The listener then reports the audit details at a later time. Drools and jBPM provide many out-of-the-box listeners. If you write your own listener, ensure that it implements java.util.EventListener.

To register your listener, you must implement one of the KIE/Drools/jBPM Listener interfaces. For example:

Here is an example of listener implementation:

<listeners><listener class="org.drools.event.DebugProcessEventListener"/>
<listener class="org.kie.event.rule.DebugWorkingMemoryEventListener"/>
<listener class="com.example.MyListener"/>
</listeners>

Loggers are special types of listeners, which you can use to output the events that occur during Knowledge execution. Support for loggers use a dedicated configuration element. You can log events to the console or a file. If events log are directed to a file, you can open those logs with the JBoss Developer Studio or JBoss Developer Studio Integration Stack. Here is an example of a logger implementation:

<loggers>
    <logger interval="2000" log="myLog" type="THREADED_FILE"/>
    <logger type="CONSOLE/>
</loggers>