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 theicon 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.