Modifying the Driver Filter

The driver filter contains the eDirectory classes and attributes for the Publisher and Subscriber channels. The purpose of the filter is to define how attributes are shared between systems. All attributes in the driver filter are required for processing, so you should not remove attributes from the filter.

You can, however, make additions to the filter. If you add classes or attributes to the filter, you should append the "merge-authority" string to the added attribute in the Mapping policy.

For example:

<filter-attr attr-name="Description" merge-authority="edir" 	   
 publisher="ignore" subscriber="sync"/>

Adding Entries to the Schema Mapping Policy

The Schema Mapping policy is contained in the driver object and applies to both the Subscriber and Publisher channel. The purpose of the Schema Mapping policy is to map schema names (particularly attribute names and class names) between the eDirectory namespace and the GroupWise namespace. Do not modify or remove existing entries in the Schema Mapping policy. You can, however, add entries to the Schema Mapping policy.

Modifying the Create Policy

You modify the Create policy to implement your specific business rules. The Create policy determines whether or not a GroupWise account is created. A Create policy also can perform other modifications to the <add> event, such as providing default values for attributes.

In the driver configuration, the Create policy specifies two required attributes: CN and Surname.

The policy is controlled by a global configuration value (GCV) that sets the initial password to <surname>-<CN>. For more information on GCVs, refer to Understanding Global Configuration Values.

Modifying the Placement Policy

Matching policies define the minimum criteria that two objects must meet to be considered the same.

Specifying the GroupWise Post Office

By default, the GroupWise Subscriber Placement rule puts all new users in the same post office. The Placement policy can also determine the post office based on an attribute value or the eDirectory user container.

The following example, created in Policy Builder, specifies the post office based on the eDirectory container where the user was created.

The following graphic shows the policies needed to place users in the Sales container into PO1 and users in the Engineering container into PO2.

Specifying Distribution Lists

You can automatically add new GroupWise accounts to a distribution list when they are created. Distribution lists are used by organizations to assure that the appropriate individuals are included in various internal communications.Wherever possible, organizations want to automatically assign new employees to these distribution lists so that they can immediately participate in the communications that are relevant to them.

Using a Subscriber Create policy, when an eDirectory user is created, the GroupWise account can be added to a distribution list based on the eDirectory container. When a user is created in the Sales container, the user is added to the Sales Distribution List. When a user is created in the Engineering container, the user is added to the Engineering Distribution List.

The policies in this section, created using Policy Builder, show how to configure the following actions:

• Creating a New User as a Member of a Distribution List Based on the User's eDirectory Container
• Adding a User to a Distribution List when He or She Becomes a Manager
• Removing a User from a Distribution List when He or She is No Longer a Manager
• Removing a User from All Distribution Lists

Using Policy Builder, you can use these examples to create similar policies and Distribution Lists for your business rules and environment.

Creating a New User as a Member of a Distribution List Based on the User's eDirectory Container

Adding a User to a Distribution List when He or She Becomes a Manager

Removing a User from a Distribution List when He or She is No Longer a Manager

Removing a User from All Distribution Lists

Setting Defaults for GroupWise Attributes

Other attributes can be set in the GroupWise account using the Create policy. Some attributes must be set in both eDirectory and GroupWise. When the eDirectory user object contains a corresponding attribute, it must be set. It is important that attribute values are set in both eDirectory and GroupWise. If the attribute is only set in GroupWise, it could be overwritten with the value in eDirectory. You must customize the driver so that it updates values in eDirectory; the driver does not do this by default.

The following example shows setting the Description attribute (Visibility is another common attribute) in eDirectory and GroupWise. The attribute write-back = "true" causes the attribute to also be written in eDirectory.

<?xml version="1.0" encoding="UTF-8"?> 
<create-rules> 
     <create-rule class-name="User" description="GroupWise Account Required Attributes"> 
          <!-- Description attribute is given a default value in both eDirectory and in GroupWise --> 
         <required-attr attr-name="Description" write-back="true"> 
              <value type="String"><![CDATA[eDirectory User synchronized by GroupWise Driver]]></value> 
         </required-attr> 
     </create-rule> 
</create-rules>

Configuring the GroupWise UserID

The CN attribute in eDirectory is used to name the GroupWise account. You must include this in the Create policy as a required attribute. The CN value from eDirectory can be ignored in the Subscriber Create policy and a CN based on other attributes can be generated. An example code segment from a Create policy is shown below. If you make modifications to this policy, the modify events coming from the engine also need to be modified.

When an attribute used to construct the CN is modified, a GroupWise rename event should be generated via the policies. The UserID must be unique within a post office. If UserID is used to generate Internet EMail Address, it must be unique in the entire GroupWise system. The User ID contains 1 to 256 characters, and cannot contain the following characters: ( ) @ . : , { } * ". The UserID must be unique within its namespace (UserID shares the same namespace as nicknames, resources, and distribution lists.) Do not use a "mapi" (reserved ID) for this value.

An Output Transformation or Event Transformation policy can monitor the attributes used to build the CN. If one of these attributes changes, a rename event should also be generated. Any attributes used here need to be added to the list of required attributes. In this case, rename events should still be forwarded to the driver with an empty <newname> element. See Renaming Users for more information.

<!--CN is used to set the GroupWise UserID. 
Construct a new CN from Given Name. 
--><xsl:template match="add-attr[@attr-name = 'CN']"> 
<!-- ignore the current CN and create a new one --> 
     <add-attr attr-name="CN"> 
          <value type="string"> 
               <xsl:value-of select="../add-attr[@attr-name='Given Name']/value"/> 
          </value> 
     </add-attr> 
</xsl:template>

Creating Mappings for Additional Attributes

You can synchronize any attribute that can be represented as a string in eDirectory with one of twenty GroupWise generic attributes (excluding octet strings and structured attributes). You specify the eDirectory attribute you want to map in the filter. In addition, the eDirectory and GroupWise attribute names must be connected in the Schema Mapping policy.

The Schema Mapping rule code segment below connects the eDirectory attribute Location with the GroupWise attribute 55003. The twenty GroupWise attributes names are 50106 through 50115 and 55002 through 55011. Address book labels can be assigned to these GroupWise attributes through the GroupWise snap-ins. You should configure the same mappings in GroupWise as you do in the driver mappings.

<attr-name class-name="User"> 
     <nds-name>Location</nds-name> 
     <app-name>55003</app-name> 
</attr-name>

Getting a Record Count from a Query

The following query, sent to the driver, will return the number of users in dom1.po1.

<nds dtdversion="1.1" ndsversion="8.6"> 
     	<input> 
             		<query event-id="query-groupwise" scope="subtree"> 
 			                <search-class class-name="User"/> 
 
                 			<!-- Referenced Domain Name --> 
                 			<search-attr attr-name="50035"> 
                    				<value>dom1</value> 
                 			</search-attr> 
 
                 			<!-- Referenced Post Office Name --> 
 			                <search-attr attr-name="50062"> 
                      				<value>po1</value> 
                 <search-attr> 
 
                 			<!-- return Record Count--> 
               			  <read-attr attr-name="Record Count"/> 
            		</query> 
     	</input> 
</nds>

If you remove the post office search attr, it will return the number of users in dom1. If you remove the domain search attr, it will return the number of users in the system. This search can be altered to apply to other search criteria.

Deleting the GroupWise User without Deleting the eDirectory User

After deleting the user in GroupWise, the driver cleans up the GroupWise attributes in eDirectory. The result is the same as deleting the user with the GroupWise snap-ins and only selecting delete from GroupWise.

You will need to change the match criteria to match the needs of your environment.

<!-- delete the GroupWise user and clean up eDirectory when the eDirectory user has not been deleted --> 
<xsl:template match="modify[@class-name='User' and modify-attr[@attr-name='50000']]"> 
     	<delete xmlns:gw="http://www.novell.com/dirxml/gwdriver" gw:original-   	    event="modify"> 
        		<!-- copy event attributes and association --> 
        		<xsl:apply-templates select="@*|association"/> 
    	</delete> 
</xsl:template>

Creating a GroupWise Nickname

GroupWise nicknames can be automatically created when an eDirectory User is renamed or when a GroupWise account is moved. This is controlled in iManager on the driver through the Global Configuration Value page. When you set this option to True, nicknames are automatically created when an eDirectory rename occurs or when a GroupWise account is moved. When you set this option to False, nicknames are not created. Nickname creation requires GroupWise 6 SP1 or higher agents to be running.You can override this option by adding code to the Output Transformation policy to specify whether a nickname should be created.

<!--  
  Override the "Create Nicknames" Driver Option   
--> 
<xsl:template match="rename"> 
     <xsl:copy> 
          <!-- Create a GroupWise nickname. --> 
          <xsl:attribute xmlns:gw="http://www.novell.com/dirxml/gwdriver" name="gw:create-nickname">true</xsl:attribute> 
          <xsl:apply-templates select="@*|node()"/> 
     </xsl:copy> 
</xsl:template>

Creating a GroupWise Nickname Record

The following examples show two ways to create a nickname record. The first specifies the post office in which the nickname is created in the <dest-dn> attribute (this implies the domain). The second example uses <add-attr> nodes to specify the domain and post office.

The Nickname can contain 1 to 256 characters, and cannot contain the following characters: ()@.:,{}*". It must be unique within its namespace (nicknames share the same namespace as users, resources, and distribution lists.)

<add class-name="GroupWise Nickname" dest-dn="Novell\dirxml\groupwise\xmlPO" event-id="0" > 
     <!-- Domain of user this nickname refers to --> 
     	<add-attr attr-name="50068" > 
   		         <value type="string">xmlDom</value> 
      	</add-attr> 
      	<!-- Post Office of user this nickname refers to  --> 
      	<add-attr attr-name="50069" > 
            		<value type="string">xmlPO</value> 
      	</add-attr> 
      	<!--  user this nickname refers to  --> 
      	<add-attr attr-name="50070" > 
            		<value type="string">Usern1</value> 
      	</add-attr> 

      	<!-- name of nickname record --> 
      	<add-attr attr-name="50073" > 
           		<value type="string">nn1</value> 
      	</add-attr> 
</add>OR <add class-name="GroupWise Nickname" event-id="0" > 
      	<!-- Domain of user this nickname refers to --> 
      	<add-attr attr-name="50068" > 
           		<value type="string">xmlDom</value> 
       	</add-attr> 
       	<!-- Post Office of user this nickname refers to --> 
       	<add-attr attr-name="50069" > 
           		<value type="string">xmlPO</value> 
       	</add-attr> 
 	      <!-- user this nickname refers to --> 
 	      <add-attr attr-name="50070" > 
          		<value type="string">Usern1</value> 
        	</add-attr> 
 
       	<!-- Domain of nickname record --> 
       	<add-attr attr-name="50035" > 
          		<value type="string">xmlDom</value> 
       	</add-attr> 
       <!-- Post Office of nickname record --> 
  	     <add-attr attr-name="50062" > 
  		        <value type="string">xmlPO</value> 
       	</add-attr> 
       	<!-- name of nickname record --> 
 	      <add-attr attr-name="50073" > 
  		        <value type="string">nn1</value> 
       	</add-attr> 
</add>

Specifying a New Resource Owner on an Owner Delete

If the owner of a resource (a conference room, for instance) is deleted, the driver automatically assigns that resource to another owner. You must designate a default user for all resource assignments. At the time the resource is assigned, if the driver detects no default user account, it creates the default user account and assigns the resource to that user.

Through a policy, you can specify an override owner. Using the Output Transformation policy, the eDirectory User delete is selected. The special attribute, gw:resource-owner-dn, is used to notify the shim of the override resource owner. This special attribute is specified on the <delete> element. Resources are always reassigned on a delete. The new owner must already exist in GroupWise and be in the same post office as the user being deleted. If a failure occurs using the override owner, the resources are automatically assigned to the default user specified in the Driver Options. The XSLT code segment is:

<!-- User Delete Reassigns GroupWise Resource 
  On an eDirectory User delete specify the GroupWise Account 
  to reassign the GW resources to. 
--> 
<xsl:template match="delete[@class-name='User']"> 
     <!-- copy the delete through --> 
     <xsl:copy> 
          <!-- Specify the override resource owner on the <delete> --> 
          <xsl:attribute xmlns:gw="http://www.novell.com/dirxml/gwdriver" 
               name="gw:resource-owner-dn">\GWDRIVERTREE\novell\users\sales\ResourceOwner</xsl:attribute> 
          <!-- copy the rest of the stuff through --> 
          <xsl:apply-templates select="@*|node()"/> 
     </xsl:copy> 
</xsl:template>

Specifying a New Resource Owner on an Owner Disable or Expire

If the owner of a resource (a conference room, for instance) is disabled or expired, you can configure the driver to automatically assign that resource to another owner (using GCVs.) In this process, you can designate a default user for all resource assignments. At the time a resource is being reassigned, if the driver detects no default user account, it creates a default user account and assigns it as the resource owner only if the Reassign Resource Ownership driver GCV is set to Yes.

When an eDirectory User Login Disabled attribute is set, the GroupWise resources of the disabled or expired account can be assigned to another GroupWise account. Normally, the new owner is a default user specified in the Default Resource Owner UserID parameter. Through a style sheet, an override owner can be specified. Using the Output Transformation style sheet, the eDirectory User login disable is selected. The special attribute, gw:resource-owner-dn, is used to notify the shim of the override resource owner. This special attribute is specified in the <modify-attr> element.

The resources are assigned to the override owner even when the Reassign Resource Ownership GCV is set to No. The new owner must already exist in GroupWise and be in the same post office as the user being expired. If a failure occurs using the override owner, the resources are automatically assigned to the default user specified in the Driver Options. The XSLT code segments for disabling and expiring are:

<!-- When a GroupWise Account is Disabled also specify the GroupWise Account to reassign the GW resouces to.--> 
<xsl:template match="modify-attr[@attr-name='50058']"> 
     <!-- When Login Disabled is true, reassign the resource --> 
     <xsl:if test="add-value//value[.='true']"> 
          <!-- copy the modify through --> 
          <xsl:copy> 
               <!-- Specify the override resource owner on the <modify-attr> --> 
<xsl:attribute xmlns:gw=http://www.novell.com/dirxml/gwdriver 
name="gw:resource-owner-dn">\GWDRIVERTREE\novell\users\sales\ResourceOwner</xsl:attribute> 
               <!-- copy the rest of the stuff through --> 
               <xsl:apply-templates select="@*|node()"/> 
          </xsl:copy> 
     </xsl:if> 
</xsl:template>

<!-- User Expire to GroupWise Expire and Reassign GroupWise Resources 
  When the eDirectory User Login Expiration Time attribute is modified, 
  change the GroupWise Mailbox Expiration Time and 
  specify the GroupWise Account to reassign the GroupWise resources to. 
--> 
<xsl:template match="modify-attr[@attr-name='Login Expiration Time']"> 
     <!-- copy the modify through --> 
     <xsl:copy> 
          <!-- copy all attributes through except for the attr-name --> 
          <!-- we'll construct the GroupWise attr-name below --> 
          <xsl:apply-templates select="@*[name(.) != 'attr-name']"/> 
          <!-- now create the attr-name attribute with the GroupWise name --> 
          <xsl:attribute name="attr-name">50138</xsl:attribute> 
          <!-- Specify the override resource owner on the <modify-attr> --> 
          <xsl:attribute name="gw:resource-owner-dn"  
               xmlns:gw="http://www.novell.com/dirxml gwdriver">\GWDRIVERTREE\novell\users\sales\ResourceOwner</xsl:attribute> 
          <!-- copy the rest of the stuff through, except for what we have already copied--> 
          <xsl:apply-templates select="* | comment() | processing-instruction() | text()"/> 
     </xsl:copy> 
</xsl:template>

Controlling Creation of GroupWise Accounts

There might be situations where an eDirectory user is created and you do not want to create a corresponding GroupWise account. In addition, not all eDirectory users initially have a GroupWise account. You can use the driver to control the creation of GroupWise accounts.

The recommended way to control the creation of an account is to define whether a GroupWise account is to be created (true/false). For example, the createGroupWiseAccount attribute.

The eDirectory schema must be extended to include the attribute createGroupWiseAccount. When the createGroupWiseAccount attribute is set to true, the GroupWise account is created. When the createGroupWiseAccount attribute is set to false, the GroupWise account is not created. Changing the value from false to true causes the GroupWise account to be created.

The createGroupWiseAccount attribute must be added to the Create policy as a required attribute and also added to the Subscriber Filter.

<!-- createGroupWiseAccount is used to control creation of the GroupWise Account --> 
     <match-attr attr-name="createGroupWiseAccount"> 
          <value><![CDATA[true]]></value> 
     </match-attr> 

Moving Users from One Post Office to Another Post Office

When a style sheet is not configured to move GroupWise accounts, we recommend that you use the GroupWise 6 snap-ins (or higher) for user moves. If you use an older version of the GroupWise snap-ins, it can cause the driver to generate errors.When the Output Transformation style sheet is configured to move GroupWise accounts, we recommend that user moves be made in eDirectory and that the driver assign the object to a new post office in GroupWise. The XSLT code segment for the Output Transformation policy is shown below. The dest-dn attribute on the parent element specifies the new post office.

<!--  
  On an eDirectory User Move add the GroupWise Post Office DN  
  based on the User's new container 
--> 
<xsl:template match="move[@class-name='User']"> 
     <!-- copy the Move through --> 
     <xsl:copy> 
          <!-- copy the attributes from the <move> element --> 
          <xsl:apply-templates select="@*"/> 
          <association> 
               <xsl:value-of select="association"/>          </association> 
          <parent> 
               <xsl:attribute name="src-dn"> 
                    <xsl:value-of select="parent/@src-dn"/> 
               </xsl:attribute> 
               <!-- Specify the post office DN based on the container --> 
               <xsl:choose> 
                    <xsl:when test="parent/@src-dn = '\GWDRIVERTREE\Novell\Users\Sales'"> 
                         <xsl:attribute name="dest-dn"> 
\GWDRIVERTREE\Novell\GroupWise\Post Offices\Sales PO</xsl:attribute> 
                        </xsl:when> 
                         <xsl:when test="parent/@src-dn = '\GWDRIVERTREE\Novell\Users\Engineering'"> 
                              <xsl:attribute name="dest-dn"> 
\GWDRIVERTREE\Novell\GroupWise\Post Offices\Engineering PO</xsl:attribute> 
                         </xsl:when> 
               </xsl:choose> 
          </parent> 
     </xsl:copy> 
</xsl:template

Adding Additional Attributes to Be Synchronized

You can map up to twenty user eDirectory attributes to generic GroupWise attributes and display them in the address book. For these attributes, you use the ranges 50106-50115 or 55002-55011. You must first add these eDirectory attributes to the filter. Any attribute names you add to the filter must be added to the Schema Mapping policy. You must configure these attributes in the GroupWise snap-ins for these attributes to appear in the GroupWise address book.

Renaming Users

We recommend that you rename users by changing the naming attribute in eDirectory and letting the driver rename the GroupWise account. When CN is the naming attribute (this is the default), no special style sheet coding is required for a rename process. However, the GroupWise MailboxID can be built from attributes other than CN. When one of these attributes is modified, the GroupWise account should also be renamed. The XSLT code segment is shown below. In this example, the eDirectory attribute Given Name is used to name the GroupWise account. When Given Name is modified, a GroupWise rename is generated. The second template below, <xsl:template match="rename[@class-name='User']">, handles the case where the eDirectory User object was renamed. In this case the <rename> command is passed through to the driver The empty <new-name/> element blocks the driver from renaming the GroupWise account. Even though the GroupWise account is not renamed, the rename event must pass to the driver.We do not recommend that you use the GroupWise snap-ins to do a rename. However, if the user is renamed using the GroupWise snap-ins, it must be done with GroupWise 6 SP1 or higher. If you use an older version of the GroupWise snap-ins, it can cause the driver to generate errors.

<!-- When the attribute used to set CN changes, in this case Given Name, create   an element <new-name> to rename the GroupWise Account 
--> 
<xsl:template match="modify[@class-name='User']"> 
     <!-- Given Name is used the for GroupWise CN, when it changes do a rename --> 
    <xsl:if test="modify-attr[@attr-name='50091']"> 
          <!-- Copy the <modify> through so all changes get made --> 
          <xsl:copy> 
               <xsl:apply-templates select="@*|node()"/> 
          </xsl:copy> 
          <!-- generate a <rename> --> 
          <rename class-name="User"> 
               <!-- copy the attributes from the <modify-attr> element to the <rename> element --> 
               <xsl:apply-templates select="@*"/> 
               <!-- The object was not renamed in eDir so use src-dn for src-dn and old-src-dn --> 
               <xsl:attribute name="old-src-dn"> 
                    <xsl:value-of select="@src-dn"/> 
               </xsl:attribute> 
               <!-- copy the children from the <modify> element to the <rename> element --> 
               <xsl:apply-templates select="node()"/> 
               <new-name> 
                    <xsl:value-of select="modify-attr[@attr-name='50091']/add-value/value"/> 
               </new-name> 
          </rename> 
     </xsl:if> 
</xsl:template>

<!--  
When the User object is renamed in eDirectory, the GroupWise account is not renamed since it is named by the Given Name attribute 
--> 
<xsl:template match="rename[@class-name='User']"> 
     <!-- Copy the rename through except new-name --> 
     <xsl:copy> 
          <xsl:apply-templates select="@*|node()[name() != 'new-name']"/> 
          <!-- <new-name> does not change since the GW account is named by the Given Name attribute --> 
          <new-name/> 
     </xsl:copy> 
</xsl:template>

Creating a Gateway Alias

The following XSLT code segment shows how to create a gateway alias in the Output Transformation policy. Your code is responsible for generating the value of attributes 50140 and 50077.

<xsl:template match="add[@class-name='User']"> 
     <xsl:copy> 
          <xsl:apply-templates select="@*"/>  
               <add-attr attr-name="Gateway Alias"> 
                    <value type="structured"> 
                        <component name="50140"><![CDATA[SMTP]]></component> 
                         <component name="50077"><![CDATA[UserOne@novell.com]]> 
                        </component> 
                    </value> 
               </add-attr> 
           <xsl:apply-templates select="* | comment() | processing-instruction() 
            | text()"/> 
     </xsl:copy> 
</xsl:template>

Querying for a Nickname

The following Output Transformation policy shows how to query for the GroupWise Nickname.The search-attrs in this style sheet are optional. They are used to scope the search. When you specify a Post Office name (50069), you must also specify a Domain name (50068). More than one Nickname can be returned.

For example, User2a is renamed to User2b, then renamed to User2c. There will be two Nickname records (User2a and User2b) which both reference User2c.This code sample queries the User of the current event for nicknames. You should use a different match criteria.

<xsl:template match="modify[@class-name='User']"> 
     	<xsl:copy> 
          		<xsl:apply-templates select="@*|node()"/> 
     	</xsl:copy> 
     	<xsl:variable name="query"> 
          		<nds dtdversion="1.0" ndsversion="8.5"> 
               			<input> 
                    				<query class-name="{@class-name}" event-id="query-groupwise" cope="entry"> 
                         					<association> 
                              <xsl:value-of select="association"/> 
                         					</association> 
                         <!-- User Domain Name --> 
                         <read-attr attr-name="50035"/> 
                         					<!-- User Post Office Name --> 
                         <read-attr attr-name="50062"/> 
                         <!-- User Object Name --> 
                         <read-attr attr-name="50073"/> 
                    </query> 
               			</input> 
          		</nds> 
     </xsl:variable> 
     	<xsl:variable name="gw-data" select="query:query($destQueryProcessor, $query)//instance"/> 
          		<xsl:variable name="query2"> 
          <nds dtdversion="1.0" ndsversion="8.5"> 
              			<input> 
                  <query event-id="query-groupwise" scope="subtree"> 
                       					<search-class class-name="GroupWise Nickname"/> 
                       <!-- Referenced Domain Name --> 
                       					<search-attr attr-name="50068"> 
						                          <value> 
                               <xsl:value-of select="$gw-data//attr[@attr-name='50035']/value"/> 
                           						</value> 
					                       </search-attr> 
                       <!-- Referenced Post Office Name --> 
                       <search-attr attr-name="50069"> 
						                          <value> 
                               <xsl:value-of select="$gw-data//attr[@attr-name='50062']/value"/> 
                          </value> 
                       </search-attr> 
                       <!-- Referenced Object Name --> 
					                       <search-attr attr-name="50070"> 
                          <value> 
                               <xsl:value-of select="$gw-data//attr[@attr-name='50073']/value"/> 
                          						</value> 
                       					</search-attr> 
                       <!-- Domain Name of Nickname Record --> 
                       <read-attr attr-name="50035"/> 
                       					<!-- Post Office Name of Nickname Record --> 
                       					<read-attr attr-name="50062"/> 
                       <!-- Object Name of Nickname Record --> 
					                       <read-attr attr-name="50073"/> 
                  				</query> 
              			</input> 
          		</nds> 
      </xsl:variable> 
      <xsl:variable name="gw-nickname" select="query:query($destQueryProcessor, $query2)//instance"/> 
</xsl:template>

<nds dtdversion="1.1" ndsversion="8.6"> 
   <source> 
      		<product build="20020409_1220" instance="GroupWise ZDS Driver" version="1.0a Beta">DirXML Driver for GroupWise</product> 
      <contact>Novell, Inc.</contact> 
	   </source> 
   <output> 
		      <instance class-name="GroupWise Nickname" event-id="0"> 
			         <attr attr-name="50035"> 
            <value type="string">TaoDom</value> 
        </attr> 
        <attr attr-name="50062"> 
            <value type="string">TaoPO</value> 
			        </attr> 
			        <attr attr-name="50073"> 
				            <value type="string">User2b</value> 
        			</attr> 
      		</instance> 
		      <instance class-name="GroupWise Nickname" event-id="0"> 
        			<attr attr-name="50035"> 
            				<value type="string">TaoDom</value> 
			        </attr> 
			        <attr attr-name="50062"> 
				            <value type="string">TaoPO</value> 
			        </attr> 
			        <attr attr-name="50073"> 
				            <value type="string">User2a</value> 
		        	</attr> 
		      </instance> 
		      <status level="success"/> 
	   </output> 
</nds>

Querying for a Gateway Alias

The following XSLT code segment shows how to query in the Output Transformation policy for the gateway alias.

<xsl:template match="modify[@class-name='User']"> 
   	<xsl:copy> 
		      <xsl:apply-templates select="@*|node()"/> 
   	</xsl:copy> 
	   <xsl:variable name="query"> 
      		<nds dtdversion="1.0" ndsversion="8.5"> 
         			<input> 
				             <query class-name="{@class-name}" event-id="query-groupwise" scope="entry"> 
               					<association> 
						                  <xsl:value-of select="association"/> 
					               </association> 
               					<read-attr attr-name="Gateway Alias"/> 
				            </query> 
			         </input> 
		      </nds> 
	    </xsl:variable> 
	    <xsl:variable name="gw-aliases" select="query:query($destQueryProcessor, $query)//instance"/> </xsl:template> 
</xsl:template>

<nds dtdversion="1.0" ndsversion="8.5"> 
	   <source> 
       <product version="1.0 SP1 Beta, 20020307_1205">GroupWise ZDS Driver</product> 
      <contact>Novell, Inc.</contact> 
	   </source> 
	   <output> 
		       <instance class-name="User" event-id="0" src-dn="TaoDom.TaoPO.User1{106}DFD036A0-0776-0000-A246-4100F0001300"> 
          <association>TaoDom.TaoPO.User1{106}DFD036A0-0776-0000-A246-4100F0001300<association> 
         <attr attr-name="Gateway Alias"> 
				            <value type="structured"> 
					               <component name="50140">SMTP</component> 
					               <component name="50077">UserOne@novell.com</component> 
				            </value> 
			         </attr> 
		       </instance> 
		       <status level="success"/> 
	   </output> 
</nds>

Querying for Internet EMail Address

The following XSLT code segment shows how to query in the Output Transformation policy for the Internet Email Address generated by GroupWise.

<xsl:template match="modify[@class-name='User']"> 
   <xsl:copy> 
		      <xsl:apply-templates select="@*|node()"/> 
   </xsl:copy> 
   <xsl:variable name="query"> 
      		<nds dtdversion="1.0" ndsversion="8.5"> 
			         <input> 
            <query class-name="{@class-name}" event-id="query-groupwise" scope="entry"> 
               					<association> 
						                  <xsl:value-of select="association"/> 
               					</association> 
               					<read-attr attr-name="Internet EMail Address"/> 
            				</query> 
         			</input> 
		      </nds> 
	   </xsl:variable> 
	   <xsl:variable name="inet-address" select="query:query($destQueryProcessor, $query)//instance"/> 
</xsl:template>

<nds dtdversion="1.1" ndsversion="8.6"> 
   <source> 
      <product build="20020502_1251" instance="GroupWise Driver"  
                     version="1.0a Beta">DirXML Driver for GroupWise</product> 
		      <contact>Novell, Inc.</contact> 
   	</source> 
   	<output> 
      <instance class-name="User" event-id="0"  
          src-dn="TaoDom.TaoPO.User2{106}5B8C40F0-0E79-0000-9ADA-350037009300"> 
			         <association>TaoDom.TaoPO.User2{106}5B8C40F0-0E79-0000-9ADA-350037009300</association> 
         			<attr attr-name="Internet EMail Address"> 
            				<value type="string">User2@domain.com</value> 
			         </attr> 
      		</instance> 
      		<status level="success"/> 
    </output> 
</nds>

Synchronizing External Users

In your business, you might have several different e-mail applications. Although not all employees will have GroupWise e-mail accounts, you want the GroupWise address book to contain all employee information. The driver has the ability to create GroupWise external users, which enables the driver to obtain data from other e-mail systems (via eDirectory) and display it in the GroupWise address book. eDirectory users can be linked to GroupWise external users.

If you are using multiple e-mail systems (GroupWise and NetMail/Notes/Exchange) you can create external users and external post offices to add the users in the non-GroupWise systems to the GroupWise address book.

To synchronize data between external e-mail systems and GroupWise, your implementation must meet the following conditions:

• External users must be assigned to or be created in an external post office.
• External post offices must belong to a non-GroupWise domain.

The default driver configuration does not include this customization. To implement this functionality, you should make appropriate changes to your filters, rules, and style sheets based on your business processes.

HINT:  In the \nt\dirxml\drivers\groupwise\extensions directory of the software, you can find examples of how to implement this solution. These are samples only and not intended for production use; customization is required. If users are in a tree other than where the GroupWise users are, you can use the simple example. If the GroupWise and non-GroupWise users are in the same tree, use the merged example.

<!-- 	The external post office name to which the user belongs. --> 
     	<add-attr attr-name="50062"> 
           		<value type="string"><![CDATA[External post office name]]></value> 
     </add-attr> 

<!-- The non-GroupWise domain name to which the external post office belongs. --> 
     	<add-attr attr-name="50035"> 
           <value type="string"><![CDATA[Non-GroupWise domain name]></value> 
      </add-attr> 

<!-- 	The non-GroupWise domain name to which the external post office belongs. --> 
     	<add-attr attr-name="50035"> 
          <value type="string"><![CDATA[Non-GroupWise domain name]></value> 
     </add-attr> 

     	<add-attr attr-name="50088" > 
            		<value type="string">EST</value> 
      </add-attr>