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.

After I detailed a lot of details of how we enabled business activity management for SAP NetWeaver BPM, this article sums it all up and applies it in an example case.

The intention of the scenario is to simulate a perfect order process. It consists of two parts: Order capturing and order processing. Order capturing comprises order reception, a check for credit worthiness and a check for availability. In case of exceptions, a sales manager has to intervene and may redirect the control flow of the process. After the order is released, order processing begins. A picking list is created for picking the goods and checking the picking result. Afterwards the goods are packed and shipped. We use two different shipment types. Express shipping is more expensive but faster than standard shipping. The different shipping types allow for staying below or close to the threshold of the average processing time of an order defined in the SLA. The evaluation in the gateway relies on external data that is calculated in real-time over multiple process instances.

image

We decided to include the following key performance indicators in real-time to be able to judge the processes performance. These include:

  • Process and task runtimes and counts (over multiple instances)
  • Perfect order rate
  • Process context/ business data such as ordered items
  • Sales target prediction

And apart from historical data, we want to be able to access external data source such as a CRM system to include complaints. In order to calculate the scenario, we implemented the queries for the KPI in Aleri:

image

This massive graph however does more than the calculation of KPI. It can also detect patterns such as duplicate orders and use SAP Business Rules Management to look up definitions of critical order and prediction thresholds which can be centrally managed.

The business activity management implementation is also able to perform process manipulations such as control flow adjustment and the suspension of process instance in case of detected patterns. Also, it can do alerting and send notifications through channels such as e-mail, SMS and Twitter messages for promotion purposes.

Below is a link to the video that explains the concept, scenario, and showcases the solution.

image

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, or if you are an SAP employee and want to demo this yourself, don't hesitate to contact me. We are looking for that kind of feedback all the time. Slipstream will be part of the Innovation Weekend and Innovation Lab at TechEd 2010 in Berlin and Las Vegas. Hope to see you at TechEd 2010.

Keep in mind: Yes, it is a fully functioning implementation, but at this time it's a prototype with a few hiccups, not an official SAP product. Feedback, suggestions for improvement, potential collaboration? Please let the author know.

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.

image

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.

image

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.

image

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.

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 the event processor, i.e. the core of business activity management. While the article focuses on enabling business activity management for SAP NetWeaver BPM, other inputs and outputs are obviously also of interest to process execution as detailed in the following.

CEP makes use of an event processing network (EPN) which consists of a number of connected event processing agents (EPA). An EPA is an active component that monitors an event stream to detect and react on certain conditions. Its behavior is defined by a set of so-called event pattern rules. These reactive rules trigger on specific instances or patterns of input events. As a result of executing a rule, the agent creates output events and changes its local state. EPAs perform filtering, transformation (incl. aggregation, translation, enrichment, projection, split, and composition), and pattern detection.

Below you can see a sample EPA query that calculates the duration of a process by comparing start and end dates within a 24h window in the Continuous Computation Language (CCL):

insert into out1
select
      in_completed.process_instance_id,
      in_completed.completionTime - in_started.completionTime as duration
from
      in_started keep 24 hours,
      in_completed
where
      in_started.process_instance_id = in_completed.process_instance_id;

 

EPAs can e.g. also be programmed and can make calls to SAP Business Rules Management in order to evaluate complex events in decision tables. As NetWeaver is a service-oriented application the calls can made automatically generated Web services. Based the input parameters BRM generates output parameters which are sent back to the client which in our case is an EPA. Unfortunately, at this stage decision tables cannot be updated as they are not stateful. Thus, return values currently have to be kept in the memory to also allow consideration over several successive BRM decisions.

EPNs can get quite large. SAP BusinessObjects and Sybase offer Event Insight and the Aleri Streaming Platform to help manage the queries with a UI. On the left hand side you can see the Aleri Studio, on the right hand side you see the Event Insight Query Builder.

 

image

We implemented our scenarios in both Event Insight and Aleri. Both of them require a specific producer to understand the event format (such as BPAF) which can be received through a standard JMS implementation such as Apache Active MQ. Events are then translated into the internal relational format.

Business Activity Management with CEP covers a wide range of different processing scenarios such as the following:

Live dashboards and business activity monitoring of multiple BPM engines and/or of multiple servers/ companies is a challenging task if no pre-packaged solution is available. As more and more information, relevant to operating a business and making decisions, is available in near real-time the need to report this information in a timely fashion rises.

Explorative and predictive process analysis such as clustering, classification or association analysis can be implemented as well as simulation based on the input data stream to predict imminent bottlenecks or excess capacities before they occur.

Context-aware business process management and automated insight to action enable processes to react to events even outside their system boundaries. This can include weather (e.g. hurricane warnings) or traffic information (e.g. port or airport closures) for logistics processes or currency exchange rates for financial systems. All of this information can be used to cancel, suspend or alter running processes or start new ones.

The CEP engine provides the basis for all business activity management operations. However, only if the insights generated by the event processor of are consumed properly, the correct action can be taken. The next article will detail event consumption.

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.

+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 producers, i.e. systems that provide input to business activity management. While the article focuses on enabling SAP NetWeaver BPM to send events, other event sources are obviously also of interest to process execution such as contextual data from sensors or traffic or weather feeds.  *Enabling Event Sending*   There are basically two ways of enabling SAP NetWeaver BPM to send events: An automated and a more manual way. When using a standard SAP NetWeaver BPM server, at this time event sending can only be enabled manually. This means that event producing tasks must be modelled explicitly into BPMN models before and after the tasks to be monitored. This entails a lot of change in the models which can be inconvenient for model management but allows for the focussed positioning of measuring points. The following BPMN model is an example for that.image

Last year, I posted a Slipstream - Live Dashboarding for SAP NetWeaver BPM (“Galaxy”) on Slipstream, an extension to SAP NetWeaver BPM which allowed for real-time dashboarding, also called Business Activity Monitoring (BAM). In the last couple of months, we have not been sitting on our hands. We have worked on a new and more sophisticated prototype which is based on a complex event processing engine - as we suggested in the previous article.

The state-of-the-art of business activity monitoring primarily deals with the observation of events and the dissemination of results in terms of diagram/ dashboard updates, as well as alerting. However, automated insight-to-action is a much more compelling use case as it eliminates the decision latency. We extend upon the real-time concept of business activity monitoring by leveraging the capabilities of complex event processing to include decision-making and feedback mechanisms to the originating BPM engine or other systems. This effectively means that the complex event processing engine, in parts, manages rather than observes the execution of the business process. Hence, it is more appropriate to speak of Business Activity Management than of monitoring.

Best of all, the prototype is being finalized in time for TechEd 2010. So, in the next couple of weeks leading up to TechEd, I will explain what we did, how we did it, and what we can demo to you in the TechEd 2010 Innovation Lab and what you can play with at the Innovation Weekend leading up to TechEd on site in Berlin and Las Vegas.

The article series is based on the usual tripartition in complex event processing. In most CEP applications, there is a distinction among the entities that introduce events into the actual CEP system (event producers), the entities that process the events (event processors), and the entities that receive the events after processing (event consumers).

image

Consequently, part 2 of this small series focuses on the event producer: It will cover ways to enable SAP NetWeaver BPM to send events that can be picked up by an event processing engine and discuss options and limitation of process event formats.

Part 3 focuses on the event processor: It will cover ideas on how to use SAP BusinessObjects Event Insight (formerly Live Enterprise) or Sybase Aleri Streaming Platform and include use cases with options for event filtering, aggregation, analysis, prediction, and federation of multiple BPM engines.

Part 4 focuses on the event consumer: In the past this has been Xcelsius for us. But serving mobile devices with real-time HTML5 dashboards is also compelling. However, there is more to BAM than dashboarding. The article will list other channels such as alert notifications and more importantly the roundtripping of data back to SAP NetWeaver BPM to make the process pro- and reactive in real time.

Part 5 combines all of the above in one integrated scenario.

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.

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.

Slipstream is a research prototype by SAP Research in Brisbane, Australia that enables dashboards with live information from SAP NetWeaver BPM ("Galaxy"). A slipstream (dt. Windschatten) is a region behind a moving object in which a wake moves at velocities comparable to the moving object. Similarly, process information resides in the wake of the current process state. We make it available in real-time for visualization and further analytics and alerting.

When analyzing the possibilities of getting data out of NetWeaver BPM 7.20, we identified the business log as the appropriate data source as it contains all time relevant process data and can be enriched with data from reporting activities. Unfortunately, there is no easy way to push the data out just yet, so we had to modify the business logger to add a listener that is capable of pushing the events to our Slipstream Core where they are transformed into events that are consumable in real-time by SAP BusinessObjects Xcelsius.

image

In the demo, we see how Slipstream can be used to facilitate the development of live dashboards for Centre Calls, a fictional service support call centre. Centre Calls came under cost pressure and needed current process data visualized on the spot and not the next day. Also, they needed to be consumable for end users and not for administrators. We explain the steps to extract data from the business log and set up a live dashboard. Slipstream dashboards can be used in a browser, as a widget, in presentation slides, and even in Web apps such as Google Wave.

image

In addition, Slipstream can also be used with Live Enterprise, SAP's vision for collecting, filtering, managing, aggregating, propagating, and publishing business events in a consistent, contextual way in an open and comprehensive framework, across multiple servers, locations, and companies. We demonstrate how SAP NetWeaver BPM events, as generated by Slipstream, can also be used to populate dashboards with Live Enterprise and also highlight Live Enterprise’s additional capabilities in this context. We will explore this connection in greater detail in future posts.

image

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.