Since Oracle BPM 12c was released this summer, many of our legacy BPM 10g customers have begun to ask what to expect from the migration path. As my colleague Suyash Khot discussed in his article Oracle BPM 12c Migration – A Hand of Friendship to Oracle BPM 10g, Oracle has luckily given us a migration utility to kick-start the process of moving code from Oracle BPM 10g to Oracle BPM 12c. While this utility is incredibly valuable and indeed very easy to use, it is well worth discussing the advantages and challenges this conversion presents us with.
This is the first in a series of articles where I’ll explore how various 10g coding patterns are translated into 12c and how we might overcome some of the issues this presents us with. While in many casesthe conversion is clean and maintenance-free, in other cases there is work to be done and issues to be on the lookout for.
In preparation for this article, I created a very simple, happy path Order Entry process in Oracle BPM 10g:
You’ll notice that this consists of the “Place Customer Order” Global Creation Activity that calls the “PlaceCustomerOrderSF” screenflow:
You’ll also notice in the process that the “Review Order” activity is in a parametric role. This activity calls the “ReviewOrderSF” screenflow:
Finally, in the process, the “Create Order in Database” Automatic Activity writes a row to a database table through an Heir object:
Let’s briefly see what this looks like in runtime:
As you can see, the Global Creation Activity invokes a screenflow that produces a very basic order entry form. This in turn creates an instance using “Region” as the parametric value:
The “Review Order” activity calls the “ReviewOrderSF” screenflow which produces this simple UI for the CSR to review and update certain fields before sending the order off for completion:
As you can already see, this is an extremely basic process that should ideally be very easy to migrate. Let’s take a look at the output from the Migration Utility after running the following script:
C:OracleMiddlewareJDev12.1.3soapluginsjdeveloperbpm
ant migrate10-12
-DprojectLocation=D:projectsAvioBlogProjectsBPM10gTo12cConversionOrderEntryApplication_10gOrderEntry
-Ddestination=D:projectsAvioBlogProjectsBPM10gTo12cConversionOrderEntryApplication_10g-12c-Conversion
The Migration Utility creates an export of the BPM project that we’ll import into BPM 12c. It also produces 2 different reports to show the results of the conversion:
The first report is an Excel file, in this case called “OrderEntry_projectStats”. As you can see below, this provides a simple list of elements that were present in the BPM project:
The other far more useful report is the XML file, in this case called “OrderEntry.xml”, which details what was and was not migrated. This will be very useful in the next step when we import the “OrderEntry.exp.”
As we examine what the converted project looks like in BPM 12c, be sure to refer back to this report to see how it performed. While many things did successfully migrate to 12c, it is immediately apparent that a good number of items did not. Let’s now turn our attention to Oracle BPM 12c where we’re going to create a new BPM application and import “OrderEntry.exp.”
BPM 12c Migrated Process Map
Immediately, we can see that there are obvious issues we need to resolve. For the sake of comparison, here’s the 10g process map again:
Original BPM 10g Process Map
Working from left to right on the 12c map, there are immediately some issues that will need to be fixed.
10g Global Creation Activity Migrated to 4 Elements in 12c
For one Global Creation activity in 10g, the Migration Utility created 4 elements in the 12c process map: Initiator Interactive, Service Activity, Message Start Event and an Exclusive Gateway. From a programmer’s standpoint, I can see why the Migration Utility does this, but personally think it should have been a bit smarter about handling a common 10g scenario like a Global Creation mapping arguments into the process. Ultimately, I will eliminate most of these activities including the associated sub process, leaving only a properly configured 12c Initiator Interactive.
12c Human Task Wasn’t Automatically Created for the Initiator Interactive
We have all known for a long time that UIs wouldn’t automatically migrate from 10g to 12c (more on this in upcoming blog articles). However, I was a bit surprised to find that the Human Task wasn’t created for an Initiator Interactive. Interestingly, Human Tasks were automatically created for other Interactives as we’ll see in a moment:
10g Global Creation Split into 12c Initiator Interactive and Service Activity
It was curious the 12c process had a “Place Customer Order” Initiator Activity as well as a “Place Customer Order” Service Activity. Remember how the Initiator Interactive didn’t have an auto-generated Human Task? The Service Activity’s answer is to call the “PlaceCustomerOrderSF” BPM Process.
In this sub process, I found that the Interactive Activity did in fact have an auto-generated Human Task, although curiously the input and output argument mappings were missing – more on this later…
10g Screenflow’s Outbound Arguments Not Migrated Into 12c’s Service Activity
In looking further at the “Place Customer Order” service activity, we’ll see that this has a rather intimidating list of issues.
If we drill into this Activity, we’ll find that Output arguments have not been mapped which is honestly a bit confusing to me since this is done graphically in 10g and not programmatically.
10g Process’s Input Mapping Migrated to a 12c Message Start Event
The Migration Utility chose to introduce a Message Start Event into the process in order to map incoming arguments that came from the 10g Global Creation activity:
10g Interactive Activity in a Parametric Role Was Not Correctly Migrated to 12c
What is interesting and somewhat concerning is that the ReviewOrder Interactive Activity is no longer in the correct swim lane:
As you can see, the Migration Utility not only has converted the 10g Screenflows into 12c Service Activities that call other BPM processes but it has also moved the “Review Order” activity into the “Customer” swim lane. I suspect that this is because from 12c’s point of view a Service Activity doesn’t need to be in a swim lane so this was dropped from the process map.
I was fine with this explanation until I took a look at the “ReviewOrderSF” BPM process that’s called by the “Review Order” Service Activity:
As you can see, the Migration Utility placed the “Review Order” Interactive Activity into the “Process Owner” swim lane, which is definitely not correct. If you need to know how to utilize parametric roles in BPM 12c (or 11g), take a look at Dan Atwood’s excellent article: Creating Parametric Roles Using Business Rules.
10g Interactive Activity Input / Output Arguments Weren’t Migrated to 12c Interactive Activity
As we can see in the image below, the Migration Utility successfully moved 10g PBL code to 12c Groovy code in Script Activities:
However, it’s interesting to note that the very clear variable mappings in the simple 10g Input Interactive Activity were not migrated over to 12c:
10g Input Interactive Activity Mappings
12c Interactive Activity Mappings
10g Catalogued Components Not Migrated to 12c
The final activity in the PlaceOrder process is the 10g Automatic Activity called “Create Order in Database” which utilizes some PBL script to write a row of information to the database with the help of an Heir Object. That was a simple BPM 10g way to convert an introspected database table into a Business Object. When this was migrated to 12c, I found that this script was not supported.
Upon further investigation, I also discovered that the Orders database table that was introspected in 10g was not automatically converted into a 12c Database Adapter as I had originally anticipated.
Conclusion
While admittedly this article has focused on a lot of the issues that I found with the migration from 10g to 12c, the good news is that there is a migration path and certainly a lot of elements were successfully moved. However, as Oracle is the first to admit, there is definitely some work to be done after a 10g to 12c migration.
In this article, we’ve seen how there are conversion issues with even the simplest of 10g processes, specifically around things like: argument mappings, parametric roles, 10g catalogued components and UIs. This is certainly not an exhaustive list, but it should give you a taste for what to expect from the migration process. For further information, please refer to Oracle’s 10g to 12c migration guide: Migrating Oracle Business Process Management Projects.
In future blogs, I’ll delve deeper into migration topics to not only point out issues you’ll encounter but also hopefully to provide some solutions.
Please check out myblog postsfor other articles around SOA process patterns, software development best practices and development methodologies.