The Power of Reuse – Custom Situation Configuration
My name is Angelika Salmen and I am the product owner of Situation Handling. With this blog post I want to illustrate the concept for custom created situations, which is based on reusability of artefacts from business applications to situation types.
The configuration relates to the extended framework for Situation Handling which has been available since SAP S/4HANA Cloud 2202 and SAP S/4HANA 2021 FPS2.
Concept of reusability
In your daily business you may face multiple issues, such as exceeded deadlines, delays, and missing out on follow-up activities. This may result in higher costs, frustrated users, or even loss of customers. Situation Handling detects these issues and helps you optimize your business processes. The framework is loosely coupled with business applications, which means you can add it at any time.
The issues you confront in your daily business often follow similar patterns. This is reflected in the Situation Handling concept of reusability. With the 4-layer approach of creating custom situations you benefit from a generic configuration but in a controlled way.
- Situation Objects model business objects that reuse existing application artefacts.
- Situation Scenarios represent business scopes by mapping selected situation objects.
- Situation Templates are blueprints for use cases derived from situation scenarios.
- Situation Types are productive use cases copied and refined from situation templates.
Application artefacts delivered by SAP need to be allowlisted. And you can also use custom artefacts.
Situation Handling also offers low-code development tools by providing a set of SAP Fiori apps for the configuration: Mange Situation Objects, Manage Situation Scenarios, and Manage Situation Types – Extended.
The configuration of Situation Handling addresses the technical processing of situations as well as the information design for the users. This blog post focuses on the technical aspects related to reusability. If you are interested in defining the user information you can refer to the blog post Fine Tuning Custom Situations: Configure the layout of My Situations – Extended.
Let me explain the relation between situation object, situation scenario, situation template, and situation typeby focusing on the central artefacts CDS views, situation triggers (business events, batch jobs), and user actions (callback actions, navigation targets). To illustrate the configuration concept, I use a fictional business context of a flight booking portal like implemented in the Situation Handling Demo app.
The situation object models a business object that reuses existing application artefacts.
- You refer to CDS views that represent the object’s data.
- You subscribe to business events that signal a transition, such as new object created, object updated, or object deleted.
- You can refer to available actions, including their parameters, for example, cancel a flight, upgrade a passenger to business class, or rebook a passenger to another flight.
- You can add navigation targets to related business apps using intent-based navigation.
You can assign multiple of these artefacts that may be relevant for identifying situations.
The artefacts within a situation object are not specific to a business scope, instead it’s a generic pool of options.
Let’s look at some exemplary cases for the fictional booking portal. We are taking three situation objects that are related to the business context into consideration: Flight, Booking, and Staff.
- Flight has two CDS views that represent different aspects of the object: One CDS view contains core data such as the flight connection, seating, and sales information. The other CDS view refers to analytical data. The Flight object comprises several triggers and user actions that relate to one or both CDS views.
- Booking has one CDS view that represents core data, such as the booking number, passenger name, and flight connection as well as the triggers and user actions related to this CDS view.
- Staff also has one CDS view that represents core data, such as the names, functions, and shifts. Triggers and user actions are connected to this CDS view.
In fact, these artefacts need a more detailed configuration in the situation object. Having done it once, you can simply refer to the artefacts in the subsequent step when defining the scenario. Let’s continue focusing on the higher level to illustrate the relations of the artefacts in the 4-layer approach.
A situation scenario describes a business scope for the object that is affected by situations (anchor object). A scenario can have only one anchor object. The business scope results from mapping one or more objects that trigger the situation (trigger objects) to the anchor object. Multiple scenarios can use the same object. The graphics below show three sample scenarios using the Flight object: Flight Profitability, Flight Staffing, and Flight Performance.
When mapping the objects in a scenario, you also need to select the artefacts from the objects that are relevant for the business scope.
- You select one CDS view that describes the structure of the anchor object.
- You add the related trigger events from the object. You can also define batch-based triggers that check CDS data periodically.
- You select the relevant user actions.
For each trigger object you choose a CDS view, situation triggers, and user actions, too. A trigger object can be the same as the anchor object or another object.
The graphics in the three following paragraphs show the selected artefacts from the situation objects used in the scenarios. To emphasize the reusability aspect a simplified view is used. The specific configuration also differentiates which artefacts are used for the anchor and for each trigger object.
Situation scenario Flight Profitability
The Flight Profitability situation scenario uses the Flight object with the first CDS view. It does not refer to event triggers but defines a periodical batch job as the trigger. Event triggers are used from the Booking trigger object. User actions are selected from both objects.
Situation scenario Flight Staffing
The Flight Staffing situation scenario uses the Flight object with the first CDS view. Event-based triggers are selected from the objects Flight and Staff as well as user actions.
Situation scenario Flight Performance
The Flight Performance situation scenario uses only the Flight object with the second CDS view, event-based triggers, and a navigation action.
The situation scenario provides a focused selection of object artefacts and refines their relation in the detailed anchor and object configuration. You do the refinement once and you can use it for all use cases derived from the scenario.
You may also refer to the blog post Custom Situation Cases: Create Your Own Situation Scenario (3/6) to see an exemplary scenario configuration.
From the situation scenario you can derive several use cases by creating situation templates.
The two graphics below highlight the artefacts from the situation scenario Flight Profitability that are used in the demo templates Booking Rate and Sales Rate. Of course, you could derive many more templates from the scenario.
Situation template Booking Rate
The situation template Booking Rate describes a use case that observes the booking status of flights, for instance, flights with an overbooked economy class. The template uses a navigation action from the anchor object Flight. The event-based triggers and the user actions are chosen from the trigger object Booking.
Situation template Sales Rate
The situation template Sales Rate describes a use case that monitors the ticket sales of flights, for example, flights that don’t sell well. The template is only based on the Flight object using the batch-based trigger and callback and navigation actions.
The templates also contain the detailed configuration for situation triggers. The core piece is the condition section that defines when a situation is created or closed. The template Sales Rate defines that a situation is created if the sales rate is below 20 %. If it raises above 20 % the flight becomes profitable, and the situation is automatically closed. The situation is also closed after the flight’s departure.
The template serves as blueprint for use cases and can be adapted for various situation types.
The situation type is used in the production system and creates the situation instances. It is a copy of the situation template and can be refined for the specific business purpose. For example, the markets for ticket sales are regionally different. So, you can reuse the configuration of the situation template and simply adapt the condition filters.
- In EMEA the flights are profitable with a sales rate of 20 % or higher. Since the market is rather varying you want to start monitoring the ticket sales 3 weeks before a flight’s departure.
- In AMER the ticket sales need to be 30 % or higher while the markets are comparably stable, so it is sufficient to monitor the flights 2 weeks before departure.
All other configurations from the template such as texts and actions are reused.
Now you are set to best support your users and create a positive impact for your business.
If you want to learn more about the extended framework of Situation Handling this might be also interesting for you:
- SAP Help Portal: Situation Handling – Extended Framework for SAP S/4HANA Cloud, Situation Handling – Extended Framework for SAP S/4HANA
- SAP Community: Intelligent Situation Handling
- Blog post series: Custom Situation Cases: Configure Your Own use cases (1/6)