Traversing over relationships can be enhanced by a filter. For example, if you want to see only addresses of type M, add a filter element with the eq subelement, as shown in the following request syntax:

<request>
	<startWith entity="party" origin="crm#customer#party" sourceId="1002" />
	<traversal>
		<traverse relationshipName="addresses">
			<filter>
				<eq attribute="cmo_type" value="M" />
			</filter>
		</traverse>
	</traversal>
</request>

The response will be only one address:

<list>
	<address>
		<metadata>
			...
		</metadata>
		<attributes>
			<party_master_id>38</party_master_id>
			<cmo_type>M</cmo_type>
			<cmo_street>80 Hemlock Dr</cmo_street>
			<cmo_city>Anmore</cmo_city>
			<cmo_state>BC</cmo_state>
			<cmo_zip>V3H4W9</cmo_zip>
		</attributes>
		<relationships/>
	</address>
</list>

Traversing filter can have more advanced conditions. For example, if you want only addresses that have good quality address instances, use the following request syntax:

<request>
	<startWith entity="party" origin="crm#customer#party" sourceId="1002" />
	<traversal>
		<traverse relationshipName="addresses">
			<filter>
				<exists>
					<traverse relationshipName="instances">
<!-- virtual traverse to address_instance records -->
						<filter>
							<eq attribute="sco_address"value="0" /> <!-- good quality means score is 0 -->
						</filter>
					</traverse>
				</exists>
			</filter>
		</traverse>
	</traversal>
</request>

This request can be translated as the following:

• Get the party record with sourceId = 1002 and origin = crm#customer#party.
• Traverse over the addresses relationship.
• For filter records, allow only those for which there is a related instance address record that has sco_address equal to zero.

This example shows that a filter defined by an exists condition can be recursive: depth is not limited. However, every step of recursion decreases performance of the service.

The filter element can contain multiple eq and exists sub-elements. Those are evaluated by default as AND, for example, all conditions must be met to return a record. You can change this to OR by setting up an operator attribute on the filter element, as shown in the following syntax:

<request>
	<startWith entity="party" origin="crm#customer#party" sourceId="1002" />
	<traversal>
		<traverse relationshipName="addresses">
			<filter operator="OR">
				<eq attribute="cmo_type" value="M" />
				<eq attribute="cmo_type" value="R" />
			</filter>
		</traverse>
	</traversal>
</request>

Traversing over relationships can be chained. For instance, multiple traverse elements can define a long path from the starting point to the destination entity. For example, if you want to get all parties related to input party records, use the following request syntax:

<request>
	<startWith entity="party" origin="crm#customer#party" sourceId="1002" />
	<traversal>
		<traverse relationshipName="relparent" /> <!-- traverse to
associative entity rel_party_party -->
		<traverse relationshipName="child" /> <!-- traverse
back to party -->
	</traversal>
</request>

Each traverse element can have its own complex filter as described above.

When preloading related records, you can apply a filter so that only some records are returned. For example, if you want a party record with all addresses of type M, use the following request syntax:

<request>
	<startWith entity="party" origin="crm#customer#party" sourceId="1002" />
	<preloadedRelationships>
		<rel name="addresses">
			<filter>
				<eq attribute="cmo_type" value="M" />
			</filter>
		</rel>
	</preloadedRelationships>
</request>

The response will contain a party record with one address, as shown in the following syntax.

<list>
	<party>
		<metadata>
		...
		</metadata>
		<attributes>
			<cmo_type>P</cmo_type>
			<cmo_first_name>Smith</cmo_first_name>
			<cmo_last_name>John</cmo_last_name>
			<cmo_gender>M</cmo_gender>
			<cmo_birth_date>1978-12-16T00:00:00+01:00</cmo_birth_date>
			<cmo_sin>095242434</cmo_sin>
		</attributes>
		<relationships>
			<addresses>
				<address>
					<metadata>
						...
					</metadata>
					<attributes>
						<party_master_id>38</party_master_id>
						<cmo_type>M</cmo_type>
						<cmo_street>80 Hemlock Dr</cmo_street>
						<cmo_city>Anmore</cmo_city>
						<cmo_state>BC</cmo_state>
						<cmo_zip>V3H4W9</cmo_zip>
					</attributes>
					<relationships/>
				</address>
			</addresses>
		</relationships>
	</party>
</list>

There are several more possibilities:

• Specifying a more complex filter: several eq and exists subelements
• Preloading multiple relationships, for example, a party record with all related addresses and contacts.
• Preloading records related to related records, for example, a party record with related addresses and address instances, or a party record with all related parties (jump over the associative entity rel_party_party). This scenario is described in the following section.

As an example, if you want to retrieve a party record with all related parties, you can use the following request syntax:

<request>
	<startWith entity="party" origin="crm#customer#party" sourceId="1002" />
	<preloadedRelationships>
		<rel name="relparent/child" />
	</preloadedRelationships>
</request>

Note the definition of preloadedRelationships relparent/child. If you want to preload records related over several relationships, you have to concatenate the names of relationships with the slash (/). This will force the service to jump over two relationships to get to records.

If you specify a filter for this preloaded relationship, it will be applied to records of the last entity, for example, party. If you want to specify a filter to be applied to the first entity (for example, associative entity rel_party_party in this example), you will have to add that entity to preloadedRelationships, as shown in the following request syntax:

<request>
	<startWith entity="party" origin="crm#customer#party" sourceId="1018" />
	<preloadedRelationships>
		<rel name="relparent">
			<filter> <!-- filter on associative entity rel_party_party -->
				<eq attribute="cmo_p2p_rel_type" value="FAMILY" />
			</filter>
		</rel>
		<rel name="relparent/child">
			<filter> <!-- filter on related party entity -->
				<eq attribute="cmo_gender" value="M" />
			</filter>
		</rel>
	</preloadedRelationships>
</request>

The response will be a more complex hierarchical XML:

<list>
	<party>
		<metadata>
			...
		</metadata>
		<attributes>
<!-- party attributes -->
			<cmo_type>P</cmo_type>
			<cmo_first_name>Sandy</cmo_first_name>
			<cmo_last_name>Hettinger</cmo_last_name>
			<cmo_gender>F</cmo_gender>
			<cmo_birth_date>1965-09-21T00:00:00+01:00</cmo_birth_date>
			<cmo_sin>856527270</cmo_sin>
		</attributes>
		<relationships>
			<relparent>
				<rel_party_party>
					<metadata>
						...
					</metadata>
						<attributes> <!-- party2party relation attributes -->
						<parent_id>29</parent_id>
						<child_id>31</child_id>
<cmo_p2p_rel_type>FAMILY</cmo_p2p_rel_type>
					</attributes>
				<relationships>
					<child>
						<party>
							<metadata>
								...
						</metadata>
						<attributes>
<!-- attributes of related party -->
<cmo_type>P</cmo_type>
<cmo_first_name>Tom</cmo_first_name>
<cmo_last_name>Donathan</cmo_last_name>
<cmo_gender>M</cmo_gender>
<cmo_birth_date>1966-02-04T00:00:00+01:00</cmo_birth_date>
<cmo_sin>961085248</cmo_sin>

								</attributes>
								<relationships/>
							</party>
						</child>
					</relationships>
				</rel_party_party>
			</relparent>
		</relationships>
	</party>
</list>

The following example shows party sourceId as an input, with the following request:

• All family-related party records representing males with the following conditions:
  • Only those males with good data quality email addresses.
  • Only those males living in the city of Anmore.
• Return the email addresses of the party that have good data quality and their addresses.

"We want to email every man in Ohio this party is related to as family."

<request>
	<startWith entity="party" origin="crm#customer#party" sourceId="1018" />
	<traversal>
		<traverse relationshipName="relparent">
			<filter>
				<eq attribute="cmo_p2p_rel_type" value="FAMILY" />
			</filter>
		</traverse>
		<traverse relationshipName="child">
			<filter>
				<eq attribute="cmo_gender" value="M" />
				<exists>
					<traverse relationshipName="contacts">
						<filter>
							<eq attribute="cmo_type" value="email" />
							<exists>
								<traverse relationshipName="instances">
									<filter>
										<eq attribute="sco_value" value="0" />
									</filter></traverse>
								</exists>
							</filter>
						</traverse>
					</exists>
					<exists>
						<traverse relationshipName="addresses">
							<filter>
								<eq attrbitue="cmo_city" value="Anmore" />
							</filter>
						</traverse>
					</exists>
				</filter>
			</traverse>
		</traversal>
		<preloadedRelationships>
			<rel name="contacts">
				<filter>
					<eq attribute="cmo_type" value="email" />
					<exists>
						<traverse relationshipName="instances">
							<filter>
								<eq attribute="sco_value" value="0" />
							</filter>
						</traverse>
					</exists>
				</filter>
			</rel>

			<rel name="contacts/instances" />
			<rel name="addresses" />
		</preloadedRelationships>
	</request>

The service performs the following tasks:

• Gets the party instance record by its sourceId and origin.
• Gets the master record for the instance.
• Gets all relations for the record of type FAMILY.
• Gets all party records form those relations.
• Filters the following party records:
  • cmo_gender is M.
  • Gets all related address records and checks if there is at least one with cmo_city equal to Anmore.
  • Gets all related contact records and filters only those of type email, then gets all related instance records and checks whether sco_value equals zero.
  • Checks that at least one contact record satisfies the above conditions.

You can see that GenericTraverseMasterService is very powerful and can create quite complex queries on master data. However, note that complex queries will require corresponding HW resources for both the iWay MDS engine and underlying database storage. This particular example executes about 10 SQL queries just for one call.