In the Functional description of the Preparation process we stated that we would describe all steps required to migrate a sample 12c preparation process to PCS. So let’s get started.
As a starting point, we have the 12c on-premises preparation process as exported application. A picture of the BPM process is shown below.
The first attempt: directly import the exported file in PCS.
In the Composer select Import Model from the hamburger menu at the top left corner.
An intro appears. Click next to continue.
Now we need to specify the source type. As we exported the project from BPM Suite 12c we select Oracle BPM Project (exp)
Select the export file and then click ok
This results in an error message. The export is made with a version that is not supported.
So a direct import of the export file does not work. So where do we go from here?
Our second attempt: let’s try to import only the BPMN file from the export.
Before doing this, we unzip the export file to make it possible to select the BPMN file.
Then we go back to the Import (see the first attempt steps) and now select BPMN 2.0 (bpmn) as the source file type. Select the BPMN file (the process model) and click next.
Since the file contains only one process model the next page is not as relevant. Just make sure that the PizzaPreparationProcess is checked. Click next to continue the wizard.
Now we have to select the naming convention to use. So let’s try the most comprehensive one ().
Oops, that results in the not so beautiful process name ‘PizzaPreparationProcess-PizzaPreparationProcess’ (E.g. would have resulted in the original process name).
When opening the process in composer, we come to the conclusion that this is not the kind of import we want.
The formatting is not pretty, all the lines are numbered and roles are created, but everything is linked to the same role. However, this was to be expected because we only imported the bpmn file and not the process_documentation.XML. There is still a lot to do in PCS to get this imported process running. So let’s try something else.
Attempt three: Find out what changes in the export file are required to make it importable.
We found out that Andre Boaventura also did something similar. For details see his blog post.
With this blog at hand we started. To work around the version incompatibility we changed the version number (in file ProjectInfo.xml, we update the projectVersion from 20120601 into 20140730).
A retry of the import results in a ‘successful’ import. How successful we will find out.
What has been imported? As we can see, the process and also the used xsd-schema are imported.
When the imported process contains unsupported elements like Scripttasks or Complex Gateways it is not possible to open the process. In that case the following error message appears.
But the process contains only supported components and so it can be opened.
And we are lucky :-), also the Business Types can be opened.
But to be honest, we have tweaked it a bit on the on-premises side. Initially we used the following xsd-schema.
The Size and Unit elements are both of type String restricted by an enumeration. But it seems that imports of such enumerations are not supported (yet?). The xsd-schema was not imported automatically. So after removing the enumeration the schema was imported.
Note: It is possible to manually import an xsd with enumerations, but the elements which are associated with enumerations cannot be used in task screens.
So we’re almost there. The 12c export does not contain the ADF Human Task screens. This makes sense because the PCS task screens do not support ADF. To get things working we still need to develop the task screens. That, however, is outside the scope of this post. The picture below is one of the screens that we used.
After creating the task screens we also had to complete the data mappings between the process and the tasks.
As the Oracle PaaS Summer Camps VII in Lisbon this year has the BPM to PCS migration tool as a topic in the Process Cloud Service track, there will be an addition to this blog available soon.