Over the last couple of months we've received a few emails asking how UserXpress works and why there's no need for any transports or configuration changes. In our UserXpress FAQ, we touched on how this is accomplished and we thought it might be best to go into more detail and explain how end-to-end communication is achieved and why UserXpress is so effective in what it does.
Why is there no need for Transports?
The SAP Identity Management module in all ABAP & Java based solutions (ECC, BW, Portal, CRM etc.) provide a series of interfaces called API's that allow Identify and Access Management (IAMs) vendors - such as 1905 - to manage SAP users and profile/role assignments. By calling these API's, 1905 doesn't need to deploy any Transports with UserXpress and is why UserXpress works right out of the box.
What is the Identity Management API?
The API for ABAP-based solutions is provided as a Business Application Programming Interface (BAPI) and is implemented as a Function Module. The Identity Management module provides a series of Function Modules that allow for identity management e.g. BAPI_USER_GET_DETAIL - but which can be remotely called by another SAP system or an external application.
The following screenshot shows a function module that is used by UserXpress and shows how the function module is enabled for remote calling by an external application. All BAPI's used by UserXpress have the option "Remote-Enabled Module" active.
How does UserXpress communicate with an SAP System?
The graphic below shows the communication path to and from an SAP system. Though it might look complex, it is quite simple in nature and ordinarily takes less than a second to execute.
For this scenario let's assume a Security Analyst wants to add the Parameter 'SCL' with the value 'X' to an SAP User ID using UserXpress.
1. To begin, the Analyst will add the Parameter to the User ID in UserXpress. When the analyst clicks OK, the request is sent to an SAP certified* interface. (1905 chose Theobald Software for their lean, robust and secure product - ERPConnect). Here the technical aspects of the request are validated before being passed on to the SAP Communications Engine.
2. The SAP Communications Engine is an essential part of the SAP GUI (hence why UserXpress is dependent on the GUI being installed) and is responsible for relaying requests from the Analysts' PC and the SAP system.
3. When UserXpress logs on to an SAP system it registers itself with the SAP Gateway on the application server to which it connected to. All requests from UserXpress will pass through the Gateway first and then on to the Dispatcher queue.
4. When a free Dialog Workprocess becomes available the Dispatcher will assign the request to it. The RFC request is examined to find out which Function Module (BAPI) should be called. In this example it's BAPI_USER_CHANGE.
5. The Workprocess first ensures that the Function Module is enabled for remote-calling, if not, an error is passed back to the calling application. Assuming all checks are in order, the Workprocess runs the Function Module that was called. It is at this point the Parameter 'SCL' is added to the SAP User ID.
6. When the function module has completed, the Workprocess passes the result back to the UserXpress entry in the SAP Gateway table.
7. The SAP Gateway relays the result back to the SAP Communications Engine (librfc32.dll) of the SAPGUI where it is parsed and formatted into readable form by SAPGUI and 3rd party applications.
8. In this case, the result is passed back to Theobald Software's ERPConnect interface where the response is reformatted into Microsoft .Net readable form.
9. Finally, the result is passed back to UserXpress where the outcome of the Parameter assignment is shown to the user.
*SAP Certified Integration with SAP NetWeaver
We hope this clarifies the communications model employed by UserXpress and gives you some insight into how the application seamlessly works with any SAP system.
Again, thank you for spending some time with us,