In this blog I would like to provide an overview of how IdM 7.2 has enabled SAP to manage its massive amount of Distribution Lists which are part of day to day business operation. While some technical aspects are covered, I will focus mostly on the business value that IdM 7.2 into the solution.
Background
SAP internal Distribution Lists (DLs) were previously maintained using a very old implementation of R/3 portal(a.k.a SAPNet). This system introduced a risk to business operation as it was too old and the hardware/software stack was already at the end of their life cycle. As a result, Global IT decided to define a project for the migration the processes and data over to other target platforms and retire SAPNet completely.
As the delivery manager and head of IdM competency center in one of the IT application teams(i.e. Social Collaboration Platform), I had the responsibility of providing a retirement path for SAPNet, manage the planning and oversee the execution of all the work streams within the scope of the retirement project. One of the work streams was indeed Group Management which required us to migrate all legacy DL data as well as relevant processes to another system. SAP Netweaver Identity Management 7.2 was confidently chosen as the product for DL management.
Pre-Migration Status
In large companies such as SAP email communication is key. As such, timely creation and availability of Distribution Lists are always critical to the success of business. Aside from the initial creation of DLs, the ongoing changes to DL hierarchies as well as user memberships, involve a lot of effort and overhead costs if the process were to be dependent solely on an IT support function within the organization.
At SAP, there are also some special type of DLs which are used for security purposes (rather than pure communication). These DLs are built automatically based on a controlling attribute (i.e. cost center) with some complex hierarchy. The DLs are then used by internal applications to enforce authorization.
In order to overcome the challenge and complexity, SAP had implemented an integrated solution comprised of the following components many years ago:
- An application with an end-users interface for self-serve DL management(SAPNet).
- One or more source systems to build DL memberships automatically in the back-end based on some business-centric criteria and replicate the DLs to the main repository. An example of the criteria would be “A DL which includes all sales managers”.
- A process to replicate all creation/updates/deletion of DLs from the main repository into corporate Active Directory.
- A set of APIs to expose DL data to other internal systems that would need to either read from or write DLs into the repository(i.e. RFC enabled Function Modules in SAPNet).
All of processes had to be re-implemented based on IdM 7.2 and all legacy data migrated to IdM 7.2 Identity Store before those process could be retired on the old SAPNet system. The analysis and planning to establish the correct sequence for both process and data migration was enormously complex due to various reasons such as quality of legacy data(i.e. hierarchies with loops etc), limited documentation of the old processes(developed more than 10 years ago), etc. In this article we will focus on the solution itself rather migration activities.
IdM 7.2 Takes Over
Now the fun part begins! That is to design an architecture which can not only satisfy the current requirements of our project but also lay a solid foundation for future growth. To achieve this, project team decided to utilize an internal cloud platform that offers Continues Delivery and DevOps.
This decision posed a huge challenge for the project as we had to work within the boundaries of product features as well as budget & timeline but the effort worth it. At the end, we were able to automate server setup and deployment of IdM Identity Center, Run time and Database host. What a pleasure!
A completely new landscape (i.e. development environment) could be built from scratch with the most recent code/configuration in less just a few hours! Although, I have to point out that the server setup and deployment to Netweaver UI could not be automated due to time constraints.
Let’s review the architecture and examine the role of IdM 7.2 in the enterprise level distribution list management solution:
Some business processes rely heavily on DLs that are generated in SAP business systems based on some criteria (as opposed to creation or updates by end-users). Those DLs need to be replicated to AD before they are usable. To achieve this and in order to achieve a federated approach for DL provisioning to AD, IdM 7.2 sits in between the business systems and AD. Two Virtual Directory Servers have been implemented for this purpose:
·
- The first one is generic one which enables any application within the corporate network to connect to IdM and create or update DLs. This VDS is fully scalable and can handle multiple clients in parallel while enforcing necessary logic to maintain data ownership per client. Currently, SAP’s HR as well as a reporting system are connected to this VDS and pushe their DLs to IdM several times a day. DL memberships are determined according to some criteria before the updates are replicated to IdM.
- The second VDS is very specific and implemented exclusively for another instance of IdM (called IT IdM) which is in charge of user/role provisioning to SAP Business systems. The IT IdM pushes pre-defined DLs used for authorization purposes to this VDS multiple times a day. The same VDS is also receiving user data updates from the IT IdM system.
- As I mentioned in the beginning of this blog, a self-serve interface for DL management is required to avoid dependencies on an IT support function for every single change. Our self-serve solution is a Web UI application that is fully integrated with IdM. The integration between IdM and WebUI is bi-directional:
- An in-bound connection has been implanted using a VDS in which the Web UI pushes all end-user updates to IdM and from there to AD.
- As for the out-bound integration, the Web UI is exposing some RESTful APIs. These APIs are called by IdM provisioning to replicate any updates from other source systems to the Web UI. This way all the back-end DLs are also visible to end-users. However, they are all displayed in read-only mode as the owner of such DLs are the upstream systems (and not the end-users).
IdM 7.2 Netweaver UI is used as an administration interface. Here some custom UI tasks have been implemented to cover the necessary functionalities for our support 1st and 2nd level support colleagues. The custom tasks enable to check on the replication status of DLs( both inbound and outbound) as well as enhanced DL maintenance functionality(compared to Web UI functionality available to end-users).
A set of Java-based RESTful APIs have been developed and hosted on NW host. These APIs enable other applications to query IdM DB, search for DLs and read DL attributes. A wide range of parameters and options are available to suit the needs of the client applications.
The most critical and complex integration is the outbound connection from IdM to the corporate Active Directory. Although IdM 7.2 offers a connector to AD out-of-the-box, due to some specific data replication requirements, we had to develop a custom LDAP connector. This connector consists of a set of Java components , IdM jobs, and custom DB tables. A queuing mechanism has been implemented to ensure all updates are processed in order and can be re-pushed to AD in case connectivity is lost.
The IdM DB utilizes SQL Server 2008 which was originally hosted on a cloud VM. Both the host and DB used to be built & deployed leveraging DevOps Chef scripts. However, overtime the VM reached its I/O limits due to high volume of updates and consequently the db performance degraded. After reviewing different options, we came to a conclusion that a physical host would be a better option long term and moved ahead with the change.
Each of the integrations has one of more corresponding jobs that run according to their schedule. Some require more frequent executions that others. Additionally, there are some stand-alone jobs that cover other areas of functionalities such as DL generation based on cost center controlling attribute in IdM.
The summary above is of course a simplified view of the architecture but I hope it can give you an idea of how IdM 7.2 supports business processes related to DL management at SAP.
Now let’s look at some statistics.
The Stats
It is always useful and interesting to gather some statistics and better understand the usefulness of a solution. Below are some figures I have gathered recently:
* Note that there are many DLs with a nested hierarchy whose member count is not included in this table.
The chart below shows the size of the AD connector queue size over a 24 hour period (Dec. 3rd, 2013):
The Bottom Line
The implementation of SAP IdM 7.2 for Distribution List management did not come easy. There were many challenges along the way from the early stages when a blueprint was produced all the way to the implementation, go-live and the support afterward. The effort, however, was worth it as critical business data and processes were migrated successfully to IdM from a very old legacy system. SAP IdM 7.2 has been running since late Q1 earlier this year and continues to be the backbone of DL management for years to come. The implementation has been a true example of "SAP Runs SAP” program.
I hope you have found this blog useful. Please feel free to post your questions or comments and I will be sure to address them accordingly.
Ali Ajdari
- SAP Managed Tags:
5 Comments
