If you have worked with BPEL, you know how dependent it is on the foundation. In this case the foundation is XML Schema and the sub-floor is WSDL. Challenges introduced in the XML Schema or WSDL, ripple there way into the BPEL definition. Here are a few novice and advanced issues that have bitten me over the past several years when dealing with BPEL variables:
- Unique namespaces are critical/mandatory in XML Schema/WSDL as they are used to uniquely identify variables and their content.
- Schemas with imports should utilize xsd:ref otherwise bpel:assign activities become a nightmare. BPEL Variables that are generated from XML Schema/WSDL that import other schemas will each have their own namespaces. This makes copying root elements between two variables with different namespaces impossible using the bpel:copy activity. The option is to copy each element individually and see the BPEL script grow exponentially. BPEL 2.0 and its support of inline XSLT will eliminate this issue.
- Some Web Services are RPC Encoded versus Document Literal. bpws:getVariableData syntax is different when extracting values from a RPC Encoded BPEL Variable versus a Document Literal BPEL Variable. BPEL Editors eliminate this issue, however when editing by hand the later will include the variable, part and XPath to the element. RPC only includes the variable and part.
- One of the most simple but common mistakes is to not initialize the BPEL Variables with a literal assignment when using Document Literal services. This will cause run-time failures or other depending on the BPEL engine you are using.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment