I can address some of this:

1. Yeah, I waffled on including the sessionId in the config. No matter what, though, is that precedence is given if sessionId is specified as a context property (most likely due to coming in as a soap header), just like processInstanceId is.  Both processInstanceId and sessionId get returned as response headers when interacting with bpm processes. If you want to re-correlate back to it, you have to send those back in with subsequent requests.  (Aside, in 0.8 we will support an application-specific business key / correlation id, as jbpm has added support for this, per my request.)
2. MVEL expressions can be anything. Variables available within the expression itself is exchange, context, message.  For <input> <mapping>s, the result of the expression will be available as a process instance variable using the name of the variable you specify in the <mapping> variable attribute.
3. For SIGNAL_EVENT, specify the id attribute of the <action> tag.  This is the signal id for the process.
4. Properties are used for configuring the knowledge session, and are free form because I didn't want to support every single drools or jbpm property out there.  So, this is how you would change from the default clock type, event processing type, etc.  You're right, this is a bit advanced.  So I figured if you're doing that kind of thing, you will know the drools options/properties you want to set.
5. In 0.6 and prior, I tried abstracting the rules and bpm components, which led me to inventing the whole TaskHandler interface mess.  Since I don't forsee us ever changing to implementations other than drools and jbpm, the abstractions are gone.  So, in 0.7 and forward, you use the REAL jbpm WorkItemHandler classes instead.  So, org.jbpm.process.workitem.wsht.MinaHTWorkItemHandler, for example.
6. Yes, BAM is configured using a <listener class=""/>  For example, org.jbpm.process.audit.JPAWorkingMemoryDbLogger is a jbpm event listener.
7. I made sure that everything that can be configured in each of the rules and bpm components made sense to be there.  In the end, only WorkItemHandlers and action types stood out as being component-specific.  Per your specific example of Channels on a BPM component, this is actually possible.  The use case is where rules gets executed as part of the process, and the rules inside the process need (a) registered channel(s).

Hope this helps,

David

If you have SwitchYard Service nodes in your process, you need the SwitchYardServiceWorkItemHandler.  If you have Human Task nodes in your process, you need one of jBPM's Human Task WorkItemHandlers.

FYI, there's also a SwitchYardServiceChannel, which does the same thing as the SwitchYardServiceWorkItemHandler.  Both will invoke a SwitchYard service. The only difference, of course, is that one's a WorkItemHandler, and the other is a Channel.

Sorry to resurrect this, but....as I look into how we might better integrate with the BPMN2 editor, I think I've come to a similar conclusion that Gary came to in this thread last summer:  https://community.jboss.org/thread/200453?tstart=0

To summarize, if we're using ServiceTask, we should:

• Resolve the service using the name of the service associated with the interface (interface ref)
• Resolve the operation using the operation name (operation ref)
• Resolve I/O data types using the same convention as the default service implementation (i.e. Parameter, Result, Fault, as used by the default jBPM ServiceTaskHandler).
• Add our special sauce, as necessary (e.g. fault behavior, etc.)

In my opinion, this would provide an interaction model similar to generic service tasks.

Here's how I envision the basic workflow:

1. User adds an interface to the process (name = SwitchYard service name)
2. User adds SwitchYard service task to process (implementation = ##SwitchYard, operation = operation)
3. User specifies "Parameter" DataInput
4. User specifies "Result" DataOutput
5. User specifies "Fault" DataOutput

The above assumes there is a component reference declared for every interface used by ServiceTasks.  This aligns nicely with other implementation types (e.g. CDI @Reference, BPEL partner link, etc.).

At the risk of being permanently disfigured at the upcoming F2F, I ask, what do you think?

1-5 will just need to align with the "SwitchYard Service Task Properties" documented in the panel at the bottom of this page: BPM Services.

Hey David,

I think the issue is that dilutes any benefit you might get from using ServiceTask.  The way we're doing things, ServiceTask is nothing more than a custom task that extends ServiceTask instead of Task.  It makes no use of the built-in support for specifying service operations that is provided by ServiceTask (the main being interface and operation).  It also changes the idea of ServiceTask when it applies to a SwitchYard service.  From your doc, here's how I see a better alignment:

• ServiceName - interface name (workItem.getParameter("interfaceImplementationRef"))
• ServiceOperationName - operation name (workItem.getParameter("operationImplementationRef"))
• ContentInputName - use "Parameter" same as default ServiceTask (workItem.getParameter("Parameter"))
• ContentOutputName - use "Result" same as default ServiceTask (output.put("Result", result))

Modifying our integration will allow users to use the existing ServiceTask tooling.  The benefit is that this is the same workflow they would use for defining any other ServiceTask.

We would continue to provide extra properties for fault handling (but I suspect there is probably a more appropriate default for passing the fault message back to the process).

Best,

Rob

One thing that using ServiceTask natively does not address is dynamic invocation of services based on routing information from other parts of the process.  To support this, I recommend continuing to use the custom Task, but change the name to something like "SwitchYard Dynamic Service Task."  So...

• SwitchYard Service Task - based on ServiceTask and provides semantics similar to the generic ServiceTask.
• SwitchYard Dynamic Service Task - based on Task and allows users to fully customize/configure a service invocation.

I've created SWITCHYARD-1332 to make this change in the runtime.  SWITCHYARD-827 depends on it.

Pull request submitted for SWITCHYARD-1332.

Attached are a couple screen shots showing the custom property pages for a SwitchYard ServiceTask.  The first is how it is displayed by default (result and fault sections collapsed); the second shows all the controls.  I still have a bit of work left to do and it does require some updates to the core bpmn editor, but we're getting there.

Let me know what you think.

Rob

Here's a screen shot of the custom tab for the dynamic service task (based on Task[@taskName=SwitchYard Service]).  By default, ContentInputName is initialized to ContentInput and ContentOutputName is initialized to ContentOutput.  It is the user's responsibility to create a DataInput and DataOutput objects for these two fields.  The user will also have to initialize ServiceName and ServiceOperationName fields appropriately.  The user can do this by either mapping to a process variable or specifying an expression.

The property names start with an uppercase "C", the default property values should start with a lowercase "c".

Sorry, I know this is yucky. For 1.0, I'd like to rename them to ParameterName=(default is "Parameter") and ResultName=(default is "Result") to be more like the standard serviceTask.