Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Take into account the following behaviors when using the Aggregation profile:

  • You can

...

  • apply an Aggregation profile to any number of workflow configurations.

...

...

  • Aggregation

...

Info

Example - Defining a Session UDR type in an Ultra Configuration

Code Block
session SessionUDRType {
   int intField;
   string strField;
   list<drudr> udrList;
};

It is recommended that you keep the session UDR as small as possible. A larger UDR decreases performance compared to a small one.

Note

Note!

Take particular care when updating the Ultra formats. It is not possible to collect data from the Aggregation session storage if the corresponding UDR has been renamed. However, if you change the format definition, you can still collect the data.

Changes to the formats are handled as follows:

  • Default values are assigned to fields that are added or renamed.

  • Fields that have been removed are ignored.

  • Default values are assigned to fields with data types that have been changed.

For further information on Ultra formats, see Ultra Format(4.2).

Profile Configuration

To create an Aggregation profile, go to the Configuration icon and select the profile from the list.

The profile consists of four tabs:

  • Session Tab

  • Association Tab

  • Storage Tab

  • Advanced Tab

Session Tab

In the Session tab you can browse to and select a Session UDR Type and configure the Storage selection settings.

...

Setting

...

Description

...

Session UDR Type

...

Click Browse to search for the Session UDR type that you want to use. See Preparations for your Profile above for information on creating a Session UDR type.

...

Storage

...

Select the type of storage for aggregation sessions. The available settings are Couchbase StorageElasticsearch Storage, File Storage, Memory Only, Redis Storage and SQL Storage.

  • Couchbase Storage and Redis Storage can only be used in real-time workflows. These storage types allow highly available systems with geographic redundancy. The session data that is replicated within the storage is available across workflows, ECs, and systems. This serves to minimize data loss in failover scenarios.

  • Elasticsearch Storage and SQL Storage can only be used in batch workflows.

  • File Storage can be used in batch and real-time workflows.

  • Memory Only can only be used in real-time workflows.

Note

Note!

Data stored in Couchbase or Redis is not available in the Aggregation Session Inspector(4.2).

...

Association Tab

You use the Association tab to configure rules that are used to match an incoming UDR with a session. Every UDR type requires a set of rules that are processed in a certain order. In most cases, only one rule per incoming UDR type is defined.

  • sessions created in the storage that is specified by the profile can be accessed by multiple active workflows simultaneously.

  • When you have selected file storage and are using an Aggregation profile across several workflow configurations, you must consider the read-and-write lock mechanisms that are applied to the stored sessions. For further information about read-and-write locks, see Aggregation Agent - Batch(4.2) and Aggregation Agent - Real-Time(4.2).

  • The Aggregation profile is loaded when you start a workflow that depends on it. Changes to the profile become effective when you restart the workflow.

Session UDR

Each Aggregation profile stores sessions of a specific Session UDR type that you define in ultra. This means that your Aggregation profile configuration must include a session UDR type. See the example below:

Info

Example - Defining a Session UDR type in an Ultra Configuration

Code Block
session SessionUDRType {
   int intField;
   string strField;
   list<drudr> udrList;
};

It is recommended that you keep the session UDR as small as possible. A larger UDR decreases performance compared to a small one.

Note

Note!

Take particular care when updating the Ultra formats. It is not possible to collect data from the Aggregation session storage if the corresponding UDR has been renamed. However, if you change the format definition, you can still collect the data.

Changes to the formats are handled as follows:

  • Default values are assigned to fields that are added or renamed.

  • Fields that have been removed are ignored.

  • Default values are assigned to fields with data types that have been changed.

For further information on Ultra formats, see Ultra Format(4.2).

Profile Configuration

The contents of the buttons in the menu bar may change depending on which configuration type has been opened in the currently active tab. The Aggregation profile uses the standard buttons that are visible for all configurations, and these are described in Build View (4.2).

The profile consists of four tabs:

  • Session Tab

  • Association Tab

  • Storage Tab

  • Advanced Tab

Session Tab

In the Session tab you can browse to and select a Session UDR Type and configure the Storage selection settings.

...

Setting

Description

Session UDR Type

Click Browse… to search for the Session UDR type that you want to use. See https://infozone.atlassian.net/wiki/spaces/UEPE4D/pages/edit-v2/233738277#Session-UDR above for information on creating a Session UDR type.

Storage

Select the type of storage for aggregation sessions. The available settings are:

  • Couchbase Storage

  • Elasticsearch Storage

  • File Storage

  • Memory Only

  • Redis Storage

  • SQL Storage

File Storage and Memory Only can be used in batch and real-time workflows.

Elasticsearch Storage and SQL Storage can only be used in batch workflows.

Couchbase Storage and Redis Storage can only be used in real-time workflows. These storage types allow highly available systems with geographic redundancy. The session data that is replicated within the storage is available across workflows, EC Groups, and systems. This serves to minimize data loss in failover scenarios.

Note

Note!

Data stored in Couchbase or Redis is not available in the Aggregation Session Inspector(4.2).

...

Association Tab

You use the Association tab to configure rules that are used to match an incoming UDR with a session. Every UDR type requires a set of rules that are processed in a certain order. In most cases, only one rule per incoming UDR type is defined.

You can use a primary expression to filter out UDRs that are candidates for a specific rule. If the UDR is filtered out by the primary expression, it is matched with the existing sessions by using one or several ID fields as a key.

For UDRs with ID Fields matching an existing session, an additional expression may be used to specify additional matching criteria. For example, if dynamic IP addresses are provided to customers based on time intervals, the field that contains the IP address could be used in ID Fields while the actual time could be compared in Additional Expression.

...

Setting

Description

UDR Types

Click the Add button to select a UDR type in the UDR Internal Format dialog. The UDR type that you select then appears in this field. A UDR type may have a list of rules attached to it. When you select the UDR type, its rules appear as separate tabs to the right in the Aggregation profile configuration.

Primary Expression

The Primary Expression is optional. You can enter an APL code expression that is to be evaluated before the ID Fields are evaluated. If the evaluation result is false the rule is ignored and the evaluation continues with the next rule.

Use the inputvariable to write this filtering expression.

ID Fields

Click the Add button to select additional ID Fields in the ID Fields dialog. These fields, along with the Additional Expression settings, enable Usage Engine to determine whether a UDR belongs to an existing session or not. If the contents of the selected fields match the contents of a session and an  Additional Expression  evaluation results in true, the UDR belongs to the session.

Note

Note!

Ensure that the selected fields are of the same type and appear in the same order for all the rules that are defined for the agent.

Additional Expression

The Additional Expression is optional. Enter an APL code expression that is to be evaluated with the ID Fields.

Use the inputvariable to write this filtering expression.

This setting is useful when you have several UDR types with a varying number of ID Fields to be consolidated. Having several UDR types requires the ID fields to be equal in number and type. If one of the types requires additional fields that do not have any counterpart in the other type or types, these must be evaluated in the Additional Expression field. Save the field contents as a session variable, and compare the new UDRs with it.

Note

Note!

When using Additional Expressions for Aggregation the caching mechanism only takes into account the primary and secondary rules when creating the session CRC. This means that if the number of sessions that cannot be told apart without the use of an Additional Expression is high, the performance of the Aggregation Agent decreases due to cache read/write operations. This is especially true if the Max Cached Sessions property is low compared to the number of sessions. For this reason, it is recommended that Max Cached Sessions is set to a high value when using Additional Expressions.

Create Session on Failure

Select this check box to create a new session if no matching session is found. If the check box is not selected, a new session is not created when no matching session is found.

Note

Note!

If you provide a primary expression, and it evaluates to false, the rule is ignored and no new session is created.

If the order of the input UDRs is unimportant, select this check box for all the rules. This means that the session object is created regardless of the order in which the UDRs arrive.

However, if the UDRs are expected to arrive in a particular sequence, only select Create Session on Failure for the UDR type/field that is considered to be the master UDR, i.e. the UDR that marks the beginning of the sequence. In this case, all the slave UDR types/fields are targeted for error handling if they arrive before their master UDR.

Note

Note!

At least one of all defined rules must have this check box selected. Otherwise, no session is created.

For further information about all available system properties, see System Properties (4.2).

Add Rule

Click this button to add a new rule for the selected UDR type. The rule appears as a new folder to the right of the UDR types in the Aggregation profile configuration.

Usually, only one rule is required. However, in a situation where a session is based on an IP number, stored in either a target or source IP field, two rules are required. The source IP field can be listed in the ID Fields of the first rule and the target IP field listed in the ID Fields of the second rule.

Remove Rule

Click this button to remove the selected rule.

...

Storage Tab

The Storage  Storage tab contains settings that are specific to the selected storagefor File Storage, Couchbase Storage, Redis Storage, Elasticsearch Storage, and SQL Storage.

Couchbase Storage

image-20240415-094900.pngImage Modified

Setting

Description

Profile

Select a Couchbase (4.2) profile. This profile is used to access the primary storage for aggregation sessions.

Mirror Profile

Selecting this Couchbase profile is optional. It is used to access a secondary storage, providing read-only access for aggregation sessions. Typically, the Mirror Profile is identically configured to a (primary) Profile, that is used by workflows on a different EC or other Usage Engine system. This is useful to minimize data loss in various failover scenarios. The read-only sessions can be retrieved with APL commands. For more information and examples, see Aggregation Functions(4.2).

...