H.0 Using Wildcard Search Capabilities

Releases of this driver prior to version 1.0.5 had issues related to the implementation of the default Subscriber Matching policy. This policy issues a query to the SAP server for matches of the “Given Name” and “Surname” attributes (mapped to ADDRESS:FIRSTNAME and ADDRESS:LASTNAME) prior to processing the creation of a new User object. The following XDS query illustrates the output of this policy.

<nds dtdversion="1.1" ndsversion="8.6">
   <source>
      <product version="1.1.2">DirXML</product>
         <contact>Novell, Inc.</contact>
   </source>
   <input>
      <query class-name="US" event-id="0">
         <search-class class-name="US"/>
         <search-attr attr-name="ADDRESS:LASTNAME">
            <value timestamp="1114621366#3" type="string">Smith</value>
         </search-attr>
         <search-attr attr-name="ADDRESS:FIRSTNAME">
            <value timestamp="1114621375#1" type="string">Joe</value>
         </search-attr>
         <read-attr/>
      </query>
   </input>
</nds>

This is a problem because SAP does not provide the capability to Search for a User account based on attribute values. Therefore, the driver needs to obtain a list of all User objects, then read each object, compare their FIRSTNAME and LASTNAME attributes to the search values, and return a list of matching objects. In a database with hundreds or thousands of User objects, this process takes a very long time.

To alleviate this problem, starting with version 1.0.5, the driver now has the capability to use a wildcard syntax for queries that contain the User name field (USERNAME:BAPIBNAME). This allows you to write policies that take advantage of the known account naming policies of the SAP system to reduce the number of objects that need to be read and compared during matching operations.

For example, the default Subscriber Create rule uses the first initial of the Given Name attribute value appended with the Surname attribute value to create a proposed account name. A new User with Given Name “John” and Surname “Smith” generates a proposed SAP User account name of JSMITH. Any duplicates of this proposed name are appended with numeric values (ie. JSMITH1, JSMITH2, etc.) The default Output Transformation policy now contains a template that takes advantage of the USERNAME:BAPIBNAME wildcard capabilities of the driver and appends this additional search attribute to the query. When the driver receives a query containing a USERNAME:BAPIBNAME search attribute, it determines if the value is a wildcard or a literal value. Any value that is contained within single-quote characters is evaluated for wildcard syntax. If the single quote characters do not exist, the driver attempts to read the specified User object.

The supported variations of the wildcard syntax are:

When the list of objects to be matched has been restricted, the remaining search attributes are used to determine a match.

The output from the default Output Transform policy converts the Matching Rule query shown above to the following query. It should be noted that this policy will only be applied to queries that do not already contain a USERNAME:BAPIBNAME search attribute.

<nds dtdversion="1.1" ndsversion="8.6">
   <source>
      <product version="1.1.2">DirXML</product>
      <contact>Novell, Inc.</contact>
   </source>
   <input>
      <query class-name="US" event-id="0">
         <search-class class-name="US"/>
         <search-attr attr-name="ADDRESS:LASTNAME">
            <value timestamp="1114621366#3" type="string">Smith</value>
         </search-attr>
         <search-attr attr-name="ADDRESS:FIRSTNAME">
            <value timestamp="1114621375#1" type="string">Joe</value>
         </search-attr>
         <read-attr/>
         <search-attr attr-name="USERNAME:BAPIBNAME">
            <value>’JSmith*’</value>
         </search-attr>
      </query>
   </input>
</nds>

With this query, the driver searches only User objects whose name starts with JSMITH for matching ADDRESS:LASTNAME value “Smith” and matching ADDRESS:FIRSTNAME value “Joe.”