Jarvis Pizzeria: The various Decisions of a Decision Model

In one of our next posts we will implement the Decision Model in the Order Process. Before we do that we first explain the various type of decisions that are available for a Decision Model.

The Decision Model editor in PCS (Process Cloud Service) or the later OIC (Oracle Integration Cloud) supports the DMN (Decision Modeling Notation) standard version 1.1, and uses FEEL (Friendly Enough Expression Language) to make decision modeling easier and more intuitive.

In DMN all decision logic is represented as ‘boxed expressions’. A ‘boxed expression’ is a graphical notation for decision logic. Within OIC we recognize the following boxed expressions:





The expressions in the boxes are FEEL expressions. A Decision Model is a tree of simple decisions notated as FEEL expressions. In the remainder of this blog we will give an example of the various boxed expressions.

Expressions
The first example is a boolean expression with the name ‘SmallPizza’. The expression is true when the size of the pizza is ‘Small’. Otherwise it’s false.


In the second example we have the named (crustArea) expression to calculate the pizza crust area.



IF-THEN-ELSE
Next we have the if-then-else construction. Actually, this is no more than a combination of 3 expressions. The first determines which of the following 2 is returned as a result.



This construction could also be defined with the following single expression


Decision Table

The Decision Table is by far the most complex and ridge boxed expression. In this post we limit ourselves to a single example and an explanation of the available hit policies.

The following table returns the required baking time for each type of pizza. The baking time is independent of the size, except for the Quattro Stagioni, the Small pizza requires a minute less than the other sizes. To get the correct outcome from the Decision Table we have to set the hit policy. By default it is set to U(nique). But that will not work for this. There are 2 rules that a small Quarttro Stagioni meets. We want the first rule to be met. We do this by setting the hit policy to F(irst) in the upper left corner.



The following list shows the available Hit Policies. Here we are not going to treat them in detail.

U
The Unique hit policy is used when at most 1 rule can match the input
A
The Any hit policy is used when multiple rules can match the input, but the output value is the same for all matching rules
F
The First hit policy is used when multiple rules can match the input. The first hit by rule order is returned.
P
The Priority hit policy is used when multiple rules can match the input.The matching rule with the highest output priority is returned.The priority is defined by the order of output values in the decision table output column header
C
The Collect hit policy is used when multiple rules can match the input, and a list of output values for all the matching rules is desired
c+
The Collect with sum hit policy is used when multiple rules can match the input, and the sum of the output values for all the matching rules is desired
c<
The Collect with min hit policy is used when multiple rules can match the input, and the smallest output value for all matching rules is desired
c>
The Collect with max hit policy is used when multiple rules can match the input, and the largest output value for all matching rules is desired
c#
The Collect with count hit policy is used when multiple rules can match the input, and the count of the matching rules is desired


Context
Next we come to the context box. A context is a list of key-value pairs.
In this example a list of 'constants'. The key must be unique, when duplicated, only the last one survives. In the example we used expressions, but it is possible to use any type that suits your needs, for example decision tables. In a context it is possible to reference entries that are defined higher in the context (like the fullname, that is using size and name).




List
A context is a list of key-value pairs and a list is a list of values without the key. It’s pretty straight forward.



Relation
Next is a relation. A relation is a shorthand for multiple contexts (a list of contexts).


Let’s convert this relation into a flat FEEL expression. We will do this in two steps. The first step is to present the relation as a list.


The next / second step is to transform this list into one single expression.




Function
The last one is the function. Functions are used to get a reusable piece of code. You can feed them with parameters. A function can contain any of the other boxed types in its body. But that is not that special. Without explicitly mentioning it we already did it before. In the context we used nested expressions.

The following function checks whether the pizza size is 'Small', 'Medium' or 'Large'. If that is the case, the cooking time is calculated. For a 'Small' pizza that is 2, a 'Medium' 3 and for a 'Large' it is 4 minutes.




The ‘index of’ function returns all occurrences of the size in the list. For our solution this could only be one occurrence. We get this single occurrence as an entry in a list. That’s why the first entry is selected and convert to a string and thereafter into a number.
In this function we used a few of the available build-in functions. We won’t get into details about all of them in this blog. In a later blog we will pay special attention to these build-in functions.

Jarvis Pizzeria: Activating activities and attaining milestones

In our previous blogs we have given a brief overview of the look-and-feel of the dynamic process possibilities within PCS. In this blog we take a dive into the activation of activities, how milestones can be attained and how rules are configured to make sure that the correct actions are triggered when conditions are met.

Let's take a look at our dynamic Jarvis overview first. In the picture below we came up with three stages: ordering, preparation and delivery.


Obviously we start the preparation phase after the ordering stage has completed. This configuration is shown below:


In here we have selected the “Preparation”-stage and clicked the edit-pencil. In the “Conditions”-tab one can choose to add Activation conditions and Termination conditions. Because we want to start preparing the pizza after the order stage completes, our activation condition is configured as in the picture below:


There is no need for us to specify termination conditions. When all activities in the preparation phase are completed and when the Prepared milestone has occurred then the stage will auto-complete. A possible use-case for termination can be that an event comes in that the order has been cancelled. Let’s see how that would look like. We create a global activity “Order Cancellation” (for the example it doesn’t really matter what type of activity this is)


Now we can configure the termination condition for the preparation phase:


One might notice that our stage has two icons added to it showing the presence :


Another way of adding a condition is by means of data, hence the “Data driven” name. To do this we have to add a Data Object that tells us whether the order has been cancelled.


The orderCancelled boolean can be set by an activity to flag that the order has been cancelled. In the Termination settings we can then specify which value “orderCancelled” must have in order to meet the condition:


Which will lead to the following result:


We have configured the activation and termination conditions of the Preparation stage. The same holds for the configuration of activities.
For milestones however, we can configure when a milestone completes. In our example, the Prepared-milestone is completed when the “Prepare Pizza” activity is completed.


Note that revoking milestones is not possible. The stage of a milestone is either “Created” or “Occur”, as is depicted below:


This wraps up the blog about activation and termination. The ones familiar with Oracle ACM might notice the look-and-feel which has improved drastically. The readability of the case as a whole has become very easy. PCS dynamic processes supports the user by provisioning the drop-down boxes with all the names of the processes and activities, making the life of the developers very easy. The only noticeable difference we encountered was the lack of the possibility to revoke a milestone. However, this might end up having dynamic process that is less complicated!









Jarvis Pizzeria: The logic underneath the Dynamic Process

In our previous blog we have made the first set up of our dynamic process. We created several stages and had the first processes, human tasks and milestones in there. Now that we have the first draft of the dynamic process, it is time to actually call some processes and human tasks from our dynamic process.
In this blog we will explain how that is done. We already had imported the Preparation Process Application. But the delivery and payment are not part of this application. They are part of the overall Jarvis Pizzeria application. So before this blog, we also imported the Jarvis 1.0 application and the DeliveryDM to the new integration cloud.

When we click the edit pencil of the ‘Prepare Pizza’ step, on the right hand side, we get to see the properties of this step. Under the Process section, we select the ‘PizzaPreparationProcess’ and the ‘start’ as start event.


We repeat these steps for all the processes we want to call, for example to do the delivery we call the existing start event from the DeliveryProcess.


For human tasks, we have to set some more options than just the process to call. Here we fill in the information concerning the task. Like, to what role it will be assigned, we choose the presentation view and set a title. Basically the same properties you also fill in when calling a human task from a structured process.



Now that all the steps have been filled and are correct, we can deploy our application and check how this looks run time. Within the OIC deploying now has been renamed to activate. So lets activate our application. Clicking the blue activate button will bring us to the familiar screen formerly known as the deploy screen.



Once deployed we can start working on the instance, by going to the workspace. Within the OIC the workspace changed a bit as well, but the url is mostly the same, it can be found at: ic/process/workspace. The menu now looks like this:



Here we find a lot of familiar things. The My Tasks option will bring us to the tasklist. The Processes menu option is the one formerly known as instances. Here you find the instances of the structured processes.
The Dynamic Processes is the new runtime representation of the dynamic process, more on that later.
My Apps is the new place where you can start the different applications that you have deployed within OIC.
The Dashboard will take you to a graphical representation and gives you an insight about what is going on. More about this when we will blog about analytics within OIC.
Last but not least, the administration for changing settings concerning roles, credentials, certificates, purging, etc.

For now we will take a dive into the new Dynamic Processes option and explore an already started instance of our Dynamic Jarvis case.


The runtime environment looks different than what we are used. We get an overview of the progress of the case. We see the activities that we can start on the left and the form in the center. 
When toggling the the top component we can also get an overview of the stages and in the audit tab we can learn more about what happened to our dynamic process. 


From the left, we can start working on our process. Lets see what happens when we open the Register Order human task. 


We see that the form get started and this looks like the form that we know from the structured processes. Which makes sense, since it is the same task being reused. 


Now we can perform an action on task and see what happens to the instance. When closing the task, we get a confirmation that the action has been performed on the task. We also notice that it is gone from the activities and is no longer available to start. 


With the setting icon, we can change the filter of the activities, it is possible to look at the completed activities and they will show up with a green check that they have been completed. 


As you can see we get a good out of the box representation of the dynamic process. We can work on the process within the OIC and have an overview of what happened with the process. We see the progression and stages on top. Activities on the left and can drill in the audit trail. 
Now that we have had a look at the runtime, we can start modifying the flow. Now all the activities are becoming available at once and we can work on everything together. In the next blog we will show how to handle the stages. Work with milestones and use condition when activities can be started or are enabled. 



Jarvis Pizzeria: Setting up the Dynamic Process

In this blog we will implement a first version of the preparation of an order using a dynamic process. We continue where blog one stopped. The imported order process is extended with an example dynamic process.



We open the DynamicOrderProcess, which should still contains the example. We will build this so that it contains the Pizza ordering process. However, when opening the Process, we can see that the example is no longer there. Apparently, the example is not saved, maybe because we did not make any changes to it? Let's create the example again, and then change it immediately.

The first step we take to make it our own is to define the stages. Rename the 'First Stage' in 'Ordering'. The 'Second Stage' in 'Preparation' and add another third stage 'Delivery'.
For changing the name of a stage, select the pencil in the title bar to get to to properties.
In there change the name. Use the add icon just above the pencil to add the third stage.




Now let's save our changes and see what happens to this modified 'example’. We close the Dynamic process, and then open it again.
However, our changes have disappeared as well. The whole example is gone once again. How is that possible? Is something thoroughly wrong with the application or is an example application just an example, and can it not be saved? Anyway, it is good to realize the example application is there as an example and not like a QuickStart application.

So let's restart again. Now we will not create an example, but just add the different stages.
After doing this, yet again, let’s put it to the test. We save our application, close it and reopen it. Yeah! Alright! Now the changes persists, so it does have something to do with the example mode.



From here we will continue to build our dynamic process. First we will show the composition of the Dynamic Process and then we will explain how we come to this.



For the order phase we have chosen to only use a humantask. This is used to place an order. This is a mandatory activity in this phase. And it is also manually activated. When you select the activity and then click pencil this will open the properties of the activity.


Here we make the activity mandatory and say that it must be activated manually. We only want one order to create a dynamic process instance, so this activity is not repeatable. 


In the preparation phase we have three activities. The structured Pizza preparation process, which is repeatable for every pizza of the order. A milestone that is set at the moment that all the pizzas of an order are ready. And finally the human task that is started to prepare the order for delivery. The table below shows the settings of these activities.


Repeatable
Required
Manually Activated
Prepare Pizza
Yes
Yes
No
Prepared
No
Yes
No
Compose Order
No
Yes
Yes

Next we get into the delivery phase. In there we have the delivery process and the delivered milestone. The delivered milestone is set as soon as the order has been delivered and paid as well. The payment can take place during the entire process, from the beginning of the order to the final delivery. As soon as the payment has been made, the milestone paid is set.


Repeatable
Required
Manually Activated
Deliver
No
Yes
No
Delivered
No
Yes
No
Payment
No
Yes
Yes
Paid
No
Yes
No
The first rough design

So that is how you set up a dynamic process. It takes a couple of stages that host the activities, tasks and milestones and you can configure the details. There is still a lot more to Dynamic Processes then the simplistic overview we gave in this blog post, but we will get there step-by-step. How does these dynamic processes modeling compare to the on-premises ACM variant? In terms of features we covered in this blog post, there is nothing much new under the sun. But in terms of developing environment it is much more smoother. The on-premises case definition was unclear. It was hard to get a real grasp of your dynamic process without diving into both the case definition and the corresponding business rules. PCS on the other hand, gives you a comprehensive outline of your case definition. It shows you the stages, the activities, the milestones and the corresponding features (i.e. activities are required, repeatable, etc.) all in one overview! Although we haven’t covered the rules yet, we can easily say that setting up a new dynamic process is a piece of cake now! In the coming blogs we will discuss features such as calling the process & human task, the run time representation of a dynamic process, the activation or disabling of activities, different ways to start a dynamic process and many more.


VBCS: Create your Mobile Application

Now that we have set up a first stable version of our application within VBCS, it is time to explore the mobile capabilities of VBCS. It leverage the capabilities of MAX (Mobile Accelerator) and is build in to the VBCS platform.
This blog post will take you through the basics of the functionality.

We start by sharing our application resources of the build VBCS web application. In the security properties we toggle to enable Resource sharing.



Once this is done, we go to the home screen and create a new mobile application.



This action will open MAX within VBCS. In the create application wizard we choose the
Screen with Top Tabs as basic template.



In the next step we can give the application a name (Screen Title) and already configure how many tabs we want the application to have and specify the names. Lets start with the Tracks and Speaker page from the earlier created application.



In the next step of the wizard, for the content we select ‘List Content’ as screen.



We have completed the wizard, so lets click the green ‘Create’ button to create the mobile app.



On the next page, we want to add data to the generated app and page, so we choose the ‘Add Data’ option.



For this we need to select a layout again, so to display the data it feels ok to add 4 fields per row on the page, we select the top right option and press Next.



Now that have selected how to display the data, we need to select a data source. Remember that we turned on the share application resources as first step of the blog? We are now going to add the application here to use the resource. Select the ‘Add Application’ option.



In the next screen we select the app we want to use:



And after that we can select business objects from that application.



After Drag & Drop’ing all the fields we want to show. You can see the data in action, by pressing the ‘Live Data Preview’:



With this we also completed the wizard to add the data to the screen and we can press finish to exit the wizard.



The phone app now looks like above, but we want to add a detail screen to this page. So as you might expect we need to select ‘Add a Detail Screen’.



In the wizard/train I select a simple screen, enter ‘Track Details’ as title and select form content.
After this we go to the detail screen and again select the ‘Add Data’ option.

Now we go through the wizard again, to drag & drop fields on the form component, but as you can see we drop more components on this form then on the previous layout. In the parent page we had a form that displayed 4 fields, here we are going to show more details:



After setting up these two pages, we still want to change the icon for our app. So go to the Application Settings. There we find the application icon and we change it to our desired logo.



Now we can run our app in the test mode. We can select the layout and the phone.



However, you can also ‘Test on Phone’, by pressing this button, a QR code is generated.



This QR code enables you to test your application on your phone. You need the MAX app for this. However, this is a clever trick by Oracle. You download the special MAX app and then add your application by scanning this code.
This way you can actually test the app on your phone and see the native behaviour, but you do not need to go through the trouble of getting your app accepted on either the play store or the app store.
A great way for easy testing on your phone!