Using set intersection operations in people assignment criteria for WebSphere Process Server (WPS)

Content

This functionality enables you to determine the set of users for a task role based on the intersection of several user sets that are retrieved by people assignment. This approach is needed in cases where using LDAP filters is not sufficient to filter users appropriately at the directory level. For example, you might to retrieve users belonging to two or more LDAP groups or users belonging to an LDAP group and satisfying additional search criteria.

A new query element <intersect> is included in the people query language that is supported for the LDAP people directory provider. It permits you to intersect a set of already collected user IDs with a second set of user IDs. Syntactically, it takes the form <intersect value="variable">, where variable can be one of the following types:

• An HTM-related or process-related replacement variable, for example %htm:task.starter%
• A (people assignment) intermediate variable, for example %setofusers%

The element is not included in the default LDAPTransformation.xsl file, but can be used to construct new custom people assignment criteria. To construct a new custom people assignment criteria you need to know how to do the following tasks:

• Specify queries that result in a first set of user IDs.
• Specify queries that result in a second set of user IDs.

Consider the following two custom verb examples:

1. Custom people assignment criteria making use of a replacement variable

The verb is to intersect the set of user IDs that are represented by the following criteria:

• The members of a group with the name given by the people assignment criteria parameter GroupName
• The readers of the given task as represented by the replacement variable %htm:task.readers%

The following snippet illustrates the XSL mapping definition that is required for the custom people assignment criteria:

    <xsl:template name="GroupMembersSatisfyingFilter">


		<sldap:staffQueries>

			<sldap:usersOfGroup>

			<xsl:attribute name="groupDN">

				<xsl:value-of select="staff:parameter[@id='GroupName']"/>

			</xsl:attribute>

			<xsl:choose>

				<xsl:when test="staff:parameter[@id='IncludeSubgroups']='false'">

	  				<xsl:attribute name="recursive">no</xsl:attribute>

				</xsl:when>

				<xsl:when test="staff:parameter[@id='IncludeSubgroups']='true'">

	  				<xsl:attribute name="recursive">yes</xsl:attribute>

				</xsl:when>

				<xsl:otherwise>

	  				<xsl:message terminate="no">

                                                   WARNING: Unexpected value: 

                                                   '<xsl:value-of select="staff:parameter[@id='IncludeSubgroups']"/>' 

                                                   for IncludeSubgroups. Continue using the default value 

                                                   'true'.

                                             </xsl:message>

				</xsl:otherwise>

			</xsl:choose>	

			<xsl:call-template name="ResultObjectSpecForGroupUserData" />

		</sldap:usersOfGroup>	

		<sldap:intersect>

			<xsl:attribute name="value">%htm:task.readers%</xsl:attribute>

		</sldap:intersect>

	</sldap:staffQueries>

   </xsl:template>

  

2. Custom people assignment criteria making use of an intermediate variable

The people assignment criteria is to intersect the set of user IDs that are represented by the following criteria:

• The members of a group with the name given by the assignment criteria parameter GroupName
• The users found using a search element with an LDAP filter (parameter Filter) with resulting user IDs stored in the intermediate variable %searchresult%.

The following snippet illustrates the XSL mapping definition required for the custom people assignment criteria:

<!-- Begin template GroupMembersSatisfyingFilter -->

   <xsl:template name="GroupMembersSatisfyingFilter">	

	<sldap:staffQueries>

			<sldap:usersOfGroup>

			<xsl:attribute name="groupDN">

				<xsl:value-of select="staff:parameter[@id='GroupName']"/>

			</xsl:attribute>

			<xsl:choose>

				<xsl:when test="staff:parameter[@id='IncludeSubgroups']='false'">

	  				<xsl:attribute name="recursive">no</xsl:attribute>

				</xsl:when>

				<xsl:when test="staff:parameter[@id='IncludeSubgroups']='true'">

	  				<xsl:attribute name="recursive">yes</xsl:attribute>

				</xsl:when>

				<xsl:otherwise>

	  				<xsl:message terminate="no">WARNING: Unexpected value: 

                                                    '<xsl:value-of select="staff:parameter[@id='IncludeSubgroups']"/>' 

                                                    for IncludeSubgroups. Continue using the default value 

                                                    'true'.

                                             </xsl:message>

				</xsl:otherwise>

			</xsl:choose>	

			<xsl:call-template name="ResultObjectSpecForGroupUserData" />

		</sldap:usersOfGroup>	

		<sldap:intermediateResult>

			<xsl:attribute name="name">filteredusers</xsl:attribute>

			<sldap:search>

  				<xsl:attribute name="filter">

  					<xsl:value-of select="staff:parameter[@id='Filter']"/>

  				</xsl:attribute>

  				<xsl:attribute name="searchScope">subtreeScope</xsl:attribute>

  				<xsl:attribute name="recursive">no</xsl:attribute>		

				<sldap:resultObject>

  					<xsl:attribute name="objectclass">

                                                     <xsl:value-of select="$DefaultPersonClass"/></xsl:attribute>

					<xsl:attribute name="usage">simple</xsl:attribute>		

					<sldap:resultAttribute>

						<xsl:attribute name="name">

                                                                   <xsl:value-of select="$DefaultUserIdAttribute"/>

                                                         </xsl:attribute>

						<xsl:attribute name="destination">intermediate</xsl:attribute>

					</sldap:resultAttribute> 

	  			</sldap:resultObject>	

  			</sldap:search>		

  		</sldap:intermediateResult>	

		<sldap:intersect>

			<xsl:attribute name="value">%filteredusers%</xsl:attribute>

		</sldap:intersect>

	</sldap:staffQueries>

   </xsl:template>   

<!-- End template GroupMembersSatisfyingFilter -->

  

Providing a new custom people assignment criteria that uses the <intersect> element

To include a new custom people assignment criteria into the set supported by WebSphere Integration Developer and WebSphere Process Server, proceed as follows:

a. Add the definition of the new people assignment criteria to the VerbSet.xml file

  <vs:DefineVerb name='Group Members satisfying Filter'>

        <vs:Description>Assigns the members of a group that

                                 also match the selection criteria of an LDAP filter.

                                 Supported by sample XSLT files for:

 - LDAP

    </vs:Description>

    <vs:Mandatory>

      <vs:Parameter>

        <vs:Name>GroupName</vs:Name>

        <vs:Type>xsd:string</vs:Type>

      </vs:Parameter>

      <vs:Parameter>

        <vs:Name>IncludeSubgroups</vs:Name>

        <vs:Type>xsd:boolean</vs:Type>

      </vs:Parameter>

     <vs:Parameter> 

       <vs:Name>Filter</vs:Name>

       <vs:Type>xsd:string</vs:Type>

      </vs:Parameter>

    </vs:Mandatory>

  </vs:DefineVerb>

  

b. Add the mapping support to your XSL transformation file

Add to the dispatching part in the XSL file:

      <xsl:when test="$verb='Group Members satisfying Filter'">


	     <xsl:call-template name="GroupMembersSatisfyingFilter"/>

      </xsl:when>  

  

Add the XSL template (GroupMembersSatisfyingFilter) specifying the mapping from the people assignment criteria specification to the LDAP query elements used by HTM. Use the template specified previously.

Migrating any 6.0.2 versions custom staff verbs to 6.1.0.3 custom people assignment criteria

Custom staff verb mappings that are defined in your LDAP transformation xsl file for any version of 6.0.2 Business Process Choreographer installation are not automatically migrated to custom people assignment mappings in a version 6.1.0 Fix Pack 3 installation. Every 6.0.2 custom staff verb mapping has to be considered individually and adapted appropriately to conform to V6.1.0 Fix Pack 3. Adapted mappings must be inserted into your 6.1.0 Fix Pack 3 LDAP transformation file.