How Context is Formed

The Context is used by Aware IM to resolve values of attributes of business objects during evaluation of rule collections (both ordered and un-ordered – see Evaluation of Rule Collections). It is important to emphasize that each rule collection has its own Context; there is no single Context that is shared by all rule collections. For example, let us suppose that we are executing a rule collection representing rules of a process. This rule collection has a Context associated with it (let us not worry for now how it was formed). If some action modifies the value of an attribute of some business object Aware IM starts evaluating the rules attached to this business object. Before doing so it assigns a new Context to this collection of rules (again let us not worry for now what gets written into this Context). Once the rules attached to the business object finish execution, the Context associated with the rule collection is discarded and Aware IM continues evaluation of the process rules. Now, if some action of these rules starts another process Aware IM assigns another Context and starts evaluating the rules of a sub-process. When the sub-process finishes Aware IM discards the Context and returns to the evaluation of the rules of the original process.

Let us now have a look at what gets written into the Context and when. The contents of the Context is changed under the following scenarios:

  1. Instances of the business objects found by the FIND and PICK FROM actions are written into the Context of the rule collection that invokes these actions1).
    For example, let us look at the following process:
    FIND Driver WHERE Driver.Name = 'John Smith'
   Driver.Age = 40

    The first rule in this process finds the driver with the name John Smith. If such an instance is found it is written into the Context.

  2. Instances of business objects or notifications created by the CREATE or ENTER NEW actions are written into the Context of the rule collection that invokes the actions.

    The following example is similar to the previous one:
    CREATE Driver WITH Driver.Name = 'John Smith'
  Driver.Age = 40
  3. When Aware IM starts evaluating the rules attached to a business object the instance of the business object is written into the Context. The instance is either taken from the parent Context (such as when an instance of a business object is modified by a process) or is provided by the external request (such as when a user changes attribute values on the business object form and submits the changes to the system).

    In the process from the first scenario the second rule modifies the attribute of the driver’s instance found by the previous rule. If the Driver object has rules attached to it Aware IM assigns a new Context to these rules, writes the instance of the Driver from the process Context into the new Context and starts evaluating rules of the Driver object.

  4. When Aware IM starts executing a process the instances of the business objects representing process input are written into the Context. The instances are taken from the parent Context. \\For example, consider the following process:
    FIND Policy WHERE Policy.MyDriver.Name = 'John Smith' 
   CalculatePremium

    Here we assume that CalculatePremium process that calculates the premium of the policy has the Policy object declared as its input. The first rule finds the policy belonging to John Smith and writes it into the Context of the main process. Then Aware IM creates a new Context for the CalculatePremium process, writes the instance of the Policy from the main process’s Context into the new Context and starts evaluating rules of the CalculatePremium process.

  5. When a new instance of a business object or notification is created by the CREATE action Aware IM writes the contents of the parent Context into the new Context which is created when rules attached to the business object or notification are evaluated.

In other words the Context of the parent rule collection is available when a new business object or notification are being created. For example consider the following process, 

FIND Policy WHERE Policy.ExpiryDate < CURRENT_DATE 
CREATE ExpiryEmail
SEND ExpiryEmail TO Policy.Driver

The first rule of the process finds the expired policy and puts the found instance into the Context of the process. The second rule of the process creates the notification ExpiryEmail and evaluates any rules attached to the creation of this notification2). The new Context is assigned to these rules, but now not only the created notification is written into this Context but the entire contents of the existing Context is written into the new Context as well. Therefore in this example Policy instance is available to any initialization rules of the notification. The created notification is also written into the original Context (as a result of creation), so in this particular case both Contexts have identical contents.

note

The following instances of business objects are always accessible to rules directly – there is no need to find them using the FIND action, as they are always implicitly present in any Context:
  1. An instance of a business object representing logged in user (must be a member of the SystemUsers group) – this instance can be referred to using LoggedIn prefix (see Instance Prefixes), for example LoggedInLibraryMember where LibraryMember is a business object belonging to the SystemUsers group.
  2. Instances of intelligent business objects with Business or System intelligence types. There are always only single instances of such business objects in the system, so they can always be unambiguously resolved.
  3. An instance of the SystemSettings object.

note

If there are multiple instances of the same business object in the Context any action that operates on such a business object operates on all instances of the object present in the Context. For example, in the scenario 1 above which describes the modification of the Driver object found by the FIND action, if the action finds several instances of the Driver object all these instances are written into the Context. Consequently the action that modifies the Age attribute modifies every single instance of the Driver object found by the FIND action. Similarly in scenario 5 if there are several expired policies the email is sent to owners of each policy.

note

When rules of an un-ordered rule collection are executed (see Evaluation of Unordered Rule Collection) instances of business objects and notifications created by the CREATE or ENTER NEW actions or found by the FIND or PICK FROM actions are not written into the Context of the un-ordered rule collection. Instead these instances are made available only within the action block that contains the FIND (PICK FROM) or CREATE (ENTER NEW) actions. This means, for example, that it is quite meaningless to attach rules to a business object, which have single FIND action. However, having an action block that finds some object and then does something with the found instance within this block may be quite meaningful.
1)
If an un-ordered collection is executing the instances are written into the Context of the action block - see Note 3 later in this section.
2)
In this example the CREATE rule is actually unnecessary. The SEND action would automatically create the notification if it has not been created already.
  • Last modified: 2022/09/13 18:15