Jarvis Pizzeria: Using an imported XSD in PCS

In the post ‘Import the 12c On-premises Preparation Process’ we saw the Business Types that were imported (also shown here)
We already stated that we had an issue with enumerations. But is this the only issue with the xsd? Unfortunately not, as will become clear soon.
Making task forms was not part of the import blog, however, in this blog we are going to do this. We will do this based on the imported xsd. So let's get started. Create a New Web Form
Give the Form a name and click the Create button.
Because the ‘Open Immediately’ check is on, the new Form opens. In the bottom right corner is the Business Types Palette. In here we see the imported Business Types that are based on the used xsd. For this form we need the PizzaPreparationBO. Drag and Drop this on the canvas.
The following form is generated. All elements of the business type are there. The ingredients are placed in a repeatable section.
Although the form is not very beautiful yet, for now, we let it be what it is. We're going to test first before we make the form look better.
Save the form and open the created process to connect the form to the tasks.
We have attached the same form to all tasks in the process. After that open the Data Association for the task. The images below show the input and output mapping used for the ‘Prepare Pizza Crust’ task.


Save and Publish the application.
Enter a comment (it’s mandatory).
Next we Deploy the application.
Details about the deployment of an application can be found in a separate Jarvis blog and starting an instance with SoapUI can be found be found in another Jarvis blog.
After running a test with SoapUI a new running instance is created. On the tasks page the first task of the running instance can be found.
Open the task by clicking on it. The task opens. But to our surprise, not all data is there. The list of ingredients is missing.
Let’s analyse this a bit further. For this go to the tracking page. The instance can also be found there.
Open it by clicking on it. The Graphical view shows that the first task is currently active.
Switch to the Tree view.
Then select the task payload (instance entered the activity). It might be a surprise but the list with ingredients is send to the task, so why is it not displayed?
Is it a bug in the used version (17.2.3)? And will it be fixed in a later release? Or is it a design decision? Only time can tell.
In a coming blog we will describe a way to overcome this issue.

VBCS: Integrate VBCS with PCS

The integration between VBCS (Visual Builder Cloud Service) & PCS (Process Cloud Service) is getting a lot better, you can now create and start processes from within VBCS. It is also possible to create a tasklist or task screens within VBCS. In this blog I will show you how to set up VBCS to be ready for these features as well as how to create a process and tasklist connected to this process. 

In the current release (17.3.5) of VBCS it is not yet possible to explore and connect to existing Process Cloud Instances. The whole process needs to be initially created from within VBCS. It also needs to be deployed from VBCS the first time, after that it can be deployed from either PCS or VBCS. After this it can be edited and adjusted within PCS. 
First we need to go to the security settings within VBCS, in the Access section, enable the basic authentication for business object REST APIs.


After that you need to go to the home page from VBCS. There is a somewhat hidden menu there on the right where an Administration option is hidden in a menu.


This brings up several Administration Options, of which some are required to fill out before VBCS & PCS are connected and integrated together. On the Tab ‘Associated Service Instances’ fill out the URL to the instance of Process Cloud.


Now we still need to go to the Allowed Origins tab to prevent CORS from happening.


To create a Process connected with VBCS, we need to go to the Business Objects under the Data Designer section. In here, there is an extra tab on the right called ‘Processes’. There is a green button to add a New Process.  
We give this a name, to recognise it within PCS, we name it ‘VBCS Process’.


After this it will show in the Processes tab on the Business Objects page.


When clicking the menu icon, you can select the Process Editor. Doing this will actually bring you to PCS and open the Process within PCS.


But before doing that, as said, we need to deploy from within VBCS first.
From the action bar we can select the ‘Deploy All’ option.


Especially the first time, the deployment might take a while.
While Deploying the button is greyed out and you can see that it is busy working on the deployment.
When the deployment is done, we can click the ‘Edit Processes’ link that brings us to PCS. The ‘Manage Process Roles’ takes you to PCS as well, but does not open the process but the security settings where you can assign users to your process roles.
Clicking the Edit link brings up the VBCS Process. In here I only have a User Task, since I want to task to be created to show up in the tasklist that we are going to build within VBCS.


Now let's start at least one instance so we have a task ready to show in the tasklist in VBCS. Here you see a running instance from our VBCS Process.


Enough about PCS, lets move back to VBCS and start working on our tasklist. In VBCS I open the Page Designer. In the components on the left hand side, there is a Process tab.


The first icon is the tasklist, when dropping this on the page a wizard will appear on the right hand side.


Here it will give you the options of selecting any of the PCS processes you created from within VBCS, this means you can have separate tasklist for different processes. Lets select the VBCS Process.
Pressing Next will bring us to the detail screen, I actually leave all the defaults on.


Clicking the green ‘Finish’ button will finish the wizard and bring up the tasklist.


As you can see, the instance that is started and waits for the human interaction is shown in the Tasklist already. In the menu, you can select actions, for this example I will press approve to see the integration with PCS working both ways.


The feedback is giving within VBCS, the action is performed. Once the fetching is done, the task will disappear from the tasklist.


Just to complete the circle, let's have a look at the instance now being completed within PCS.

Jarvis Pizzeria: Deployment and using the workspace

Having played around with all the features PCS has to offer it is now time to see some action. In this blog we will show you how to deploy your application, start the application and see how it behaves within the workspace.


But first of all, we need to have a application that is ready to deploy. In other words, our minimal deployable product consists of an application without any errors. Pressing the validate button in the top-right corner will tell you the current state of the implementation.


Unfortunately, we ran into a bunch of errors! Mostly due to missing implementations of service calls. The good thing however is the “Fix” link.
In contrast to JDeveloper, clicking the “Fix”-link will bring you directly to the - in this scenario - properties screen to fix the issue. Oops, we forgot to select a ruleset for our business rule activity.




Having fixed all the issues it is now time to show the first rays of sunlight to our Jarvis Pizzeria application. Clicking the “Deploy”-button in the top right corner will bring us to the tab where we can deploy our latest-and-greatest published version of Jarvis.
In the screen that follows the user can click “Deploy new version” in the top right corner.


This brings us a popup where we can select which snapshot we want to deploy. We choose to deploy our last published project.


Clicking at “Customize” brings us to the next screen within the popup:
In here you can customize your services that are used. Obviously, the endpoints can differ from environment to environment. Most likely your development environment will mock the service endpoints, whereas from you acceptance environment you connect to the live services. The question is, can we use configuration plans as we know from the on-premises soa composite applications? So far, we have found nothing about configuration plans in the documentation. Maybe something to add for a future release?
Clicking the “Validate” button will check the application for design-time errors. Luckily in our examples there are only warnings, which enables us to continue.


The options to select from are shown below. These options are the familiar ones, that one might known from the Jdeveloper deployment wizard. The only new option that has been added is the choice whether this application should use fault policies. Does this mean that we don’t have to struggle with creating the fault-policies and fault-binding files? Let’s see what happens.






Now it’s time to start our application and see how it behaves. As one might recall, any PCS  application can be started with either a SOAP message or a REST call, hence we cannot start it manually from the workspace. An application can be started manually if the start node is a manual activity (for example a manual task).  But no worries, in this SOAP blog post (LINK to SOAPUI post) and this REST (LINK to REST post) blog post we explained how to start the application.
In this case we choose to create a new SoapUI project and import our WSDL. In the image below the WSDL is imported and the authentication credentials are added.
Now we are going to open the Workspace to see if we can find our instance.
The starting screen of the workspace looks like the picture below. One might notice two things:
  • There is blue bar in the top of the screen which let us choose if we want to be in testing mode. Not sure about the exact meaning of this option, Oracle’s documentation is clear about it:
Note the Testing Mode indicator at the top of the page. When using Testing mode, you can only access the data generated by the applications activated to the test partition. This data is isolated from data in the production environment. “


There happens to be two partitions.The test partition and the production partition. In a future post we will elaborate on this.


Below the blue bar there is Test (1.0) application that can be started. Note, that this is not the application we just deployed. This is a testing project in which we start an application with a manual task.
We click the “Track Instances” button at the right side of the screen.
There we see our instance we just started via SoapUI.
However the icon indicates the instance is running, looking at the process flow, it seems to hang at the “End Delivery” callback.
The Delivery process is a standalone process which we invoke with a process-as-a-service call. If we remove the search filter, we can look for errored instances within the Delivery process.


There it is, the Delivery process is in an errored state, however the engine has indicated the error as “Recoverable”, indicated by the icon:
When clicking the errored instance we get the following screen


Unfortunately the Order Info step went wrong, so let's take a look into the tree view to see what the error looks like:
That’s interesting. The service call went wrong, the error is indicated as recoverable and the service call is retried after ten seconds. That looks like the fault policies are doing their job!
But looking at the configuration settings, we could not find the location to configure the fault policies. An interesting feature for the fault policies would to define them in a more granular way. In other words, for a certain service invocation error one would do two retries before human intervention is entered, whereas for a another service it might come in handy to go directly to human intervention without doing a retry.
The recovery options are divided into the following categories:
  • Abort
  • Retry
  • Continue
  • Manipulate the flow


That gives the operator great power to fix instances that are in an errored state. The abort option exits the current process, the retry option does a retry on the faulted activity and the continue option just “skips” the faulted activity. Note that the latter option is quite dangerous as the faulted service have not returned any data to the process which - when not modeled properly - will result in a selection failure later on.
We choose to manipulate the flow, another “dangerous” option as it gives you the power to remodel the process at runtime.
In the image below we actually simulate the “Continue”-option, telling the engine to skip the faulted activity and go to “AnnounceOrder”. It also gives you the ability to pick a data object and manipulate the data. Lets resume the flow.




And all of a sudden, we have a successful flow!


And also our main flow has ended successfully:

This wraps up our blog about deploying and running our application and a first glance at PCS’ error recovery possibilities. Although, there are many similarities with the on-premises BPM version, there are also some differences. We have seen differences in the usage of a config plan, setting up fault policies and the flexibility one is offered in recovering runtime errors.