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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
7 | |
5 | |
4 | |
4 | |
3 | |
3 | |
3 | |
3 | |
3 | |
3 |