Templating in Oracle Process Cloud Service

Oracle Process Cloud Service released a new capability in the space of re-usability and templating called "QuickStart Master", a way to streamline application and process development by promoting your own applications as templates.

This feature is build on top of the existing QuickStart Apps capability, a very nice feature which part part of the very first release of Oracle PCS.

So let's see how you can create a very simple application in Oracle Process Cloud Service and how you can promote it as a QuickStart app.

Create a new application in Oracle Process Cloud Service, give it a name and file it under a space (I've named it "Travel Request Application" under a custom space called "aantoniou").

Create also a sample process. For simplicity purposes I've created a process using the "Form" pattern and named it "TravelRequestProcess".

Open the "Start" properties, define a title and create a new "Web Form".

Save your work and close the process. We are now ready to convert our application to a QuickStart Master.

To do so, from the "Application Home" click on the elipse button (denoted by the three dots) and choose "Convert to QuickStart Master".

On the confirmation dialog select "Yes". You can define some generic properties for your QuickStart app as well as some personalization criteria.

Expand the "Properties" section and choose an image to be used for your QuickStart App.

Colapse the "Properties" section and expand "Personalize". You can add multiple customization layers to control what settings users can customize. Click on the plus button to create a new customization.

Define a label and a title for the item that you want to provide customization capabilities. From the "Process" drop down select your process and select the type of component and the specific item that you want to provide a customization (I've selected the "Activity" type and the "Start" item).

Depending on the component type and the actual item selected, you have various properties which can be flagged for customization. In my case where I've selected the "Start" activity component, the only properties available for customization is the title (if you switch component type and item, for example lane and choose one of your lanes, you should see the "Role" property available for customization).

You also have the ability to give the capability to the users of this QuickStart app to disable the item under customization. I've left the default option to "No".

Click on "Done" and save your work. We are now ready to promote our QuickStart Master as a QuickStart application. To do so click on the "Promote" button. On the "Request to Promote as QuickStart App" properties window define a name and click "Promote"

You should get a confirmation message that your application was promoted as a QuickStart app.

Let's create a new application using our application we just promoted as a QuickStart app. From the "Composer Home" click on "Create" and select "QuickStart App". From the list of QuickStart apps select our promoted application template to create a new application.

Oracle Integration Cloud Service Integration in Oracle Process Cloud Service

A new integration connector has been introduced with the latest release of Oracle Process Cloud Service that enables Oracle Process Cloud Service applications to communicate directly with Oracle Integration Cloud Service.

This is a very important "architectural" feature since it encourages a solution topology that includes a virtualization layer, an integral "ingredient" in integrations to avoid point-to-point connections through decoupling and abstraction.

So let's see how you can use the "ICS Connector" to connect to ICS and consume a SOAP endpoint.

The use case that I will use in this blog post is quite simple; I will call a "Hello World" ICS Service from an Oracle Process Cloud Service process utilizing the "ICS Connector".

I've already created "Hello World" synchronous SOA composite. The implementation is very simple. I'm just using an assign component with the "concat" function to assign a static text ("Hello ") and the input to the output element of my "Hello World" service.

My "Hello World" SOA service is deployed to Oracle SOA Cloud Service (SOA CS).

Moreover I've already virtualized the above service on Oracle Integration Cloud Service (ICS) by first creating a SOAP connection to my SOA CS service and then creating a basic map data integration that uses the SOAP connection as a trigger and an invoker, creating a basic data mapper for both request and response messages.

So with the SOA service deployed on SOA CS and the virtualized service created on ICS, we are ready to create our PCS application.

Create a new application in Oracle Process Cloud Service, give it a name and file it under a space (I've named it "OracleICSIntegrationInPCSDemoApp" under my personal space).

Before creating our process, we need to create the actual integration to ICS. To do that navigate to "Integrations" and surprisingly enough you will notice that there are only two types of connectors, a "SOAP Connector" and a "REST Connector".

This is because you need to configure an "Integration Cloud Service" connection in Oracle PCS. Therefore from the Oracle PCS Home page, click on "Configure" and from the "Services" menu ensure that the "Platform" tab is selected and configure ICS by entering the URL and credentials to connect to your Oracle ICS instance. Ensure you test your connection before saving the configurations.

Go back to your application (via the "Develop Process" banner) and navigate to the "Integrations" section. You should now see the "ICS Integration" option available.

Click on the "Use ICS Integration" button and you should see a list of all your active ICS integrations. Locate and select your integration and click on "Next".

In the "Advanced" step you can configure the security for your calling service as well as some basic parameters such as the read timeout and the connection timeout.

My ICS Integration is using a username token so I've selected "APP Id - Username Token" from the "Security" drop down list.

Oracle PCS allows you to define keystores for storing your username and passwords. If you already created a keystore for your ICS service, select it from the list, otherwise select "[New Key]", give your keystore a name and supply the username and password that you use to connect to ICS and click "Create".

In your "Integrations" space you should have now your ICS integration. Please note that all metadata are inherited from ICS (for example, name, description, code and version).

To test my ICS integration I will create a simple process that starts with a form for the user to enter the service's request parameter, call the ICS service and again using the same web form to display the response from the service call.

So create a new process using the "Form" pattern.

Open the properties of the start component and define a title for your process and create a new web form.

On your web form, drag two input text components. Name the first name "Name" and the second one to "ServiceResponse". You can optionally disable the second text component since we will just use it as a placeholder for copying the service response.

Go back to your process and drag a Service component (from the System folder) between your start and end components. Rename it to "Invoke ICS Service" and go to its properties.

From the Implementation Type drop down select "Service Call" and click on the "Edit" button. This will popup the "Configure" window. Ensure that "ICS" is selected and click on the browse button to select your ICS connection.

Next we need to define the data that will be passed on to the service and the retrieve the data that will be returned back. To do that we will use the data association functionality. So From the service call component click on "Open Data Association".

Ensure that "Input" is selected and expand "Process Data", your web form's data object and drag the "name"element to the left pane of the data association editor. This should be mapped to your service's request element (in my case it's called "input").

Select "Output" and assign your service's response element (in my it's called "result") to your web form's "serviceResponse" element. The "Output" transformation should look like below.

Drag a submit human task just after your service call. Open it's properties and select the same form you've create and used in your start component.

We are now ready to test our process. Click on the play button just above your process to run an in-place execution of your process. On the start button click on the play button to open the "Play" window. Click on play to open your web form. Enter a value in your "name" field and "Submit" the form.

Please notice how PCS highlights the execution path of your instance process. You should see the token passing from the ICS Service call task and waiting at the human task component.

Click on the play button on the human task component and select "Launch Form" to open your web form. You should now see in your placeholder element the response from the service call.

Private Application Deployments in Oracle Process Cloud Service - New Feature!

The latest Oracle Process Cloud Service (PCS) brought finer control with respect to deployment strategies with the introduction of "Private" deployments, an entirely new feature that allows you to define deployment permissions on individual environments.

Previous versions of Oracle Process Cloud Service allowed the developer to not only test their applications, which basically does a deployment to a sandbox environment, but to also deploy applications to configured targets.

The latest Oracle Process Cloud Service allows you to define a more fine grained deployment strategy, thus restricting developers from deploying applications and only granting this privilege to a user with administrative permissions.

What is even more interesting is that this configuration can be performed for each target. So for example, you might have different environments, DEV, TEST and PROD and only allow developers to deploy on DEV.

To configure the deployment permissions, from the Composer Home page click on "Management". You will notice that for each server there is a drop down with the default selection set to "Private". This denotes that only administrators can deploy applications to that server.

Use the drop down list and select the "Open" deployment option to allow both administrators and developers to deploy to the selected target.

Event Based Gateways and Correlations in Oracle Process Cloud Service

The latest Oracle Process Cloud Service release in September 2016 (v16.3.5) added the support of two important functionalities; the "Event Based Gateway" for process branching and "Correlations" for process communication.

These capabilities have been available for quite some time in Oracle's Process Cloud Service counterpart, the Oracle BPM Suite and have been described in detail in two of my blog posts; "Correlations in Oracle BPM 12c" and "Oracle BPM 12c Gateways (Part 5 of 5): Event-based Gateway".

Even though the functional concept is the exactly the same, whether used in an Oracle BPM Suite process or an Oracle Process Cloud Service process, there are yet some small differences, especially with the "Event Based Gateway" in Oracle Process Cloud Service.

So in this blog post we will see, in detail, how you can use the "Event-Based Gateway"to implement divergence and branching in your processes using events generated from external processes. Process communication will be implemented using "Correlations".

The scenario that I will use is quite simple and I will use two processes. The first process will simulate a warehouse inventory process that depending on the order id (supplied as a process request argument) will respond whether the stock item is available or not.

The second process will invoke the "Warehouse Inventory" mockup process using a custom correlation key and will make use of the "Event Based Gateway" to pick the generated event.

So let's start with the implementation of the "Warehouse Inventory" mockup process. Create a new application in Oracle Process Cloud Service, give it a name and file it under a space (I've named it "EventBasedGatewayAndCorrelationsDemoApp" under my personal space).

Next create a new process using the "Message" pattern

Next we will create the "Warehouse Inventory" process. From the "Create a Process" screen, select the "Message" pattern, give your process a name and click on "Create".

Edit the "Start" component, edit the interface by clicking on the "Edit" button next to the "Define Interface" type to add a new request argument called "orderId" of type string.

The "Warehouse" process, depending on the supplied order id will respond back to the caller using a different end message component. But let's first configure the default "Message End" component.

Edit the default "End" component and add two string response arguments, "orderId" and "status" and change the default operation name to "endWithNo". Change also the default label from "End" to "End with NO" (to distinguish between the two operations from the calling process).

Add another "Message End" component and again create two string arguments, "orderId" and "status" and change the default operation name to "endWithYes". Change also the default label to "End with YES".

We will need one process data object to store the incoming order id and pass it back to the response. So click on the "Data Objects" and create a new data object called "orderId" of type string.

Next assign the process input order id argument to the order id process data object. On the "Start Message" select "Open Data Associations" and drag the orderId input argument to the "Start" association input box. Expand the "Process Data" and drag the orderId process data object to the "WarehouseProcess" association input box.

Now that we have the process data objects defined, we can process with providing the data associations on the two "Message End" components. Therefore open the data associations of the "End With YES" task and map the order id process data object to the orderId response argument and a static string (let's say "YES") to the status response argument.

Do the same thing with the "End With NO" task but this time mapping a different static string to the status response argument (for example "NO").

Next we will add an "Exclusive Gateway" between the "Start" and default end message component (if you followed my instructions it should be the "End with NO" message end component). Optionally rename the default "Exclusive Gateway" label to something more meaningful (for example, "Stock is Available?") and add a conditional flow from the "Exclusive Gateway" to the second end message component ("End with YES"). For better readability of the process you can add labels to the default and conditional flows.

If you click on the "Validation" button you should notice that there is a validation error. That's because we have created a conditional flow with an empty condition. So open the conditional flow and define a condition (for example, take that path if the orderId is "123").

Our "Warehouse Inventory" mockup process is now complete. We can now move on with creating our main process, the process that will be calling the "Warehouse Inventory" process.

Create a new process using again the "Message" pattern (I've named this new process "OrderProcess").

This new process will accept and order id and will return a status (both arguments will be of type string). Therefore on the "Start" message component, go its properties, click on the "Edit" button next to the "Define Interface" implementation and create a string argument called orderId.

Using the exact same steps, create a "status" response argument on the "End" message component.

Both arguments will have to be carried along the main process, therefore create two new data objects, using the same names and types.

Just like we did with the "Warehouse Inventory" process, we need to assign the request argument to its respective process data object so that it can be used along the process. So open the "Start" data associations and drag the orderId input argument to the "Start" association input box. Expand the "Process Data" and drag the orderId process data object to the "OrderProcess" association input box.

Using the same approach, we need to map the "status" process data object to the response argument. Open the "End" data associations, expand the "Process Data" and drag the status process data object to the "OrderProcess" association input box. drag the status output argument to the "End" association input box.

We will be invoking the "Warehouse Inventory" process using a "Message Send" component and we will be using the new correlation capabilities support in Oracle Process Cloud Service to define the conversation association between the calling and callee process.

Drag and drop a "Message Send" task between the "Start" and "End" tasks and name it "Invoke Warehouse Process". Open its properties and from the "Type" drop down select "Process Call". Click on the "Edit" pencil button and from the "Process" search box select your "Warehouse" process. The "Target Node" should be automatically populated with the "Start" message.

If you recall, the "Warehouse" process requires an order id to be passed as input. So open the "Message Send" data associations and map the orderId process data object to the orderId send task argument.

Drag and drop an "Event Based Gateway" just after the "Invoke Warehouse Process" send message task and name it "Catch Warehouse Event". Delete the default sequence flow from the "Event Based Gateway" to the "End" task and add two "Message Catch" events and name them "Catch No Event" and "Catch Yes Event" respectively. Add a default sequence flow from the "Event Based Gateway" to the two new "Message Catch" tasks and add a default sequence flow from each of the two "Message Catch" tasks to the "End" task.

We need to define the implementation details of each of the "Message Catch" events. Go to the "Catch No Event", open its properties and from the implementation type drop down select "Process Call" and click on the "Edit" pencil button. From the "Process" search box select your "Warehouse" process and in the "Target Node"select the "End with NO" end message.

The "Warehouse" process, depending on the order id will return a different status (mapped via it's status response argument). So go to the data associations of each of the "Message Catch" tasks and map the status response argument to the status process data object.

The only thing left before we deploy and test our processes is to define the correlations between the calling process (OrderProcess) and callee (WarehouseProcess). Custom correlations, also known as "message-based" correlations enables the definition and use of "business-friendly" information carried as part of the message payload to be used to uniquely identify and associate a message with a conversation. This type of correlation enables the definition of multiple attributes referred to as "Correlation Properties" into various correlation sets know as "Correlation Keys".

We will be using only one correlation property and that will be the order id. Click on the "Correlations" button (located above your process on the button toolbar), create a new correlation key and a new string correlation property called orderId. Please make sure you shuffle the correlation property to your correlation key, otherwise you will not be able to use it.

With custom correlations you have the concept of an initializer, the task that set's up the message association agreement and we also have the notion of a correlator, tasks that wait to receive a message using the correlation definition instantiated by the initializer.

In our case the initializer will be the "Message Send" task while the two "Message Catch" tasks will be the correlators. So go the "Invoke Warehouse Process" message send properties, select "Correlations" and click on the "Add" button to add the correlation key you created in the previous step. It should automatically detect the orderId correlation key property. You just need to assign a value to it and this will be the order id process data object.

On each of the "Message Catch" tasks, go to "Properties", then "Correlations" and make sure to switch to the "Correlate" tab and add your correlation key. Again assign the orderId process data object to the orderId correlation property.

One last step before we can deploy is that we have to publish our work. So click on the "Publish" button and in the "Publish Application" popup add a comment and click "Publish".

We are now ready to deploy and test our application. Click on "Deploy" and select "Deploy new version". In the "Select Version" train stop select "Last Published Version" and click "Customize". Leave all defaults on the "Customize" screen and click on the "Validate" button. Ensure that your application is successfully validated and click on "Options". Set a revision id and click on "Deploy".

Since our main order process can only be started using a message, we need to get the endpoint URL and invoke it via SoapUI. To do so click on the "Management" link, locate your application from the list of deployed applications and scroll to the right. Click on the "Actions" button and select "Web Services".

You should have two endpoint URLs, one for the order process and one for the warehouse process. Ensure you copy the order endpoint and using SoapUI invoke an instance of the order process. I will go with the happy path so I've enter order id "123" (please note that you will need to pass your credentials and a timestamp in the header, otherwise you will get a security exception from Oracle Cloud).

From the Oracle Process Cloud Service dashboard click on the "Track Instances" banner to go to instance tracking. Ensure from the filters you've selected "Completed". You should see two instances completed, one from the "Warehouse Process" and one from the "Order Process".

Go to the details of the "Order" process (click on the green arrow) and expand the history view. You should see that the order process followed the "happy" path.

Invoke the process again this time providing an different order id. Go to instance tracking and again you should see a pair of instances. Open the "Order" instance details and you should now see that the process followed the alternative path.