Collections, Agent Classes, and Processing Units

Collections

On the Collections tab, you can (optionally) group rules, rule functions, and destinations into collections so that they can be easily assigned to agent classes (and processing units in the case of log configurations).

See Configuring Collections of Rules, Rule Functions, and Destinations.

Agent Classes

Agent classes define the different sorts of agents you can deploy. Various agent types are available depending on the object management (OM) type and on the add-on products used. Each agent type is configured differently.

Note: See Using Properties at Different Levels to understand the effect of using agent class properties at the cluster level and at the processing unit level to widen the scope of the property.

Configuring Agents with Collections and Individual Resources

Different agent types use different types of resources.

In the Agent Classes node (on the left side of the CDD editor) you see categories of collections. Here, you add collections you defined earlier, as needed to configure the agent class.

Rules

(Inference agent classes only.) It can be convenient to organize rules into collections for use in different inference agent classes. Select rule collections and individual rules as needed to define what rules will execute on inference agents of such classes at runtime.

Input Destinations

Different agents listen for messages arriving at different destinations. When you select a destination for use in a collection or an individual agent, you add deploy time configuration settings, to create a destination configuration. For example, you define an event preprocessor and a threading model to use. Each destination configuration is assigned a unique ID.

In the configurations for Input Destinations under Collections, you can optionally specify this rule function under Thread Affinity Rule Function.

Note: This is only available for Shared Queue and Destination Queue threading configurations. When specified, the return value from the rule function is used to pick up the thread to which the message will be dispatched. The rule function is called with the event as the parameter, and is expected to return a not null value. Events that return the same value, will always be assigned to the same thread.

It is required that the rule function handles its exceptions and does null checks and returns non-null values. Failure to do so will cause the message allocation to a thread to fail also. In other words, the message will fail to propagate.

The rule function should be lightweight and should only perform read-only operations on the event or its payload.

Note: It is only a convenience mechanism to identify, compute and return the relationship key. It should not perform the wider range of operations that are allowed in rule functions used elsewhere such as in pre-processors or in rules, such as load, create, update, delete objects, acquire locks and so on. Doing so may cause unknown behavior.

Startup Functions and Shutdown Functions

Select function collections and individual functions as needed, to define which functions execute at engine startup and shutdown respectively.

Tip:

How Startup Rule Functions and Shutdown Rule Functions are Executed

The order of the functions (including the order of functions within collections) is the order in which they execute at runtime.
Put startup rule functions (for use at start up) into different collections from shutdown rule functions (those used at shut down) so you can select them appropriately on the agent classes tab.

Log Configurations

Also on the Collections tab, you can add different log configurations. These are used when you configure processing units.

See Log Configurations.