The following, I'd like to give an overview of the different features, and modules of the One Identity Manager ACP support. The One Identity Manager ACP support consists of the One Identity Manager, ACP connector, and the SAP HANA Connector. The ACP connector contains the following modules, and add-ons. The SAP R3 basis module provides ACP user, and role management capabilities, and R3 content data connection features. Basic ACP current lifecycle management is performed by this module, or direct as well as CUA connections. The ACP R3 Compliance Add-on sits on top of the basis configuration, and provides compliance-related capabilities.
It provides the capability for ACP role, and profile content analysis, and segregation of duties. Transactions, authorization, objects, or fields, and values will be analyzed for rule checking by this add-on ACP R3 analysis authorization add-on sits on top of the basis configuration, and provides ACPPI analysis authorization management capabilities. The R3 Structural Profiles Add-on provides support for sub HCM structured profiles.
When we look into the details, you can see that the add-ons, and different content, and capabilities to the system. For example, the ACP basis knows about systems versus clients, and about ACP roles, and users. So as you can see SAPSystem versus SAPMandant is the German word for client. The CUA support adds additional information about ACP users, and on which clients these users are provisioned. SAPUserInSAPMandant is the table that will provide this information.
The compliance add-on provides additional to the rights, and authorization editor to create ACP functions to be used in compliance rules to evaluate toxic permission combinations. The HR add-on on provide capabilities around personnel planning data, and structural profiles, and will provide the capability to write back data to the ACP HR system.
A very common request we get from HR department is the lack of information back flow from enterprise systems. The HR department does not get employee-related communication data back from other systems. While identity manager's ACP connector is capable of writing back this information into a CPA chart. This is the only write operation to the ACP HR system, and will only affect the info type communication data. Further looking into the detail, the system will reveal that One Identity Manager connect to also takes the visibility of objects into account.
There are system-wide objects like licenses, parameters, printers. And there are client wide objects like user accounts, user groups, rolls, and profiles. When we look into the CUA, we will see that the synchronized system is a ACP CUA central client, and it manages four CUA child systems. Three child systems are on the same system in this environment the system is T03. And one child system-- that is on a different system. Here the system, T01.
In order to connect to an ACP system, we first need to prep the environment. First up here, is to check the ACP kernel version. We are interested in the release version of the installed SAP kernel whether the installed system is a Unicode system or not, and the name of the database. Once we have verified that the system is being supported by the ACP connector, we need to apply the One Identity Manager ERP modules to the client you're going to connect.
In order to do this, we need to import transport files. These transport files will be provided with the One Identity Manager software distribution, and can be imported using DSAP transaction STMS. This transaction requires special permissions, and will normally be performed by the ACP base team of the customer. When the ACP transport management system is being started, the information about the system, and the transport domain will be displayed. Again, this will be performed by the ACP admins, and is only required once for the client.
In the following process, the input queue can be selected. And the transport packages can be added to the queue. The input of transport are performed by request. Going to the extras menu, other requests at, and then the system will show the list of available transfer packages on the system. One Identity provides for packages. After selecting the transport package, it will be added to the queue.
Now from the queue, the transport package can be selected, and additional detail information can be provided like to target client on the system, when to import this package, and additional information. Some transport packages might have warnings that can safely be ignored. As you can see, the four packages provided by One Identity Manager are SAPRepository. The SAPRepository creates the init name-space in the ACP system repository. The SAPTable. The SAPTable defines the table structure for fiat init users, and the ACP system dictionary.
The SAP transport contains the functions defined in the name-space. There is Unicode, and the non-Unicode version of the transport. Select the transport package that suits your ACP system. Lastly, the ACP role contains a convenience role for ease of use. This all can be assigned to the service account, and will contain all the necessary permissions for the connector. Sometimes, customers do not want to use the provided ACP role, but create their own role. For this case, they require permissions as described in detail in the ACP connector documentation.
Once we have the One Identity Manager module installed on the client, we need to create a service account for the one Identity Manager connect. To create a user in ACP user transaction as user 1, and provide the user name to create, and click the create icon.
Using the user creation dialogue, the details of the service account can be provided. Specific detail, is the user type to verify. For production systems, the user type will be most likely system. For development systems, create a user type dialog. This will allow you to look in this user using the SAPQuery, and check if there are any issues with the user's permissions if necessary.
And don't forget to assign the service account to required permission. If you have imported the SAPRole transport, provided by the One Identity Manager installation package file, the role name is via init sync. If the customer has decided to create his own role, please use that role.
Now that the ACP client has been prepared, we need to configure the synchronization with One Identity Manager. In One Identity Manager's connector configuration tool, the synchronization editor, create a new synchronization project. From the list of available connectors, please select ACP connector, and follow the instructions of the configuration visit.
The ACP R3 connection type screen is of special interest for the configuration of the different connection options, or a different deployment of an ACP system. You can select if you want to connect directly to an application server, or access to system via a router, or if you need to connect with messaging server. In most cases, it will be the application server, so it is a direct connection. If a message server is used, you will get the detailed information from the ACP basis administrative.
Depending on the selected options, the next screen will ask for different information. Here in this case, it is a direct connection to an application server, or a router. And the information for this kind of a connection are being required. These are the host name, or IP address of the host, or the router, the system number, and the system ID.
The necessary information, and once again will be provided to you by the ACP basis admins.
One Identity Manager also supports an SNC connection to the ACP system. Secure network communication, or SNC protected data communication, paths between various clients, and server components of the ACP system. Did it use the ACP protocols RFC, or DIAG. And provides single sign-on capabilities with external systems like for example, Active Directory.
SNC implements well known cryptographic algorithms to encrypted communication. Finally, the client specific information are required. The client ID of the client that are going to be managed from One Identity Manager, as well as the service account name, and the password.
Once the information are entered, a connection test can be performed. If the connection succeeds, the next steps of the connector configuration can be performed. If the information-- if this client is a central user, administration's central client instance can be configured by checking the box. One Identity Managers ACP connector can be extended if needed. It is very common that customers have extended the ACP standard schema, and have added custom tables, and attributes. These so-called z-tables might contain relevant information that needs to be maintained via One Identity Manager.
One Identity Manager connector provides the capability to extend the existing schema with additional schema objects, and attributes. The schema extension file is an XML document that describes the additional schema objects, and the different methods to list, read, or write information. A sample XML schema extension file can be found in the One Identity Manager SAP documentation. Schema extensions can be provided by support, or by experienced delivery persons.
Once space connectivity to the SAP system is being established, the ACP synchronization template must be selected. In identity management system, the essential information that needs to be synchronized are the identities, and the organizational structure. ACP HCM provides the HR, and OM data that can be used in One Identity Manager to represent the enterprise's organizational structure, and the employee, or identity data in One Identity Manager.
In order to synchronize the HCM Data, the ACP R3 ACM employee objects template needs to be selected. This will create a synchronization template with the required schema objects, and attributes, and metrics between these objects, and attributes in ACP, and One Identity Manager.
If a red tag of communications data is not required, the connection can be configured as read-on. In the case of redirect configuration of the ACP HCM template, only the info type 105 communications data will be returned back to the ACP HCM. In this case, each email address, or phone number change in the identity management system will be provisioned to the ACP HCM system. When the configuration has been finished, the project template can be saved, and activated. This will create a synchronization configuration, including a schedule that can be activated for periodic synchronization of HCM Data.
Now that the synchronization for HCM OM data has been configured, let's have a look into the data in SAP HR, and how the data is represented in ACP. You have to understand the structure, and data model of the ACP HR, and OM, in order to understand the implications of this model in the One Identity Manager data model.
To start with, let's have a look into the data model of organizational units in ACP. In ACP OM, the enterprise structure consists of multiple objects. The building blocks of organizational management are also called SPOC. S, stands for position. For example, customer services representative for region South, or for region Southeast. P stands for person. This is the employee representation. And O, stands for organizational unit, or org unit. It represents the department in a company. C, stands for job. For example, customer services representative.
The job describes a job class like customer service representative, or pre-sales architect. The position however, is a specific instance of a job like customer services representative for region South, for region Southeast, or pre-sales architect one, or pre-sales architect two. It is the specific opening linked to an organizational unit. The position is an instance of the job in a specific organization. In SAP OM employees, or persons are not assigned directly to an organizational unit, but to positions.
With the one to one linking of a position to an organizational unit, the employee, or person is indirectly assigned to the organizational unit. A position that is linked to a specific organizational unit, can be marked as head of owner organization. Any person occupying this position will be the Department Manager, or the head of the organizational unit.
An organizational unit can contain other organizational units. The position is being assigned to an organizational unit, and is an instance of a job. A cost center can be assigned to organizational unit, or to position as a master call center. A person can be assigned to a position. Each relationship is reflected by a number like 002 for a hierarchical assignment between organizational units, or 002 for assignment of position to an organizational unit.
The relationship numbers are preceded by an A, or B for the direction of the link. From an Identity Manager perspective, the position can be considered as the primary business role. There is some discussion whether it's the job, or position. But if you assume the position is the primary business role, we have to consider some special cases. In ACP OM, a person can occupy a position partially. During the assignment, a percentage can be provided. This position can be shared by two or more persons. This is going to become interesting for the position marked as head of its own organizational unit. Special configuration needs to be applied in this case.
In ACP, there are some org management transactions we should be aware of. The organization, and staffing menu contains the following transactions. PPOCE will allow the creation of organizational units. PPOME will allow the modification of organizational units like renaming, assigning other positions to the organization in units, et cetera.
And PPOSE, which is the one that is most relevant to us, is to display the information of an organizational unit. To review the organizational unit setup, please use this transaction. There, we looked into the organizational units data model. Let's look into the person or employee representation in ACP HCM.
AP's data model for employees is comprised of the main employee record which contains basic employee information, and additional records in so-called info types. For example, an employee personal data, and address information are stored in a different input type. Or his bank details are stored in a separate incident. This provides great flexibility to the system, and auditing historization capabilities. For example, if an employee changes his organizational assignment, or his bank account number, any entry will be created with the new information, and marked as active, and the old information is still available for reference.
Here's an incomplete list of the info types. The list of information stored in the ACP HR is complete, and contains more information than needed in an identity access governance system. We don't need to know an employee's bank details, or basic pay, or payroll status information. This is relevant for HR operations, but not from an IG perspective.
Some others on the other hand, might be interesting depending on the customer's requirements, like leave information, et cetera. One Identity manager's default permissions will not fetch information on info types that are not directly needed for the operations of Identity Manager. Often, customers are concerned that the service account might see more than needed. The connector is not accessing other information, and the permissions are not allowing to access those sensitive information.
I was explaining previously, the info types contain the current, and all previous entries to an employee. Each info type record contains a validity start, and the validity end date. In this example, the employee has two records in the organizational assignment info type. This is the info type, 001. The first organizational assignment record starts in June 1999, and ends on October 2000. And the second record starts in October 2000, and ends on December 31st, 9,999.
December 31st 9,999, is the last day in every record in ACP. I hope there are still ACP experts around when we reach that date. Otherwise, we will have another year 10,000 problem. How are these records being created? ACP de-limits or ends the previous record the day before the new record takes effect. When HR admin enters a new record, the system automatically de-limits limits, or ends the currently active entry by putting the day before the new record takes effect as the validity end date, and puts validity end date of the new record to December 31st, 9,999, if not specified otherwise.
The system ensures that no records can be valid for the same time period. In this example, it highlighted a permanent address record for the employee will be created with the validity end date of December 31st, 9,999. This is the black hole at the bottom of the slide. Sometime later, the employee moves to a new address. The HR department creates a new permanent address record effective immediately. This will lead to the ending of the previously active record on the day before, and the new record will be set active until December 31st 9,999. This is the vertical red line interrupting the black line at the bottom, and the horizontal red line depicting the new valid entry.
Sometime later, the employee announces to the HR department that it's going to move to a new address on the first of the next month. The HR department creates a new permanent address record effective on the first of the next month. This will again, lead to the ending of the previously active record on the last day of this month, and the new record will be set active from the 1st of next month until December 31st, 9,999. This is the vertical green line interrupting the red. This is also called future dated event.
At any time, there is only one active record in the system. But the system can contain past, as well as future events. All this information is stored in the info type table, and it is the connectors responsibility to fetch the currently active, or valid entry from this list. One Identity Managers ACP connector handles these info types, and always fetches the currently active entry from ACP. However sometimes, these future dated events are of interest to some of our customers as well.
In case they want to run workflows in One Identity Manager before some entry is becoming active, One Identity Manager provides the capabilities to analyze these future data events, and the ability to act on these future data events. For example, if an employee is going to move department in two weeks, a special workflow can be triggered depending on the customer's requirements.
ACP had some personal administration transactions you should know of. The HR master data menu contains the transactions. The most common, or interesting from an identity governance perspective we should be aware of are PA20 to display personal data, and PA30, maintain personal data. Be aware of that.
Now how is the ACP data mapped into One Identity Manager schema? The employee, or person object in ACP is represented by the schema object HR employee underscore active, and will be mapped to the person object in One Identity Manager schema. / Some attributes are personal number, primary department, first and last name, et cetera.
The HR person 0041, so info type 0041, date, specifications, and is mapped to person in One Identity Manager schema. Some attributes here that are mapped are entry date, leaving date, technical entry date. The HR person 105 info type, this is info type 105 communication data, is mapped to the SHPersonComData object in One Identity Manager schema. Some of its attributes are account, or email.
The HROrgUnit schema object is mapped to the department in one Identity Manager schema. Some attributes here are object ID, and department name. And the HROrgUnit manager schema object is mapped to department in One Identity Manager schema as well. It will set the department manager information. This thing is set up out of the box, and does not require any configuration.
Now, when you're looking to details in the schema object, and into the synchronization editor tool from One Identity Manager, we can see the available information for our synchronization. In the case of HROrgUnit, which is mapped to department in One Identity Manager, we can see the validity start date, end date, the change date, and the object ID of the organization unit. This is the unique key in the ACP system. As you might remember from the previous slides, in the SPOC model, O, represents the organization. So the object ID is prefixed with an O.
When we look at HROrgUnit manager, which represents the information who is the department manager, we'll see the triple of objects needed to resolve this. The org unit, ID, the position ID, and the employee ID.
The HR employee active schema object contains the active employees. Here, we can see yields like employees full name, personnel number, his position, et cetera. We'll also see more details in the HR employee active schema object. The fields are grouped by the info types, the connector has access to. You can see the attributes coming from info types 0032 internal data, and info type 105 communications data.
The synchronization editor will show all the attributes with the values from all the access to info types. Since the connector doesn't resolve the currently active entry automatically, the past or future entries for a person are not mapped. And for that reason, not automatically visible in the default list of mapped schema objects. The information is however, available to the connector if needed.
In this example, the full schema is displayed. And in the schema object, HR person in all, you can see that all organizational assignments of a person. This information can be mapped, and synchronized if the customer has a specific use case.
As you can see here, that the dummy test user has three entries in HR person in org, and these are marked with different validity dates. In the extended schema, all available positions can be viewed as well. Depending on the customer requirements, these positions can be synchronized as primary business roles of employees.
The schema object HR person 0709, info type 0709 person ID, identifies employees with multiple records, or context. This will allow to synchronize employees with multiple work contracts into individual person objects in One Identity Manager, and to establish the relationship between them using master SAPIdentities.
25:24