Implementing Order completion using a Timer
Let's implement another phase of the process: Closure.
Think about the lifecycle of an order, and the fact that its status will eventually go to Closed (or Cancelled, which we will deal with later). Of course, we could build a UI experience for someone having to close the order... and perhaps it will be set to Closed through some other way, but perhaps this isn't really a thing a user should worry about doing manually. Let's say that the requirement is that an order will stay in the state of Delivered for some period of time, then it will automatically become Closed. It turns out that it's very easy too have our Order Lifecycle Process take care of this by having a flow from an element called a Timer.
Adding the Timer
Here are the quick steps. Remember that you can always get more information from the documentation - if needed please refer to Adding a Timer element to a wait step.
The logic goes like this:
- After the existing Notify Submitter of Delivery, the process should wait until the Order becomes Closed. Nothing new here - we just use the User Task again.
- This User Task should time out using a Timer element that is dragged onto it. For quick testing purposes, we can set it to something small, like 1 minute.
- The flow from the Timer means that after one minute goes by, it can branch to some other path. In this case, we will flow to an Update Record activity that will force the Order record into a state of Closed.
The new steps of the process look like this:
The Wait for Closed Activity is standard stuff for us now - just configure it to use Existing Record, the order's ID, and a Completion Criteria that uses the Wait for Closed > Status to be >= "Closed".
Since the user may never explicitly close it, we can ensure it closes by drag a Timer onto the border of the activity. Set the Interval to 1 minute just to make this easier to test.
Add drag and configure the Update Record activity. This one is very easy and is an activity we already used in the quick start exercise.
- Specify the Record Definition Name and ID for the order.
- Add Status to the Input Map.
- Set the value expression to "Closed" (including the quotes).
Set the flows to the End element in each case.
That's it! You are ready to test it.
Testing
This time it's very easy because the application UI is not affected, so you can test it using your view (by the way, when you have only changed a process or a rule, there is normally no need to refresh the application page or preview).
To try it, create a new Order and set it to Delivered using the UI. About a minute later, refresh the record grid, and you should expect the Status to automatically change from Delivered to Closed (you will have to refresh the record grid to see the update).
What we learned
- You have learned how to use a Timer to effect a time-out during a process. By the way, this is the first of four ways a process flow can change dynamically (the others are Exclusive Gateway, Dynamic Call Activity, and Error End, and we will have a change to try all of these in upcoming lessons).
- Actually it's worth thinking about when the Timer can be used. It actually only makes sense to use it when the process is blocked, waiting for something. There are only a few things that cause this to happen; it is usually one of these cases:
- A User Task with some Completion Criteria
- A Receive Task (we haven't used this yet in this tutorial)
- A Call Activity to another process that itself blocks for some reason
Another more general thing to note from this: BMC Helix Innovation Studio is said to follow the Model / View / Controller pattern. This really just means that you can approach data, UI, and logic as separate things. Using the Timer this way is a perfect example of how you can enhance the application's behavior without touching the UI, because this behavior is fundamental to the business process and should be true no matter how users are interacting with it.