Thank you to Paul Pacholski, Stuart Jones, Dave Wakeman, William Snare for Exploring this Area and Providing Information About this Functionality As Well as Sample Configuration Steps.
Background
This paper addresses the concept of receiving SAP WF-events into a BPM Integration, where it is possible to analyse and process the incoming information, possibly after performing additional SAP-lookups to acquire more information about the document addressed in the trigger.
Possible processing steps could be for example to:
- Store information in an internal database or external System of Record, possibly via web services or additional SAP BAPI/ALE-calls.
- Send important KPI-information to Business Monitor
- Call a BPM-process with the retrieved information to start a designed process flow
Any combination of these suggestions is viable – as well as numerous other alternatives.
This document primarily addresses the concepts – and does not focus in detail on the separate steps required to configure SAP and BPM. This information can be found elsewhere – both on the Internet and from IBM.
SAP Workflow Events
SAP Workflow Events are defined as signals that inform you about the adaptation in the state of a business object. Events are defined in the Business Object Repository (BOR) as components of an SAP Business object type. It is possible to define any number of events for a particular object, and in that process use the BOR to view a list of events created for a particular object type.
It is possible to subscribe to these kinds of events – meaning that in practice it is possible to forward information about such triggering events to other applications – both local and remote.
Using this functionality, it is possible to provide non-intrusive monitoring of SAP object specific operations. The incoming events can be used for several purposes – one of the most useful purposes might be the possibility to retrieve KPI-information, based on business events.
Typically, the information in these kinds of events is limited. What can be expected is:
- Object type: The name of the Object type whose event is generated. Sales order is for example BUS2032, Maintenance Notification is BUS2038 and the object type for Accounting document is BKPF.
- Object key: The unique identification of an object. In the example below the Sales Order document number of the created order is 14476.
- Event: the event in question (CREATED, CHANGED, aLECreated…). This information can be found by using the BOR browser (SAP Transaction code SWO2)
- Receiver Type – typically workflow template, for workflow linking, but purely informational in the monitoring context discussed in this document. The connection between the event and the receiver type is maintained in SAP Transaction code SWE2.
<Event>CREATED</Event>
<Objkey>0000014476</Objkey>
<Objtype>BUS2032</Objtype>
<Rectype>RECV_INVOICE_E</Rectype>
- In addition, it is possible to provide custom data in a provided table in the structure – the EventContainer. Primarily this is a property/value relation, where it is possible to specify the data type and length of the value. BUS2032/CREATED – among other table entries – provide date/time of the event as well as the user and SAP Transaction code involved:
<SapEventContainer>
<Element>_EVT_CREATION_TIME</Element>
<TabIndex>000000</TabIndex>
<Elemlength>006</Elemlength>
<Type>T</Type>
<Value>102546</Value>
</SapEventContainer>
<SapEventContainer>
<Element>_EVT_CREATION_TIMESTAMP</Element>
<TabIndex>000000</TabIndex>
<Elemlength>008</Elemlength>
<Type>P</Type>
<Value>20151104092547</Value>
</SapEventContainer>
<SapEventContainer>
<Element>_EVT_CREATOR</Element>
<TabIndex>000000</TabIndex>
<Elemlength>014</Elemlength>
<Type>C</Type>
<Value>USJHELLSTROM</Value>
</SapEventContainer>
In addition, it is possible to trigger events programmatically in ABAP, but it falls outside of the document scope to delve into this area.
Typically – however – the information provided in the trigger event is just meta information about the business event. For example, it is not possible to see the order items or amounts in the Sales order. If the information requirements include additional details, it would be possible to lookup this information as a result of the trigger.
How to Subscribe to the SAP Workflow Events
Connections
The triggered events can be sent to specific SAP RFC-destinations – as specified in SM59, using for example TCP/IP connections. This allows integration (EAI)-functionality, like what is provided in IBM BPM Advanced, to register a synchronous BAPI-listener in Integration Designer. When the functionality is deployed/activated, the listener will connect to a SAP Gateway and register its RFC Program ID.
Typically – assuming the name of the RFC Program ID is “SESalesJHEvent1”, one will see the following status changes of the listening BAPI thread:
serverStateChangeOccurred Server 9.153.164.205|3310|SESalesJHEvent1 changed state from [STOPPED] to [STARTED]
traceServerInfo Server 9.153.164.205|3310|SESalesJHEvent1 obtained. Number of connections - 1
serverStateChangeOccurred Server 9.153.164.205|3310|SESalesJHEvent1 changed state from [STARTED] to [ALIVE]
The important configuration parameters when connecting the SAP Transaction code SWE2 event type triggering to a BPM Advanced Integration flow are:
- An RFC-Destination with Program ID “Program ID X” must be created in SAP Transaction code SM59.
Depending on the chosen Implementation pattern – addressed below in the chapter “How to Organize and Deploy SAP Triggered Event Integrations” it is possible – in its simplest form – to create the RFC-Destination once and reuse that destination. It is also possible to create one RFC-Destination per business object type. It depends on the implementation scenario decided upon. - A BAPI-Listener with Program ID “Program ID X” must be created in Integration Designer.
The number of BAPI-Listeners for a specific “Program ID X” can be one or more. The important thing is that there should be at least one available “Program ID X” per RFC-Destination I SAP using that particular Program ID. In the simplest of setups, only one listener is required. - An Event Type Linkage must be created in SAP Transaction code SWE2, which should point to the aforementioned RFC-Destination.
An Event Type Linkage must be created for every new Business object type.
Depending on the chosen Implementation pattern – addressed below under chapter “How to Organize and Deploy SAP Triggered Event Integrations” it is possible to create the RFC-Destination once and reuse that destination. It is also possible to create one RFC-Destination per business object type. It depends on the implementation scenario decided upon.
Development Pattern
A typical scenario in IBM® BPM for SAP includes transferring the details of an SAP business object to an SAP event and then triggering other actions in IBM BPM. Integration Designer – the development tool to be used during Integration creation – provides an SAP event pattern that bridges this gap and facilitates the receipt of message events from SAP modules based on existing SCA interfaces.
The SAP event instance provides the following key components:
- An inbound adapter that receives the business object that corresponds to the SAP event. The business object contains the details of the SAP business object in the SAP event.
- An implementation to map the event information to the input of the SCA interface through a BPEL process
- An SCA interface to connect to arbitrary post processing, including – but not limited to -triggering an IBM BPM process.
When using this built in pattern it is assumed that a SAP Interface already should have been created – this can be further explored in other sources – and that some other kind of Interface (essentially a WSDL – Web Service Definition Language) should be available.
The pattern assumes that the incoming SAP message is to be mapped into a narrowed down business-related structure and thus that some kind of mapping is to be performed. The pattern will thus ask for the SAP Interface and the SCA (Systems Component Architecture) Interface and create an initial BPEL-component as well as an SCA-import and connect them with the SAP component in the Assembly Diagram.
Note: this pattern in the Patterns Explorer is more an illustration of the importance of this pattern. It is just as easy to create the separate components individually and connect them – and at times it could even be preferable in order to fit into a specific design pattern.
How to Organize and Deploy SAP Triggered Event Integrations
There are some important items one should consider when creating BAPI-listeners in the Integration Designer:
- It is possible to have many listeners – for the same or different events – in one module. However, this means that when bringing down the specific deployment for maintenance, all listeners will be deactivated. At times this could be useful – at other times it could be contra productive. Of course it is also possible to separate out listeners and logic into separate modules depending on factors such as the nature of the integrations (for example HR, FI..).
- It is possible to separate modules (and deployments) and make certain that the SAP Listeners and the logic are separately managed. This could be advantageous if one wishes to separate communication layers from logic layers.
- It is possible – since the incoming SAP Event Triggers use the same BAPI-structure regardless of business object – to just use one (or more, should technical or logistical reasons so dictate) SAP BAPI Listener functionality for all incoming SAP-events. If this approach is deemed reasonable, one would need to route the incoming message, typically depending on Object type (business object) and receiver type (linking) information. This would make it possible to maintain routing information in a database or another System of Record.
This approach could prove beneficial if one wants to minimize the integration effort required for developing new incoming event flows, since SAP BAPI Receiver exports do not have to be created for each new business object type. By using a routing functionality, one would also be able to implement the associated business logic elsewhere (like SAP PI or as a BPM Process Definition). Separate business logic of course needs to be developed for each Object type. - If many integrations are to share Interfaces and Business Objects, it could be worthwhile to separate those objects into a Library. The SAP Adapter Wizard allows for this and it makes certain that the generated artefacts can be reused.
- The SAP-adapter itself can be deployed either with each module or centrally. In the latter case it means that all SAP-related functionality would share the IBM BPM Advanced SAP Adapter. This would be beneficial that the actual deployed functionality would be smaller and thus have less memory impact. The advantage of including the SAP-adapter with each deployment (one or more SAP-related Integrations) is that it could be possible to try out different versions of the SAP-adapter should fixes become available or a step-by-step migration is to take place.
Before commencing on a high-scale SAP triggered event integration approach, it could prove beneficial to form an opinion on how to design development/test and production environments based on a deployment architecture.
Business Monitor and KPIs
Both tooling platforms: Integration Designer (Integration) and Process Designer (Process development) have powerful support to create and work with Business Monitor Models. It would for example be possible to monitor technical information, such as how long time it would take to perform an SAP lookup as a result of the trigger, in the Integration and forward the business data to Process Designer for further KPI refinement.
The Monitor Models include information of what event information (for example SAP event triggers) to take into consideration, how different instances should be considered and what information is to be used to trigger an instance, as well as defined KPIs and much more. The Monitor Models are represented as Java EE deployments and are to be deployed in the separate Business Monitor runtime.
In Integration Designer – each time a module is updated with a new SAP event trigger that one would want to monitor; the existing Monitor Model needs to be regenerated and redeployed. This would not necessarily mean that all customization performed in a previous model will be lost, since there is an “update”-functionality available, which will keep manually entered information, such as metric definitions and instance stop information.
IBM Business Monitor displays the events in web-based dashboards, such as the automatically generated diagram showed below. This diagram can be automatically generated by IBM Business Monitor based on a global view of the monitor model, and can quickly depict SAP transaction flows without a major development effort.
A choice can be made to deal with Business Monitor models either during Integration execution or during process execution – or both. The graph below comes from Integration Designer business modelling and displays one of the standard KPIs: average duration. Two widgets are defined for presentation, but many more are available.
These same capabilities in IBM Business Monitor that deliver passive process analytics and characterization, also provide easily configurable real-time active monitoring for SAP.
There are external sources that further explain the technical steps necessary to establish an Integration Designer monitor project, create the artefact used for Business Monitor deployment and how to access the Business Space in order to configure widgets and analyse instance data.
