1.6 Publishing to the Identity Vault

The SAP HR system is the authoritative source of HR data, and can propagate all Add, Delete, and Modify object event data to the Identity Vault. The Publisher channel is the component used for propagation.

For data to flow from the SAP HR system, the driver utilizes the SAP ALE technology to publish HR Master data records and captures incremental changes using change pointers. The HRMD_A message IDocs are transported by using a File port that stores the IDocs on the SAP host system. The driver handles the parsing and filtering of the IDoc file, and provides secure transport of the data to the Identity Vault. Only data elements specifically selected by the system administrator are transported from the host system to the Identity Vault.

1.6.1 IDoc Consumption by the Driver

The driver consumes only Output IDoc files with the client number that is reserved for the driver, thus ensuring the privacy of other IDocs that might be generated by another driver configuration. Only the IDoc attributes that have been specified in the driver’s Publisher filter are published to the Identity Vault.

The format of a successfully published IDoc file is:

(O)utput>_<client number>_<consecutive IDoc number>

For example:

O_300_0000000000001001. 

After the specified attributes have been published, the filename of the IDoc file is modified to reflect the status of the publication processes. The driver caches the status of every event and associates the status with the object information in the IDoc. If multiple objects are processed from the IDoc, there might be multiple output files with different extensions created.

The following table lists the IDoc status and corresponding suffix:

IDoc Status

Filename Suffix

Processing, but not published

.proc

Processing, but not published (future date IDoc)

.futp

Processed successfully and published

.done

Processed with an error or warning

.F.fail or W.warn

Processed with corrupt or illegitimate data

.bad

Process on date shown in timestamp

8 digit timestamp.futr

You should determine what action is required, if any, after IDoc publication is complete.

Removing the filename extension makes the IDoc available for re-processing.

If a policy generates multiple events from one object, the worst-case status is cached for the IDoc object. For example, if an IDoc contains data for Person object 00001234 and that data triggers policy events for the Identity Vault User, his Job, and his Position, three separate <status> elements are returned. If two of the events have a success status, and the third status is warning, the warning status is used.

After all of the objects in the IDoc have been processed, the driver creates output files based on the status of events. If the IDoc contains warning status events, an IDoc file is generated containing all of the objects whose status was a warning. The name is a concatenation of the original IDoc name and a W.warn extension (for example, O_001_0002 becomes O_001_0002W.warn.) In a similar fashion, if the original IDoc contains error or fatal status events, a file with an F.fail extension is generated with those events in it.

To reprocess the IDoc, remove the extension. The use of the X character before the extension helps ensure that subsequent reprocessing events do not overwrite the status files from the previous processing attempts.

1.6.2 IDoc Object Types Consumed by the Driver

Object types vary from system to system and can include objects such as Person, Job, or Organizational Unit. The driver allows the administrator to configure which object types can be processed by the driver.

Only object types specified in the configuration and object types that are in the Publisher Filter are processed. The driver parses the data for each object individually and transmits the data to the Metadirectory engine as a single transaction.

NOTE:If SAP connectivity is specified, the driver attempts to populate empty Publisher values by reading values from the SAP server. This only occurs if the Metadirectory engine requests more data (via a query request) when trying to complete an Add event operation.

1.6.3 Attribute Mapping from the SAP HR Database to the Identity Vault

Schema mapping is used by Identity Manager to translate data elements as they flow between the SAP HR database and the Identity Vault. The SAP HR schema is based on the SAP HRMD_A message type. The schema map contains all attributes of the various data infotypes in the HRMD_A message types.

Several of the HRMD_A infotypes could be instantiated multiple times on the HR personnel records. Infotypes such as P0006 (Private Address) and P0105 (Communication) might be used several times to indicate unique subtypes. The Private Address infotype might have, for example, Home, Work, or Temporary subtypes. The Communication infotype might contain Cell, Pager, EMail or other subtypes. The Identity Vault administrator can configure the driver to receive whatever subtypes of P0006 and P0105 infotypes are desired. The SAP HRMD_A messages that are generated by the SAP HR system are posted in the form of a text file. The schema map also contains the file position offset and length of each attribute in each segment of infotype data.

This information is presented in a schema map. The map elements have the following format:

<Segment Infotype>:<Infotype Attribute>:<Infotype Subtype> or none: <Segment offset>:<Attribute length>

Table 1-1 lists a few examples of maps between SAP HRMD_A attributes and Identity Vault attributes. The Infotype P0002 attributes have no possible subtypes. Infotypes P0006 and P0105 have a configurable set of subtypes.

Table 1-1 Attribute Mapping

Identity Vault Attribute

SAP HR Attribute

Given Name

P0002:VORNA:none:134:25

Surname

P0002:NACHN:none:84:25

City

P0006:ORT01:US01:133:25

Home City

P0006:ORT01:1:133:25

Internet EMail Address

P0105:USRID:MAIL:78:30

Mobile

P0105:USRID:CELL:78:30

Pager

P0105:USRID:PAGR:78:30

Home Phone

P0006:TELNR:1:195:14

The driver only utilizes configuration for Private Address (0006) and Communication (0105) infotypes. Mapping of additional instance-specific infotype attributes might create errors caused by a many-to-one object relationship.