- SAP Managed Tags:
With SAP S/4HANA Cloud 2202 you can now create your own situation use cases. In this blog post series, I want to introduce the new configuration apps based on demo cases. In the fifth part of this blog series, you learned how to create an escalation case. Now let’s configure a complex case that works with multiple situation triggers and specific instance behavior features.
To illustrate how you can create situation use from scratch, the extended framework comes with demo cases that you can trigger with the Situation Handling Demo app. The is based on a simplified, fictive 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.
First, let’s configure a situation template as a blueprint for the situation type. The demo case Booking Rate informs the users responsible if one or more economy passengers are booked on an already full flight. This could also be configured as a batch-based case like the other demo cases. But let’s consider a different configuration to illustrate the further powerful features of the extended framework for Situation Handling.
Overbookings are only allowed for economy passengers up to the maximum number of business class seats. In the demo business process, all further overbookings are simply ignored. Technically, overbookings are unconfirmed bookings (confirmed = false).
To achieve the required behavior, the standard settings for situation instances are changed.
In the standard setting, each trigger creates a single situation instance. Enabling trigger accumulation allows you to bundle multiple triggers in one situation instance, this means adding booking triggers to the anchor object flight. The situation page lists all overbookings for a flight and refers to the object name and its semantic keys. If you select an overbooking, you can see its details, like the passenger’s name and luggage weight, on the right.
With the standard setting Close and Keep a resolved situation is stored in the system. If the life cycle configuration includes the option to reopen situations, users are informed about updates of the same instance (see the demo case Sales Rate). This setting will not detect a new situation of the same type for the same anchor object.
For the overbooking case, however, users need to be informed if a flight with a resolved overbooking situation is affected by overbookings once again. Technically this is a new situation on the same anchor object. That’s why the status changes to Close and Delete. The instance is directly deleted after closing, which enables Situation Handling to create a new situation if another issue occurs.
Only trigger-specific actions are configured for this use case.
The event-based configuration with enabled trigger accumulation increases the options for creating, updating, and resolving a situation instance, for example:
These cases are covered by four different triggers. The differentiation between create/update and close/update is defined in the corresponding condition sections.
Booking Created and Booking Unconfirmed have the trigger behavior Add/Update. The other triggers have a different behavior. Booking Confirmed removes one of the accumulated triggers from the situation instance by changing its status from confirmed = false to confirmed = true. The booking is still available and can be referenced, for instance, in notifications. The trigger behavior is Remove (Trigger data available). Booking Canceled removes one of the accumulated triggers from the situation by deleting the booking object. You can no longer reference the booking. The booking behavior is Remove (Trigger data not available).
Additionally, the batch-based trigger Periodical Flight Check is used as a clean-up after the flight has departed.
Booking Created and Booking Unconfirmed create and update situation instances using the same condition configuration.
Only one condition is required to create a situation. It has two Trigger Object Filters:
The texts for situations and notifications are the same.
Standard notification behavior 1 is used. This sends notifications to all users responsible if a new situation is created. Updates are sent only to the assigned processor of a situation.
The trigger-specific callback actions relate to the booking objects and resolve the situation. In combination with trigger accumulation, all actions need to support mass processing by applying the action to all overbookings. Depending on the chosen action, all overbookings are cancelled, or all overbooked passengers are upgraded to business class, or rebooked to the next flight with the same airline and connection ID. Again, the simplified processes of the fictional booking portal apply and bookings that exceed the availabilities are simply ignored.
Navigation to the related app is trigger-specific, as defined in the booking object and goes to the flight-specific page in the Situation Handling Demo app.
An overbooking (confirmed = false) is confirmed if a regular economy class seat becomes available by either deleting a confirmed booking or by assigning a larger plane to the flight. The event removes the trigger object booking from the situation. Since the booking still exists, the trigger behavior is Remove (Trigger data available).
The trigger behavior Remove requires a different condition configuration that takes only these two cases into account:
The notification behavior and the life cycle are simplified so you can select whom to notify directly.
The trigger behavior Remove (Trigger data available) removes the overbooking from the situation instance while the booking itself is still available in the system. Therefore, it can be referenced in the notification. Still, in the example below, the notification text refers only to the flight data.
With the removal, the object is no longer part of the situation. Therefore, it does not require a situation text. If there are updates, the text of the existing instances is used.
With the removal of the booking from the instance, no callback and navigation actions are required.
The cancelation of an overbooking removes it from the situation instance and deletes the booking object. It is no longer in the system and cannot be referenced. So, the trigger behavior is Remove (Trigger data not available).
Like the trigger Booking Confirmed, the trigger Booking Deleted requires a different condition configuration. These two cases are taken into account:
With the simplified notification behavior, you can directly select whom to notify.
For deleted objects, only notification texts are needed.
No actions need to be defined for deleted objects.
The batch-based trigger Periodical Flight Check is used to clean-up the situation after the flight’s departure.
There is only a simple condition needed that closes the flight using the anchor object filter:
This filter works for a daily batch job. For less frequent clean-up runs, the filter needs to be adapted accordingly.
Contrary to the triggers Booking Unconfirmed and Booking Canceled, no one should be informed about the clean-up. So, no texts are needed.
Standard notification behavior 2 is selected: No notifications after closing.
No callback and navigation actions are needed.
The batch job is scheduled to take place once a day after midnight.
Recipient determination works the same you’re familiar with from the standard framework for Situation Handling.
The configuration of the template can be used directly for a productive situation type without any further adaptations. However, let’s change the recipients so they reflect the team structure based on the airline regions. Two teams are defined: one is responsible for APJ and AMER, the other for EMEA.
The Airline Region filter is added in the Responsibility Definition.
The settings are reflected in the Manage Teams and Responsibilities app.
Settings for the team responsible for APJ and AMER.
Settings for the team responsible for EMEA.
The users responsible receive a notification about the overbooked flight on SAP Fiori launchpad.
Selecting the notification takes you to the My Situations – Extended app.
The situation page displays the detailed information. While the other demo cases Critical Eco Index and Low Sales Rate had only a detailed section for Flight, the demo case Overbooking also shows a Booking section, as defined in the scenario. With trigger accumulation enabled, you will see all overbookings in a list. The details of the selected item are displayed next to the list.
The solution proposals (callback actions) and the navigation option to the Situation Handling Demo app were configured in the situation type (unchanged from the situation template).
This was the last blog post of the series. I hope the sample configurations provided an helpful insight about how you can use the extended framework for Situation Handling.
Let me point you to further information:
New apps for the extended framework for Situation Handling
Demo Cases
To illustrate how you can create situation use from scratch, the extended framework comes with demo cases that you can trigger with the Situation Handling Demo app. The is based on a simplified, fictive 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
First, let’s configure a situation template as a blueprint for the situation type. The demo case Booking Rate informs the users responsible if one or more economy passengers are booked on an already full flight. This could also be configured as a batch-based case like the other demo cases. But let’s consider a different configuration to illustrate the further powerful features of the extended framework for Situation Handling.
- The situation template is event-based to inform the users in a timely manner
- Not every overbooking should be turned into a situation, but I want to create one situation for the flight showing all overbookings in the situation instance
- Solution proposals are defined that resolve the situation with one click, that is, mass activities that apply to all overbookings of a situation instance
- New overbookings should be detected after the situation has been closed
- Since the number of overbooked passengers can increase or decrease over time, further triggers are required that either update or close a situation
Overbookings are only allowed for economy passengers up to the maximum number of business class seats. In the demo business process, all further overbookings are simply ignored. Technically, overbookings are unconfirmed bookings (confirmed = false).
Situation Instances
To achieve the required behavior, the standard settings for situation instances are changed.
Enabled Trigger Accumulation
In the standard setting, each trigger creates a single situation instance. Enabling trigger accumulation allows you to bundle multiple triggers in one situation instance, this means adding booking triggers to the anchor object flight. The situation page lists all overbookings for a flight and refers to the object name and its semantic keys. If you select an overbooking, you can see its details, like the passenger’s name and luggage weight, on the right.
Instance Behavior Close & Delete
With the standard setting Close and Keep a resolved situation is stored in the system. If the life cycle configuration includes the option to reopen situations, users are informed about updates of the same instance (see the demo case Sales Rate). This setting will not detect a new situation of the same type for the same anchor object.
For the overbooking case, however, users need to be informed if a flight with a resolved overbooking situation is affected by overbookings once again. Technically this is a new situation on the same anchor object. That’s why the status changes to Close and Delete. The instance is directly deleted after closing, which enables Situation Handling to create a new situation if another issue occurs.
General Actions
Only trigger-specific actions are configured for this use case.
Situation Triggers
The event-based configuration with enabled trigger accumulation increases the options for creating, updating, and resolving a situation instance, for example:
- Create a situation by booking one or more economy passengers to a fully booked flight
- Create a situation by assigning a smaller plane to a very well booked flight
- Update a situation by adding a booking to an overbooked flight
- Update a situation by canceling a booking for an overbooked flight
- Close a situation by upgrading the last overbooked passenger to business class
- Close a situation by rebooking a regular economy passenger to another flight so that the last overbooked passenger gets the free seat
These cases are covered by four different triggers. The differentiation between create/update and close/update is defined in the corresponding condition sections.
- Booking Created either triggers a new overbooking situation or adds to an overbooking situation if an economy class ticket is booked
- Booking Unconfirmed either triggers or adds to an overbooking situation if a smaller plane is assigned to a flight and a regular economy booking (confirmed = true) turns into an overbooking (confirmed = false)
- Booking Canceled updates an overbooking situation if either a regular economy booking or an overbooking is canceled. If it was the last overbooking, the situation is closed.
- Booking Confirmed updates an overbooking situation if a seat becomes available, either by canceling a regular booking, by updating an economy booking to business class, or by assigning a larger plane to the flight. If it was the last overbooking, the situation is closed.
Booking Created and Booking Unconfirmed have the trigger behavior Add/Update. The other triggers have a different behavior. Booking Confirmed removes one of the accumulated triggers from the situation instance by changing its status from confirmed = false to confirmed = true. The booking is still available and can be referenced, for instance, in notifications. The trigger behavior is Remove (Trigger data available). Booking Canceled removes one of the accumulated triggers from the situation by deleting the booking object. You can no longer reference the booking. The booking behavior is Remove (Trigger data not available).
Additionally, the batch-based trigger Periodical Flight Check is used as a clean-up after the flight has departed.
Trigger Details – Booking Created & Booking Unconfirmed
Booking Created and Booking Unconfirmed create and update situation instances using the same condition configuration.
Conditions
Only one condition is required to create a situation. It has two Trigger Object Filters:
- Flight Date within the next two weeks. (You could also use the anchor object filter here. In the scenario both fields, which contain the same information, were mapped.)
- Booking status Confirmed is false
Situation Display
The texts for situations and notifications are the same.
Notification Behavior
Standard notification behavior 1 is used. This sends notifications to all users responsible if a new situation is created. Updates are sent only to the assigned processor of a situation.
Callback Actions
The trigger-specific callback actions relate to the booking objects and resolve the situation. In combination with trigger accumulation, all actions need to support mass processing by applying the action to all overbookings. Depending on the chosen action, all overbookings are cancelled, or all overbooked passengers are upgraded to business class, or rebooked to the next flight with the same airline and connection ID. Again, the simplified processes of the fictional booking portal apply and bookings that exceed the availabilities are simply ignored.
Navigation Actions
Navigation to the related app is trigger-specific, as defined in the booking object and goes to the flight-specific page in the Situation Handling Demo app.
Trigger Details – Booking Confirmed
An overbooking (confirmed = false) is confirmed if a regular economy class seat becomes available by either deleting a confirmed booking or by assigning a larger plane to the flight. The event removes the trigger object booking from the situation. Since the booking still exists, the trigger behavior is Remove (Trigger data available).
Conditions
The trigger behavior Remove requires a different condition configuration that takes only these two cases into account:
- After removing the trigger object, at least one further overbooking exists. This updates the situation.
- The removed trigger object was the last one. Removing it closes the situation.
The notification behavior and the life cycle are simplified so you can select whom to notify directly.
Situation Display
The trigger behavior Remove (Trigger data available) removes the overbooking from the situation instance while the booking itself is still available in the system. Therefore, it can be referenced in the notification. Still, in the example below, the notification text refers only to the flight data.
- Situation display 1 notifies users about the update of the situation
- Situation display 2 notifies users about the closed situation
With the removal, the object is no longer part of the situation. Therefore, it does not require a situation text. If there are updates, the text of the existing instances is used.
Callback and Navigation Actions
With the removal of the booking from the instance, no callback and navigation actions are required.
Trigger Details – Booking Canceled
The cancelation of an overbooking removes it from the situation instance and deletes the booking object. It is no longer in the system and cannot be referenced. So, the trigger behavior is Remove (Trigger data not available).
Conditions
Like the trigger Booking Confirmed, the trigger Booking Deleted requires a different condition configuration. These two cases are taken into account:
- After deleting the trigger object, there’s still at least one more overbooking. This updates the situation.
- The removed trigger object was the last one. Removing it closes the situation.
With the simplified notification behavior, you can directly select whom to notify.
Situation Display
For deleted objects, only notification texts are needed.
- Situation display 1 notifies the user about update of the situation
- Situation display 2 notifies the user about the closed situation
Callback and Navigation Actions
No actions need to be defined for deleted objects.
Trigger Details – Periodical Flight Check
The batch-based trigger Periodical Flight Check is used to clean-up the situation after the flight’s departure.
Conditions
There is only a simple condition needed that closes the flight using the anchor object filter:
- Flight Date is Yesterday
This filter works for a daily batch job. For less frequent clean-up runs, the filter needs to be adapted accordingly.
Situation Display
Contrary to the triggers Booking Unconfirmed and Booking Canceled, no one should be informed about the clean-up. So, no texts are needed.
Notification Behavior
Standard notification behavior 2 is selected: No notifications after closing.
Callback and Navigation Actions
No callback and navigation actions are needed.
Batch Job Scheduling
The batch job is scheduled to take place once a day after midnight.
Recipients
Recipient determination works the same you’re familiar with from the standard framework for Situation Handling.
Create a Situation Type
The configuration of the template can be used directly for a productive situation type without any further adaptations. However, let’s change the recipients so they reflect the team structure based on the airline regions. Two teams are defined: one is responsible for APJ and AMER, the other for EMEA.
The Airline Region filter is added in the Responsibility Definition.
The settings are reflected in the Manage Teams and Responsibilities app.
Settings for the team responsible for APJ and AMER.
Settings for the team responsible for EMEA.
Informing End Users
The users responsible receive a notification about the overbooked flight on SAP Fiori launchpad.
Selecting the notification takes you to the My Situations – Extended app.
The situation page displays the detailed information. While the other demo cases Critical Eco Index and Low Sales Rate had only a detailed section for Flight, the demo case Overbooking also shows a Booking section, as defined in the scenario. With trigger accumulation enabled, you will see all overbookings in a list. The details of the selected item are displayed next to the list.
The solution proposals (callback actions) and the navigation option to the Situation Handling Demo app were configured in the situation type (unchanged from the situation template).
This was the last blog post of the series. I hope the sample configurations provided an helpful insight about how you can use the extended framework for Situation Handling.
- 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: Configuration of a simple use case (4/6)
- Custom Situation Cases: Configuration of an escalation case (5/6)
- Custom Situation Cases: Configuration of 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
2 Comments
