Jarvis Pizzeria: Import the 12c On-Premises Preparation Process

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 (<file><page><pool>).

Oops, that results in the not so beautiful process name ‘PizzaPreparationProcess-PizzaPreparationProcess’ (E.g. <page> 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.

Jarvis Pizzeria: Functional description of the payment process

Before we start preparing our pizza the order needs to be paid. With the implementation of the payment process we try to answer the following questions:

• How do the business rules work in PCS and how do they differ from their on-premises counterpart?
• What types of gateways do we have at our disposal?
• Do we have multi-instance subprocesses?
• How do we implement correlation?
• And more…

The business process that would fit most of our purposes would look something like the image below:

We start our process without a message, i.e. the payment process will be a reusable subprocess, according to the blog ‘Setting up the Jarvis 1.0 process’ where we explained the setup of our main process.

After the start we are going to determine which payment options would be at the customer’s disposal. Interesting to see is to what extent the web based version of the business rule implementation will be a copy of the business rules editor we have at our disposal in the on-premises versions of the BPM suite. Although that implementation is quite intuitive and straightforward, it definitely leaves room for improvements. Let’s find out!

The second activity will be a multi-instance subprocess where we will use the outcome of the business rules to start the available payment options. Although it is not clear from the picture, we are intending to implement the subprocess as a multi-instance parallel embedded subprocess (see the image below).

After starting the several payment options we have to wait for a callback of one of the payment options confirming the order has been paid. Obviously the event-based gateway is the component to use for listening to the several callbacks.

The observant reader might have noticed that using a parallel subprocess to make several service calls and subsequently use a single callback setup looks counter intuitive. We agree, but let's see what PCS is up to :).

There is also a timer connected to the gateway as we don’t want to wait forever for the customer to pay. After a timeout of the payment we notify the admin, here we want to try out the notification task mechanism of PCS, and end the process by throwing an error end event which will be caught by the main process as we have seen in the blog ‘Setting up the Jarvis 1.0 process’ .

After the gateway construction we will notify all the instances that we have started (a combination of creditcard, debit and deferred payment based on the outcome of the business rules) that the payment has happened in one of the available manners. These services have to listen to the event we throw and end themselves peacefully. This way we don’t end up with a bunch of orphan processes and we can experiment with the usage of correlations.

Jarvis Pizzeria: Functional Description of the Pizza Preparation Process

Lets take a closer look at one of the stages of the Jarvis Pizzeria process, the second phase is the preparation process. The implementation is a simplified presentation of reality. The purpose of the blog is not implementing a true presentation of reality, but learning some PCS features in particular.

The learning objectives for the preparation part of our blog series are:

• (Im)possibilities during the conversion of 12c on-premise to PCS. Determining alternatives for the impossibilities.
• Starting a process via a SOAP User Interface (SoapUI).
• Oracle Content and Experience Cloud (CEC) Integration. (Start a process via a Document, Archive the Order.)
• Usage of a Decision Service, Correlation and more …
• Transforming the Preparation process into a reusable subprocess

The image below is a view of the process we will implement.

Notes to this image:

We start at the processing of orders. This process is initiated by entering an order. We will implement this in two different ways. Firstly, a message that enters via a Soap User Interface. The second way is through a document that enters via the Content and Experience Cloud.

Without regard to any other order, a single order also uses some business logic. For the preparation of pizzas the following variables must be taken into account:

• Number of available crust chefs.
• Number of available filling chefs.
• Number of pizzas that fit in the oven.
• Total number of pizzas in the order.
• Preparation time for each type of pizza.

The values of these variables determine the order in which the pizzas should be prepared. The order is determined at the beginning of the order process. Any intermediate adjustment by emergent events are not yet supported.

From the order process the parallel subprocesses for preparing the individual pizzas are started. The actual starting of the preparation process may possibly be postponed as a result of the determined preparation order. This is a result of the Decision Service (where the business logic is defined).

After starting the preparation process the parallel instance starts waiting for a status update. This happens when the pizza is created and ready to be placed in the oven. Currently nothing happens with this interim result, but a possible correction of the total order and other preparation processes would be an application.

Below are the steps of the preparation process completed with the value of some parameters:

• Making the crust. Depending on the size this will be 2 or 3 minutes. This concerns a human task in which the relevant data is visible to the chef. Once the crust is ready the chef finishes the task.
• Filling of the pizza. Depending on the size and type this will be between 3 and 6 minutes. This concerns a human task in which the relevant data is visible to the chef. Once the pizza is filled the chef finishes the task.
• Notifying the order processing process of this interim status. This happens automatically after finishing the previous activity.
• Putting the pizza in the oven. This is also an human task. Once this task is completed, a descending timer starts to keep track of the remaining time for the pizza to stay in the oven. Depending on the size and type this will be between 6 and 10 minutes.
• Taking the pizza from the oven and putting it in a box. This human task will be available as soon as the pizza is in the oven. This contains the timer from the previous step and also some other required information. Once the timer runs out, the pizza is taken from the oven and put in a box. Then the task can be completed, which automatically finalizes the process. This human task takes about 2 minutes.

The parallel order processing process receives the completion message from the preparation process. Once all preparation processes are completed the total order can also be completed. Before this happens, the order is archived. For this we also make use of the Content and Experience Cloud (CEC).

The preparation process will be implemented in the following steps:

1. As a starting point, we deliver the 12c on-premise preparation process as exported application. All the steps needed to get this application working in PCS we are going to describe.
2. Starting the preparation process from SoapUI and through a Document.
3. Implementation of the order processing operations with specific attention to the decision service, correlation and Content and Experience Cloud integration.
4. Description of the steps required to transform the preparation process to a reusable subprocess.

Jarvis Pizzeria: Setting up the Jarvis 1.0 process

For the Jarvis pizzeria process we have distinguished three phases: payment, preparation and delivery. Hence, the main process is comprised of those three phases. Setting up the main process enables us to work together, because each one of us can implement a separate phase, without running into merge conflicts or whatsoever.

For creating a new process, click the plus icon in the application home screen.

Note that we can check the “Document Only” box, which will start our process in draft mode, i.e. disabling the implementation of activities. As pioneers we like to live on the edge as we let the “Document Only” checkbox unchecked and start right away with the implementation.

On the right hand side of this popup, PCS allows us to choose from certain start patterns. As we would like to use SoapUI later on to start our process with a payload, we choose to start our Jarvis process with a message.

For the implementation of the three phases we tried to mix up the different options of calling a process. Looking at the picture below, the first step in our process is concerned with payment. Obviously, we don’t want to hand out our precious hand crafted pizzas for free.

The payment process is implemented as a Call activity which calls a reusable process “PaymentProcess”, which can be selected by opening the properties of the Call activity. This will open the properties screen below the process where we can configure the Implementation of the Call activity.

The preparation process is an asynchronous process, so we use the send and receive tasks for starting the process and receiving its callback.

This implementation is also known as a Process-as-a-Service call which comes with the drawback of marshalling and unmarshalling the payload. We are not totally sure what the impact will be in a PCS environment, but we suggest to take it into consideration before using it as the default pattern in your application.

Last but not least, the delivery process is implemented with both a message throw event and a message catch event.

Although the Send-Receive activities and the Throw-Catch activities might look the same, there are some subtle differences. The most important thing to consider is that the Send and Receive activities support attaching boundary events to themselves, whereas the Throw and Catch events do not. This implies that within the process we can catch an error on the invocation of a process and act upon it, whereas an error while invoking a process through a throw event would disappear somewhere in the abyss.

When implementing the main process we must admit that we were happily surprised by the fact that PCS neatly aligns the activities in order to make it look like a decent and readable BPM process!

Now that we have composed the main process we are ready to implement all the stages and start baking some pizzas!

Jarvis Pizzeria: Call Services with the help of Integrations

From within our process in Oracle Process Cloud Services (PCS), we can call different service types. We can call an Integration on the Oracle Integration Cloud (ICS), a SOAP endpoint or a REST service. However, before we can call the service we need to create an Integration within PCS. The name integration here is a bit confusing, because it does not refer to Integration from ICS, but a local integration within PCS.

On the left hand side, in the black menu, we can see the Integrations tab. When we click here, we go to the Integrations page. Here we can create the integrations to call from our process. As you can see, we can use ICS Integrations as well as SOAP or REST connectors. We will not discuss the ICS Integrations, but focus on the SOAP & REST connectors that we want to call.

Let's start with creating a SOAP connector. Clicking ‘Create a SOAP Connector’ will start up the wizard in which we need to enter the wsdl location.

We can use an existing file (if there already is one) or upload a file to PCS. In our case we have a mock running on mockable.io to illustrate the calling of an actual SOAP endpoint. After selecting to Use URL, we enter the actual WSDL location in the textarea and click Next.

The WSDL on the location is recognised and will be imported into the PCS application. We name this the SoapPizzaSC and select the corresponding port types.

We do not have any need to tweak the advanced properties, so we will leave all the defaults on and create the SOAP connector by pressing the Create button.

This will result in our first Integration within the Application.

Now that we have a SOAP Integration, let's also create a REST connector. Clicking the add icon on the right will bring up the options we saw before on the home page. After selecting External we are able to choose a REST connector.

This will open a popup to enter a Name and the Base URL for the REST Service. We use a mock REST endpoint on apiary for this example.  

After finishing the wizard, the Rest Connector Editor will open. In here we can fine tune and edit the connector. Clicking the add button will bring up the screen to add an operation to the endpoint.

We want to add a get operation on the REST connector, so again we click the add icon, but this time the one a bit lower, in the Resources section.

The resource for the get operation will open and we can enter a name and path after which we need to add an example request and response payload to the operation.

Here we are going to upload a response example payload. When we add the example json, it will create business objects based on the payload that we supplied.

The result of the REST connector.

Now that we have created the SOAP and REST connectors, let’s see how we can use them in a process. For illustration purposes and to test the connectors we created an empty process.

From the right hand side we open the System tab and select ‘Service’. We then drag and drop it on the line between the Start and End.

As Type of implementation we select Service Call, after which a popup will show to select the integration.

Let’s start with a (SOAP) Web Service. When clicking the search icon, another popup will appear to select an integration. We will see the SOAP Connector that we have created with the name SoapPizzaSC and select it.

The SOAP Connector only knows about the getMenu operation, so this is the only option to select and the default value.

After pressing OK, the service implementation is done and we can drag and drop another Service task in the process.

For this Type of implementation we also select the Service Call. However, in the configure screen, we will select REST instead of Web Service.

Clicking on the search item will again show us a popup to select the connector, but this time, because we selected REST as option, the only available connector is the RestPizzaC.

We have only one resource and operation within the REST Integration, so these are filled in by default and are correct.

After pressing OK, the Service implementation is done and we have created a process that calls a SOAP service as well as a REST endpoint.