Bug 993420 - Transformation problem when calling Bean service from BPEL process
Transformation problem when calling Bean service from BPEL process
Status: CLOSED WORKSFORME
Product: JBoss Fuse Service Works 6
Classification: JBoss
Component: BPEL Integration (Show other bugs)
6.0.0 GA
Unspecified Unspecified
low Severity medium
: ---
: 6.1.0
Assigned To: tcunning
Jiri Sedlacek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-05 17:40 EDT by Jiri Sedlacek
Modified: 2015-08-14 15:36 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
The BPEL integration tooling allows you to configure a transformer between WSDL and the Java interface as a JAXB transformer. This results in an error. This happens because JAXB transformations are only valid for data objects that contain JAXB annotations or include an ObjectFactory in a configured context path. A string does not qualify, so using JAXB in this context is invalid. More constraints need to be added to the tooling to ensure that only valid data is input.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-07-13 15:20:19 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
reproducer (3.71 KB, application/x-compressed-tar)
2013-08-05 17:40 EDT, Jiri Sedlacek
no flags Details
reproducer_v2 (6.79 KB, application/x-compressed-tar)
2013-08-10 07:28 EDT, Jiri Sedlacek
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker ENTESB-3610 Major Closed Document transformers / MessageComposers use and what happens with unexpected input 2015-08-14 15:36:12 EDT

  None (edit)
Description Jiri Sedlacek 2013-08-05 17:40:52 EDT
Created attachment 783037 [details]
reproducer

I have a simple composite: 
- BPEL Process with WSDL interface
- Bean service with Java interface (matching WSDL)
- SOAP binding, promoted service is BPEL process

When I try to invoke Bean service from BPEL process, transformation between WSDL message and Java object has to be done, but error is thrown. 

Problem is, that BPEL process sends message according to WSDL file and corresponding XSD, but JAXB transformer between WSDL and Java bean expects XML document with different tags (according to JAXB annotations of that Java file).


Second problem may be, that even if the bean service is called with error, process doesn't know it and waits for response until specified timeout doesn't run out.

Example reproducer is attached.
Comment 1 Keith Babo 2013-08-09 16:43:25 EDT
JAXB transformation is for data objects that contain JAXB annotations or include an ObjectFactory in a configured context path.  String does not qualify, so using JAXB in this context is invalid.

As to the second issue, the transformation error is returned to the BPEL engine and it's up to Riftsaw to decide what to do with it at that point.  I don't see a build version being used here, but I noticed Alpha1 as the SY version in the pom.xml.  I can't recall whether error reporting on in-only was included for Alpha1 or not, but it's definitely in 1.0.0.Final.  I tested your app locally and the error definitely gets back to the engine.
Comment 2 Jiri Sedlacek 2013-08-10 07:28:01 EDT
Created attachment 785164 [details]
reproducer_v2
Comment 3 Jiri Sedlacek 2013-08-10 07:42:36 EDT
I've added new version of reproducer, now the method takes JAXB annotated object as a parameter. But it the outcome is still the same, problem with unmarshalling, because message from BPEL process is formatted according to WSDL with tag representing the method. 

Anyway, if tooling lets me to configure required transformer between WSDL and Java interface as a JAXB transformer, I expect it will work. 

It's possible to use JAXB transformer to transform to plain String parameter and it works in other cases (if BPEL process is not involved).


It should be documented very properly where to use transformator and which kind and where users should use MessageComposer or any other principal Switchyard is using, now it's not clear and users will be confused.
Comment 4 Keith Babo 2013-08-11 22:15:00 EDT
In terms of the actual failure here, this is no different than a Smooks, Java or XSLT transformation which gets unexpected input.

I agree with your point on documentation.  I seem to remember someone coming up with a similar issue in the community recently.  We can definitely add some text which specifically calls out the expectations for JAXB transformations.

It would be nice if the tooling could help constrain this more, but it turns out to be a bit involved.  I need to dig up the community thread on this and attach it to the BZ for context.  From my POV, I would consider it an interesting usability enhancement, but I don't consider it a bug in the current tooling


In summary, I don't think this is a Beta blocker.  I do think we can do a better job in the docs of explaining what's expected for JAXB transformers.
Comment 5 Jiri Sedlacek 2013-08-14 09:37:47 EDT
It may help if there will be a possibility to set 'unwrap' parameter in BPEL Process as it can be set on SOAP binding. Then it will receive just XML representation of the object, not the method name tag around it.
Comment 6 Keith Babo 2015-01-28 08:39:59 EST
I don't think any code changes are necessary for this in the 6.2 release provided that the documentation includes the details in "Doc Text" on scenarios where JAXB transformations are problematic.  In a future release, it's worth looking at additional validation in the tooling around types used with JAXB transformers.
Comment 7 tcunning 2015-07-13 15:20:19 EDT
We're moving to tracking Fuse 6.2.1 issues in JIRA, so I'm closing this issue and have logged https://issues.jboss.org/browse/ENTESB-3610 to more closely track the changes to documentation.
Comment 8 JBoss JIRA Server 2015-08-14 15:36:12 EDT
Tom Cunningham <tcunning@redhat.com> updated the status of jira ENTESB-3610 to Closed

Note You need to log in before you can comment on or make changes to this bug.