Skip to Content
Product Information
Author's profile photo Angelika Salmen
Angelika Salmen
March 16, 2022 6 minute read

Custom Situation Cases: Configure an Escalation Case (5/6)

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.

New%20apps

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.

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.

Let me point you out to further information:

 

Assigned Tags

      Be the first to leave a comment
      You must be Logged on to comment or reply to a post.