Sanity Check 0.7.0 Final - Visual Editor BPM Im...| JBoss.org Content Archive (Read Only)

30. Re: Sanity Check 0.7.0 Final - Visual Editor BPM Implementation

dward Mar 28, 2013 12:47 PM (in response to rcernich)

FYI, SwitchYard falls back to "Interface" if it can't find "interfaceImplementationRef". Same thing with regard to falling back to "Operation" if it can't find "operationImplementationRef". Aside, I just coded what I was told to... :/

31. Re: Sanity Check 0.7.0 Final - Visual Editor BPM Implementation

jeffdelong Mar 28, 2013 1:33 PM (in response to dward)

No problem, that's why we test stuff.

32. Re: Sanity Check 0.7.0 Final - Visual Editor BPM Implementation

jeffdelong Mar 28, 2013 4:07 PM (in response to jeffdelong)

Good news: I changed the implementation ref on the interface definition to match the SwitchYard service name (PolicyQuoteEntityService) and it worked. However the BPMNS Editor is set up to enter the fully qualified Java class name if you use the import tool. And uses that to infer the operation.

Once having done this, I am now facing issues with the JPA Binding in SwitchYard. Even though my configuration is the same as the quickstart:

<sca:reference name="PolicyQuoteEntityService" multiplicity="0..1" promote="PolicyQuoteProcess/PolicyQuoteEntityService">

<sca:interface.java interface="org.acme.insurance.PolicyQuoteEntityService.PolicyQuoteEntityService"/>

<jpa:binding.jpa>

<jpa:contextMapper/>

<jpa:entityClassName>org.acme.insurance.PolicyQuote</jpa:entityClassName>

<jpa:persistenceUnit>org.jbpm.persistence.jpa</jpa:persistenceUnit>

<jpa:transactionManager>#jtaTransactionManager</jpa:transactionManager>

</jpa:binding.jpa>

</sca:reference>

I get the following exception:

org.switchyard.HandlerException: org.apache.camel.ResolveEndpointFailedException: Failed to resolve endpoint: jpa://org.acme.insurance.PolicyQuote?persistenceUnit=org.jbpm.persistence.jpa&transactionManager=%23jtaTransactionManager due to: Could not find a suitable setter for property: transactionManager as there isn't a setter method with same type: java.lang.String nor type conversion possible: No type converter available to convert from type: java.lang.String to the required type: org.springframework.transaction.PlatformTransactionManager with value #jtaTransactionManager

--- Caused by org.apache.camel.ResolveEndpointFailedException: Failed to resolve endpoint: jpa://org.acme.insurance.PolicyQuote?persistenceUnit=org.jbpm.persistence.jpa&transactionManager=%23jtaTransactionManager due to: Could not find a suitable setter for property: transactionManager as there isn't a setter method with same type: java.lang.String nor type conversion possible: No type converter available to convert from type: java.lang.String to the required type: org.springframework.transaction.PlatformTransactionManager with value #jtaTransactionManager

--- Caused by java.lang.IllegalArgumentException: Could not find a suitable setter for property: transactionManager as there isn't a setter method with same type: java.lang.String nor type conversion possible: No type converter available to convert from type: java.lang.String to the required type: org.springframework.transaction.PlatformTransactionManager with value #jtaTransactionManager

------ End Message Trace -------

13:50:40,899 ERROR [org.switchyard.component.bpm.service.SwitchYardServiceWorkItemHandler] (http-localhost-127.0.0.1-8080-1) Fault encountered: org.apache.camel.ResolveEndpointFailedException: Failed to resolve endpoint: jpa://org.acme.insurance.PolicyQuote?persistenceUnit=org.jbpm.persistence.jpa&transactionManager=%23jtaTransactionManager due to: Could not find a suitable setter for property: transactionManager as there isn't a setter method with same type: java.lang.String nor type conversion possible: No type converter available to convert from type: java.lang.String to the required type: org.springframework.transaction.PlatformTransactionManager with value #jtaTransactionManager: org.switchyard.HandlerException: org.apache.camel.ResolveEndpointFailedException: Failed to resolve endpoint: jpa://org.acme.insurance.PolicyQuote?persistenceUnit=org.jbpm.persistence.jpa&transactionManager=%23jtaTransactionManager due to: Could not find a suitable setter for property: transactionManager as there isn't a setter method with same type: java.lang.String nor type conversion possible: No type converter available to convert from type: java.lang.String to the required type: org.springframework.transaction.PlatformTransactionManager with value #jtaTransactionManager

at org.switchyard.bus.camel.audit.FaultProcessor.detectHandlerException(FaultProcessor.java:137) [switchyard-bus-camel-0.8.0.Final.jar:0.8.0.Final]

at org.switchyard.bus.camel.audit.FaultProcessor.handle(FaultProcessor.java:8

33. Re: Sanity Check 0.7.0 Final - Visual Editor BPM Implementation

jeffdelong Apr 1, 2013 11:22 AM (in response to jeffdelong)

I started a new discussion on the JPA TransactionManager issue.

So I think this change is implemented correctly except for the interface class vs SwitchYard service name which needs to be resolved (see above).

34. Re: Sanity Check 0.7.0 Final - Visual Editor BPM Implementation

dward Apr 1, 2013 12:18 PM (in response to jeffdelong)

Thanks Jeff!

35. Re: Sanity Check 0.7.0 Final - Visual Editor BPM Implementation

rcernich Apr 2, 2013 12:24 PM (in response to dward)

Hey guys,

It sounds like we are almost there. Regarding how we look up the service and operation, there are two ways we can go:

Use the implementation ref's (which is what we do today)
Use the names.

To me, it seems like using the implementation ref fields is the "right" way to go, as we are specifying what the implementation is. That said, I don't believe it is feasible to customize the bpmn editor to allow the user to import a SwitchYard service or specify a SwitchYard service as the implementation.

By default, the name fields line up pretty well with the local part of the service names, the default of which, when importing an interface, is the simple name for the type, which fits in well with the defaults used by the SwitchYard tooling (default service name is simple type name).

If we stick with implementation ref, the user must override the default value after importing the service. If the service name does not match the simple name of the type, the user must still edit something. Furthermore, I'm guessing the user couldn't specify a qname for the name of the interface (even if you wanted to). On the other hand, we do have the "SwitchYard Dynamic Service Task" which is fully customizable.

So, do we switch things up and use the names, or do we leave them the way they are and document that users must change the implementation ref for the interface? My vote is to switch and use the name fields. What do you all think?

Best,

Rob

36. Re: Sanity Check 0.7.0 Final - Visual Editor BPM Implementation

rcernich Apr 2, 2013 12:29 PM (in response to jeffdelong)

Hey Jeff,

Jeff DeLong wrote:

Now your instructions make more sense, although I am uncertain why I should use the SwitchYard Service vs the Service Task and how this would impact portability? The SwitchYard Service creates:

<serviceTask id="ServiceTask_2" tns:icon="org.switchyard.tools.ui.editor.SwitchYard.16" name="PolicyQuoteEntityService" implementation="##SwitchYard" operationRef="Operation_2">

I don't understand the icon attribute.

I was expecting to use the Service Task and have to select ##SwitchYard from a list of choices (the other being ##WebService, which appears is not yet supported in BPMN2 Editor).

The extra tool creates a ServiceTask preconfigured for use with SwitchYard. The SwitchYard extension to the bpmn editor provides additional property pages for configuring the service for use with SwitchYard. To be honest, it never crossed my mind to try to reuse the existing ServiceTask. I can look into doing so when I get more time.

(The icon attribute is supposed to update the icon on the diagram element, but, as you've probably noticed, it doesn't work.)

Best,

Rob

37. Re: Sanity Check 0.7.0 Final - Visual Editor BPM Implementation

jeffdelong Apr 2, 2013 1:06 PM (in response to rcernich)

If this were a WebService, the implementationRef would most likely specify the WSDL portType.

So why doesn't specifying the Java interface work, since WSDL portType and Java interface are equivalent in SwitchYard?

My service is defined with

<sca:reference name="PolicyQuoteEntityService" multiplicity="0..1" promote="PolicyQuoteProcess/PolicyQuoteEntityService">

<sca:interface.java interface="org.acme.insurance.PolicyQuoteEntityService.PolicyQuoteEntityService"/>

Can't the name of the service be inferred from the interface?

38. Re: Sanity Check 0.7.0 Final - Visual Editor BPM Implementation

rcernich Apr 2, 2013 1:26 PM (in response to jeffdelong)

Jeff DeLong wrote:

If this were a WebService, the implementationRef would most likely specify the WSDL portType.

So why doesn't specifying the Java interface work, since WSDL portType and Java interface are equivalent in SwitchYard?

Because it's a SwitchYard service, not a Java interface or WSDL portType. For jBPM integration, we updated the bpmn editor to allow the user to import Java types as interfaces. This is purely a convenience for the user. You could manually define an interface in bpmn, theoretically without any implementation, and SwitchYard should be able to invoke the service (assuming the ServiceTask is ##SwitchYard and the name matches a declared service in SwitchYard). In other words, while something like org.example.SomeService may be used to define the interface for a SwitchYard service, it is not a SwitchYard service.

I think ideally it would be nice if you could simply drag a SwitchYard service from the navigator into your process and have all the pieces generated for you (interface, interfaceImplementationRef, ServiceTask). That's probably a little ways off at this point though.

Best,

Rob

39. Re: Sanity Check 0.7.0 Final - Visual Editor BPM Implementation

jeffdelong Apr 2, 2013 1:33 PM (in response to rcernich)

Could the SwitchYard Service name be inferred from the interface? Or can multiple SY services implement the same interface?

40. Re: Sanity Check 0.7.0 Final - Visual Editor BPM Implementation

rcernich Apr 2, 2013 1:56 PM (in response to jeffdelong)

Jeff DeLong wrote:

Could the SwitchYard Service name be inferred from the interface? Or can multiple SY services implement the same interface?

Yes and yes. The service name defaults to the interface name (simple name), but the user can change the name to whatever they prefer. Multiple services can implement the same interface.

41. Re: Sanity Check 0.7.0 Final - Visual Editor BPM Implementation

jeffdelong Apr 2, 2013 2:06 PM (in response to rcernich)

So here the interface that is working

However I had to manually change

implementationRef="PolicyQuoteEntityService"

from

implementationRef="org.acme.insurance.PolicyQuoteEntityService.PolicyQuoteEntityService"

This is one option mentioned above.

Another option is for SY jBPM component to use the name attribute

name="PolicyQuoteEntityService"

Perhaps a third option is to use

So here is the interface that is working

However I had to manually change

implementationRef="PolicyQuoteEntityService"

from

implementationRef="org.acme.insurance.PolicyQuoteEntityService.PolicyQuoteEntityService"

This is one option mentioned above.

Another option is for SY jBPM component to use the name attribute

name="PolicyQuoteEntityService"

A third option might be to use

org.acme.insurance.PolicyQuoteEntityService.PolicyQuoteEntityService as the name of the interface, and have the editor use the name to infer the operations.

So the interface would look like:

The displaying of operations from the interface is an editor user friendly feature, not sure it matters which attribute is used? The implementationRef would be used by the SY BPM Component, and the BPMN2 spec does not precisely state how this attribute is specified, only that "This attribute allows to reference a concrete artifact in the underlying implementation technology representing that interface, such as a WSDL porttype. "

42. Re: Sanity Check 0.7.0 Final - Visual Editor BPM Implementation

rcernich Apr 2, 2013 2:27 PM (in response to jeffdelong)

Hey Jeff,

That all sounds good. One of the issues with changing the way import interface works is that jBPM supports using a Java class for a ServiceTask. In that case, you would import the Java type, and jBPM uses the implementation ref to instantiate the class and invoke the operation. Given that, I think the default for importing a Java type is to use the fully qualified type name for the implementation ref. (The bpmn editor is generic.)

I think the ideal would be to allow the user to import a SwitchYard service, which would configure the interface correctly. However, I don't think this is feasible at this time.

Part of the issue is that we've got the bpmn editor, which is generic. The generic editor is customized for use with jBPM. Which is further customized when using jBPM inside of SwitchYard.

Rob

43. Re: Sanity Check 0.7.0 Final - Visual Editor BPM Implementation

jeffdelong Apr 2, 2013 2:37 PM (in response to rcernich)

So we don't want to change the Import tool, and we don't want to make the user overwrite the implementationRef.

So the options then are

1) for the SY BPM component to use the name field, and document that this must be the name of the SY service.

2) for the SY BPM component to use the interface class name in the implementationRef to infer the SY service name (with the caveat this will be indeterminant if there are two services that implement that same interface).

44. Re: Sanity Check 0.7.0 Final - Visual Editor BPM Implementation

rcernich Apr 2, 2013 3:15 PM (in response to jeffdelong)

I don't think the second option buys much. I think it's really which should be used: name or implementation ref. Out of the box, it seems like name is the more usable of the two, given where we are with the tools, but I also see an argument for implementation ref. That said, either set of options, my vote is still option 1.