My name is Axel Spriestersbach and I have been architecting, designing, and developing Situation Handling from its inception. In this role I also detect and solve a variety of issues in SAP S/4HANA and SAP S/4HANA Cloud, internally as well as in customer systems. I want to share some of my knowledge with you.
When you use the standard or extended framework of Situation Handling, most of the processing happens in the background. A look under the hood helps you understand the behavior and might even help you solve some issues yourself or help you create support tickets.
In this blog post, I will focus on the standard framework of Situation Handling that shares the logging tools with the extended framework, but differs when it comes to the log objects, the processing, and the errors logs. I will explain the specifics of the extended framework later in a dedicated blog post. This blog post is addressed to users with a technical background who face unexpected behavior or want to get a deeper understanding of the framework.
First, we'll focus on the log analysis tools, the log objects, and how to best work with them. Afterwards, we will look at a successful run of the standard framework of Situation Handling and check the logs written by the sub-components involved. Finally, we’ll take a look at logs indicating errors in the system setup or issues resulting from an incorrect situation type or team configurations.
Application logs can be accessed in two ways:
In this blog, I’ll be focusing on the SAP Fiori app in the examples since this app is available for both SAP S/4HANA Cloud and SAP S/4HANA customers.
To display data related to Situation Handling only with the generic Display Application Logs app (as shown in Figure 1), use the following filter settings:
Table 1: Situation log types
Before we turn to logs that indicate issues, let’s look at logs resulting from normal processing.
The logs for the Manage Situation Types (WB or MST) app are design-time logs for changes to a situation type. The logs show the operations that were performed together with their outcomes. Figure 2 for example, shows the successful update of the situation type “ZAS_LOG_DEMO” that is based on the “DEMO_SFLIGHT_LOW_BOOKING_CLASSIC” situation template. This situation type will be used as sample throughout this blog post.
Other logged situation type operations are the creation and deletion of situation types and their enablement. If there are no situation type logs, no type was created for this system and client.
Scheduling logs are runtime logs indicating that a situation type was either scheduled to be run at a specific time ("batch run") or by an event.
Figure 3 shows examples of both types:
A common error with regards to missing situation instances surfaces when the log contains no entries like the ones displayed above. This means that either the event was not raised, or the technical jobs have not been set up correctly.[2]
The scheduler determines the system resources and orchestrates the evaluation of situation types. A log showing the available system resources and the resources to be used by the standard framework of Situation Handling shown in Figure 4. The most important part is the available resources in terms of dialog (# Dialog Process Available =18) and background processes (# BG Processes Available =5). Whenever there are no available resources (... Available =0), no situation types are processed. If this situation persists, please ask your system administrator to increase the available system resources.
When system resources are available, the log lists the situation types to be run. The DEFINITION[x]-SITNDEFINITIONID contains information on the types that will be run, in the example ZAS_LOG_DEMO in Figure 5.
The scheduler can start multiple situation engine instances, each of which is responsible for processing a single situation type.
The log shows the situation type that is processed (Definition ID = ZAS_LOG_DEMO) and the event object key. The example in Figure 6 shows a batch run without a specific event object. This means the log contains an empty event object key (Event Object Key =<INITIAL_TABLE>). Event-based types contain the event object key sent with the event in this field.
Then the conditions are processed. Figure 7 shows the trigger object view (C_SITNSFLIGHT / (<MESSAGE> =C_SITNSFLIGHT WITH PRIVILEGED ACCESS AS TRIGGER) used for the filter conditions. In the example, the TRIGGER~CARRID field must match (EQ) the value DL. This is repeated for all filter conditions of the situation type.
If no conditions are met - a valid result when no situations have been found - this fact is visible in the logs (Figure 😎 and the processing stops. If conditions are met, the result is shown in the log (Figure 9) and the processing continues.
The log also contains the instance operations: created, updated (indicated by a timestamp), deleted, or meaning the status remains unchanged. Here we distinguish between normal and so-called shadow instances[3]. The logs in Figure 10 show six newly detected instances (Number of Active Instance Create =6) and no other instance operation indicated by all other entries being <INITIAL>.
For situation instances with status changes, the Responsibility Management framework is used to get a list of responsible users for the situation instances. Th example below displays a team-based responsibility determination.
Figure 11 shows a configuration for the responsibility determination the context type and the keys passed (rsm.it_objects[x]). Figure 12 below shows the results for each situation instance ID. In the example, two users (User IDs: CB9980000020 and CB9980000024) are responsible for the instance 42010AEF4E0E1EECBA854327B8129FE6.
Finally, SAP Fiori launchpad notifications are passed to the notification framework for these users.
The first part of the log in Figure 13 shows configurations passed to the notification API, such as the Notification provider id, notification type key, and so on. The log entries show the list of notification parameters (Fiori notification entry-PARAMETER[x]) for the current system language (E = English in the example). These are the replacement parameters used in the "Secure Notification Details" text defined in the section of the Manage Situation Types app. The example shows two parameters (SALESQUOATION and SALESQUOATION), their values, and the type. If a user uses a different language, these parameters need to be retrieved from the back end, which leads to additional log entries of log type NOTIF (see Table 1).
Finally, the log contains information for the navigation to the target application: its semantic object (Fiori notification entry-NAVIGATION_TARGET_OBJECT), semantic action (...-NAVIGATION_TARGET_ACTION), and the filter parameters passed: In the example, it only contains the reference to an xapp-state (see blog "Restoring Fiori Application State") that contains the filter details.
Once you understand the logging tools and logs of a normal engine run, you may face situations where the standard framework of Situation Handling behaves unexpectedly because of an incorrect situation type, system configurations, and so on.
This section lists a couple of anti-patterns that can be found in logs and their implications.
This pattern was already mentioned in the Scheduling Logs section. The pattern isn’t the existing log entries, but rather the lack of specific log entries. The simplest way to investigate whether the scheduling works correctly is to filter for the SCHED "Sub-Category" (see Table 1). This should result in logs entries like the ones shown in Figure 5. If there are no entries at all, something is wrong, and depending on the situation type (event or batch-based), either the events were not emitted, or the technical jobs were not set up correctly.[4] If event are missing, this most likely has to with the use case.[5]
This pattern was already mentioned as part of the engine run (see Figure 8). Getting no instances (and no notifications) is a very common pattern. The resolution is not always straightforward as there may be multiple reasons, for example:
Also, a frequent issue are missing SAP Fiori notifications, even if situation instances have been detected (see previous anti-pattern). In many cases, the root cause is empty or incorrect recipients. This may happen for all situation instances (Figure 14) or for some situation instances, such as, instance ID 42010AEF... shown in Figure 15. In addition, the list can be wrong or incomplete.
Figure 14 shows an example where no recipients were found (log entry “Key missing in RSM result”), as the key passed to the Responsibility Management (RSM) framework (DL19842922808) didn’t return any values for the source configured in the RSM framework.
Figure 15 shows an example where no recipients were found for some situation instances. If this is unexpected, the team configurations, including the CDS view used, the member function, and so on, we probably misconfigured and need to be corrected in the Manage Teams and Responsibilities app. For rule-based responsibility determinations, please consult the documentation provided for the respective situation template in the Manage Situation Types app.
To avoid flooding users with too many instances and notifications, the standard framework of Situation Handling implements an upper threshold of 10,000 instances for a single run. The log shown in Figure 16 indicates that this threshold has been exceeded and no instances were created.
Please narrow the filter conditions for the situation type and get fewer results to solve this.
Setting up SAP S/4 HANA systems require some configurations that are pre-delivered for S/4 HANA Cloud systems. The settings required for SAP S/4HANA are described under Technical Configuration Settings on SAP Help Portal. Sometimes, these configurations are incorrect or incomplete and lead to the additional errors described below.
This log pattern has already been partially described in the "No Scheduling Logs" section. You may notice the absence of the required technical jobs when the batch-based situation templates are not processed, or the processing of these situation types is stuck.
The simplest way to find out whether the , is to filter for the TJOB subcategory (see Table 1) which results in logs entries, like the ones shown in Figure 17. If there are no such logs, check the technical documentation and complete the setup of the technical jobs.
The error shown in Figure 18 indicates that the notification provider configuration is incorrect and should be corrected as described under on SAP Help Portal.[6]
The error shown in Figure 19 indicates that the notification configuration is incorrect and the backend alias needs to be maintained. The blog SAP Fiori – Notification Channel Configuration describes the necessary steps.
In my blog post, you learned how to analyze application logs written by the standard framework of Situation Handling to help you identify and resolve issues that may occur. Please include critical log entries in your support ticket (CA-SIT-*) to accelerate processing. This blog post is considered a living document. Feel free to add additional logs with your questions in the comments. We'll try to answer them in the comments or even include them in the blog post.
More blog posts about Situation Handling and Intelligent Situation Automation are available:
For more information, see SAP Help Portal for Situation Handling in SAP S/4HANA Cloud and Situation Handling in SAP S/4HANA. We welcome your valuable feedback.
[1] With the CE2208 and OP2022 releases two additional Fiori apps are accomplishing the standard log viewer for the key user role Display Application Logs - Situation Handling (Fiori ID F6594) and Display Application Logs - Situation Handling Extended (Fiori ID F6595) with the corresponding log objects as presets.
[2] Especially for an SAP S/4HANA system. See Set Up Technical Jobs @help.sap.com for the correct system setup.
[3] see the blog Intelligent Situation Automation – an extension of SAP S/4HANA Situation Handling for more information on the Intelligent Situation Automation extensions in BTP and shadow instance handling
[4] Especially in an SAP S/4HANA system. See Set Up Technical Jobs @help.sap.com for the correct system setup.
[5] Please check the use case documentation, for example, the test scripts for the scope item ID in the SAP Best Practices Explorer. You can find a list of all Situation Handling use cases including links to the scope items here for SAP S/4HANA Cloud and here for SAP S/4HANA.
When you use the standard or extended framework of Situation Handling, most of the processing happens in the background. A look under the hood helps you understand the behavior and might even help you solve some issues yourself or help you create support tickets.
In this blog post, I will focus on the standard framework of Situation Handling that shares the logging tools with the extended framework, but differs when it comes to the log objects, the processing, and the errors logs. I will explain the specifics of the extended framework later in a dedicated blog post. This blog post is addressed to users with a technical background who face unexpected behavior or want to get a deeper understanding of the framework.
First, we'll focus on the log analysis tools, the log objects, and how to best work with them. Afterwards, we will look at a successful run of the standard framework of Situation Handling and check the logs written by the sub-components involved. Finally, we’ll take a look at logs indicating errors in the system setup or issues resulting from an incorrect situation type or team configurations.
SAP Application Log Analysis Tools
Application logs can be accessed in two ways:
- With the Analyze Application Log SAP GUI application in SAP S/4HANA that is launched with the transaction code slg1
- With The SAP Fiori app Display Application Logs (Fiori ID F1487/ see Figure 1) available with the SAP Application Services catalog on SAP Fiori launchpad.[1]
In this blog, I’ll be focusing on the SAP Fiori app in the examples since this app is available for both SAP S/4HANA Cloud and SAP S/4HANA customers.
Figure 1: Application logs with filter SIT
To display data related to Situation Handling only with the generic Display Application Logs app (as shown in Figure 1), use the following filter settings:
- In the "Category" filter, enter "SIT".
- In the optional "External Reference" filter, enter a situation type ID to display logs for a specific situation type.
- In the optional "Subcategory" filter, limit the results to the subcomponents of Table 1
| Log Type | Description |
| WB / MST | Logs for the Manage Situation Types app |
| ENG | Situation engine logs |
| SCHED | Logs for the situation engine scheduler |
| NOTIF | Logs for the interaction with the notification framework APIs |
| API | Logs related to the APIs for incoming or outgoing API calls |
| DA | Situation monitoring and data analytics logs |
| DCTX | Data context logs |
| SECURITY / SEC | Security-related logs |
| TJOB | Logs from technical jobs that are used for cleanup and batch scheduling |
Table 1: Situation log types
Logs Standard Situation Runs
Before we turn to logs that indicate issues, let’s look at logs resulting from normal processing.
Manage Situation Types App
The logs for the Manage Situation Types (WB or MST) app are design-time logs for changes to a situation type. The logs show the operations that were performed together with their outcomes. Figure 2 for example, shows the successful update of the situation type “ZAS_LOG_DEMO” that is based on the “DEMO_SFLIGHT_LOW_BOOKING_CLASSIC” situation template. This situation type will be used as sample throughout this blog post.
Figure 2: Sample log entry for a Manage Situation Types operation
Other logged situation type operations are the creation and deletion of situation types and their enablement. If there are no situation type logs, no type was created for this system and client.
Scheduling Logs
Scheduling logs are runtime logs indicating that a situation type was either scheduled to be run at a specific time ("batch run") or by an event.
Figure 3: Created by indicating event or batch-based scheduling logs
Figure 3 shows examples of both types:
- Log entries created by SAP System Processing are batch types.
- SAP Workflow Runtime are event types.
A common error with regards to missing situation instances surfaces when the log contains no entries like the ones displayed above. This means that either the event was not raised, or the technical jobs have not been set up correctly.[2]
Figure 4: Available system resources for scheduler logs
The scheduler determines the system resources and orchestrates the evaluation of situation types. A log showing the available system resources and the resources to be used by the standard framework of Situation Handling shown in Figure 4. The most important part is the available resources in terms of dialog (# Dialog Process Available =18) and background processes (# BG Processes Available =5). Whenever there are no available resources (... Available =0), no situation types are processed. If this situation persists, please ask your system administrator to increase the available system resources.
Figure 5: Scheduler logs – situation types selected for processing by the scheduler
When system resources are available, the log lists the situation types to be run. The DEFINITION[x]-SITNDEFINITIONID contains information on the types that will be run, in the example ZAS_LOG_DEMO in Figure 5.
Situation Engine Logs
The scheduler can start multiple situation engine instances, each of which is responsible for processing a single situation type.
Figure 6: Situation Engine processing batch type ZAS_LOG_DEMO
The log shows the situation type that is processed (Definition ID = ZAS_LOG_DEMO) and the event object key. The example in Figure 6 shows a batch run without a specific event object. This means the log contains an empty event object key (Event Object Key =<INITIAL_TABLE>). Event-based types contain the event object key sent with the event in this field.
Figure 7: Condition processing log
Then the conditions are processed. Figure 7 shows the trigger object view (C_SITNSFLIGHT / (<MESSAGE> =C_SITNSFLIGHT WITH PRIVILEGED ACCESS AS TRIGGER) used for the filter conditions. In the example, the TRIGGER~CARRID field must match (EQ) the value DL. This is repeated for all filter conditions of the situation type.
Figure 8: Filter conditions returning no results
Figure 9: Filter conditions returning results
If no conditions are met - a valid result when no situations have been found - this fact is visible in the logs (Figure 😎 and the processing stops. If conditions are met, the result is shown in the log (Figure 9) and the processing continues.
Figure 10: Instance operations
The log also contains the instance operations: created, updated (indicated by a timestamp), deleted, or meaning the status remains unchanged. Here we distinguish between normal and so-called shadow instances[3]. The logs in Figure 10 show six newly detected instances (Number of Active Instance Create =6) and no other instance operation indicated by all other entries being <INITIAL>.
For situation instances with status changes, the Responsibility Management framework is used to get a list of responsible users for the situation instances. Th example below displays a team-based responsibility determination.
Figure 11: Selection criteria for responsibility determination
Figure 11 shows a configuration for the responsibility determination the context type and the keys passed (rsm.it_objects[x]). Figure 12 below shows the results for each situation instance ID. In the example, two users (User IDs: CB9980000020 and CB9980000024) are responsible for the instance 42010AEF4E0E1EECBA854327B8129FE6.
Figure 12: Responsibility determination results
Finally, SAP Fiori launchpad notifications are passed to the notification framework for these users.
Figure 13: SAP Fiori Notification logs
The first part of the log in Figure 13 shows configurations passed to the notification API, such as the Notification provider id, notification type key, and so on. The log entries show the list of notification parameters (Fiori notification entry-PARAMETER[x]) for the current system language (E = English in the example). These are the replacement parameters used in the "Secure Notification Details" text defined in the section of the Manage Situation Types app. The example shows two parameters (SALESQUOATION and SALESQUOATION), their values, and the type. If a user uses a different language, these parameters need to be retrieved from the back end, which leads to additional log entries of log type NOTIF (see Table 1).
Finally, the log contains information for the navigation to the target application: its semantic object (Fiori notification entry-NAVIGATION_TARGET_OBJECT), semantic action (...-NAVIGATION_TARGET_ACTION), and the filter parameters passed: In the example, it only contains the reference to an xapp-state (see blog "Restoring Fiori Application State") that contains the filter details.
Logs with Common Issues
Once you understand the logging tools and logs of a normal engine run, you may face situations where the standard framework of Situation Handling behaves unexpectedly because of an incorrect situation type, system configurations, and so on.
This section lists a couple of anti-patterns that can be found in logs and their implications.
No Scheduling Logs
This pattern was already mentioned in the Scheduling Logs section. The pattern isn’t the existing log entries, but rather the lack of specific log entries. The simplest way to investigate whether the scheduling works correctly is to filter for the SCHED "Sub-Category" (see Table 1). This should result in logs entries like the ones shown in Figure 5. If there are no entries at all, something is wrong, and depending on the situation type (event or batch-based), either the events were not emitted, or the technical jobs were not set up correctly.[4] If event are missing, this most likely has to with the use case.[5]
No Situation Instances Detected
| Information | ENGI rule results empty |
| Warning | RULE_RESULT empty =RETURN |
This pattern was already mentioned as part of the engine run (see Figure 8). Getting no instances (and no notifications) is a very common pattern. The resolution is not always straightforward as there may be multiple reasons, for example:
- The filter conditions in the situation type definition maybe to narrow
- The trigger object doesn't contain the expected data, which might be an indication that the use case in not implemented correctly or issues in the master data.5
Responsibility Management - No Recipients Found
| Information | Number of Receipients =<INITIAL> |
| Information | NOTIF No rsm receiver determined for several instances. |
Also, a frequent issue are missing SAP Fiori notifications, even if situation instances have been detected (see previous anti-pattern). In many cases, the root cause is empty or incorrect recipients. This may happen for all situation instances (Figure 14) or for some situation instances, such as, instance ID 42010AEF... shown in Figure 15. In addition, the list can be wrong or incomplete.
Figure 14: No recipients found
Figure 14 shows an example where no recipients were found (log entry “Key missing in RSM result”), as the key passed to the Responsibility Management (RSM) framework (DL19842922808) didn’t return any values for the source configured in the RSM framework.
Figure 15: Some instances have no recipient
Figure 15 shows an example where no recipients were found for some situation instances. If this is unexpected, the team configurations, including the CDS view used, the member function, and so on, we probably misconfigured and need to be corrected in the Manage Teams and Responsibilities app. For rule-based responsibility determinations, please consult the documentation provided for the respective situation template in the Manage Situation Types app.
Instance Threshold Exceeded
| Information | Number of Instance identified are more then allowed (10000) |
| Error | Message =No Instances will be created |
Figure 16: Upper threshold 10000 situation instances
To avoid flooding users with too many instances and notifications, the standard framework of Situation Handling implements an upper threshold of 10,000 instances for a single run. The log shown in Figure 16 indicates that this threshold has been exceeded and no instances were created.
Please narrow the filter conditions for the situation type and get fewer results to solve this.
Issues in SAP S/4HANA Systems
Setting up SAP S/4 HANA systems require some configurations that are pre-delivered for S/4 HANA Cloud systems. The settings required for SAP S/4HANA are described under Technical Configuration Settings on SAP Help Portal. Sometimes, these configurations are incorrect or incomplete and lead to the additional errors described below.
Missing Technical Jobs
This log pattern has already been partially described in the "No Scheduling Logs" section. You may notice the absence of the required technical jobs when the batch-based situation templates are not processed, or the processing of these situation types is stuck.
Figure 17: Log entries for technical jobs
The simplest way to find out whether the , is to filter for the TJOB subcategory (see Table 1) which results in logs entries, like the ones shown in Figure 17. If there are no such logs, check the technical documentation and complete the setup of the technical jobs.
Log Pattern - Missing or Incorrect Notification Provider
| Information | Notification Provider is Inactive (or missing) |
| Error | Notification_Provider_=SIT_NOTIF_PROV |
Figure 18: Missing notification provider error
The error shown in Figure 18 indicates that the notification provider configuration is incorrect and should be corrected as described under on SAP Help Portal.[6]
Log Pattern - Missing Backend Alias for the Notification Framework
| Information | NOTI SEND exception |
| Error | message =Backend system alias not maintained |
Figure 19: Missing backend alias for the Notification Framework
The error shown in Figure 19 indicates that the notification configuration is incorrect and the backend alias needs to be maintained. The blog SAP Fiori – Notification Channel Configuration describes the necessary steps.
Summary of the Log Analysis for the Standard Framework of Situation Handling
In my blog post, you learned how to analyze application logs written by the standard framework of Situation Handling to help you identify and resolve issues that may occur. Please include critical log entries in your support ticket (CA-SIT-*) to accelerate processing. This blog post is considered a living document. Feel free to add additional logs with your questions in the comments. We'll try to answer them in the comments or even include them in the blog post.
Want to learn more?
More blog posts about Situation Handling and Intelligent Situation Automation are available:
- A valuable source for understanding the behavior of the standard framework of Situation Handling are our monitoring tools that are described in a separate blog "Situation Handling: How to analyze situations using Monitor Situations"
- As many issues we receive are questions on (missing) notifications, the blog ''Help – Why don’t I get a situation notification?" is a valuable source for information, especially in combination with the insights provided here.
For more information, see SAP Help Portal for Situation Handling in SAP S/4HANA Cloud and Situation Handling in SAP S/4HANA. We welcome your valuable feedback.
Links
[1] With the CE2208 and OP2022 releases two additional Fiori apps are accomplishing the standard log viewer for the key user role Display Application Logs - Situation Handling (Fiori ID F6594) and Display Application Logs - Situation Handling Extended (Fiori ID F6595) with the corresponding log objects as presets.
[2] Especially for an SAP S/4HANA system. See Set Up Technical Jobs @help.sap.com for the correct system setup.
[3] see the blog Intelligent Situation Automation – an extension of SAP S/4HANA Situation Handling for more information on the Intelligent Situation Automation extensions in BTP and shadow instance handling
[4] Especially in an SAP S/4HANA system. See Set Up Technical Jobs @help.sap.com for the correct system setup.
[5] Please check the use case documentation, for example, the test scripts for the scope item ID in the SAP Best Practices Explorer. You can find a list of all Situation Handling use cases including links to the scope items here for SAP S/4HANA Cloud and here for SAP S/4HANA.
- SAP Managed Tags:
4 Comments
