Using events in Business AutomationWorkflow Part 1

I love event messages and the flexibility they can bring to an IBM Business Automation Workflow. In a few short blogs, I will share some of the use cases and ways I have leveraged events in workflow implementations.

Photo by Jonas Von Werne: https://www.pexels.com/photo/multicolored-fireworks-2897462/

In this blog series, the technical implementation will focus on using Undercover agents using the Asynch queue and UCA services. You can explore the technical variations that vary the delivery modes or the triggering mechanisms, but these are not the focus of this series. Here we will focus more on how I have utilized events and the built-in workflow nodes that support the event-driven interactions.

Over the series of articles, we will provide simple examples based on actual use cases that will examine various ways to use events. The scenarios we will explore will include

1. Starting and Ending processes using events
2. Timer Event usage
3. Throw and Recieve Error Events
4. Sending and receiving message Events
5. Utilizing Event gateways
6. Event Subprocess

Most of the events from the designer palette are self-explanatory in their name, so we will not spend much time explaining but dive into the example and scenarios of when we use these events.

Figure 1 Events Icon definitions

Events are triggered on a process using a construct called undercover agents (UCA). The UCA passes data to processes through a service or variable. The UCAs will use a service in the example used in this series. The three steps to defining the UCA and Service Flow are;

1. Define the Undercover Agent choosing from schedule types of Timer or event.

Figure 2 Defining an Undercover Agent

2. Define the service details by clicking the "New" or "Select" buttons to select the service. The Service parameters in the service will automatically map to the parameter Mapping.

Tip: Use a wrapper object in the event service flow parameters. This will mean that if the contents of the object changes the event definition remains the same. If many individual parameters are defined in the service flow changes can require a cascade of changes. 
When working with events that require correlation keys the service flow would include the correlation key and the wrapper business object.

Figure 3 Define the Service Details

3. The service flow pattern is typically a pass-through flow with input and output parameters matching

Figure 4 Service Flow with Wrapper BO as input and Output

Starting and Ending Processes With Events

Starting processes with events is common. It is an excellent way to reduce orphaned processes (1st step started but never progressed); it can also be an easy way to separate phases of a process and decouple processes across business lines.

Let us start with the simplest of examples. We will complete a starting data collection form from a Client-Side Human Service, and once complete, we will start the process.

1. Define the start event. This example uses the event detailed for creating the above event. In this case, we have a StartNewRequstUCA and NewRequestUCAService.
2. Now define a process that has a start event with the event mapped to the StartNewRequestUCA. The event variable should be mapped to the process variable and subsequently mapped or passed to process activities. By checking the "Consume Message.".

Tip: Keep in mind process design best practices by not keeping really large process variables. Process variables should be small business objects or key objects that hold key data to lookup more complex business objects.

Figure 5 Shown here is the Start Event With the UCA

Figur6 Map the Inbound event Variable to Process Variable

3. From the Client-Side Human Service (CSHS), we see the CSHS definition, and it makes a service call to invoke the event passing the business object data captured in the UI.

Figure 7 shows the Simple UI and the Service Flow call that maps to the Send Event.

Note: One downside of this 1st step outside the process pattern is that the time spent on this step is not measured. You could consider measuring this and sending the information to be captured as a part of the event data submitted and later captured this as tracing data.

Each event scenario has an event Reciever and an Event Sender modeled; in terms of execution, this can mean multiple processes receive and process the event. Another thing that should be clear is that the configuration and execution of events are relatively simple and have low code. As we explore more use cases, the flexibility and ability to decouple work should become clear. It can be a brilliant design choice to break larger processes that include sub-processes using events; it allows for simpler isolated testing and allows different business groups to evolve their sub-process variants independently.

Let's now examine ending a process with a send event. From the ending process point of view, there is no impact except that the last action is to send an event. Use cases for End events are to rejoin a waiting process or start a new process. In Figure 8, I show a scenario where a process sends an intermediate event followed by an event gateway that splits into a timer event or a response event. We will discuss the event gateway later for those unfamiliar with it. In this illustration, all you need to understand is that one of the two event options occurs. Once one occurs, the system stops waiting for the other and moves on to the next activity.

Figure 8 Using the End event to return to waiting for the creator process

In Figure 9, we illustrate the more straightforward starting of a new process when the end process event occurs.

Figure 9 The ending first process triggers and starts a new subsequent process.

In our simplified example, again, no actual coding; the developer creates the UCA, and the UCA Service defines the parameter object to pass and map to the event and data mapping definitions.

Figure 10 If the Status is Set to Investigate the Launch Start Investigation event triggers.

In the example, a user outcome initiates the end event; this could easily result from rules or data analysis outcomes.

Timer-based Events

Before we launch into intermediate message events and some more complex scenarios, we will discuss timer events. There are two supported mechanisms, the intermediate timer event, modeled as a process step, or the boundary event on an activity, and the Timer-based UCA.

I have rarely used the intermediate timer event, which causes a delay. One scenario I did observe was when working with out-of-process activities that are known to take a longer time. The timer event injected into the flow delayed starting of the next task allowing for activities outside the process to complete.

Figure 11 Intermediate TIme Event Configuration

The "Use the process work schedule" checkbox is worth noting that the Timer will pause when outside of scheduled work hours. Figure 12 illustrates this by reflecting that the Timer started right before lunch in the work schedule will pause, changing the effective timer duration to be 4 Hours.

Figure 12 Use the process work schedule.

Figure 13 Boundary Event Timer

Similar to the intermediate Timer the boundary event timer can link to the activity work schedule and when using timers.

Tip: Using the work schedules is recommended.Good practice is to also standardize the units for timers across your process then use variables and extranlize the values of timers so they can be dynamically modified without having to change code.

Additional, in the boundary event, are two properties that need discussion. These properties apply to timer and message boundary events; these are

1. Interrupt Activity, when checked and the event occurs, the activity that the event is attached to will be interrupted, and now the process will proceed following the boundary event branch. For example, after three days is not complete, the task is automatically escalated.
2. Repeatable, when checked, this means that the event can occur more than once. In the case of a timer, it will repeat based on time, or in the case of message events, multiple messages will be sent/received. For example, if the activity remains incomplete, send an email reminder to the assigned user every day.

It should be obvious but an boundary event cannot be simultaneously Interupt and Repeastable.

As mentioned above, a timer UCA is another type of timer event. Time-elapsed UCAs set up repeatable schedules, which are very useful in triggering repeated processes that must run at set periods. For example, monthly report processes.

Figure 14 Time Elapsed Events

Figure 15 Scheduler and Schedule Details of Time Elapsed UCA

Conclusion

In this first blog, we have established the basics of events and highlighted that they could introduce flexibility and support the decoupling of processes. Also shown is that they are largely low code and configuration driven regarding the triggering and executing of the events within a process. We examined the most straightforward events, the start events, end events, and timer events. We will explore intermediate messages and message boundary events in the next blog.