Sanity Check 0.7.0 Final - Visual Editor BPM Implementation

[jeffdelong]

• Would be nice if Process ID could be determined by browsing to a bpmn file
• SessionId is unknown at design time, I have no idea how to configure this. It is also not clear how to specify the ProcessInstance to Session mapping (i.e. 1 to 1 or 1 to Many). Is this not possible yet?
• Resources
  • Add button adds process.bpmn2
    • It would be nice if this widget allowed you to browse to the process definition
    • My assumption is that the filename is relative to the resource directory
• Persistent check box is not “persisting”, i.e. when I reopen file it is unchecked
• Actions
  • It would be nice if the operation could be determined by browsing to the Java interface class and selecting a method.
  • Inputs and Outputs boxes do not automatically re-size to fit in the overall Properties Panel, instead I find I have to use the scrollbar. Is this expected behavior?
  • Really not clear how to specify the MVEL Expression for a Variable. I assume this is the location in the Message. Can the expression be left blank and mean the variable is the name of the object at the root of the message?
  • Not clear how to configure correlation for the SIGNAL_EVENT
• Advanced
  • What are Properties used for?
  • WorkItem Handlers
    • I cannot enter org.switchyard.component.bpm.task.work.SwitchYardServiceTaskHandler in the Class column, the … does not do anything, and I am not sure how to use the name column or the third column
    • Class should default to the above, I only know this classname because I have the old version of the file pulled up in an editor
  • EventListeners
    • Is this where I would configure BAM? Is there an out of the box default provided with SwitchYard, or do I have to implement my own?
• General comment: while it is nice from a consistency standpoint to have the same underlying xml scheme for bpm and rules, the SY Visual Editor should be implementation specific. For example, I am not sure how I would use Channels in a BPM components?

[dward]

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

[jeffdelong]

David,

Thanks it does help and I will test some of these things out. I do request that for some of these meaningful defaults be available, i.e., the WorkItemHandler. Still not clear what should be specified here; the human task workitem handler or the switchyard workitem handler (I realize this is due to the funky way jBPM requires you to add workitem handlers to your session, but hey I am just a dumb user trying to configure my service, why do I care about this stuff?)

[dward]

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.

[jeffdelong]

Then I would like to see those two as listed options (better yet would be to default having both there, I don't think there is necessarily a harm in having them). It's great that there is flexibility in the jBPM API, but as a process / service designer I would rather not have to specify this except in some rare case I want to override the default behavior. Could we just list those two as there by default, and let the user change / remove them if they are smart enough? (I know I have argued to do away with the SY Service Task however when and if this happens we can remove it from the default list).

[rcernich]

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?

[dward]

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.

[rcernich]

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

[rcernich]

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.

[jeffdelong]

+1

[dward]

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

[dward]

Pull request submitted for SWITCHYARD-1332.

[rcernich]

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

[rcernich]

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.

[dward]

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.