SAP Multichannel Foundation for Utilities and Public Sector: User Management Overview

[yevgen_trukhin]

Introduction

In this blog I will explain user management approach delivered in standard SAP Multichannel Foundation for Utilities and Public Sector on a high level. The solution uses the user management based on SAP Gateway. A self-service user is created as a communications type user on the SAP Gateway system with a password (visible in SU01 User display transaction). Corresponding user entries with the same user name are also created in SAP ERP and SAP CRM (as well, SU01) with password deactivated. Potential landscape with standard user management could look like this:



SAP Gateway provides a set of OData services for user request creation, password reset, and password change (when logged in) processes. SAP Gateway is based on SAP Netweaver ABAP technology; user management and authentication is done in the same way as for any SAP ABAP system.

If standard user management is not suitable for your scenario due to limitations, you have options to integrate SAP IDM or other 3^rd party identity management solutions that can provision users into SAP systems. There is a series of blogs written by Olga Esipova on how to integrate IDM solutions.

Overview of OData services

I will explain the functionality based on scenario where SAP CRM is a leading system. However, for SAP ERP only scenario, the user management behaves in the same way. Instead of service CRM_UTILITIES_UMC_URM, ERP_UTILITIES_UMC_URM should be used. /IWBEP/USERREQUESTMANAGEMENT is available on both SAP CRM and SAP ERP.

User Request OData Service CRM_UTILITIES_UMC_URM

This service is an extended service which inherits from SAP Gateway /IWBEP/USERREQUESTMANAGEMENT service. This service performs two main functions: user creation processing and reset user password processing.

User creation works in two phases:

Phase 1:

1. User sends a user creation request based on contract account/business agreement ID and email (existing customer scenario)


2. Alternatively, user sends a user creation request with new business partner record to be created as well (new business partner scenario which is used in deregulated scenarios)


3. User request creation and validation happens on SAP CRM as a leading system


4. Email is sent in case of successful validation with a link to an HTML page which calls OData service to create a user.

Phase 2:

1. User clicks on activation link which launches the browser that opens an HTML/SAP UI5 page which performs an OData call to activate a user on all systems.


2. User creation is performed on SAP CRM, Gateway, and ERP. It can be done in asynchronous way with background RFC then user would not know immediately if the user was successfully created or synchronous way via standard RFC with immediate feedback.

Reset password works in two phases:

Phase 1:

1. User triggers a reset by supplying user name (there is no support at the moment for forgotten user name but it can be implemented by extending the service)


2. Email is sent with a generated temporary password to the email address  of a business partner linked to the user

Phase 2:

1. User is forced to change password upon log on with a temporary password (this is done automatically by SAP Gateway).

 

I want to stress upon last point since this step is not done by an OData request! It is executed automatically by the server when the server detects that the password needs to be changed. If you develop any custom UI (not SAP UI5) instead of our standard delivered UI, you would need to implement the change password UIs that should be provided by SAP Gateway. The class on the ABAP side responsible for generating login and change password screen is /UI2/CL_SRA_LOGIN. You can inherit it and put your own logic for UI screens for login/change password.

The following OData entities and function imports are inside this service:



This service has to run in the context of the service user, which should have rights to create users.

The following main fields were added by us for user request validation:

• EmailID


• BusinessAgreementID


• AccountID (optional)


• Fields passed on to create a BP in the system in case this scenario is supported

You can add your own logic for user request validation and extend the structure if needed. One useful SCN blog about customization and configuration can be found here.

User service /IWBEP/USERMANAGEMENT

The purpose of standard SAP Gateway service /IWBEP/USERMANAGEMENT is to provide user information when a user is logged in, for example, which user group it belongs to. Additionally, it provides a password change functionality when user is logged in.

OData entities and function imports of this service:

Authentication

User authentication happens against SAP Gateway. On SAP ERP and SAP CRM, user has a reference to a business partner which is necessary to establish user identification and maintain security. While SAP Gateway supports many different types of authentication which you can choose in your project, the default one for our delivered UI template applications is a form based authentication over HTTPS. When the user asks for index.html of our SAP UI5 application on the WebServer, SAP Gateway Server will render a login page. The logic of rendering the login page is controlled by /UI2/CL_SRA_LOGIN class on the SAP Gateway. There is more explanation on how to customize the login pages in the Administrator’s Guide.

FAQ

Is there a requirement to have users created in SAP Gateway, ERP, and CRM systems?

In our standard delivery, users need to be represented as communications users in SAP Gateway, ERP and CRM with user references maintained to point to correct BPs (only on CRM and ERP). Any alterations to this approach require careful security design for your integration scenarios.

 

Will there be a user state maintained for each logged in user? What about system scaling with many concurrent users logged in?

 

No, OData calls are RESTful meaning that they are stateless. There is no user state maintained between OData calls. The stateless nature of OData calls definitely helps to scale the system. Please check the Sizing Guide for our suggestion on system hardware requirements.

 

How do I debug user management OData requests with communication user?

Communications user type means that the user has no access to the SAP system in dialog mode as well as there is no way to perform debugging with that type of user which might be important when you are setting up the system. For debugging during the system setup, switch the user’s user type to a dialog one and assign proper debugging privileges (should only be done on test systems). Please use the external breakpoint with immediate activation for successful debugging. Also, a common mistake is trying to put a breakpoint for user alias. You need to put a breakpoint for actual user ID which you use for testing.

I’m testing user management OData services and something doesn’t work. Where should I check for issues in my setup?

Most of the time, the problems are related to configuration of OData services and service user authorization profile setup. I hope you followed the Admin Guide. The tools that you can use for tracing:

1. Check in transactions /IWFND/ERROR_LOG on SAP Gateway and /IWBEP/ERROR_LOG on SAP ERP or SAP CRM depending on which system is a leading system for you. These transactions will show you the error traces for service executions and might help to pinpoint a problem.


2. Check SU53 authorization trace to see if your service user is setup correctly.


3. In the worst case, it is still good to do good old debugging. External breakpoint in service user context should help.

Conclusion

I hope this blog makes it clear how standard user management works; there will be further blogs on the topic of user management.