[Part-2] Explore “Events-To-Business Actions” Framework

In previous blog post of this series Event-to-Business Actions” architecture: An event-driven framework on SAP BTP to implement Industry 4.0 scenarios with Microsoft Azure services by PVN Pavan Kumar, we understood the context and rationale behind this open-source framework based on SAP BTP to strengthen and automate business processes execution to boost operational effectiveness by translating the events from systems and applications to business processes.

Blog post series [Part-1] ‘Events-to-Business Actions’: An event-driven architecture on SAP BTP to implement Industry 4.0 scenarios with Microsoft Azure Services (click here) [Part-2] Understand the details of “Events-To-Business Actions” Framework (click here) [Part-3] SAP Integration Suite’s upcoming event bridging functionality for outbound scenario (click here) [Part-4] Try out ‘Events to Business Actions Framework’ for SAP Service Cloud scenario (click here) [Part-5] Collaborative Event-Driven Business Applications with SAP BTP and Microsoft Teams (click here)

In this blog post, we will deep dive into this framework, look at the basic building blocks and present a sample event-driven application on how it can used to translate any events from applications or systems into business actions in SAP business systems.

At the end of the blog post, you will be able to deploy and use this framework to build an application for your eventing scenario.

What is the Events-To-Business Actions framework?

The Events-to-Business Actions Framework implements an event-driven architecture which enables integration of SAP and non-SAP systems which can be source for events to SAP business systems like SAP S/4HANA, SAP Customer Experience or SAP Asset Performance Management etc. as depicted in Figure-1.

Figure-1: “Events-to-Business Actions” Framework

The objective is to provide a framework which is flexible, customizable, and meta data driven to develop applications. The different components help the application developer to jump start the application development and reduce the development effort to build the application. It allows customization and provides multiple utilities like application security, connectivity, logging, authorization with backend system for integration etc.

The overall flow of the integration is outlined in the solution diagram, as depicted below in Figure-2

Figure-2: “Events-to-Business Actions” Architecture

The key technical services leveraged in SAP BTP are SAP Event Mesh, SAP Connectivity Service, SAP Destination Service, SAP Private Link service (in case SAP BTP and SAP S/4HANA are deployed on Microsoft Azure), SAP Business Rules and SAP Cloud Foundry runtime. The framework is developed to create applications that can receive the incoming events and translate them into configured business actions.

 

Understanding the framework

The framework is developed using SAP Cloud Application Programming (CAP) Model and Node.js. It has primarily 3 components.

1. Modeler
2. Processor
3. Monitor

 

Modeler

As depicted in Figure-3, using the Modeler UI, you can configure the business actions that need to be triggered in the Business systems (Ex: Creation of Purchase Order Requisition in SAP S/4HANA, Service Ticket in SAP Service Cloud etc.) based on the incoming event.

Modeler UI is built using SAP Fiori elements and provides the following tiles to configure action types, actions, business rules and monitor the business action execution logs. Modeler UI implementation sample code can be found in Build Events-to-Business Actions Scenarios with SAP BTP and Microsoft Azure GitHub repository for modeler implementation.

Figure-3: Modeler homepage

 

Once you have the application successfully deployed, the home page will be accessible.

As depicted in Figure-4, “Manage Action Types” tile can be used to define the action types that have common parameters across different actions. An action type “Service Integration” is defined out of the box, and you can add other action types based on your business requirements.

 

Figure-4: Defining Action Types

 

“Manage action” tile can be used to configure the business actions. It is integrated with SAP Destination Service so that you can select the required destination configured for SAP business system to add the endpoint and the payload that is needed to create the business action.

The modeler supports defining and chaining actions based on the context flow as depicted in Figure-5.

• “Default action” is used by the processor to determine which main action needs to be triggered for an incoming event. Only one default action can be defined in modeler.

 

• “Main action” is the action that can be used to create a transaction in the business system (Purchase Order Requisition, Service Tickets etc.).

 

• “Pre-actions” are actions that are like supporting actions that are executed before the “Main Action” so that you can use the output parameters from them while creating “Main-Action”.

 

• “Post-actions” are actions that are executed after the “Main Action” is successfully executed that you can use to trigger further business processes or notify any users/systems of the Business action creation.

 

Figure-5: Manage Actions

In real world scenarios, before any business process is initiated in SAP, data from various sources are required apart from real time event data. For example, you may need to get the material information from Material Master to create Purchase Requisition. The framework allows to create these actions as “Pre-actions” that are required to be executed before the execution of the “Main action” and then use the response of the “Pre-action” in the payload for execution of “Main action”. The framework also supports defining actions as “Post-action” that need to be executed after the creation of “Main Action” like notifying or updating the status etc.

Figure-6 shows the example of defining Purchase Order Requisition creation in SAP S/4HANA system using the destination “ACTION_MODELER_S4” and chaining it with “Update Device Cloud Property” as “Post-Action” to update the device properties after the Purchase Requisition is created.

 

Figure-6: Configuring Purchase Order Requisition

 

The dynamic parameters in the action payload can be defined using templating and the values will be replaced at runtime while processing the respective actions. Each action definition that is created is uniquely identified by a GUID that can be used to replace the dynamic parameters.

For example, if you have defined a “Pre-Action” (action id is “1620443f-53da-4f46-acd3-cf7f18cae24f”) to fetch the material information from the Material master, then you can define “materialId” as “${{pre.1620443f-53da-4f46-acd3-cf7f18cae24f.Result[0].materialId}}” in the Purchase Requisition creation payload and the processor dynamically replaces the respective values. Note that, Result[0].materialId is essentially the path from the response payload of Pre-Action.

“Manage Business Rules” tile federates the content from “SAP Business Rules” and can be used to define the business rules projects which can be used for determining business actions, as depicted in Figure-7. You can refer SAP Business Rules Help documentation to know more about business rules.

Figure-7: Manage Rules Project

Processor

Processor is the backend module that subscribes to the SAP Event Mesh topic and executes the corresponding business actions in the SAP S/4HANA system.

The processor implementation can be found in Build Events-to-Business Actions Scenarios with SAP BTP and Microsoft Azure GitHub Repository for service implementation.

The processor executes the following steps once it receives an event from the SAP Event Mesh.

• Processes ‘Default Action’ to determine which business actions (Main Action) needs to be processed.
• Fetches the respective business action definition and the associated pre/post actions.
• Executes the defined pre-actions one by one and then executes the main business action. The processor replaces the respective dynamic values from the event/pre-actions before executing the main action.
• Once the main action is successfully created, it executes the post-actions that are defined for this main action.

 

The processor entry point can be found here and the templating logic for replacing the dynamic parameters can be found here.

The processor logs the entire execution process that can be used for monitoring/troubleshooting and the logger implementation can be found here.

The processor application can be scaled horizontally and vertically based on the business requirements using the cloud foundry auto-scalar.

Monitor

You can use the Monitor application to monitor the status of the business actions and check the logs for troubleshooting. See the screenshot below in Figure-8 for Monitoring Dashboard.

The processor logs the business action execution logs into SAP HANA database table and the “Business Action Logs” tile can be used to monitor/drill down into the logs.

Figure-8: Monitoring Dashboard – Overview

 

You can drill down to the individual action execution to find out the respective logs and can be used for troubleshooting any failed executions as shown in Figure-9 below.

Figure-9: Monitoring Dashboard – Detailed logs

Monitor application can be enhanced based on the information that you want to visualize and additionally provide the functionality to re-trigger any actions in case of failures.

 

Conclusion

By using this framework, you can develop applications and integrations use-cases to integrate events from systems and applications into any SAP Business applications with minimum configuration. This helps us to manage all the actionable events for SAP business operations. Also, it is possible to include both pre and post action calls to both SAP and non-SAP applications in addition to the main business action. This helps to create bidirectional communication between systems.

You can use the GitHub repository for step-by-step instructions on how to build sample scenario of integrating IoT events from Microsoft Azure IoT to  SAP S/4HANA system. Read the blogpost Leveraging ‘Events-to-Business Actions Framework’ for SAP Service Cloud Scenario by Ajit Kumar Panda in which he has built a new scenario leveraging this framework for Service Order creation process in SAP Service Cloud.

To learn more about SAP BTP, see the learning journey on SAP Learning called Discover SAP Business Technology Platform, a great introduction to BTP and the Intelligent Enterprise strategy to see what it’s all about for free or check out Develop Advanced Extensions with SAP Cloud SDK plus much more free learning at SAP Learning site.

For more information about this topic or to ask a question, please contact us at paa_india@sap.com