Action

From RuleCore Support

An action is one of the rule's parts. An action is executed as the last step in the evaluation process of a rule in response to a detected situation, or optionally when it is determined that a situation is undetectable.

Informally a rule execution follows the following steps:

1. Update the event stream view of the rule instance
2. Evaluate situation detector.
3. Execute action if situation is detected.

The aim with executing an action when a rule triggers is to create a summary of the detected situation and deliver that summary in an outbound event to external systems.

The summary, which is found in the event body of the outbound event, can be created by extracting, aggregating and otherwise summarizing information from any of the events which contributed to the detection of the situation. The XSLT transformation which performs this has also access to the event stream view of the rule instance as it looked when the situation was detected.

The outbound event created by the action is called the reaction event

The time stamp attribute of the reaction event root element is set to the same value as for the terminator event last event in the situation detection. The last event of a situation detection process is called the terminator event as it terminates the situation detection process and causes the rule to trigger. The eventId attribute is automatically assigned a new unique id.

The body of the reaction event is created using XSLT. The XSLT transformation is executed in the context of the rule instance and can thus use information from all the events that contributed to the situation detection. The event stream view of the rule instance is also accessible in the rule's context.

Example 1

The creation process of the reaction event is extremely flexible as you can use to full power of XSLT to create the contents of its body. For example, the contributing events found in the rule's context can be used to:

• Find total time of situation detection. Found by taking the difference between the time stamps of the first and last events in the situation.
• The total number of events which contributed to the detection of the situation.
• Find what actual events caused the situation to be detected. For example if the Any is used there can be a number of possible events which actually caused the situation to be detected.
• Aggregate information from contributing events. For example a sum over order totals.
• Extract information from certain contributing events. For example supplier id information from a number of order failure events.
• Determine in what order the contributing events actually occured when using non sequencing detector nodes such as Any or All.
• Find the order and contributing events of sub situations.

Example 2

Actions are created by the AddActionDef system event.

The XSLT transformation is specified in the EventBody element. The action definition is named using the ActionDef element's name attribute.

The first element under the ActionDef element must be the <Event> element. This element speficies what user event is generated as the reaction event. The event must be previously defined using the AddEventDef system event.

The typeDef should evaluate to a valid user event definition. Its default context is /Rulecore/Items/Types/UserEventDef so a shorter relative ruleCore XPath expression can be used to select an definition.

The body of the outbound reaction event is created by executing the XSLT transformation under the <XsltBuilder> element.

Here an XSLT transformation, or stylesheet if you wish, is specified. The output from that XSLT transformation is copied into the EventBody of the outbound reaction event.

<?xml version="1.0" encoding="UTF-8"?>
<AddActionDef
  xmlns="http://www.rulecore.com/2008/user"
  xmlns:base="http://www.rulecore.com/2008/base"
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.rulecore.com/schema/rulecore-event AddActionDef.xsd"
  base:eventId="0eb61bd8-f9be-4574-abe7-35d13d94268a"
  base:eventTimestamp="2007-06-12T14:00:01.1023Z"
  base:eventClass="system">
 
  <base:EventHeader>
    <base:SecurityInfo>
      <base:Credentials>12345678-1234-1204-1234-123456789abc</base:Credentials>
    </base:SecurityInfo>
  </base:EventHeader>
 
  <base:EventBody> 
    <ActionDef name='ReportFaults'>   
      <Event
        <EventDef><base:XPath>EventDef[@eventType="ExcessiveFaults"]</base:XPath></EventDef>
        <Body>
          <XsltBuilder>
	    <xsl:stylesheet version="1.0" xmlns:sim="http://www.rulecore.com/2008/user">
  	      <xsl:template match="/">
                Errors:
	        <ErrorCount>
		  <xsl:value-of select="count(//sim:PickupSets[@pickupNode='errors']/sim:EventSet/sim:Event)"/>
     		</ErrorCount>
                Warnings:
	 	<WarningCount>
	 	  <xsl:value-of select="count(//sim:PickupSets[@pickupNode='warnings']/sim:EventSet/sim:Event)"/>  
	 	</WarningCount>
	       </xsl:template>		
	     </xsl:stylesheet>		                      
           </XsltBuilder>
	</Body>                
       </Event>             
    </ActionDef>  
  </base:EventBody>
</AddActionDef>

An outbound reaction event created by the XSLT above could for example look like:

<?xml version="1.0" encoding="UTF-8"?>
<ReportFaults
  base:eventId="c3e0254b-5f09-4a21-a5c3-b4538354401f" 
  base:eventTimestamp="2008-02-04T16:48:39.335279"
  xmlns="http://www.rulecore.com/2008/user"
  xmlns:base="http://www.rulecore.com/2008/base">
  <base:EventBody>
     Errors:
     <ErrorCount>
        12
     </ErrorCount>
     Warnings:
     <WarningCount>
        34
     </WarningCount>
 
  </base:EventBody>
</ReportFaults>