Often times when we are authoring our rules, we need a data element somewhere else in our schema or data hierarchy. To review, child entities that possess a one-to-one relationship with its parent entity are directly in the context of its parent. Child collections with a one-to-many relationship with its parent entity can be interrogated using aggregate or lookup functions. When a rule is at the context of a child entity and the needed data exists in the parent entity, you can easily access it with the Parent Context option selected as shown in the examples below.
We see that Parent Context option allows rules written at the child level to access data on the parent level. However, what can we do when we need to access information in the context of the parent entity if we cannot use Parent Context?
Use Case
A good example of this could be an address. An address uses a standard entity structure and it would make sense to use a single entity format and reuse it. However, that address could belong to a customer, vendor, provider, or an institution.
For this example, let us assume that we are validating transactions between a vendor and a customer and we need to ensure that the vendor and customer are not using the same address. In addition, both the customer and the vendor can have multiple addresses, such as the mailing address and finding address. For this example, we have a resulting schema like this:
To compare each vendor address against each customer address, we will use a pair of techniques using entity variables and entity parameters in explicit rulesets.
One feature that sets apart explicit rule sets from auto-firing rule sets is the ability to accept parameters. These parameters can be any of the .NET primitive types or an entity. We will begin by creating an explicit rule set at the customer level that will accept an Address entity as a parameter as shown below.
Now we can use collection functions to see if any of the addresses belonging to the customer match our vendorAddress parameter like so:
Next, we will create a rule set in the context of the Vendor. A For each rule was used, using an entity variable. This rule will take each address in the address collection, assign it to my vendorAddress entity variable, and then I can use the Execute Rule set action to fire the explicit rule set that I made above using my entity variable as a parameter. An example of this is shown below:
By using entity variables or parameters, we can access parts of our schema that may not be easily accessible. Even top-level entities can be passed down to collections many levels removed without parent context. Furthermore, one will also have access to Vocabulary Templates and rule sets within the context of the entity type specified. Together these techniques provide additional flexibility to your rule applications.
In our next Patterns and Practices post, we will demonstrate the use of temporary collections where members are located in a different location from the root-level entity.
