With SAP S/4HANA Cloud 2202 you can now create your own situation use cases. In this blog post series, I’d like to introduce the new configuration apps based on demo cases. In the fourth post of this blog series, you learned how to create a simple use case. Now let’s configure an escalation case in which situation instances can be closed and reopened according to changing data.
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. The app is based on a simplified, fictional booking portal using 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.
Again, let’s start by creating a situation template that serves as a blueprint for the situation type. The demo case Sales Rate illustrates an escalation case. Users are informed early about a non-profitable flight by displaying a situation in the My Situations – Extended app. When the flight is closer to departure, they also receive a notification. Additionally, the configuration reacts to changing data. If a flight becomes profitable the situation is closed automatically. If the sales rate drops again the situation is reopened.
The standard settings for instance behavior remain unchanged. Each trigger creates a single situation instance and, after closing a situation, the instance remains in the system. The situations are displayed in the instance list of the corresponding situation type.
Here you assign all callback actions and navigation actions that are supported by the flight object to provide the user with flexible choices to resolve the situation.
The sales rates of flights are subject to constant change. To avoid information overflow for the end user, the batch-based trigger Periodical Flight Check is used. Instead of signaling each change to the user, the situations are checked at specified points in time.
You use the trigger details to define the conditions that determine if and when users will be notified about situations.
The escalation case requires multiple conditions.
To provide the end user with specific information, each condition has a different situation display assigned to it.
The notification behavior differs for each condition, too, using both, standard and custom behaviors.
Condition 2 does not send any notifications, but it displays the situation instances in the My Situations – Extended app. This behavior is not covered by the standard and a custom notification behavior (4) is added. The notification behavior is closely related to the life cycle of situation instances and needs to consider all possible life cycle transitions.
Condition 1 uses the standard notification behavior (3) in which all users responsible are notified when a situation instance is created or reopened, while only processors get a notification when the situation is updated.
Condition 3 also has a custom definition of the notification behavior (5). If a situation is closed based on this condition, the processer gets a notification.
The trigger-specific callback and navigation actions contain all actions that are related to the anchor-trigger pair. Actions defined as general actions are automatically displayed here. Since the anchor and trigger refer to the same object in this case, and all anchor related actions are already part of general actions, no trigger-specific actions are selectable.
The batch jobs are scheduled twice a day at 5 a.m. and 5 p.m.
Recipient determination works in the way you’re familiar with from the standard framework for Situation Handling.
To trigger situation instances, I’ll create and enable a situation type called Low Ticket Sales. The configuration of the template can be used right away for a productive situation type. But let’s add another condition and adapt batch job scheduling.
The clean-up condition closes all situations after a has departed. It uses one filter:
The flight date is the leading condition. This means the condition needs to be the first one in the processing order.
After the clean-up, situations are closed and still visible in the Manage Situation Types – Extended app. No text is needed. No one should be notified. However, the configuration needs a formal display assignment, so you can simply reuse situation display 3 for the clean-up condition.
To make sure no one is notified after the clean-up, you assign standard behavior 2: No notification after closing.
The users responsible only receive a notification about low ticket sales if its departure date is nearing or if a user is assigned as processor. Otherwise, the situation appears only in the My Situations – Extended app.
The situation instance is displayed in the list view and its details are shown on the situation page. The header section and the actions reflect the configuration of the situation type Low Ticket Sales. The details section displaying the related flight information is configured for the situation trigger Periodical Flight Check in the situation scenario. The information layouts for the situation pages Low Ticket Sales and Critical Eco Index are the same.
In the next blog post, I will show you a complex configuration using multiple trigger objects and special features for the instance behavior. Stay tuned.
Let me point you out 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. The app is based on a simplified, fictional booking portal using 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.
Create a Situation Template
Again, let’s start by creating a situation template that serves as a blueprint for the situation type. The demo case Sales Rate illustrates an escalation case. Users are informed early about a non-profitable flight by displaying a situation in the My Situations – Extended app. When the flight is closer to departure, they also receive a notification. Additionally, the configuration reacts to changing data. If a flight becomes profitable the situation is closed automatically. If the sales rate drops again the situation is reopened.
Situation Instances
The standard settings for instance behavior remain unchanged. Each trigger creates a single situation instance and, after closing a situation, the instance remains in the system. The situations are displayed in the instance list of the corresponding situation type.
General Actions
Here you assign all callback actions and navigation actions that are supported by the flight object to provide the user with flexible choices to resolve the situation.
Situation Triggers
The sales rates of flights are subject to constant change. To avoid information overflow for the end user, the batch-based trigger Periodical Flight Check is used. Instead of signaling each change to the user, the situations are checked at specified points in time.
Trigger Details
You use the trigger details to define the conditions that determine if and when users will be notified about situations.
Conditions
The escalation case requires multiple conditions.
- Condition 2 informs the user in advance by displaying a situation in the My Situations – Extended The defined filters are:
- Departure of flight within the next four weeks
- Sales rate below 20 %
- Scheduled status of the flight is true. The scheduled status needs to be taken into account because all cancelled flights are still in the system with a sales rate of 0 %. These flights must not be included when detecting situations.
- Condition 1 additionally notifies a user when the flight’s departure date is nearing. Since the conditions are processed from top to bottom and the first that matches is executed. This condition must be first because it’s a subset of the time period defined in condition 2. The defined filters are:
- Departure of the flight within the next seven days
- Sales rate below 20 %
- Scheduled status of the flight is true
- Condition 3 closes the situation when the sales rate has surpassed the threshold and is profitable. Only one filter is needed now because it applies to all existing situations.
- Sales rate is 20 % or above
Situation Display
To provide the end user with specific information, each condition has a different situation display assigned to it.
- Situation Display 1 informs the user in advance and suggests promoting the flight. Deselecting notification aggregation sends notifications for each instance so the same texts can be used for situations and notifications.
- Situation Display 2 is used when a flight’s departure date is nearing, and the user is requested to cancel the flight. Again, notification aggregation is deselected, and the same texts are used for situations and notifications.
- Situation Display 3 informs about closed situations. These situations are no longer displayed in the My Situations – Extended app and do not require a text. They are still part of the instance list in the Manage Situation Types – Extended app though.
Notification Behavior
The notification behavior differs for each condition, too, using both, standard and custom behaviors.
Condition 2 does not send any notifications, but it displays the situation instances in the My Situations – Extended app. This behavior is not covered by the standard and a custom notification behavior (4) is added. The notification behavior is closely related to the life cycle of situation instances and needs to consider all possible life cycle transitions.
Condition 1 uses the standard notification behavior (3) in which all users responsible are notified when a situation instance is created or reopened, while only processors get a notification when the situation is updated.
Note: With SAP S/4HANA Cloud 2308 the standard life cycle number 3 Notify all after creation or reopening / Processor only after update was changed to Notify all after reopening. It only contains the reopening activities which enables a more distinct life cycle management.
Condition 3 also has a custom definition of the notification behavior (5). If a situation is closed based on this condition, the processer gets a notification.
Callback and Navigation Actions
The trigger-specific callback and navigation actions contain all actions that are related to the anchor-trigger pair. Actions defined as general actions are automatically displayed here. Since the anchor and trigger refer to the same object in this case, and all anchor related actions are already part of general actions, no trigger-specific actions are selectable.
Batch Job Scheduling
The batch jobs are scheduled twice a day at 5 a.m. and 5 p.m.
Recipients
Recipient determination works in the way you’re familiar with from the standard framework for Situation Handling.
Create a Situation Type
To trigger situation instances, I’ll create and enable a situation type called Low Ticket Sales. The configuration of the template can be used right away for a productive situation type. But let’s add another condition and adapt batch job scheduling.
Add a Clean-Up Condition
The clean-up condition closes all situations after a has departed. It uses one filter:
- Flight date is yesterday’s date
The flight date is the leading condition. This means the condition needs to be the first one in the processing order.
Reuse of Situation Display
After the clean-up, situations are closed and still visible in the Manage Situation Types – Extended app. No text is needed. No one should be notified. However, the configuration needs a formal display assignment, so you can simply reuse situation display 3 for the clean-up condition.
Notification Behavior
To make sure no one is notified after the clean-up, you assign standard behavior 2: No notification after closing.
Informing End Users
The users responsible only receive a notification about low ticket sales if its departure date is nearing or if a user is assigned as processor. Otherwise, the situation appears only in the My Situations – Extended app.
The situation instance is displayed in the list view and its details are shown on the situation page. The header section and the actions reflect the configuration of the situation type Low Ticket Sales. The details section displaying the related flight information is configured for the situation trigger Periodical Flight Check in the situation scenario. The information layouts for the situation pages Low Ticket Sales and Critical Eco Index are the same.
In the next blog post, I will show you a complex configuration using multiple trigger objects and special features for the instance behavior. Stay tuned.
- 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 out to further information:
- SAP Help Portal: Situation Handling – Extended Framework for SAP S/4HANA Cloud
- SAP Community: Intelligent Situation Handling
- SAP Managed Tags:
