- SAP Managed Tags:
With SAP S/4HANA Cloud 2202 you can create your own situation use cases with the extended framework for Situation Handling. This blog post series gives you a detailed look at how to configure custom situations based on demo cases. The previous blog post Custom Situation Cases: Model your own situation objects (2/6) illustrated the configuration of objects. Here you will learn how to map objects to a situation scenario that describes a specific business area.
To illustrate how situation use cases can be created from scratch, the extended framework comes with demo cases that can be triggered with the Situation Handling Demo app. It’s based on a simplified, fictional booking portal that uses SFlight demo data. The configuration comprises two objects (Flight and Booking), one scenario (Flight Profitability), and three demo templates (Ecological Footprint, Sales Rate, and Booking Rate). See also: Situation Handling – Extended Framework.
A situation scenario describes a specific business area from which several situation templates can be derived. A situation scenario contains one anchor object that will be affected by situations and multiple objects that can trigger a situation. Assigning these objects includes all the application artefacts that come with the situation object.
Furthermore, you define the layout of the situation page in the scenario.
The anchor object is the object that will be affected by situations. Select the object and choose the structure (CDS view) that represents the object in the business scenario you want to cover. Select a unique key from the CDS view so you can identify the specific object.
Additionally, you link the scenario to a context ID of Responsibility Management you have already created. The context ID is used to link Situation Handling with Responsibility Management and to identify which users will be informed about a situation.
Here you define the events that, in combination with the object, can trigger situations for the anchor object. A trigger can either refer to the anchor object itself or some other object.
In the demo scenario, five situation triggers are defined: a batch-based trigger related to the anchor object, and four event-based triggers related to a booking object
The trigger objects have specific object behaviors:
Let’s look at trigger definition 2 with the Booking Created event to see how trigger definitions are configured.
In the detailed trigger definition, you reference the trigger object, select the appropriate CDS view, and a key field that uniquely identifies the object. You also select the trigger object behavior that describes the impact on a situation instance.
Then you select specific events. In the demo case, there’s one event that signals the creation of a booking.
The fields of the trigger CDS view are used as filters, for example, when defining the conditions of the use case and when inserting text variables in the Manage Situation Types - Extended app. You can choose to hide fields that are too technical or don’t really match the use case.
If the anchor and trigger object are different, you define the mapping between the corresponding fields with the same content to establish the associations.
You can use these action types to define the actions used for solving situations:
General actions relate to the anchor object and can be used for any anchor-trigger combination.
Trigger-specific actions can only be used for the corresponding anchor-trigger combination.
Now the trigger-anchor mapping is complete. Let’s continue with the situation page definition.
The My Situations – Extended app has three different views:
In the scenario, you define the layout of these views.
By default, the situation list page contains the columns for the situation description, its status, and the assigned processor. You can add one more columns for the anchor object and the trigger object. Both columns are used in the demo. While the anchor object is always the same (flight), the trigger object can vary (flight or booking). Therefore, the column label for the trigger object is generic: Additional Information.
Depending on the trigger, the user may need different information. So, the details are modeled specifically for each situation trigger definition.
For the anchor object flight, the fields, Airline Code, Connection ID, Flight Date, and Plane Type are selected.
For the trigger object booking, the fields Passenger Name, Luggage Weight, and Agency ID are chosen.
All fields can also be selected to be displayed as filters in the scenario-specific list view of the My Situations – Extended app.
Additionally, you can define up to four fields from anchor and/or trigger objects that will be displayed as Key Information in the generic list view. In the demo case, the selection contains the fields Airline Code and Connection ID from the anchor object and the fields Passenger Name and Agency ID from the trigger object.
The situation page contains three parts: the header, the details section, and the actions section. While the header is predefined, you can adapt the details with the scenario layout, and the actions in the use case definition in the Manage Situation Types – Extended app.
For the details section, you can define one section for the trigger and one for the anchor object. We recommend starting with the trigger information as this is usually more closely related to the instance than the anchor-related details.
You may have noticed that contrary to the column label the section label for the trigger object is specific: Booking Details. Since the demo scenario only uses two objects, two layout schemas can be configured.
Each section can have further subsections or directly display the details. In the demo case we illustrate both. While the trigger section directly lists the details, the anchor section uses further grouping.
That’s it. You’ve configured the scenario.
The next blog post (4/6) provides insights in creating a simple use case based on the scenario. You learn how to create a situation template and a situation type, and how the situation is displayed in the My Situations – Extended app.
Let me point you to further information:
New apps for the extended framework for Situation Handling
Demo Cases
To illustrate how situation use cases can be created from scratch, the extended framework comes with demo cases that can be triggered with the Situation Handling Demo app. It’s based on a simplified, fictional booking portal that uses SFlight demo data. The configuration comprises two objects (Flight and Booking), one scenario (Flight Profitability), and three demo templates (Ecological Footprint, Sales Rate, and Booking Rate). See also: Situation Handling – Extended Framework.
Manage Situation Scenarios App
A situation scenario describes a specific business area from which several situation templates can be derived. A situation scenario contains one anchor object that will be affected by situations and multiple objects that can trigger a situation. Assigning these objects includes all the application artefacts that come with the situation object.
Furthermore, you define the layout of the situation page in the scenario.
Anchor Object
The anchor object is the object that will be affected by situations. Select the object and choose the structure (CDS view) that represents the object in the business scenario you want to cover. Select a unique key from the CDS view so you can identify the specific object.
Additionally, you link the scenario to a context ID of Responsibility Management you have already created. The context ID is used to link Situation Handling with Responsibility Management and to identify which users will be informed about a situation.
Situation Triggers
Here you define the events that, in combination with the object, can trigger situations for the anchor object. A trigger can either refer to the anchor object itself or some other object.
In the demo scenario, five situation triggers are defined: a batch-based trigger related to the anchor object, and four event-based triggers related to a booking object
The trigger objects have specific object behaviors:
- The trigger definitions 1 – 3 can be used to create or update a situation instance.
- Trigger definition 4 is used to close a situation instance by changing the trigger data, such as, its status. The trigger remains in the system and can still be referenced, for example in a notification for the end user.
- Trigger definition 5 closes a situation instance by deleting the trigger object. Data from the trigger object can no longer be referenced.
Trigger Object Details
Let’s look at trigger definition 2 with the Booking Created event to see how trigger definitions are configured.
In the detailed trigger definition, you reference the trigger object, select the appropriate CDS view, and a key field that uniquely identifies the object. You also select the trigger object behavior that describes the impact on a situation instance.
Trigger Events
Then you select specific events. In the demo case, there’s one event that signals the creation of a booking.
Hidden Fields
The fields of the trigger CDS view are used as filters, for example, when defining the conditions of the use case and when inserting text variables in the Manage Situation Types - Extended app. You can choose to hide fields that are too technical or don’t really match the use case.
Mappings
If the anchor and trigger object are different, you define the mapping between the corresponding fields with the same content to establish the associations.
Actions for the end user
You can use these action types to define the actions used for solving situations:
General actions relate to the anchor object and can be used for any anchor-trigger combination.
Trigger-specific actions can only be used for the corresponding anchor-trigger combination.
Now the trigger-anchor mapping is complete. Let’s continue with the situation page definition.
Situation Page & List Page
The My Situations – Extended app has three different views:
- A list view that displays all situations in a user’s responsibility
- A scenario-specific list view
- A situation page with detailed information and actions for one situation instance
In the scenario, you define the layout of these views.
List Page Layout
By default, the situation list page contains the columns for the situation description, its status, and the assigned processor. You can add one more columns for the anchor object and the trigger object. Both columns are used in the demo. While the anchor object is always the same (flight), the trigger object can vary (flight or booking). Therefore, the column label for the trigger object is generic: Additional Information.
Depending on the trigger, the user may need different information. So, the details are modeled specifically for each situation trigger definition.
For the anchor object flight, the fields, Airline Code, Connection ID, Flight Date, and Plane Type are selected.
For the trigger object booking, the fields Passenger Name, Luggage Weight, and Agency ID are chosen.
All fields can also be selected to be displayed as filters in the scenario-specific list view of the My Situations – Extended app.
Additionally, you can define up to four fields from anchor and/or trigger objects that will be displayed as Key Information in the generic list view. In the demo case, the selection contains the fields Airline Code and Connection ID from the anchor object and the fields Passenger Name and Agency ID from the trigger object.
Situation Page Layout
The situation page contains three parts: the header, the details section, and the actions section. While the header is predefined, you can adapt the details with the scenario layout, and the actions in the use case definition in the Manage Situation Types – Extended app.
For the details section, you can define one section for the trigger and one for the anchor object. We recommend starting with the trigger information as this is usually more closely related to the instance than the anchor-related details.
You may have noticed that contrary to the column label the section label for the trigger object is specific: Booking Details. Since the demo scenario only uses two objects, two layout schemas can be configured.
- If the anchor and trigger object are the same, there’s no need to duplicate the information. Defining one section for the flight is sufficient (see batch-based trigger Periodical Flight Check).
- In the other case, only booking can be the trigger object.
Each section can have further subsections or directly display the details. In the demo case we illustrate both. While the trigger section directly lists the details, the anchor section uses further grouping.
That’s it. You’ve configured the scenario.
The next blog post (4/6) provides insights in creating a simple use case based on the scenario. You learn how to create a situation template and a situation type, and how the situation is displayed in the My Situations – Extended app.
- Custom Situation Cases: Configure Your Own use cases (1/6)
- Custom Situation Cases: Model your own Situation Objects (2/6)
- Custom Situation Cases: Create Your Own Situation Scenarios (3/6)
- Custom Situation Cases: Configure a Simple Use Case (4/6)
- Custom Situation Cases: Configure an Escalation Case (5/6)
- Custom Situation Cases: Configure a Complex Use Case (6/6)
Let me point you to further information:
- SAP Help Portal: Situation Handling – Extended Framework for SAP S/4HANA Cloud
- SAP Community: Intelligent Situation Handling
4 Comments
