6.2 Using the Relationship Query

The SAP HR system is a relational database. Individual HR objects, such as the Person object, do not contain all the information that is typically needed to describe the function of the Person within an organization. Organizational and Position information is contained in different objects that are related to the Person object for a specified period of time. The name of a Position a Person holds, the name of the Organization he or she belongs to, and the Organizational hierarchy to which a person belongs can only be determined by traversing the various relationships between objects.

The Manager or Direct Reports relationship is only maintained if the SAP HR system is using the Supervisory model of reporting. Position objects have a reporting structure among themselves. Only the Position objects are required for building the Manager and Direct reports relationships. For example, S12 is a Manager and reports to S12345, and S123 and S1234 directly report to S12. Most of the large SAP HR implementations can build the reporting structure within their O objects with related Position objects.

The SAP driver has a special capability that allows a query to be made for the object relationships between an SAP object being processed in the Publisher channel and other SAP objects. This information is contained in Infotype 1001 (Object relationships) in the HRMD_A IDoc. (The documentation for the meaning of the various fields of this Infotype can be found on the SAP system by using transaction WE60.) Because this relationship information cannot be easily mapped to Identity Vault attributes, and because namespace attributes are stripped out of XML documents during various phases of processing, the capability to query for the pseudo-class RELATIONSHIPS was built into the driver.

The Relationship Query uses two different forms described below.

Query 1

This query uses the class identifier of the last object sent by the driver to the engine. In the context of the driver’s default configuration, this query provides accurate results for obtaining relationship data from Position objects as they are processed.

<nds dtdversion=”1.0” ndsversion="8.5">
  <input>
     <query class-name="RELATIONSHIPS" event-id="0"   
      scope="entry">
        <association>50000354</association>
     </query>
  </input>
</nds>

Query 2

This query utilizes the<search-class> element to specify the class of the object from which relationship data is desired. The driver combines the value of the element with the association to identify the proper relationship vector to return. This allows the policies to obtain relationship data from any object in the current IDoc being processed. The default driver configuration contains queries of this type to provide working examples.

<nds dtdversion="1.0" ndsversion="8.5">
  <input>
     <query class-name="RELATIONSHIPS" event-id="0"
      scope="entry">
         <association>50000354</association> 
         <search-class class-name="S"/>
     </query>
   </input>
</nds>

The driver allows the return of all relationship information in a structured <value> format. This allows the style sheets to utilize any relationship data that is desired for implementing business rules. It is the responsibility of the configuration expert to determine which data is utilized, including time stamp information. The driver returns all requested fields in the 1001 (Relationships) infotype that contain a value. If a field is not populated or present, it is not returned. A sample of a reply to the RELATIONSHIPS Query 2 is presented below:

<nds dtdversion="1.0" ndsversion="8.5">
   <source>
<product build="INVALID_BUILD_ID" instance="SAP-HR" version="1.0.2">Identity Manager Driver for SAP/HR</product>
   <contact>Novell, Inc.</contact>
    </source>
     <output>      <instance class-name="RELATIONSHIPS" timestamp="20030529" xmlns:sapshim="http://www.novell.com/dirxml/drivers/SAPShim">
            <association>50000354</association>
            <sapshim:policyAttr attr-name="RELATIONSHIPS">
             <value type="structured">
                <component name="ITXNR">00000000</component>
                <component name="BEGDA">20020225</component>
                <component name="INFTY">1001</component>
                <component name="SEQNR">000</component>
                <component name="ISTAT">1</component>
                <component name="OTYPE">S</component>
                <component name="RELAT">003</component>
                <component name="ENDDA">99991231</component>
                <component name="SCLAS">O</component>
                <component name="PLVAR">01</component>
                <component name="MANDT">001</component>
                <component name="UNAME">NOVADM</component>
                <component name="RSIGN">A</component>
                <component name="SOBID">50000127</component>
                <component name="OBJID">50000354</component>
                <component name="VARYF">O 50000127</component>
                <component name="AEDTM">20020225</components>
             </value>
             <value type="structured">
                <component name="ITXNR">00000000</component>
                <component name="BEGDA">20020225</component>
                <component name="INFTY">1001</component>
                <component name="SEQNR">000</component>
                <component name="ISTAT">1</component>
                <component name="OTYPE">S</component>
                <component name="RELAT">005</component>
                <component name="ENDDA">99991231</component>
                <component name="SCLAS">S</component>
                <component name="PLVAR">01</component>
                <component name="MANDT">001</component>
                <component name="UNAME">NOVADM</component>
                <component name="RSIGN">A</component>
                <component name="SOBID">50000485</component>
                <component name="OBJID">50000354</component>
                <component name="VARYF">S 50000485</component>
                   <component name="AEDTM">20020301</component>
                 </value>
                 <value type="structured">
                   <component name="ITXNR">00000000</component>
                   <component name="BEGDA">20020225</component>
                   <component name="INFTY">1001</component>
                   <component name="SEQNR">000</component>
                   <component name="ISTAT">1</component>
                   <component name="OTYPE">S</component>
                   <component name="RELAT">007</component>
                   <component name="ENDDA">99991231</component>
                   <component name="SCLAS">C</component>
                   <component name="PLVAR">01</component>
                   <component name="MANDT">001</component>
                   <component name="UNAME">NOVADM</component>
                   <component name="RSIGN">B</component>
                   <component name="SOBID">50000144</component>
                   <component name="OBJID">50000354</component>
                   <component name="VARYF">C 50000144</component>
                   <component name="AEDTM">20020225</component>
                   </value>
            </sapshim:policyAttr>
          </instance>
        </output>
      </nds>

The <read-attr> implementation of the driver RELATIONSHIPS query has been modified as follows:

The <search-attr> functionality of the XDS DTD has been added to the driver RELATIONSHIP query. This enables queries for relationships matching more exacting criteria to reduce the quantity and type of reply data. Multiple <search-attr> values are interpreted as a logical AND of the individual search components. The default Publisher Command Transformation policy has been modified to use the new capabilities of the driver.

The following example is from the set-roles-manager-attr template, used to retrieve the SOBID value from any relationship with an RSIGN value of A and an SCLAS value of S:

Query 3

<nds dtdversion="1.0" ndsversion="8.5">
 <input>
    <query class-name="RELATIONSHIPS" event-id="0" scope="entry">
      <association>
         <xsl:value-of select="$newRole-ID"/>
      </association>
      <search-class class-name="S"/>
      <search-attr attr-name="RSIGN">
          <value>A</value>
      </search-attr>
   <search-attr attr-name="SCLAS">
       <value>S</value>
    </search-attr>
    <read-attr attr-name="SOBID"/>
  <query>
 </input>
</nds> 

6.2.1 Populating the Identity Vault with Organizational Data

In order to populate the Identity Vault with the organizational data, the existing data must be exported from SAP. To export your organization’s hierarchical data, perform the following steps before starting the driver:

  1. From the SAP client, enter transaction code PFAL.

  2. Insert the Object Type O for Organization objects.

  3. Enter the organizations you want to export to the Identity Vault. You can choose to export one organization, a range of organizations, or all organizations.

    If you are exporting a range of objects, go to the Parallel Processing tab on the HR: ALE Distribution of HR Master Data page, then, select a value of 100 or less at the Number of Object per Process prompt. This ensures that driver processing does not consume too much Java heap space.

  4. Click Execute. Ensure that the status is set to Passed to Port Okay.

  5. Repeat the above process for Object Type C for Job objects.

  6. Repeat the above process for Object Type S for Position objects.

    IMPORTANT:Export the objects in the order specified above. This ensures that the driver creates the correct relationships when users are imported into the Identity Vault.