This blog entry is part of a series of blog entries on Slipstream, an SAP Research prototype for Business Activity Management for SAP NetWeaver BPM. It is a follow up on last year’s blog entry and extends beyond mere monitoring.
This article deals with event consumers, i.e. systems that should able to understand and work with events produced by a CEP engine to complete the full circle of business activity management. While the article focuses on dashboards and SAP NetWeaver BPM to receive events, other event consumers are conceivable such as other BPM engines, other CEP engines, or – as that matter of fact – any system that has an open interface.
To make the data which is processed within the CEP engine available to external systems, we developed a Slipstream Aleri Connector which provides an interface which can be used by different components of the Slipstream environment.
The most apparent event consumer in a BAM scenario is the reporting dashboard. In the Slipstream architecture, we use Xcelsius for visualization. Xcelsius enables the users to create dashboards based on Excel spreadsheets. Data in the spreadsheet can be retrieved from external sources at runtime in form of an Xcelsius-specific XML format. Slipstream uses the Aleri Connector to convert the calculated figures into the Xcelsius XML format and to provide it for remote use.
SAP NetWeaver BPM is not only a producer but also a main consumer of events. SAP NetWeaver BPM has the ability to access calculated data from the CEP engine, e.g. to control the process flow at gateways in running processes or of future process instances by changing decision tables or variables at decision gates. But it can also receive events to start new instances, suspend, resume or cancel running instances with the help of Web services.
This requires that all variants, which are to be executable based on event information, have to be available at build time (i.e. when the process is deployed). SAP NetWeaver BPM – similar to most BPM engines – does not allow process alterations without undeploying and redeploying the model. The below BPM model includes two variants (standard and express) which can e.g. be executed based on average order durations of the day (to meet overall SLA) or the actual running order process (to meet this specific SLA). The gate value is changed dynamically.
Unfortunately, at this stage in practice it is currently not possible to control an arbitrary BPM engine with standardized events to behave in the desired way.
Other extensions of Slipstream include connection plugins for Twitter, Sipgate SMS, and email. Also, as mentioned in Part 3 SAP NetWeaver BRM which can be used within the CEP models. It is also possible to make the data available on mobile devices in real-time through Web pages or native apps.
In order to make this introduction to business activity management with SAP NetWeaver BPM more visual and concrete, we will flesh out and conclude the series with an example that shows how to start, cancel, suspend and alter running processes of SAP NetWeaver BPM and visualize the information on a dashboard.
Slipstream 2.0 has been a collaborative effort which could not have been done by one person. The current prototype has been developed in a collaboration of the SAP Research Center Brisbane in Australia with the European Research Center for Information Systems (ERCIS) at the University of Münster in Germany. The project team consisted of Felix Leif Keppmann, Jan-Philipp Friedenstab, Stefan Thiemann, Marcel Walter, Thomas Raffelsieper, Robert Malsch, and Bernd Schwegmann. The project was supervised by Martin Matzner, Oliver Müller, Prof. Dr. Jörg Becker, and myself.
If you have questions or application scenarios you would like to discuss, don’t hesitate to contact me. We are looking for that kind of feedback all the time.