1 - Example Action Sequence XML

This is a listing of the Example1.xaction Action Sequence Document.

<action-sequence>
   <name>Example1.xaction</name>

   <!-- some header nodes deleted -->

   <inputs>
      <region type="string">
         <default-value>Central</default-value>
         <sources>
            <request>REGION</request>
            <session>aRegion</session>
         </sources>
      </region>

      <from type="string">
         <default-value>joepentaho@pentaho.org</default-value>
      </from>

      <subject type="string">
         <default-value>Pentaho Example1</default-value>
      </subject>

      <message-plain type="string">
         <default-value>
                 This is an email from the Pentaho BI Platform - Example1
         </default-value>
      </message-plain>
   </inputs>

   <outputs/>

   <resources/>

   <actions>
      <action-definition>
         <action-inputs>
            <region type="string"/>
         </action-inputs>

         <action-outputs>
            <rule_result type="string"/>
         </action-outputs>

         <component-name>JavascriptRule</component-name>
         <component-definition>
            <script>
               <![CDATA[
                  if ( "Central".equals( region ) ) {
                     rule_result = "joe@pentaho.org";
                  }
                  else {
                     rule_result = "suzy@pentaho.org";
                  }
              ]]>
            </script>
         </component-definition>
      </action-definition>

      <action-definition>
         <action-inputs>
            <to type="string" mapping="rule_result"/>
            <from type="string"/>
            <subject type="string"/>
            <message-plain type="string"/>
         </action-inputs>
         <component-name>EmailComponent</component-name>
         <component-definition/>
      </action-definition>

   </actions>
</action-sequence>

In this example, the Action Sequence has 4 inputs: region, from, subject and message-plain. For region, the type is defined as a string; it has a default value of Central and may come from one of two sources; request and session. When the RuntimeContext resolves the region input at runtime, it will first look in the request (most likely an http request.) If it doesn't find it in the request, it will look in the session (most likely the http session.) If it is not available in the session, the default value will be used. The order that the sources are specified in the XML document is the order that they will be searched. The default is always used as a last resort.

The other inputs only specify a default value. This is analogous to hard coding the parameters to a constant value. Since the output of this Action Sequence is an email, no output parameters will be set.

There are 2 action-definition nodes for this sequence. The first defines a JavaScript rule and requires a region parameter; it will create a new parameter called rule_result. This new parameter will be made available to other action-definition nodes in the sequence.

Without getting too deep into the workings of the JavaScript rule, the script defined in the component-definition will be executed and will set the value of rule_result to the appropriate email address based on the value of region.

When the first <action-definition> completes, the second will execute. It defines an interaction with the Email component. The email component requires 4 action-inputs: to, from, subject and message-plain. You may have noticed that the action-inputs: from, subject and message-plain are specified in the inputs section of the Action Sequence header. The RuntimeContext will take the values from there and hand them to the Email Component just as it handed region to the JavaScript Component. The source of the to action-input isn't directly defined. It is indirectly defined with the mapping attribute. This attribute is telling the RuntimeContext to use the value from rule_result that was generated by the JavaScript rule and use it as the components to input.