Custom Situation Handling Use Case for Professional Services: Unstaffed Resource Requests
Here’s the deal: There’s an urgent business issue that you want to bring to the attention of the end users, but none of the available predelivered Situation Handling use cases fulfill your requirements.
While we continue increasing the number of standard situation templates with each SAP S/4HANA Cloud release, did you know that you can also create your own? That’s right, you can model custom situation use cases with the extended framework of Situation Handling.
Read this blog post to get an overview of the new features available with the extended framework.
I’ll share a few tips and tricks with you that will help you get started with your own Situation Handling use cases in SAP S/4HANA Cloud by using an example in Professional Services.
Use case description
In SAP S/4HANA Cloud, project managers use the Plan Customer Projects and Plan Internal Projects apps to manage their projects, including planning work packages and resources. It can be challenging to keep track of resource staffing, especially when there are several resource requests to be processed. Staffing the needed resources to a project in a timely manner is crucial to ensure that the expected scope is successfully delivered within the planned budget.
In this blog post, I’ll show you how Situation Handling can help project managers avoid project delays by notifying them about pending resource requests 30 days before the start date of the work package.
Model your use case
You can configure your custom use case for Situation Handling in 5 steps:
- Think about the outcome you want to achieve and work backwards.
- Identify the technical artifacts needed for your use case.
- Define the responsibility context.
- Create your situation object, situation scenario, situation template, and one or more situation types.
- Prepare your business data and test your custom use case.
Let’s look at this in more detail.
Step 1: Think about the outcome you want to achieve and work backwards
Maybe you know from the standard framework of Situation Handling that a situation template serves as a blueprint for creating a situation type. It includes all the elements that you need to define your use case. When the conditions defined for the situation type are met, a situation instance is detected, and the user responsible for it is automatically notified. This is also applicable to the extended framework. To create a custom use case, you need to define a situation template based on a situation scenario and one or more situation objects.
Before looking into the technical feasibility, think about which fields should be included as condition filters for your situation template and which related information could help the user understand and solve the issue.
For Unstaffed Resource Requests, I came up with the following condition filters:
- Project Type (customer project ‘C’)
- Resource Type (team resources ‘0ACT’)
- Project Stage (in progress ‘P003’)
- Resource Request Status (pending staffing ‘P’)
- Work Package Start Date (next 30 days)
It’s also important to consider the notification text and the situation page content from the get-go.
The notification is the user’s first contact with the situation, therefore it should be meaningful. Using variables such as project, work package, work item, and activity type in the text quickly help identify the unstaffed resource requests.
The user can access the situation page by clicking on the notification or with the My Situations – Extended app. In my custom use case, the situation page should display additional project, work package, and resource request data to contextualize the situation and support the decision-making process.
Step 2: Identify all the technical artifacts needed for your use case
Identify which CDS views (and business events, if applicable) are needed to ensure that the situation is detected. But also keep in mind the condition filters, the notification text, and the situation page mentioned in step 1.
In this case, the required data is not available in a single allow-listed view, so I had to build my own. I created YY1_ResourceRequest using a custom CDS view with I_ResourceRequest as the primary data source for the project header, work package and resource request data, along with custom views based on I_EngagementProjectStageText, I_EngagementProjectSrvcOrgText, and I_EngmntProjResourceText filtered by language (in this case, English ‘E’) as the associated data sources. The latter views are needed for the descriptions of the project stage, service organization, and activity type that should appear on the situation page.
Step 3: Define the responsibility context
Consider who should be automatically notified about your business situation. With Responsibility Management, you can use team structures and responsibility rules to define responsibilities and get the right users to take care of the situation. The responsibility context is a collection of team categories and agent rules that you’ll be able to use in your situation scenario.
In this case, project managers should be informed about pending resource requests in their projects. For this purpose, I created a custom responsibility rule to determine the responsible project managers.
I started by implementing the Responsibility Rule BAdI in the Custom Logic app, using the following logic:
TRY. DATA(lo_iterator) = parameter_name_value_pair->get_iterator( iv_reset_current_iteration = abap_true ). CATCH cx_ble_dynamic_table_error. " Dynamic table handling errors. RAISE EXCEPTION TYPE cx_ble_runtime_error. ENDTRY. WHILE lo_iterator->next_row( ). TRY. DATA(lv_projectid) = lo_iterator->get_value( 'PROJECT' ). "PROJECT is the parameter name. CATCH cx_ble_dynamic_table_error. " Dynamic table handling errors. RAISE EXCEPTION TYPE cx_ble_runtime_error. ENDTRY. ENDWHILE. DATA lv_projectmanagerid(8) TYPE N. DATA lv_businesspartnerid(10) type c. DATA lv_userid(12) type c. IF lv_projectid is not initial. SELECT single ProjectManagerWorkAgreement FROM I_EngagementProject where EngagementProject = @lv_projectid into @lv_projectmanagerid. SELECT single Person FROM I_PersonWorkAgreement_1 where PersonWorkAgreement = @lv_projectmanagerid into @lv_businesspartnerid. SELECT single UserID FROM I_BusinessUserBasic where BusinessPartner = @lv_businesspartnerid into @lv_userid. agents = VALUE #( ( lv_userid ) ). ENDIF.
After the custom logic, I created a custom responsibility rule in the Manage Responsibility Rules app and used the BAdI filter value as the custom responsibility rule ID.
Finally, I configured the responsibility context YY1_PROJECT_MANAGEMENT. As it is mandatory to maintain a team category when creating a custom situation template, I included a category in the responsibility context along with the agent rule described above. We don’t have a standard team category available for Professional Services, so I created my own (YY1_COMMPROJECT). Check our documentation to find out how to create team categories, as well as configure team types, responsibility definitions, and team member functions.
You can use teams and responsibility rules simultaneously to inform the responsible users about business situations. In the context of this use case, you can inform project managers about unstaffed resource requests in their projects via rule and use the team option to bring these situations to the attention of additional stakeholders, for example resource managers.
Step 4: Create your situation object, situation scenario, situation template, and one or more situation types
With all artifacts in place, you can now start modeling your custom use case with the apps Manage Situation Objects, Manage Situation Scenarios, and Manage Situation Types – Extended, in this sequence.
Situation Object: Resource Request
Start with the Manage Situation Objects app to create the Resource Request situation object. A situation object includes a collection of all technical artifacts that are needed to identify situations related to it.
A structure represents the object that can be affected by a situation or that triggers a situation. In the Resource Request object, I defined the custom CDS view YY1_ResourceRequest created in step 2.
Navigation targets as end-user actions
In addition, I also maintained navigation options to the Plan Customer Projects and Plan Internal Projects apps.
The navigation options can be offered as buttons on the situation page to help users solve situations.
Situation Scenario: Resource Request Status
Then connect your situation object to a situation scenario in the Manage Situation Scenarios app. In this app, you can map the anchor and trigger objects, define the layout of the situation page and associate your responsibility context with the situation scenario.
In the Resource Request Status scenario, I maintained the Resource Request situation object as the anchor object, represented by the unique key field Resource Request GUID from the underlying custom CDS view, and assigned the responsibility context defined in step 3.
A daily check is sufficient for this use case. That’s why I created a batch-based situation trigger with the Resource Request object as the trigger object. For Unstaffed Resource Requests, both the affected object (anchor) and the object that triggers situations (trigger) are the same.
There are two types of situation triggers – batch-based and event-based. The former is based on periodical checks via batch runs, while the latter triggers situations when certain business events occur. If you’re thinking about which one to choose, keep in mind that
- event-based triggers are more relevant for time-critical issues that are not expected to occur too
- often batch-based triggers are a better control especially for larger number of situations.
Within the situation trigger, you can define the layout of the situation page. I defined two sections for the situation page – Project and Resource Planning – and for each of them, I linked the CDS view data fields that should be displayed to the user.
Last but not least, I chose the navigation targets defined in the situation object as trigger-specific actions.
Situation Template: Unstaffed Resource Requests
Based on the scenario, you can now configure your custom situation template and situation type in the Manage Situation Types – Extended app. In the situation template you can define the default notification text, any default condition filters, and add the team category and responsibility rule (or rules) from the responsibility context.
I created the Unstaffed Resource Requests situation template based on the Resource Request Status situation scenario and added the batch-based trigger from the scenario to this template.
For the batch-based trigger, I defined one condition with a couple of default configuration values. This use case generally focuses on requested team resources with status pending. That’s why I maintained those as default parameters to be included in subsequent situation types.
Furthermore, in the Situation Display section I entered the situation text that appears at the top of the situation page, the notification text, and the public text used for email alerts.
Under Navigation Actions, I defined the relevant navigation targets for this trigger. These are offered as buttons on the situation page in the My Situations – Extended app under Related Apps.
Batch job scheduling
Whenever you’re working with batch-based triggers, you’ll need to schedule a background job. You have the flexibility to schedule different recurrence patterns for your batch jobs. I chose to run the job daily at 9:00 AM GMTUK.
To determine the users responsible for the situations, I added both the custom team category and the responsibility rule Notify Project Manager to the situation template.
Situation Type: Unstaffed Resource Requests for Customer Projects
The final step is the creation of the situation type. Depending on your business requirements, you can create as many situation types as needed from the template.
Here I want to inform project managers about resource requests in ongoing customer projects that are not staffed yet, although the activities are set to start in the next 30 days. To do that, I created situation type Unstaffed Resource Requests for Customer Projects in the Manage Situation Types – Extended app.
I made a couple of adjustments to the content inherited from the situation template, specifically to the situation trigger. I maintained additional filters for the project type (customer project), project stage (in execution), and resource request start date (in the next 30 days).
Additionally, in the trigger-specific actions, I removed the navigation target for internal projects since we are focusing on customer projects.
After enabling the situation type, the configuration to get this custom Professional Services use case running in SAP S/4HANA Cloud is complete.
Step 5: Prepare your business data and test your custom use case
Once your custom situation is defined, you need to test it to make sure that it produces the results you expect. To do that, you need to create the conditions that will lead to the situation. So, make sure you take into account the condition filters established in the situation type when preparing your test data.
If you’re assigned as the project manager, you’ll be notified about the unstaffed request and have access to the situation page. Here’s what the outcome looks like:
Once you’ve successfully tested the use case in quality, you can transport your situation objects, scenarios, and types to production through Software Collection.
In this blog post, I have provided an overview of the steps that you need to follow to enable the custom use case Unstaffed Resource Requests. This is only one example of how you can use our 5-step approach to create custom situations. Stay tuned for more use case examples.