If you could open the lid on any SAP component in your production system, you'd find that it is positively humming with events. Although events might, at first glance, seem a bit of a mystery, they are quite real, they are useful, and they influence the way your SAP components run.
As you may know, one of the distinguishing characteristics of an event, like the placing of a sales order, is that the application in which the event takes place (the CRM solution) does not require information about how the event will be used in other applications. In fact, that event may not be used by another application at all. Like radio waves that fill the ether, events are out there, and your applications are not aware of them until they are "tuned in" to the right frequency.
Likewise, events are a critical part of SAP business process development, and can act as the trigger for your workflows. But unless a workflow is set to receive (or "subscribe to") the event, it simply vanishes without a trace - just like a radio signal that no one tunes in to (see Figure 1).
In this article, you'll learn how WebFlow tunes in to events so that your business processes are synchronized with the mySAP applications that raise the events. What's more, events can also translate into more reliable and robust workflows.
||Events Can Be Raised With or Without Receivers
Some Background on Events and Workflow
WebFlow technology ties business processes in to events via a publish/subscribe mechanism: the events are published by the triggering application, and the workflows subscribe to them.1 This approach is very efficient: the events themselves carry very little information, other than an event name and a reference to the object that is related to the event. However, this is all that is needed. Keeping the data to a minimum keeps interfaces slim and easy to use, without taking a toll on system performance.
For example, the Sales Transaction Created event published by the CRM application carries the information that an order has been created, along with a reference to the newly created order, so that any workflow that subscribes to this event can process this particular order. If the workflow needs additional data - which it almost certainly will - it can query the database record of this order to extract what it needs. But the database key of the record is all that is needed to make the query, and this is exactly what the event carries.
How Do You Locate the Right Event?
You'll need the exact name of the event in order to link it to your workflow. Events are catalogued in the Business Object Repository (BOR - transaction SWO1) to make them easy to find. The BOR stores reusable objects for business processes to help developers design and implement business workflows. Each business object in the BOR includes the information needed (interfaces, key fields, attributes, methods, and events) for the modeling of a common business process.
The BOR allows you to search for SAP event definitions using simple textual queries or the hierarchical directory of components. No expert knowledge of the application, such as transaction or report names, is needed to find the event. By typing in "sales transaction" in the text query in the BOR, you would arrive at a list of business objects for order creation shown in Figure 2.
||The Sales Transaction Event in the Business Object Repository
In our example, the Sales Transaction Created event goes under the name BUS2000115 Created.2 The "BUS" prefix is part of the BOR namespace that indicates that this object has business relevance. The underlying object definition also contains release-status information, which reflects whether the object type has been released for general use.3
How Are Events Raised?
An event is typically raised when the status of something changes, such as when business objects are created, deleted, or changed significantly (e.g., released, blocked, approved, or revoked).
Applications can raise events directly - completing a time-sheet always raises the Time-Sheet 4 Completed event - or via a generic mechanism, such as change-document management, HR info-types, or status management. These generic mechanisms are useful because they allow you to add your own events without modifying any application code. In fact, in the BOR, you will find at least six different generic methods for raising events.5 For more information on these generic methods, see SAP Library help.
The Main Types of Events for Workflows
From the workflow perspective, it helps to think of events in two groups:
- Triggering events, which spawn workflows: Sales Transaction Created can start a workflow to make sure the order is processed properly.
- Terminating events, which terminate parts of a running workflow or confirm that a workflow step has finished: Applicant ConfirmedInterviewDate finishes off the part of a recruitment workflow that deals with the interview and allows the process to move on to the next stage.
When you look at the way an event is raised or how it is defined in BOR, you cannot tell whether it is a triggering or a terminating event. The distinction between the two types simply reflects how a workflow uses this event. Indeed, a single event can simultaneously be both a terminating event (ending one process) and a triggering event (starting a new process). Nevertheless, when talking about process modeling it helps to make this distinction.
Subscribing to Events to Trigger a Workflow
The most common reason for subscribing to any event is to start a workflow. The event will carry the reference to the business object that triggered the event (i.e., the Sales Transaction ID) so that this can be processed in the workflow.
Some technical information is also passed to the workflow, such as the user ID of the person who triggered the event (the customer service representative or customer). The user ID is often helpful later on in the process for sending notifications or alerts or for determining responsibilities, such as the manager or cost-center of this user. Depending on how the event is raised, the event can carry additional information to the workflow, but this is more the exception than the rule - the reference to the original business object is usually all that the workflow needs.
The workflow subscribes to a triggering event via a switch called the event linkage. The switch is activated or deactivated from the Workflow Builder or from customizing transactions (SWE2). Often conditions are embedded in the event linkage, so that the workflow is only started in certain circumstances. The conditions are defined using the condition editor (SWB_COND) and can be as complex as you require. (Thanks to a suggestion from one of our user groups, there is also an event queue, described later in this article, to protect your production system from incorrectly modeled workflows or transport damage. This, too, is activated in the event linkage table.)
Event linkage is at the heart of the publish/subscribe mechanism, and in addition to the performance advantages, it also makes it easy to:
- Commission or decommission workflows
- Trigger several workflows using one event
- Trigger workflows conditionally
- Link workflows to business applications without modifications
- Isolate the business application raising the event from any side effects of the workflow
For further information on these features, visit SAP Library help.
Workflow tasks that require a terminating event to signal that the activity is finished are asynchronous tasks. For these tasks, you do not have to activate event linkages because the workflow action is only terminated when a particular event instance is received. So the system is designed to expect the event, and event linkages are created for you the very first time a terminating event is expected.
Once the customer has placed the order, it is processed and then released. If your workflow is set to wait for the confirmation that an order is released before it can move on to the next step, it will only proceed when the particular order that it is processing is released (signaled by the event). In other words, when order number 4711 is released, the workflow processing of order 4711 can continue, but not the processing of order 4712.
In contrast with a triggering event, which always triggers a new workflow every time an Order Created event is raised, terminating events like Order Released are always waited for - the WebFlow Engine expects them.
Now that you have been introduced to the powerful impact of events on your business processes, the next sections introduce you to other ways that events can lead to more robust and reliable workflows.
Events to Synchronize Multiple Workflows
With or without a workflow, business processes in your company will work in parallel, synchronizing with other processes (assuming you have more than one employee). So it is essential that the workflows that automate these business processes can do this, too.
You not only can use events to synchronize workflows with applications, you also can use events to synchronize different workflows with each other, or even to synchronize different parallel branches of one workflow with each other.
Adding "wait" steps to a workflow definition will ensure that a branch waits for a terminating event. You can add event creator steps to a workflow, to allow that branch to raise events that are used as signals to other branches or other workflows. This is a powerful mechanism, and it is essential for creating robust business processes.
One additional synchronization feature is the ability of the complete workflow to react to a particular event. The workflow can be configured (basic data settings) to restart, abort, or even to re-execute the agent-determination rules so that work items are re-assigned.6 This gives you an idea of the richness of the event-integration in the WebFlow Engine.
Built-In Fault-Tolerance with the Event Queue
From Release 4.6C, you should always make use of the event queue. In high-volume situations, the event queue will help manage the flow of events through the workflow, and will spread the system load by releasing the events from the queue over a longer time interval. This does cost a little performance, but it prevents the system from choking when many thousands of events are created in the space of a few seconds by a batch job.
Using the event linkage settings (transaction SWE2), you can configure an event queue for each event/workflow. With the event queue on ("Enable Event Queue"), you adjust the system load for that particular event linkage.
In low-volume situations, the event queue should be switched off, for that particular event linkage, as in the settings in Figure 3. However, even when it is off, the queue is used indirectly if an error occurs, such as when an incorrectly modeled workflow is transported into the production system.
||Diagram of Event Linkage (Transaction SWE2)
Typically, you would set the flag "Behavior Upon Error Feedback" to "Mark linkage as having errors," so that as soon as an error occurs, the event linkage for this workflow is switched off, preventing unstartable workflows from being triggered. This event and all subsequent events of this type are now diverted to the event queue, and the workflow administrator is notified of the problem with an email alert.
When the workflow definition has been corrected and the event linkage is switched on again, the buffered events are released out of the queue one at a time, as if nothing had happened. This is done using the Event Queue Administration Transaction (transaction SWEQADM), which you can see in Figure 4. The data carried by the event is also stored in the event queue, so no information is lost.
||The Workbench Queue Administration Screen in the Workbench
If the workflow sporadically fails to start, the source of the problem is most likely to be timing or locking problems caused by a poorly modeled workflow. In this case, the setting "Do not change linkage" is more suitable, because only the events that fail are added to the queue, but the other events pass through unhindered. As in the previous case, you can release these events via the administration transaction SWEQADM later.
For pre-4.6C systems, see "Tips for Fault Tolerance in Pre-4.6C Systems" below.
Event Logs to Help Debug Faulty Workflows
For debugging purposes, you can switch on the event log (not to be confused with the event queue), which simply writes a log of the events as they are triggered.
You should not switch this on in a production system unless you use a filter7 (like the Event Trace filter "Restrictions for trace") to specify a particular event to log. The log will not only show you the event that is raised, but also the receivers that subscribed to it (such as a workflow) and whether the receiver reacted. If a start condition is evaluated as "false," the workflow is not triggered and the failure is logged.
Without events, your business processes would simply bulldoze to completion, irrespective of the dynamic environment in which they run. Although there is an element of mystery about the events being triggered in a mySAP.com component, SAP has gone to great lengths to provide the tools needed to make them robust enough for a production environment. The simplicity of the publish/subscribe mechanism and the ability to handle both triggering and terminating events is what makes it so easy to use WebFlow to perform complex synchronization between the business processes and the applications that the processes are driving.
Tips for Fault Tolerance in Pre-4.6C Systems
If you are using an R/3 system older than Release 4.6C, you do not have the luxury of this kind of fault tolerance. Develop your workflows as robustly as possible and take great care over the first step in the workflow. If the first step cannot be created, the workflow will fail and the event linkage will be disabled to protect your system.
You can help ensure that your workflows stay up and running by taking a few important steps:
- Make the first step robust by avoiding agent-determination rules lacking defaults.
- If you are likely to suffer from dirty data from legacy systems, make sure that the first workflow step does not depend on this data.
- Above all, make sure that valid workflow administrators have been configured in the customizing transaction SWU3, because all administrators are alerted by an email if the system deactivates an event linkage.
1 Incidentally, in SAP terminology, subscribers are also called receivers.
2 This is true in a CRM system. In an R/3 system, it will have the ID BUS2032.
3 ABAP objects also raise events, but because no universal business directory exists, these events are usually technical in nature and not relevant to business processes. From Release 6.30 they can be used.
4 BOR ID bus2075.
5 If you still cannot find a mechanism for raising your particular event, you can always use a Business Add-in to raise it directly. For documentation on this procedure, see SAP Library help.
6 Available from Release 6.10 of the Web AS.
7 Available from Release 4.6D.
Alan Rickayzen is the Product Manager for WebFlow. He has been with SAP since 1992 and in data processing since 1988. In 1995, he joined the SAP Business Workflow group, performing development work as well as consulting for various major US customers, and as a result amassed a good technical knowledge of the product. In 1998, he moved to the area of workflow product management. Alan Rickayzen is coauthor of the book Practical Workflow for SAP, available at http://store.sapinsider.wispubs.com, and may be contacted at email@example.com. SAP customers can access more information on WebFlow at http://service.sap.com/webflow.