Process phases in Rule Engine

The following illustration shows all the possibilities you could encounter in a session. If you have not enabled any particular function, the system skips automatically to the next function in the sequence.

Processing phases

Characteristics

This core function carries out consistency checks on the settings supplied.

Process

The parameter settings you provide configure Rule Engine at the start of the session. The system runs consistency checks on the major options at this point to avoid any anomalies that may bring the transformation process to a halt. For example, the system checks the definitions of:

  • Stamping identifiers for consistency with the audit option chosen
  • The position of fields when they are to be identified by segment

What happens if an error occurs?

The system halts the session with a configuration error, return code = 12.

Read in the Input-Events

Characteristics

This core function can be configured via script.ges for the relevant type of exchange zone.

Process

File Mode

The file is read sequentially, taking into account either the position and length or the fixed values of the Input-Event identifiers, in the following decreasing order of priority:

  • The group code, if you activated the group management option
  • The name of the Input-Event type
  • The version number of the Input-Event type

The occurrence of an Input-Event is identified by an identical set of values for:

  • The name of the Input-Event type
  • The version number of the Input-Event type
  • The instance code

A change in any of these values indicates a new occurrence of an Input-Event.

An Input-Event group is identified by the value of the group code, which is the same for all Input-Events in the group. A change in this value indicates a change of Event group.

MQSeries mode and JMS mode

The system reads through the queue in order of arrival. Each instance of an Input-Event must be described completely within a given message. However, a single message may contain more than one instance of an Input-Event. For more information, refer to Read and produce messages.

What happens if an error occurs?

The system halts the session with a system error (return code = 16).

Input-Event restructuring exit

Characteristics

This optional function is activated through script.ges.

For more information, refer to Rule Engine Exits and External Calls.

Process

The exit processes the Input-Event segments in the order in which they are input into Rule Engine.

This exit enables you to:

  • Create
  • Merge
  • Re-order
  • Delete
  • Change the contents of Input-Event segments

What happens if an error occurs?

The system rejects the Input-Event that is being processed (return code = 6).

If an error occurs during the restructuring process, this causes the system to stop the session (return code = 16).

Identify Input-Events

Characteristics

This core function can be configured for each technical field via the associated Processing-Context-In.

For each technical field, identification by:

  • segment means that the system picks out the identifier in the segment by its position and length, as defined for the associated Processing Context-In
  • context means that the value of the identifier is unique within the session and referenced by a constant supplied by the associated Processing Context-In

Rule Engine looks for the following fields.

Field type Contents

The identifiers related to the Input-Event type

Name of the Input-Event type

Version of the Event type

Name of the segment type

Instance code (if present)

Group code (if present)

The Input-Event processing parameters

Balancing check code

Reversal code

Anomaly phase code. The Input-Event is to be recycled back through the Transformation-Phase

Process

The point at which the system carries out this identification depends on the options that you activated for the session. If all options are activated, the system runs the identification immediately before the sort.

However, if you have not activated the sort option, the identification is carried out immediately before pre-processing. Similarly, if you have not activated the Input-Event aggregation option, identification is carried out immediately before processing. The system carries out the identification for each segment it encounters.

What happens if an error occurs?

The system rejects the Input-Event that is being processed, as it cannot be identified (return code = 6).

If you have not activated the Group Management option, and the system has identified a group to which the rejected Input-Event belongs, this group is itself rejected. In this case the system sets a return code = 8, which takes priority over the return code = 6.

If a rejection threshold is reached, either for Events or groups, this causes the system to stop the session, with a return code=10.

Sort Input-Events

Characteristics

This optional function is enabled through sys.dat. For more information, refer to Sort Input-Events. However, it is automatically activated if you select the Input-Event aggregation option.

What happens if an error occurs?

The system halts the session with a system error (return code = 16).

Preprocess Input-Events (spyglass A)

Characteristics

This optional function is enabled through script.ges when you specify preprocessing for the Input-Event types that are to be processed.

Process

The system preprocesses the Input-Event segments in the order in which they emerge from the sorting process. For more details, refer to Sort Input-Events.

The processing comprises:

  • Input-Event audit before aggregation
  • Input-Event aggregation
  • Input-Event audit after aggregation

The system preprocesses the segments in sets. The sets are built from the results of the sort process and are composed of either of the following:

  • Segments belonging to a single Input-Event, if the Input-Event being processed is multi-segment
  • For mono-segment Input-Events, segments belonging to more than one Input-Event.
    If you set the Group Management option, the system aggregates the Input-Events by group. The group code is an implicit criterion for aggregation.

The system can extract an audit trace for each individual segment emerging from the sort process, provided that you configured this option for the preprocessing of the relevant Input-Event type.

The individual segments are then aggregated in accordance with their associated aggregation rule.

An audit trace can also be extracted for the aggregated segment emerging from the aggregation process, provided you configured this option for the preprocessing of the Input-Event type.

What happens if an error occurs?

The system rejects the Input-Event that is being processed (return code = 6).

If you have set the Group Management option, the group to which the Event belongs is itself rejected. In this case, the systems sets a return code = 8, which takes priority over the return code = 6.

If a rejection threshold is reached, either for Input-Events or groups, this causes the system to stop the session with a return code = 10.

Input-event aggregation exit

This optional function is enabled through sys.dat during Input-Event aggregation. You must activate the Input-Event aggregation option. For details, see Axway Rule Engine Exits and External Call.

The exit processes the segments in the order in which they are input into Rule Engine.

What happens if an error occurs?

The system rejects the Input-Event that is being processed (return code = 6).

If you have set the Group Management option, the group to which the Event belongs is itself rejected. In this case, the systems sets a return code = 8, which takes priority over the return code = 6.

If a rejection threshold is reached, either for Input-Events or groups, this causes the system to stop the session with a return code = 10.

A more serious error causes the session to stop with a return code = 16.

Enrich and check Input-Events (spyglass B)

Characteristics

This core function includes certain optional operations, which are configured in sys.dat.

The core operations check the Input-Events that are to be transformed.

These operations take place before transformation and check that:

  • The parameters specify only processes that are valid for the Input-Event type that is to be processed
  • The Input-Event type to be processed is valid for the DAR

The optional operations allow you to:

  • Activate an exit to enrich or check Input-Event segments
  • Check for the existence of the rules that are to be applied

Process

The order in which the system enriches and checks Input-Events depends on the processing that has already been applied to them, such as sorting, preprocessing, restructuring by exits, and so on.

The Input-Events are enriched and checked one at a time. Rule Engine loads an instance of an Input-Event into memory, that is, all the segments of the Input-Event, and enriches and checks them in accordance with the configuration settings.

What happens if an error occurs?

The system places the Input-Event being processed in anomaly for the Transformation-Phase in which the error occurred (return code= 4).

If the Input-Event being processed is placed in anomaly for all the Phases, the system rejects the Input-Event (return code= 6).

If you set the Group Management option, the system places the group to which the Input-Event belongs itself placed in anomaly or rejects it. In this case, the system sets a return code = 8, which takes priority over the return codes 4 or 6.

If a rejection threshold is reached, either for Input-Events or groups, this causes the system to stop the session with a return code = 10.

If the error is more serious, the system stops the session with an error code = 16.

Process Input-Events (spyglass C)

Characteristics

This core function applies the rules for processing the various Input-Event types.

Process

The system processes the Input-Event segments in the order in which they were enriched and checked, if applicable.

In the same way as explained above, the Input-Events are processed one at a time. Rule Engine loads an instance of an Input-Event into memory, that is, all the segments of the Input-Event, and checks and processes them in accordance with the configuration settings.

The system applies processing according to the follow rules:

  • If you configured more than one phase, the system executes them in the alphabetical order of the phase names
  • Within a phase, the system applies rules in the order in which you configured them for the Input-Event type
    The system applies each rule to all segments of one type before it applies the next phase rule

Rule Engine stores in memory all data relating to the Input-Event currently being processed until it finishes processing that Input-Event. This data comprises:

  • The Input-Event itself (all segments)
  • Any anomalies that arise
  • The Output-Events generated
  • The traces extracted
  • The segments modified

Illustration of the processing applied

Input-Event type:  COMM_RECEP (commissions due).

This Input-Event type consists of two segment types:

  • COMM_FCPS (Commissions on mutual funds)
  • COMM_GENE (Commissions due, all types)

The phases to apply to this Input-Event type are as follows.

Phase Segment type Associated Transformation-Rule

GENERAL_ACCOUNTING

COMM_FCPS

FRC01
(general accounting - mutual funds, French securities)

FRC11
(general accounting - mutual funds, foreign securities)

 

COMM_GENE

1RC01
(general accounting - French securities)

1RC11
(general accounting - foreign securities)

ADMINISTRATION

COMM_GENE

1ST01
(processing statistics - French securities)

1ST02
(International group information - foreign securities)

 

COMM_FCPS

FST01
(statistics on volume processed - French securities)

FST02
(International group information - mutual funds, foreign securities)

COST_ACCOUNTING

COMM_FCPS

XRC01
(cost accounting - mutual funds, all securities)

 

COMM_GENE

2RC01
(cost accounting - all securities)


This example uses an instance of Input-Event COMM_RECEP composed of the following, ordered segments:

  • 12 COMM_GENE segments
  • 6 COMM_FCPS segments
  • 5 COMM_GENE segments

The system executes the phases in the following sequences:

Phase

Rule Applied Number of Applications Segment Type Processed

1 - The ADMINISTRATION phase this being the first phase name in alphabetical order

 

 FST01

6

COMM_FCPS

 

 FST02

6

COMM_FCPS

 

 1ST01

17 ( 12 + 5 )

COMM_GENE

 

 1ST02

17 ( 12 + 5 )

COMM_GENE

2 - The COST_ACCOUNTING phase, the next phase name in alphabetical order

 

 XRC01

6

COMM_FCPS

 

 2RC01

17 ( 12 + 5 )

COMM_GENE

3 - The COST_ACCOUNTING phase, the next phase name in alphabetical order

 

 FRC01

6

COMM_FCPS

 

 FRC11

6

COMM_FCPS

 

1RC01

17 ( 12 + 5 )

COMM_GENE

 

 1RC11

17 ( 12 + 5 )

COMM_GENE

What happens if an error occurs?

The system places the Input-Event it is processing in anomaly in the Transformation-Phase in which the processing error occurred (return code=4).

If the Input-Event being processed is placed in anomaly for all the Phases, the system rejects the Input-Event (return code= 6).

If you activate the Group Management option, Rule Engine rejects or places in anomaly the group to which the Input-Event belongs. In this case, a return code = 8 is set, taking priority over the return codes 4 or 6.

If a rejection threshold is reached, either for Input-Events or groups, this causes the system to stop the session with a return code = 10.

If the error is more serious, the system stops the session with an error code = 16.

Process Output-Events (spyglass D)

Characteristics

This core function includes certain optional operations, which are configured for the associated Processing Context-In.

Rule Engine processes Output-Events in sets, where each set consists of the Output-Events generated when you apply a Transformation-Rule to a segment.

Process

Rule Engine processes Output-Events sequentially. For each Output-Event, the processing is applied in the following order:

  • Core processing: Identifying the associated Processing-Context-Out
  • Optional processing:
    • Checking or enrichment by exit
    • Accounting processing
    • Balancing checks by rule
    • Extracting the trace or a traceability check
    • Aggregation or an “aggregability” check

What happens if an error occurs?

The Input-Event from which the Output-Event was created that gave rise to the processing error is placed in anomaly. Also, the products of the phase that created the Output-Event are canceled (return code=4).

If the Input-Event from which the Output-Event is derived is placed in anomaly for all the Phases, the Input-Event is rejected (return code= 6).

If the Group Management option is enabled, the group to which the Input-Event belongs is itself placed in anomaly or rejected. In this case, a return code = 8 is set, taking priority over the return codes 4 or 6.

If a rejection threshold is reached, either for Input-Events or groups, this causes the system to stop the session with a return code = 10.

If the error is more serious, the system stops the session with an error code = 16.

Input-Event / Group Level Checks (spyglass E)

Characteristics

This core function is applied in accordance with the options activated for the session.

Process

Checks are carried out at Input-Event level when all the Transformation-Phases are applied to an instance of an Input-Event. This involves:

  • Balancing checks at Input-Event level
  • Verification of authorization to manage Input-Events without producing Output-Events, if no Output-Events result from the transformation of the Input-Event
  • Placing Events in anomaly, or rejecting them, depending on what happens during processing

Checks at group level are applied to the Input-Events that belong to the same group. This is done as the Input-Events are processed. This involves:

  • Balancing checks at group level (at end of group)
  • Possible rejections, depending on what happens during processing.

What happens if an error occurs?

The Input-Event being processed is placed in anomaly for   the Transformation-Phase in which the processing error occurred (return code= 4).

If the Input-Event being processed is placed in anomaly for all the Phases, the Input-Event is rejected (return code= 6).

If you have set the Group Management option, the group to which the Event belongs is itself rejected. In this case, the systems sets a return code = 8, which takes priority over the return codes 4 or 6.

If a rejection threshold is reached, either for Input-Events or groups, this causes the system to stop the session with a return code = 10.

If the error is more serious, the system stops the session with an error code = 16.

Sort Output-Events

Characteristics

This function is enabled automatically if the Aggregate Output-Events option is enabled.

What happens if an error occurs?

The system halts the session with a system error (return code = 16).

Aggregate Output-Events (spyglass F)

Characteristics

This optional function is enabled through the Processing Context-In and sys.dat.

It is applied to the Output-Events after they have been sorted.

Process

The segments are processed in sets built from the output from the sort process. They may or may not contain Output-Events from the processing of a single group, depending on the parameters set.

An audit trace is extracted for each individual Output-Event that emerges from the sort, provided that this option has been enabled for the Processing-Context-Out associated with the Output-Event.

The individual Output-Events are subsequently aggregated in the manner specified in the aggregation rule.

An audit trace is extracted for each aggregated Output-Event that emerges from the aggregation process, provided that this option has been enabled for the Processing-Context-Out associated with the Output-Event.

Output-Event aggregation exit

This optional function is enabled through sys.dat during Output-Event aggregation, providing the Output-Event aggregation option is enabled. Refer to Manage exits and external calls for more detailed information.

The exit processes the segments in the order in which they are input into Rule Engine.

What happens if an error occurs?

If the option to aggregate Output-Events by group has been enabled in step P, the Input-Events are rejected (return code=6). Alternatively, the session is terminated if the maximum permitted number of anomalies has been reached (return code = 10).

In all other cases, the session is terminated with a system error (return code = 16).

Output-Event restructuring exit

Characteristics

This optional function is enabled via the Processing Context-In and sys.dat. For a detailed description, refer to Manage exits and external calls.

Process

The Output-Event restructuring exit processes Output-Events in the order in which they are generated.

This exit allows you to:

  • Create
  • Merge
  • Re-order
  • Delete
  • Change the contents of Output-Events

What happens if an error occurs?

The system halts the session with a system error (return code = 16).

Write the transformation products

Characteristics

This core function is enabled through script.ges.

Process

The results of a transformation session are made available in the exchange zones which you have defined in the >Script.ges< section of script.ges.

What happens if an error occurs?

The system halts the session with a system error (return code = 16).

Related Links