1.2 Driver Concepts

The driver is a bidirectional synchronization product between SAP R/3 and Enterprise R/3 systems and the Identity Vault. This framework uses XML and XSLT to provide data and event transformation capabilities that convert Identity Vault data and events into SAP data and vice-versa.

The Identity Vault acts as a hub, with other applications and directories publishing their changes to it. The Identity Vault then sends changes to the applications and directories that have subscribed for them. This results in two main flows of data: the Publisher channel and the Subscriber channel.

1.2.1 Publisher Channel

The SAP system publishes User object information in the form of USERCLONE IDocs using Application Link Enabling (ALE) and Central User Administration (CUA) technology. If desired and properly configured, the SAP system can propagate all Add, Delete, Lock, Unlock, and Modify User event data to the Identity Vault. The driver consumes the IDoc data and converts it into XML format. For more information on how the driver handles IDoc processing, refer to IDoc Consumption by the Driver.

The Publisher channel then submits XML-formatted documents to the Metadirectory engine for publication into the Identity Vault. By using Identity Manager and other Identity Manager drivers, the data can be shared with other business applications and directories. These other applications can add additional data, which in turn can be transferred back into the SAP User records using the standard SAP Business Application Programming Interface (BAPI).

Depending on the ALE port configuration you choose, the Publisher channel either polls the SAP database for changes via a file port or it receives the data via a TRFC connection.

The following diagram illustrates the file port configuration. With the file port configuration, the entire IDoc is stored on the SAP host system.

Figure 1-1 Publishing Data to the Identity Vault using the File Port Configuration

The following diagram illustrates the TRFC port configuration. When using the TRFC configuration, a minimal “trigger” IDoc is stored on the driver host system. The driver handles the parsing of the IDoc data and uses the information to read the current User object. The driver then parses the appropriate data fields specified by the driver configuration, and provides secure transport of the data to the Identity Vault. Only data elements specifically selected by the system administrator are transported from the SAP host system to the Identity Vault.

Figure 1-2 Publishing Data to the Identity Vault using the TRFC Configuration

IDoc Consumption by the Driver

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

The format of a successfully published IDoc file is:

<(I)nput or (O)utput>_<client number>_<consecutive IDoc number>

For example:

O_300_0000000000001001

After the IDoc has been processed and specified attributes have been published, the filename of the IDoc file is modified to reflect the status of the publication processes. The following table lists the IDoc status and corresponding extension:

IDoc Status

Filename Extension

Processing but not published

.proc

Processed successfully and published

.done

Processed with an error or warning

.fail or .warn

Processed and retained for future-dated processing

.futr

Processed with corrupt or illegitimate data

.bad

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

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

1.2.2 Subscriber Channel

The Subscriber channel receives XML-formatted Identity Vault events from the Metadirectory engine. The driver converts these documents to an appropriate data format, and updates SAP via the BAPI interface. The Identity Vault sends changes only to the applications that subscribe to receive them.

Figure 1-3 Populating SAP with Data from other applications via the Subscriber channel

For data to flow from the Identity Vault to the SAP system, the driver uses the SAP BAPI functions. The level of functionality is based upon the R/3 release level. By default, the driver is configured to support a SAP 4.6C system using USERCLONE03 messages. (To determine the level of USERCLONE messages available on your SAP system, run transaction WE60 and specify object name USERCLONEnn.) As a SAP administrator, you can select which attributes from the infotypes can be modified.

1.2.3 Attribute Mapping from the SAP User Management Database to the Identity Vault

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

Several of the USERCLONE infotypes can be instantiated multiple times on the User records. Infotypes such as ADDTEL (Telephone Number) and ACTIVITYGROUPS (Roles) are Table fields and can contain multiple values. Other infotypes such as ADDRESS and LOGONDATA are Structure fields and are instantiated only once but have multiple fields associated with them. Still other fields are simple field types that contain only a single data field element.

The Identity Vault (eDirectory) system administrator can configure the driver to receive any of these various data fields, and can also configure the driver to handle the data in multiple ways. The Schema Map represents the data elements that can be synchronized in the SAP system.

The map elements have the following format:

<Table or Structure Name>:<Field>   // Field

or

<Table Name>   // Map to entire table or structure

Below are a few examples of maps between SAP User attributes and Identity Vault attributes.

Identity Vault Attribute

SAP User Attribute

Given Name

ADDRESS:FIRSTNAME

Surname

ADDRESS:LASTNAME

sapRoles

ACTIVITYGROUPS:AGR_NAME

buildingName

ADDRESS:BUILDING_P

floor

ADDRESS:FLOOR_P

Internet EMail Address

ADDSMTP:E_MAIL

OU

ADDRESS:DEPARTMENT

Pager

ADDPAG:PAGER

sapAlias

ALIAS:USERALIAS

DirXML-sapLocRoles

LOCACTIVITYGROUPS

The driver can synchronize multiple-instance data (such as TELEPHONE), but it cannot guarantee the specification of a primary value. It is also possible to specify only the Table name in a schema mapping. This is useful if you want to synchronize all data fields in a Table to the Identity Vault. You must use policies to parse desired fields from the Table data. Refer to Section E.0, Example XML Document Received from the Driver to see how various formats are represented in modify events.

1.2.4 Associations

Associations are created between SAP and Identity Vault objects during the synchronization process. For the SAP User object, a unique 12-character name (per client) must be created. However, the Identity Vault and other applications do not need to share this same unique ID. Identity Manager allows the various naming policies in an organization to be applied to objects by using the DirXML-Association attribute.

The DirXML-Association attribute is multivalued. Therefore, if Identity Manager is being used to synchronize an object among multiple applications, all of the object’s unique IDs (or associations) can be stored in this attribute on the Identity Vault object.

The unique ID association links objects in SAP to their objects in the Identity Vault. When an Add or Matching event occurs, the association is made. This association allows the driver to perform subsequent tasks on the appropriate object.

The DirXML-Associations field is stored on the Identity Vault object on the Identity Manager property page.