Migrating your BPEL 1.1 process to BPEL 2.0 – SOA Suite 11gR1PS2 to PS3

In my current project we just started creating BPEL 1.1 processes. Then SOA Suite 11gR1PS3 came along and gave use BPEL 2.0. As we are just in the early stages of development we decided to have a look at the impact of upgrading our already build BPEL 1.1 processes to version 2.0.

As there are no BPEL 2.0 upgrade tools we had basically two options. The first was to complete rebuild all our processes. Not a very good option to redo all the work. The second options was to manually upgrade the BPEL 1.1 definitions to 2.0. Expecting this to be less work we choose the second option.

The first step was to fool Jdeveloper into thinking a BPEL 1.1 process is actually BPEL 2.0.

1.       In the BPEL source file I changed two namespaces:
xmlns =”http://schemas.xmlsoap.org/ws/2003/03/business-process/” into xmlns=”http://docs.oasis-open.org/wsbpel/2.0/process/executable”
xmlns:xxx=”http://docs.oasis-open.org/wsbpel/2.0/process/executable”  into xmlns:bpel=”http://docs.oasis-open.org/wsbpel/2.0/process/executable”

2.       In the composite.xml  I added the version=”2.0” attribute to the bpel component  <component name=”name bpel process” version=”2.0”>

3.       Finally I closed JDeveloper, deleted the SCA-INF directory and restarted JDeveloper. The SCA-INF was created again. When I opened the bpel process in the editor it was recognized as a BPEL 2.0 process:

But it contained quit some errors. This was to be expected as there are differences between BPEL 1.1 and 2.0. I fixed the errors. The fixes I will discuss do not cover all possible errors that will arise when you upgrade to 2.0. I only described the ones I encountered.

1. I clicked on all my partner links to check if all roles are still correct. Of the six processes I migrated only one partner link was corrupted and needed to be reassigned.
2. Then I clicked on all invokes, replies and receives just to make sure the correct operation was still selected and the right variables still used. No problems here.
3. The assignments (assign activity) needed some major fixing.In BPEL 1.1 if you look at the assign activity under the hood you will see this:

   </pre>
   </li>
   </ol>
   <pre><assign name="Assign1">
   <copy>
   <from variable=”inputVariable” part=”payload” query=”ns2:/StartRequest/ns2:procesId”/>
   <to variable=” start_InputVariable” part=”payload” query=”/ns6:/Parameters/ns6:procesId”/>
   </copy>
   <copy>
   <from expression=”concat(bpws:getVariableData(‘inputVariable’,’in’,’ns2:/StartRequest/ns2:procesId’,’ _tmp’))/>
   <to variable=” tempvalue” />
   </copy>
   </assign>
   

   In BPEL 2.0 a xsl variable notation is used. The above assignments now look like:

   <assign>
   <copy>
   <from>$inputVariable.payload/ns2:procesId</from>
   <to>$start_InputVariable.payload/ns6:procesId</to>
   </copy>
   <copy>
   <from>concat($inputVariable.in/ns2:procesId,’ _tmp’)</from>
   <to>$tempvalue</to>
   </copy>
   </assign>
   

   First I opened the assign editor for all assignments and closed it again (press ok). If you look at the source before and after, you will notice the contents of  the variable and part attribute have been moved to the correct location.

   The expression and query attribute have not been moved and are still there. You will have to do this yourself. Add them to the variable but remove the first level of the xpath as it is no longer not needed.

   IF you have assigned a XML fragment to a variable you need to do the following. Enclose the fragment inside a <literal> element.

   Check all the assignments if they are correct.

   1. You need to add an additional attribute to the catch element when you are catching faults. This can be a faultMessageType or faultElement. Open the catch fault editor and select the right one
   2. In BPEL the while condition is an attribute of the while element. In BPEL 2.0 this has become a child element instead. Remember you need to use the xsl variable format here also.
   3. The switch statement has been replaced by an if statement.
      1. Just rename the switch to if
      2. Make the condition attribute of the first case element a child element of the if element and change its a xsl variable format (see earlier).
      3. All other Case  elements become elseif’s. For the condition the same applies as explained before.
      4. otherwise becomes else.
   4. I enclosed the Embedded Java activity element (bpelx:exec) by the extensionActicity element and removed the version attribute.
   5. The checkpoint  element can be replaced by the dehydrate element also enclosed by an extensionActicity element as it is a oracle specific bpel 2.0 extension like the embedded java activity.
   6. The terminate activity just needs to be renamed to exit.
   7. The until attribute of the BPEL 1.1 Pick/onAlarm element has become a child element in 2.0 and needed to be moved.
   8. Not all annotations are supported anymore. I commented some of them out for now as they were mainly for documentation purposes only.
   9. Unfortunately the skipCondition attribute is no longer supported.  I was a little disappointed about this although I can understand why it is removed. This attribute is just not part of the BPEL 2.0 standard. I had to add if/then/else constructions to mimic the same behavior polluting my once so beautiful BPEL processes.

   So we painted our donkey brown but is it a horse now?  Our transformed BPEL 1.1 process validates as a BPEL 2.0 process so it looks like it.  Now you can do some BPEL 2.0 refactorings to make it into a proper horse. Here are some suggestions:

   1. In BPEL 2.0 there is the notation of variable initialization. Where in BPEL 1.1 you need an additional assign activity to initialize a variable in 2.0 you can do this as part of the variable definition. So you can  make the BPEL process cleaner by moving the initialization to the definition part.
   2. The assign activity has some additional functionalities:
      keepSrcElementName (in BPEL 2.0 projects only): Select this option to toggle the keepSrcElementName attribute on the copy rule on and off. This option enables you to replace the element name of the destination (as selected by the to-spec) with the element name of the source.
      Change Rule Type (in BPEL 2.0 projects only): Select this option to change the type of the selected rule to one of the BPEL extension rules: bpelx:copyList, bpelx:insertAfter, bpelx:insertBefore, or bpelx:append.

   For six simple to moderate complex BPEL processes this cost me about a day and a half work. For our project it was not cost effective to automate this. We could have created  an xsl transformation to do parts of the migration. I wonder if you could fully automate this especially the refactoring part.