Note:  The information in this article is already old.  Most notably, <actions><action> will be <operations><operation> when SWITCHYARD-1554 gets processed, and a new <faults><fault> mapping construct has been introduced as well.  For more information , please see the extensive Comment in that jira.

SWITCHYARD-1382 is all about bringing simplicity and consistency to the Rules and BPM component configurations.  It also is about finally kicking some old skeletons out of the closet, and fixing some bugs along the way.  Any changes needed to be done before 1.0 goes out the door, as 1.0 implies a solid config model.  So now was the time to get them done, especially after having several releases to hear what has (and has not) worked for people.  So, without further adieu, the changes:

Sanity for variable mapping:

This is the old way:

<action operation="submitOrder" type="START_PROCESS">

    <inputs>

        <mapping expression="context['org.switchyard.messageId']" variable="messageId" scope="MESSAGE" expressionType="MVEL"/>

        <mapping expression="message.content" variable="contentInput"/>

    </inputs>

    <outputs>

        <mapping expression="myProcessVar" variable="contentOutput"/>

    </outputs>

</action>

This is the new way:

<action operation="submitOrder" type="START_PROCESS">

   <inputs>

       <input from="context['org.switchyard.messageId']" to="messageId"/>

       <input from="message.content" to="myProcessVar"/>

   </inputs>

   <outputs>

       <output from="myProcessVar" to="message.content"/>

   </outputs>

</action>

A few things above:

1. <globals> now have <global> children, <inputs> now have <input> children, and <outputs> now have <output> children.
2. The scope and expressionType attributes are GONE.
3. The expression and variable attributes have been replaced with from and to attributes, which are much easier to understand.
4. The to attbribute is not required when feeding data into the Rules component, but is necessary for process variable names feeding into the BPM component.
5. For the BPM component, the output's from attribute can be a process var, and the output to can be an expression, for example "message.content".  If you have multiple output from's feeding the same output to, then they are combined into a List before being set.
6. Given that you can specify an expression for the output to (like "message.content"), there is no longer a hardcoded dependency on an output variable being called "contentOutput".  This was a huge skeleton-in-the-closet which is now gone.
7. If you don't specify any input from's, the default is that the message.content will be set into the process with a to name of "Parameter".
8. If you don't specify any output from's, the default is that a process variable of "Result" will be looked for, and used to set the outgoing message.content.

Eventing improvements

1. <action id="signalId" ...> is now <action eventId="eventId" ...>.  This makes it more clear that you are talking about events, both for Complex Event Processing in the Rules component (where the eventId defines the event channel to filter facts to), and for signaling events in the BPM component.
2. The old request header / context properties for {urn:switchyard-component-bpm:bpm:1.0}signalEvent and {urn:switchyard-component-bpm:bpm:1.0}signalId are GONE.  They just confused things, and were too much of a pain for developers to have to worry to set, when they could just specifcy the SIGNAL_EVENT action type and eventId attribute to do the same thing.
3. There was a bug where you couldn't specify an <input> expression when your action was of type SIGNAL_EVENT.  Now, you can specifcy any number of <input> elements with various from expressions, and they can feed your event.

Better alignment with jBPM for input/output/task/parameter naming:

1. The standard "Service Task":
   • By default, the standard "Service Task" will now look first for an "Interface" parameter, before it falls back to the "interfaceImplementationRef".  This is reversed from 0.8, and was decided upon by the team.
   • By default, the standard "Service Task" will now look first for an "Operation" parameter, before it falls back to the "operationImplementationRef".  This is reversed from 0.8, and was decided upon by the team.
2. The dynamic "SwitchYard Service Task":
   
   • The "SwitchYard Service" taskName is now called "SwitchYard Service Task" to be more like the standard "Service Task".
     
   • ServiceOperationName is now OperationName.
     
   • ContentInputName is now ParameterName, and defaults to Parameter, to be more like jBPM.
     
   • ContentOutputName is now ResultName, and defaults to Result, to be more like jBPM.
     
   • FaultSignalId is now FaultEventId, to align with the action element's eventId attribute mentioned above.
     

Various other bug fixes:

1. There was a bug in the Rules component under the FIRE_UNTIL_HALT scenario, where facts that came in through the message content were not getting iterated over and properly/individualyinserted into the stateful knowledge session.  This is now fixed.
   
2. There was a bug in the BPM component where global mappings were not being respected and set into the stateful knowledge session.  This is now fixed.