AccountingIntegrator Reference Guide

AccountingIntegratorVersion 2.2.11 July 2019

Reference Guide

Copyright © 2019 Axway

All rights reserved.

This documentation describes the following Axway software:

Axway AccountingIntegrator 2.2.1

No part of this publication may be reproduced, transmitted, stored in a retrieval system, or translated into any human or computer language, in any form or by any means, electronic, mechanical, magnetic, optical, chemical, manual, or otherwise, without the prior written permission of the copyright owner, Axway.

This document, provided for informational purposes only, may be subject to significant modification. The descriptions and information in this document may not necessarily accurately represent or reflect the current or planned functions of this product. Axway may change this publication, the product described herein, or both. These changes will be incorporated in new versions of this document. Axway does not warrant that this document is error free.

Axway recognizes the rights of the holders of all trademarks used in its publications.

The documentation may provide hyperlinks to third-party web sites or access to third-party content. Links and access to these sites are provided for your convenience only. Axway does not control, endorse or guarantee content found in such sites. Axway is not responsible for any content, associated links, resources or services associated with a third-party site.

Axway shall not be liable for any loss or damage of any sort associated with your use of third-party content.

Contents

Preface 9Who should read this document 9Related documentation 9

Accessibility 10Screen reader support 10Support for high contrast and accessible use of colors 10

What's new 11Documentation 11

1 Rule Engine model 12Rule Engine within the information system 12Communication between applications 13Specify the Processing-Context-Ins 13Specify the Processing-Context-Outs 13Specify the sessions 14

Physical organization 14Input data 15Procedures 16Output data 17

Communication between sites 18Process phases in Rule Engine 20Read in the Input-Events 22Input-Event restructuring exit 23Identify Input-Events 24Sort Input-Events 25Preprocess Input-Events (spyglass A) 25Input-event aggregation exit 26Enrich and check Input-Events (spyglass B) 27Process Input-Events (spyglass C) 28Process Output-Events (spyglass D) 30Input-Event / Group Level Checks (spyglass E) 31Sort Output-Events 32Aggregate Output-Events (spyglass F) 33Output-Event aggregation exit 33Output-Event restructuring exit 34Write the transformation products 34

AccountingIntegrator 2.2.1 Reference guide 3

2 Session general procedure 35Change the Rule Engine license key 35Deploy configuration containers 35Manage Rule Engine configurations with the Repository 36Import configuration into the Repository 36Repository commands 36

Transformation session 41

3 Implement the functions 43Steps in a transformation session and sys.dat file 43File Mode 46MQSeries mode and JMS mode 46

Mandatory parameter settings 46Environment variables 46General Options in script.ges 47Physical characteristics in script.ges 48

Define an exchange zone 50Rules 50Define a virtual exchange zone in script.ges 51Define a queue-type exchange zone for MQSeries in script.mqs or for JMS in script.jms 51Define a file-based exchange zone in script.file 52

Internal sorts 53Common parameters 53Sort properties 54Sort Input-Events 55Sort Output-Events 57

Group management 58Parameter Settings in script.ges 59

Aggregation 59Aggregate Input-Events 59Aggregate Output-Events 60

Balance checks: standard and with compensation option 62Reminder about setting parameters in AI Enabler 62

Accounting checks and reversals 63Reminder about setting parameters in AI Enabler 63

Links to Sentinel 63Environment variables 63Sentinel business monitoring 68

Links to InterPlay 69Links to Rule Engine Server 70Create a new log file for the Rule Engine Server 70Externalize variables stn_dep and stn_maj in RDJDEP 71


4 Manage transformation anomalies 72Reminder about how the Rule Engine works 72Transformation Errors: Return codes 73

Input-Event in anomaly during transformation 73Circumstances 73Consequences 74

Input-Event rejected 75Circumstances 75Consequences 75

Group of Input-Events rejected 76Circumstances 76Consequences 76

Session stopped 77Circumstances 77Consequences 77

Transformation errors: Return codes 78

5 Implement advanced functions 79Audit mono and multi sessions 79A reminder about setting parameters in AI Enabler 79Audit rejects and anomalies 87

Phase-specific recycling of Input-Events in anomaly 89Reminder about setting parameters in AI Enabler 89

Exits and external calls 89Exits 89External calls 96

Set up the transformation environment 96Session environments and domains 96Implement redirection 97

Optional environment variables setting 99

6 Set parameters for MQSeries and JMS implementations 102Set MQSeries-specific or JMS-specific parameters in script.mqs 102Structure of the messages transmitted 103Read and produce messages 104Messages in anomaly 105Unreadable messages 105Suspect messages 105

Structure of the messages generated 105Use an exit to reformat Input-Event messages and transformation products 108Parameter settings in script.mqs or script.jms 108

Manage groups with MQSeries or JMS 108Define a complete group 110Define an incomplete group 110


Reproduce a group 110Parameter settings in script.mqs or script.jms for a queue of Output-Events 111

Utilities for accessing the MQSeries or JMS exchange zones 111Empty queues: rdjcleanmqs, rdjcleanjms 112Stop the session: rdjstopmqs,rdjstopjms / RDJSTO 119Transferring data from a file to a queue: rdjputmqs,rdjputjms /RDJPUT 120Transferring data from a queue to a File: rdjgetmqs,rdjgetjms/RDJGET 123

RuleEngineJMS and IBM-MQSeries implementation 129Generate the JNDI file using JMSAdmin 129Update the RuleEngine JMS runtime environment 135Test in the RuleEngine JMS runtime environment 137

7 Standard reports 139General appearance 140Statistics 140TC1 counters 141TC2 counters 142TC3 counters 142TC4 counters 143TC5 counters 144

Transformation details 144Transformation detail – Header 145Contents of the processed segment 145Properties and contents of the Output-Event produced 146Contents of the modified segment 146

Transformation anomalies 146General information 147Input-Event identifiers 147Anomaly identifiers 148Description of the anomaly 150System identifiers 151Contents of the segment 151

Redirection of Input-Events 152Input-Event aggregation counters – File specific 153Aggregation counters by Input-Event 153Aggregation Counters by Segment 154

Output-Event aggregation counters – File specific 155Account Log 155Account Log - Header 156Account Log - Detail lines 156

Compensation Log 156Compensation Log - Header 157Compensation Log - Detail lines 157

Counter summary 158


Input-Event aggregation detailed report 158Output-Event aggregation detailed report 159Reformatting using exits 161

8 BIRT reports 162BIRT process 162Report names and activation conditions 163BIRT directories 163Define the report properties 164Report modification prerequisites 166Reorganize the data display 166Use styles 167Use images 167Define report labels 168

9 Implement the Rule Engine using permanent files 169Overview 169Script.ges: Syntax and commands 169Syntax 169Script commands 171Define variables in the >Script.ges< section 171Include a script file into the >Script.ges< section 172Display a comment 172

Optional table updates 173Create an update file 173Syntax of mvt.mvt file 173Execute procedure rdjmaj 182

10 Appendices 183UTF-16 implementation details 183AI Enabler characteristics 183Rule Engine 184

Terminology 184Required files for the Rule Engine 184Functional context generated by the sender parameter settings 186Logical organization 186Syntax 187Mandatory configuration settings 188Group management 194Aggregate Input-Events 195Aggregate Output-Events 195Balancing check 195Accounting checks and reversals 196Parameter settings for system tuning 197


Audit 199Phase-specific recycling of Output-Events in anomaly 201Exits 202Anomalies and rejections from transformation 203


Preface

This document describes the features of the AccountingIntegrator component Rule Engine and its implementation using the AI Enabler.

Who should read this documentThis document is intended for users of Rule Engine.

In this guide, we assume that you have a good understanding of the previous versions of Rule Engine.

Related documentationThe AccountingIntegrator documentation set includes the following documents:

l AccountingIntegrator User Guide

l AI Enabler User Guide

l AccountingIntegrator Installation Guide

l Rule Engine Reference Guide

l Rule Engine Operations Guide z/OS

l Rule Engine Exits and External Calls

l Rule Engine Error Messages Guide

l Rule Engine Installation Guide z/OS

l Rule Engine Installation Guide OS/400


Accessibility

Axway strives to create accessible products and documentation for users.

This documentation provides the following accessibility features:

l Screen reader support

l Support for high contrast and accessible use of colors

Screen reader support l Alternative text is provided for images whenever necessary.

l The PDF documents are tagged to provide a logical reading order.

Support for high contrast and accessible use of colors

l The documentation can be used in high-contrast mode.

l There is sufficient contrast between the text and the background color.

l The graphics have the right level of contrast and take into account the way color-blind people perceive colors.


What's new

The AccountingIntegrator Rule Engine includes the following new features:

l Turbo mode – Rule Engine can now work in turbo mode to increase the performances by 10% to 15%. The Turbo mode is only available on z/OS and can only be used if all numbers are valid integers.. Decimal numbers management is not supported.

l Rule Engine license check – The license checks the number of running instances. Since the Rule Engine license is based on an authorized number of instances, the check is done each time a Rule Engine session is launched. If the maximum of parallel instances is reached, the session is not launched.

l Rule Engine configuration managed by the AI Enabler – Most of the script.fic options are now managed by the AI Enabler. You can now configure the whole set of options through the Context-in definition using the AI Enabler. This configuration is automatically taken into consideration by the deployment procedure. If you still want to use the script.fic definition, you can provide your settings in it.

l Standardized log file – Rule Engine provides now standardized log messages inside a log file. These messages are provided by the configuration reset, configuration deployment and transformation session procedures.

l Automatic generation of output files names – If an output name is not defined in the script.fic file regarding a given Context-out definition, Rule Engine generates automatically the output file name, using the Context-out name to define it.

l Optimized output file generation – To avoid empty-file generation (when there is no output to generate in a given context-out), Rule Engine generates now the output files only when an output event is detected to be written.

Documentation l New AccountingIntegrator User Guide with information regarding the Rule Engine use with the new Rule Engine Server.

l New Rule Engine User Guide in HTML including all the information contained in the Rule Engine PDF guides.

l New AccountingIntegrator Installation Guide with installing information regarding the AccountingIntegrator product.


1 Rule Engine model

This section describes where the Rule Engine is located in the information system and how processes are set up.

Rule Engine within the information systemRule Engine provides the following implementation modes:

l File mode: input data and corresponding output data are stored in files in Latin (ASCII, EBCDIC) or UTF-16 format

l MQSeries mode: input data and corresponding output data are stored in messages in Latin (ASCII, EBCDIC)

l JMS mode: input data and corresponding output data are stored in messages in Latin (ASCII) on UNIX/WINDOWS platforms only

There are two implementation procedures for File mode andMSQSeries mode: Latin and UTF-16.

Rule Engine is configured via the AI Enabler. For more information on UTF-16 implementation actions and limitations, refer to chapter UTF-16 implementation details on page 183.

A study of the positioning of Rule Engine within the information system enables you to determine:

l The number of Rule Engine implementations you want

l The machine on which each Rule Engine is to run

l The type of implementation for each Rule EngineThis depends on the characteristics of the machine on which it is running and the nature of the data being passed between the applications in the information system

If you are implementing something other than a file processing system, refer to the chapter on the relevant type of implementation for the additional parameters.

For each machine hosting Rule Engine, you must define:

l The installation environment, that is, the directories or physical libraries into which you intend to install

l One or more run-time environments, that is, the directories or physical libraries into which you intend to install the run-time parameters

If you intend to create more than one run-time environment, you can share the configuration directories.

You must then specify, for each Rule Engine, whether there is to be access to external repositories.


1 Rule Engine model

If this is the case, describe the nature of the data and the external repositories to be accessed, and how the link is to be made between this data and Rule Engine:

l By table

l By external calls and using the functions of the associated language. For more information, refer to Rule Engine Exits and External Calls Guide.

l By means of exits. If so, define when they are to be called, so that the relevant exits can be activated. For more information, refer to Rule Engine Exits and External Calls Guide.These possible approaches are not mutually exclusive. You can combine them.

By working your way through the above list of actions, you can clearly define the properties of each of your Rule Engine implementations.

Communication between applicationsYou need to carry out the following steps for each Rule Engine implementation.

Note Note:From this chapter onwards, this manual explains what you need to do for a single implementation of Rule Engine. Obviously, you need to repeat the steps for each implementation.

Specify the Processing-Context-InsIdentify the applications that produce information for input to Rule Engine.

For each of these applications, list:

l How to identify each of the technical fields associated with the Input-Events sent(identification of the technical data in the flow)

l The processing options to be executed

l The external calls and exits that need to be developed

Where two or more applications produce events with identical physical characteristics (identity of technical fields, processing options, exits activated), you can associate them with a single Processing Context-In.

You need, therefore, one Processing-Context-In for each group of applications that generate distinct physical characteristics.

The result of the above exercise is the set of Processing-Context-Ins which you must reference in Rule Engine and whose characteristics you must define in AI Enabler.

Specify the Processing-Context-OutsIdentify the applications that receive the data output from Rule Engine.


1 Rule Engine model

These applications also have their requirements as regards the physical properties of the output from Rule Engine and the mandatory checks to be carried out on this data.

For each of these applications, list the following:

l The structure to be expected in the incoming data

l The type of checks to be carried out on the data

l The processing options to be executed

l The exits to be developed

l The exchange zones that are to receive the data

Each set of data sharing an identical set of the characteristics listed above corresponds to one logical Processing-Context-Outs, together with its processing options.

The result of the above exercise is the set of Processing-Context-Outs you must reference in Rule Engine and whose characteristics you must define in AI Enabler.

Specify the sessionsKnowledge of the way in which the applications are used and receive their inputs, together with the frequency with which they produce the relevant data, allows you to define the schedule for running Rule Engine, that is, daily, weekly, monthly, quarterly, annually and so on.

Finally, the sets of Processing Context-Ins, Processing Context-Outs, exits and external calls to be activated, together with the associated execution schedules, allow you to define the various Rule Engine sessions.

Physical organization This section summarizes briefly the physical organization of the product. For more information on this topic related specifically to the machine on which you are running Rule Engine, refer to the appropriate Installation Manual.

This illustration is specific to MVS:


1 Rule Engine model

Figure 1. Physical organization

The various elements are grouped by category:

l Input Data

l Procedures

l Output Data

Input dataDirectory Contents

System files(SYS for MVS)

System files:The system context, including all the Rule Engine options suppliedError messages: contains descriptions of all errors generated during processing

Executable files (EXE for MVS)

Executables for all required transformations


1 Rule Engine model

Directory Contents

Report templates(FMT for MVS)

Templates for all reports:Results of redirectionDetails of transformation anomaliesInput-Event aggregation countersDetails of Input-Event aggregationAggregation counters for accounting Output-Event Details of Output-Event aggregationTransformation countersTransformation counters summary Details of modified Input and Output-Events generated in a sessionAccount log

Configuration files (REF et DAT for MVS)

Configuration files:Some of these are updated by automatic procedures (for example, descriptors, functional context, rules and compiled tables)Others must be updated manually via the implementation script script.ges, where the value of ges is the implementations file, mqs for MQSeries, jms for JMSThe data to be processed by the procedures. You can configure the names.

Procedures

Continuous useThe JCLLIB or SCRIPT directory (or library) contains the run-time procedures:

Procedure Purpose

For continuous use

rdjexp Procedure for transforming Input-Events into Output-EventsSyntax : rdjexp [txt/pdf/html] [session] [audit] [business] [ews]

txt : file *.edi report format (by default)

rdjews Procedure for creating a file of Input-Events in anomaly, to be passed to Axway InterPlay

rdjstn Procedure for gathering tracking information to be sent to Sentinel


1 Rule Engine model

Procedure Purpose

For use during tuning

rdjmaj Procedure for automatic compilation of the Rule Engine environment parameter settings, to be run after export from AI Enabler

rdjrch Procedure for merging the default functional context parameter files (sys.dat and usr.dat) in the Rule Engine environment during partial exchanges from AI Enabler (securing exchanges) which requires merging exchange files with those already present

rdjtrf Procedure for extracting the configuration settings in the form of an input file

rdjedr Procedure for printing the contents of the compiled parameter files

rdjrgt Procedure for extracting the configuration settings in the form of an RGTR file

rdjmnt Procedure for updating the compilation of the configuration file

For use during installation

rdjraz Procedure for reinitializing the environment, used to create an empty site: Under DAT, only the supplied files are re-initialized

rdjsic Procedure for running and managing the SIC (Information and verification system) installation process

Output dataDirectory Contents

MVS Windows/UNIX

EDI edi Reports containing the results of the execution of the various procedures

TMP tmp Temporary work files used by the procedures

REF and DAT

envref/dat and dat

Parameter files updated by rdjmaj and rdjrch after export from AI Enabler:

l The descriptors (sys.dat)

l The compiled rules and tables


1 Rule Engine model

Directory Contents

BRS bres The products generated by rdjexp:

l The Output-Events

l Modified Events

l Redirected Events

l Input-Events in anomaly during transformation

l Rejected Events

l Input-Event traces

l Output-Event traces

Communication between sitesThis section discusses the general organization that you require in order to ensure proper communication between AI Enabler and the various Rule Engine sites.

Since the reference parameter settings are located in AI Enabler, you require a general procedure that reflects the way in which your enterprise works.

The following table explains the objective of this procedure.

Step Action

1 To export the coded objects from AI Enabler to the simulation site, to check the coding (*)

2 To correct any errors found in the coding and to return to step 1

3 To export the coded objects to the pre-production environment, in order to check them against any other objects already present in that environment (*)

4 To correct any errors found in the coding and to return to step 1

5 To export the validated objects to the full production environment. (*)

(*) The coded objects are exported:

l Either in connected mode via the Broadcast Agent in the AI Enabler interface

l Or in disconnected mode. The configuration containers created in the AI Enabler are then deployed via the rdjdep tool. For more information on this tool, refer to Change the Rule Engine license key on page 35

You can change the Rule Engine license key provided during installation in one of the following files depending on your operating system:


1 Rule Engine model

OS Core File name

MVS <RDJ_HOME> RESFSQ.RDJKEY.SYS

Others [Install_Path]\RuleEngine\core\res\ rdjkey.txt

These steps are required to ensure that the information stored by AI Enabler is accurate and to enable Rule Engine to permanently update the parameter settings used in the production environment.


1 Rule Engine model

Process phases in Rule EngineThe illustration below 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.


1 Rule Engine model

Figure 2. Figure 2: Processing phases

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


1 Rule Engine model

ProcessThe 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:

l Stamping identifiers for consistency with the audit option chosen

l 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

CharacteristicsThis 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:

l The group code, if you activated the group management option

l The name of the Input-Event type

l The version number of the Input-Event type

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

l The name of the Input-Event type

l The version number of the Input-Event type

l 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.


1 Rule Engine model

MQSeries mode and JMS modeThe 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 on page 104.

What happens if an error occurs?The system halts the session with a system error (return code = 16).

Input-Event restructuring exit

CharacteristicsThis optional function is activated through script.ges.

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

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

This exit enables you to:

l Create

l Merge

l Re-order

l Delete

l 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).


1 Rule Engine model

Identify Input-Events

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

For each technical field, identification by:

l 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

l 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 typeVersion of the Event typeName of the segment typeInstance code (if present)Group code (if present)

The Input-Event processing parameters

Balancing check codeReversal codeAnomaly phase code. The Input-Event is to be recycled back through the Transformation-Phase

ProcessThe 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.


1 Rule Engine model

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

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


Preprocess Input-Events (spyglass A)

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

ProcessThe 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 on page 25.

The processing comprises:

l Input-Event audit before aggregation

l Input-Event aggregation

l Input-Event audit after aggregation


1 Rule Engine model

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:

l Segments belonging to a single Input-Event, if the Input-Event being processed is multi-segment

l 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.


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.


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.


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


1 Rule Engine model

Enrich and check Input-Events (spyglass B)

CharacteristicsThis 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:

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

l The Input-Event type to be processed is valid for the DAR

The optional operations allow you to:

l Activate an exit to enrich or check Input-Event segments

l 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 the error is more serious, the system stops the session with an error code = 16.


1 Rule Engine model

Process Input-Events (spyglass C)

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

ProcessThe 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:

l If you configured more than one phase, the system executes them in the alphabetical order of the phase names

l Within a phase, the system applies rules in the order in which you configured them for the Input-Event typeThe 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:

l The Input-Event itself (all segments)

l Any anomalies that arise

l The Output-Events generated

l The traces extracted

l The segments modified

Illustration of the processing appliedInput-Event type: COMM_RECEP (commissions due).

This Input-Event type consists of two segment types:

l COMM_FCPS (Commissions on mutual funds)

l COMM_GENE (Commissions due, all types)

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


1 Rule Engine model

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:

l 12 COMM_GENE segments

l 6 COMM_FCPS segments

l 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


1 Rule Engine model

Phase Rule Applied Number of Applications

Segment Type Processed

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.



Process Output-Events (spyglass D)

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


1 Rule Engine model

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.

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

l Core processing: Identifying the associated Processing-Context-Out

l Optional processing:

o Checking or enrichment by exit

o Accounting processing

o Balancing checks by rule

o Extracting the trace or a traceability check

o 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.



Input-Event / Group Level Checks (spyglass E)

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


1 Rule Engine model

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

l Balancing checks at Input-Event level

l Verification of authorization to manage Input-Events without producing Output-Events, if no Output-Events result from the transformation of the Input-Event

l 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:

l Balancing checks at group level (at end of group)

l 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.



Sort Output-Events

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



1 Rule Engine model

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.

ProcessThe 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 exitThis optional function is enabled through sys.dat during Output-Event aggregation, providing the Output-Event aggregation option is enabled. Refer to Rule Engine Exits and External Calls Guide for more 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).


1 Rule Engine model

Output-Event restructuring exit

Characteristics This optional function is enabled via the Processing Context-In and sys.dat. For a detailed description, refer to Rule Engine Exits and External Calls Guide.

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

This exit allows you to:

l Create

l Merge

l Re-order

l Delete

l Change the contents of Output-Events


Write the transformation products

Characteristics This core function is enabled through script.ges.

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



2 Session general procedure

This chapter describes how to use the deployment tool and presents the execution steps of a transformation session.

Change the Rule Engine license keyYou can change the Rule Engine license key provided during installation in one of the following files depending on your operating system:

OS Core File name

MVS <RDJ_HOME> RESFSQ.RDJKEY.SYS

Others [Install_Path]\RuleEngine\core\res\ rdjkey.txt

Deploy configuration containersThis step is only executed if you have chosen to process the business objects in disconnected mode. You must have previously created a configuration container in the Composer.

Axway provides the rdjdep tool with the product.

To deploy the configuration container:

1. Copy the container resulting from AI Enabler and located in the <RDJHOME>/container

<RDJHOME> is the prefix of the installation environment and the directory that contains all the reference objects (error files, executables and so on).

2. Depending to your operating system, launch the deployment script from:

<RDJ_EXEC>/script/rdjdep.sh

or<RDJ_EXEC>/script/rdjdep.bat

Where <RDJEXEC> is the prefix of the run-time environment and contains the objects to be processed (options, objects to read and to produce).

The rdjdep script:

l Checks the container prerequisites

l Copies the Rule Engine repository files(ctx.mvt and mvt) of the container in the <RDJ_EXEC>/dat execution environment



l Updates the Rule Engine(rdjmaj and rdjrch)

l Sends the container configuration status to the Sentinel Tracked Objects ServerLog

Manage Rule Engine configurations with the Repository

At runtime, the Rule Engine Server configures and manages the different instances of Rule Engine using the configuration information stored in the Repository.

The configuration information is composed of:

l Configuration files from the AI Enabler: structures, formats for data and tables, rules to be applied, and so on. The configuration is deployed as a set of 1 ctx.mvt + 1 mvt.mvt files.

l Internal table values: extracted from the central referential of the company. Used to validate the rules inside the Rule Engine transformations. The tables are deployed as an mvt.mvt file.

Import configuration into the RepositoryThe AI Enabler configuration files are imported into the Repository incrementally because they change less frequently than the configuration of the internal tables.This way, only the modified objects need to be deployed from AI Enabler when the configuration changes.

The configuration of the internal tables is updated with each change.

When imported into the Repository, the AI Enabler configuration files are associated to:

l an application name

l an identifier (configuration identifier)

When imported into the Repository, the internal table files are associated to:

l an application name

l a configuration identifier

l an identifier (table identifier)

Repository commandsThere are Repository commands to:

l Import configurations into the Repository on page 37

l Export configurations from the Repository on page 38

l List configurations from the Repository on page 38

l Clean configurations from the Repository on page 39



Import configurations into the RepositoryTo import configurations into the Repository, use the following command:

importAIConfiguration [-id id] [-o option] [ImportDirectory], where:

id:

Identifier of the configuration to be imported or sequenced/updated. Mostly used to sequence a configuration that already exists in the Repository.

The id must match the folder name that stores the configuration files: ImportDirectory/aiConfiguration/<aiConfigurationIdentifier>. If the id and folder name do not match, the import stops and an error message is displayed.

if the id is not specified, all the configurations files under the ImportDirectory/aiConfiguration folder are imported.

option:

Possible values:

- config: it imports only the AI Enabler configuration. It imports a set ctx.mvt + mvt.mvt.

- table: it imports only the configuration of the internal tables values. It imports one or several mvt.mvt files.

If the option is not specified, it imports the configurations from the AI Enabler and the internal tables values.

ImportDirectory:

The AI Enabler configuration files must be stored in the ImportDirectory under the folder aiConfiguration/<aiConfigurationIdentifier>

The configuration files of the internal tables are stored in the ImportDirectory under the folder aiConfiguration/<aiConfigurationIdentifier>/tables

If the ImportDirectory is not specified, the default import directory is used under the structure shown above.

Sequenced AI Enabler configurationsThe import command also allows importing a sequenced AI Enablerconfiguration. The suffixes of the configuration files correspond to the id of the sequence.

Note The first configuration is considered base and the files names have no suffix

Some conditions must be met to import a sequenced configuration:

l That there is no configuration with same identifier in the repository. Otherwise an error is displayed.



l That configuration numbers are in the right order (base, then 1, 2, etc.)and apply for both mvt and ctx files.

Export configurations from the RepositoryTo export configurations from the Repository, use the following command:

exportAIConfiguration [-id id] [-o option] [ExportDirectory], where:

id

Identifier of the configuration to be exported. Only the specified configuration is exported.

If the id is not specified, all the configurations files from the Repository are exported.

option

Possible values:

- config: it exports only the AI Enabler configuration. If the configuration is sequenced, all the configuration updates are exported as pairs of ctx.mvt + mvt.mvt files.

- table: it exports only the configuration of the internal tables values. Since the configuration is not sequenced, only the last version is exported.

If no option is specified, the whole set of configuration —from both the AI Enabler and the internal tables values— is exported

List configurations from the RepositoryTo list configurations from the Repository, use the following command:

listAIConfiguration [-id id] [-o option], where:

id

Identifier of the configuration to be listed. Only the specified configuration is listed.

If the id is not specified, all the configurations files from the Repository are listed.

option

Possible values:

- config: it lists only the AI Enabler configuration. If the configuration is sequenced, all the configuration updates are listed.

- table: it lists only the configuration of the internal tables values.

If no option is specified, the whole set of configuration —from both the AI Enabler and the internal tables values— is listed.



Clean configurations from the RepositoryTo clean configurations from the Repository, use the following command:

cleanAIConfiguration [-id id] [-o option] [-from from], where:

id

Identifier of the configuration to be deleted. Only the specified configuration is deleted.

If the id is not specified, all the configurations files from the Repository are deleted.

option

Possible values:

- config: it deletes only the AI Enabler configuration.

- table: it deletes only the configuration of the internal tables values.

If no option is specified, the whole set of configuration —from both the AI Enabler and the internal tables values— is deleted.

from

Specifies the index from where to start cleaning the configuration sequence.

To be used only for the AI Enabler configuration.

If it is not specified, all the AI Enabler configuration updates are removed.

ExampleThe following example describes the use of the Repository commands.

The table below displays three AI Enabler configurations and their corresponding internal table values:

AI Enabler configuration Internal table value

aiconfig1 COA.mvt, CURRENCY.mvt, RATE.mvt

aiconfig2 COA.mvt

aiconfig3 COA.mvt, CURRENCY.mvt

The import folder must have the structure described in the picture below:



Figure 3. Import folder structure

If some updates are needed, the exported configuration folder wil have an specific structure. For example, if the configuration config1 has two updates, config2 has 1 update and config3 has no update; the exported configuration folder will have the structure described in the picture below:



Figure 4. Export folder structure

To clean only the last update of the first configuration, run the following command: cleanAIConfiguration –id aiconfig1 –o config –from 2

Transformation sessionTo run a transformation session, do the following:

Step Action

1 Extract the configuration settings for the Processing Context-Ins and Input-Event types that you want to work with

2 Update the extracted settings by running procedure rdjmaj

3 Update the tables whose entries are managed by Rule Engine by running the rdjmaj and rdjrch procedures



Step Action

4 Define the steps of a transformation session

5 Define additional parameters on the Rule Engine site (options and exchange zones) in the script file

6 Define the additional parameters for the type of implementation of Rule Engine (File, MQSeries, JMS)

7 Make the exchange zone containing the Input-Events available to Rule Engine

8 Start the session by running procedure rdjexp

9 Examine the results produced and the execution reports

10 Use the results in the applications of your Information System


3 Implement the functions

This section describes the configuration instructions for a standard implementation. For each function, keywords are defined as well as the corresponding values. This section is common to all implementations (File, MQSeries and JMS).

To know more about the default parameter setting, refer to:

l Rule Engine Installation Guide (zOS)

l Rule Engine Installation Guide OS400

In this section:

l Steps in a transformation session and sys.dat file on page 43

l Mandatory parameter settings on page 46

l Define an exchange zone on page 50

l Internal sorts on page 53

l Group management on page 58

l Aggregation on page 59

l Balance checks: standard and with compensation option on page 62

l Accounting checks and reversals on page 63

l Links to Rule Engine Server on page 70

l Links to Sentinel on page 63

l Links to InterPlay on page 69

l Implement advanced functions on page 79

l Set parameters for MQSeries and JMS implementations on page 102

Steps in a transformation session and sys.dat file

The table below shows which combinations are possible and which functions are enabled by each combination. The square brackets [ ] indicate an optional function.

Step Code

Processing

E Read +[Restructure (*)] +[Sort (*)] + [Aggregate Input-Events [by group] (*)]



Step Code

Processing

ET Read +[Restructure (*)] +[Sort (*)] + [Aggregate Input-Events [by group] (*)] + Transform + [Aggregate Output-Events all groups (*)]

ETS Read + [Restructure (*)] + [Sort (*)] + [Aggregate Input-Events by group (*)] + Transform + [Aggregate Output-Events by group (*)] + [Aggregate Output-Events (*)] + Routing

T Transform + [Aggregate Output-Events by group (*)]

TS Transform + [Aggregate Output-Events by group (*)] + [Aggregate Output-Events (*)] + Routing

S [Aggregate Output-Events (*)] + Routing

(*) Not available in MQSeries and JMS modes

Each execution within a session applies the processing specified by the Step keyword in sys.dat.

Successive executions must follow the logical sequence of the three steps.

Execution 1 Execution 2 Execution 3

Step = E Step = T Step = S

Step = E Step = TS

Step = ET Step = S

Step = ETS

The following diagram shows the processing flow through the steps in the session.



Figure 5. Figure 1: Processing flow

Note Within a step, you can use keywords that are suffixed with the step letter. For example, during the E (Input) step, you can use E_xxx keywords.



File Mode A session requires you to activate at least one of the three possible steps:

l INPUT (E)

l PROCESSING (T)

l OUTPUT (S)

You can activate each of these three steps independently in different executions of a session or combine them in the same execution. The possible combinations of these steps, and how to configure them in sys.dat, are explained in General Options in script.ges on page 47.

MQSeries mode and JMS modeRule Engine MQSeries or JMS require you to run all three steps (E, T, and S) together.

Mandatory parameter settingsTo implement a transformation, you must export a Processing Context-In to Rule Engine and set the relevant parameter settings in the implementation script file.

These settings relate to:

l Definitions of environment variables

l General options in script.ges

l The physical characteristics in script.ges

Environment variablesThese variables are used by the procedures at run-time.

You must define them to allow the procedures to reference valid values (refer to the appropriate Installation Manual).

Variable Use

RDJ_HOME Reference directory (or library) containing all the reference objects (For example, error files and executables)

RDJ_EXEC Run-time environment containing the objects to be processed (For example options, objects to read and to produce)



Variable Use

RDJ_LANG Reference language (French or English)If this variable is not set, English is used by default

QRDJ_PREF MQSeries or JMS queue prefix (Rule Engine MQSeries or JMS)This mandatory variable is automatically referenced by the installation kit

General Options in script.gesKeyword Description/Values

>Script< Sectioninsert “<THIS FILE>”,”Script.File”

Insert the name of the script section to be activated, the script being script.fic for a file, script.mqs for MQSeries, script.jms for JMS.Use this main section to define the physical characteristics of the script, notably the names of the Rule Engine inputs and outputs for the relevant operating mode (File, MQSeries or JMS)

>Configuration< Section

define DAT Specify the DAT directory (or library) in which the parameter files are located

Session Specify the name of the active transformation session

Date_Operation Specify this date in the format dd/mm/yyyyIf it is not defined, the system date is used

Repository Specify the name of the technical context for the transformation

Environment_Transformation

Specify the name of the transformation environment activated by the session

UNIX onlyThe codification parameter enables you to configure the sign for numerical signed and packed data (data types S and P).

Previously, the sign was always set in the COBOL kernel level NTR590 in EBCDIC format. However, now you can choose between an ASCII and EBCDIC format. You set the codification parameter in the section >ScriptConfiguration< section of the sys.dat file using the following values:

l Codification = ASCII

l Codification = EBCDIC (default value if this parameter is not present in the sys.dat file)



Physical characteristics in script.ges

Defining the processing Context-In

Keyword Description/Values

>Script.Ges< Section

Input_Event (Name_Sender)

The name of the exchange zone containing the Input-Events to be processed and the Processing Context-In identifier

IEvent _I (Name_Sender)

Processing Context-In identifier preceded by the name of either the:Output file in Step EInput file in the next step TS Mandatory for a session without Step TS (Configured as E)

IEvent _Redirected (I)

Name of the Processing-Context-Out (E) for the Input-Event, providing the Redirecting Input-Event option is activated

Defining the exchange zones associated with the processing-Context-Outs in script.ges


Script.Ges< Section

OSegt (Processing-Context-Out)

The name of the exchange zone associated with the Processing-Context-Out that is specified in bracketsOutput-Events Business MonitoringProcessing-Context-Outs dedicated to Sentinel must include the following parameter: BusinessMonitoring=yesExample:Me(STN)=DEFAUT,“<ME>BusinessMonitoring.seq;BusinessMonitoring=yes”

The name of the default exchange zone, used to receive the Output-Events for which no exchange zone has been defined




OSegt _P (required in a session with no step S: that is, configured as ET)

Name of the output file from a T step or the input file to a subsequent S step

Rules for defining exchange zones:

l Associate each Processing-Context-Out for Output-Events processed in a session with an exchange zone

l You may associate more than one Processing-Context-Out with the same exchange zone

l If an exchange zone is missing, when the Output-Events are written out as follows:

o The Output-Events concerned are written to the OSegt exchange zone, if one is defined

o If no OSegt exchange zone is defined, the Input-Event from which the Output-Event was generated is placed in anomaly or rejected

Defining exchange zones associated with the transformation products

Keyword Type of Data

IEvent_Anomaly Input-Events placed in anomaly during transformation

IEvent_Rejected Input-Events rejected during transformation

IEvent_Modified Contents of Input-Events modified during transformation

Trace_ IEvent Contents of traces generated by the Input-Events during the session

Trace_ OSegt Contents of traces generated by the Output-Events during the session

Detail_Transformation Information required for report on transformation details

Counter_Transformation Information required for report on transformation counters

Rule_Counter Information required for the transformation summary report

Detail_Redirection_IEvent Information required for report on Input-Event redirection

Detail_Anomaly_Rejection_IEvent

Information for report on transformation anomalies and rejections



Keyword Type of Data

Counter_Aggreg_IEvent Information required for report on Input-Event aggregation counters

Detail_ Aggregation_IEvent Information required for report on Input-Event aggregation details

Counter_ Aggregation_OSegt Information required for report on Output-Event aggregation counters

Aggreg_Account Information required for report on Output-Event aggregation details

Log_Account Information required for the accounting journal report

Log_Compensation Information required for the compensation journal report

Refer to Set parameters for MQSeries and JMS implementations on page 102 for details of the reports generated.

Define an exchange zoneIn general, an exchange zone is defined by its type and name. The name may have properties appended to it.

Exchange_Zone = Type_EZ, "Name_EZ;properties".

RulesType_EZ is required and may take the following values.

Value Use

VIRTUAL Virtual output

MQS MQSeries-type or JMS-type exchange zones

DEFAUT Default (file-type) exchange zone

The properties associated with an exchange zone depend on the exchange zone type. However, the total length of the name and the properties, (that is, the characters enclosed within the double quote marks), must not exceed 128 characters.



Define a virtual exchange zone in script.gesYou can use this type of exchange zone with any type of implementation of Rule Engine.

The data associated with this type of output is not physically written out. You can use this type of solution in the following situations:

l During tuning

l To save on writing time when some of the outputs, such as the modified Input-Events, are not used

This type of exchange zone definition must not be associated with temporary, working exchange zones or with Input-Events that are to be transformed (input exchange zone).

Definition of a virtual exchange zone on a UNIX or NT machine:

OSegt(Processing Context-Out) = VIRTUAL, "/dev/null"

Definition of a virtual exchange zone on an MVS machine:

OSegt(Processing Context-Out) = VIRTUAL, "DD DUMMY"

Define a queue-type exchange zone for MQSeries in script.mqs or for JMS in script.jmsA queue-type exchange zone is used in an MQSeries or a JMS implementation.

Queue= MQS , "Manager=Qmngr (MQSeries) or QCF (JMS);Queue=Queuename; Blocking=Yes;Buffer=nb; Reformatting=Yes"

Rules for defining a queue-type exchange zone:

l Rule Engine: The name of the remote manager (if there is one) for the queue containing the data to be read or written:

o Optional parameter

o Maximum length of the manager name: 48 Characters for UNIX/WIN, 4 characters for MVS (MQSeries only)

l Queue: Name of the queue containing the data to be read or written. It may be local or remote, if the 'Rule Engine' parameter is supplied or an alias:

o Required parameter

o Maximum length of the queue name: 48 characters

l Blocking: Request to block the product by message (optional parameter):

o Yes: Each message is filled with the maximum number of elements possible

o No:(the default value if the Blocking keyword is not present): A single element is written in each message. This parameter is not used for queues of Input-Events, or for queues



of rejected, anomalous or redirected Input-Events. For these, the messages must always be blocked. Rejected Input-Events are output with the same blocking used at input.

l Buffer: Size in KB of the message input (or output) buffer for this queue (optional parameter)

o If this parameter is missing, the buffer is set to the length of the longest message associated with the queue

o The value nb must be in the range 1 (minimum) to 4096 (maximum)

l Reformatting: Activates the reformatting exit (See Rule Engine Exits and External Calls Guide)

Place all properties of the queue between the double quote marks. They must be separated from each other by semi-colons (;).

Examples:

Queue of Input-Events to be transformed, for the Processing Context-In APPLI_MQ1, on which the reformatting exit is enabled:

IEvent(APPLI_MQ1) = MQS,"Queue=CRE.ISSU.APPLI_MQ1;Reformatting=Yes"

Output-Event queue, associated with output DEST_COMPTA_GENE, with blocking and a 12KB buffer:

OSegt(DEST_ACCNT_GENE)=MQS,"Queue=OSegt.Accnt.General;Blocking=Yes;Buffer=12"

Define a file-based exchange zone in script.fileA file-based exchange zone is used in a file-based implementation or to define temporary work files in other types of implementation.

File = DEFAULT , "Name_Of_File"

Rules for defining a file-based exchange zoneName_of_File:

l Name of the file (path and name in UNIX or DD name in MVS) that contains the data to be read or written.

l Required parameter.

l Maximum length of the file name: 128 characters.

Examples:

l File containing Input-Events to be transformed, for the Processing Context-In SENDER_TEST, on a UNIX machine:

IEvent (SENDER_TEST) = DEFAULT , "/xrdj/_rdjfic/dat/file_

ievent.seq"



l File containing modified Input-Events, on an MVS machine:

IEvent_Modified = DEFAULT , "DD:IEVMOD"

l File containing generated Output-Events, associated with the output ACCOUNTING, on a UNIX machine:

OSegt (ACCOUNTING) = DEFAULT , "/xrdj/_rdjfil/result/osegt_

accnt.seq"

Internal sortsProcedure rdjexp can sort:

l Input-Events This sort can be configured to match the physical properties of the Input-Events to be processed.

l Output-EventsThe procedure enables this sort automatically when Output-Event aggregation is configured.

In either case, you must supply certain parameters that are common to both types of sort (See Common parameters on page 53).

Parameters specific to one type of sort are explained in Sort Input-Events on page 55 and Sort Output-Events on page 57.

Common parametersYou must supply the parameters listed below if you implement one or both of the types of sort available (of Input-Events or Output-Events).

Parameter settings in script.ges and sys.dat


>ScriptConfiguration< Section

Memory_Sort

Amount of memory in KB to be reserved for the sort moduleThis amount of memory is allocated at the beginning of the sort and freed at the endBy default, 5000KB of memory is allocated




Length_Average_ISegt

Average length of an Input-Event segment (number of bytes) If this value is incorrect, the system adjusts it automatically during the sorting processHowever, it is recommended that you set a relevant size in order to optimize the sort configuration (See Recommendations for optimizing the sort in Sort properties on page 54)

Length_Average_OSegt

Average length of an Output-Event segment (number of bytes)If this value is incorrect, the system adjusts it automatically during the sorting processHowever, it is recommended that you set a relevant size in order to optimize the sort configuration


Sort_Tmp1 Name of the first temporary work file

Sort_Tmp2 Name of the second temporary work file

Optimize the sort

RulesThe sort module uses both the reserved memory and the work files to sort the data:

l Only use the second working file for large volume Input-Events. Use of this file in any other circumstances indicates the sort is incorrectly configured.

l To reconfigure the sort, change the settings for the amount of memory and the number of segments.

Sort propertiesThe list of keys for the sort is deduced automatically from the current parameter settings. If two keys in the list are equal (same position, length and data type) the key having the lowest priority in the list of keys is deleted.

The sort is stable. This means that two segments with equal key values are returned in the order in which they are read.

The sort arranges the sorted elements in ascending order of the key fields. If a key field in a segment is incorrect, a low value is set for that key. This means that segments with empty key fields are to be found at the front end of the sorted segments.



The segments are sorted first on the primary keys. A key is said to be primary if it is applicable equally to all the segments.

Recommendations for Optimizing the Sort (UNIX and WINDOWS only)The following formula gives you the minimum amount of memory needed consistent with minimal use of the temporary work files.

Memory_Sort in KB = SMAX * (AvLng + 0.234) / (200 * AvLng)

Where:

l SMAX = Volume in KB of the total data to be sorted

l AvLng= Average length in KB of the data segments to be sorted

Example:

If AvLng is 2 KB and SMAX is 512000 KB

Then Memory_Sort is at least 2590 KB.

Sort Input-EventsYou can sort the Input-Events immediately after they are read in or after a call to the restructuring exit.

Sorting is recommended to optimize the loading of the rules and access to the parameter settings.

Rules for sortsIn any of the following situations, a sort is mandatory:

l If all the segments of an Input-Event do not occur consecutively in an input file

l If the Group Management option is enabled but either the Input-Events of a group do not occur consecutively in an input file or they are dispersed across more than one file from a single Processing Context-In

l If the Input-Events are to be aggregated but the segments to be aggregated do not occur consecutively in the input file

This sort is only possible if: The session has an Input (E) step.






I_Sort_IEvent

Yes

Length_Average_ISegt

Average size of an Input-Event segment (in bytes)If this value is incorrect, it is adjusted dynamically during the sortHowever, it is in your interest to give a figure as close as possible to the correct value as this optimizes the configuration of the sort (See paragraph Optimize the sort on page 54)

Rules for defining the value of Length_Average_Segt:

Minimum Value Allowed

Maximum Value Allowed Default Value

20 bytes 4000 bytes 500 bytes

>Script.ges< Section

I_Tmp_IEvent_Sort

Temporary file containing the sorted Input-Events (for a Processing Context-In) before aggregation

The sort keys for Input-Events The table below lists, in decreasing order of priority, the keys you can specify for sorting Input-Event segments.

Order of Priority

Field

1 The group code, if the Group Management option is enabled

2 The name of the Input-Event type

3 The version number of the Input-Event type

4 The instance code

5 The name of the phase that is in anomaly, if the option for phase-specific recycling is enabled



Order of Priority

Field

6 The segment name

7 The DAR (Date of Application for Rules)

The following only apply if the aggregation of Input-Events is implemented:

Order of Priority

Field

8 The name of the aggregation rule applied to the segmentThis is set in the preprocessing parameters for the Input-Event type

9 The start date of validity of the version of the aggregation rule applied to the segmentThis is calculated from the value of the DAR

10 The values of the aggregation criteria. These are extracted from the segment in accordance with the version of the aggregation rule applied.

If one of these keys can be identified by context, it does not appear in the list of sort keys.

This list may be empty, if the aggregation of Input-Events is not enabled and if all the identifiers are defined by context.

Sort Output-EventsA sort of the Output-Events is enabled automatically when aggregation of the Output-Events is requested. It can be used to sort Output-Events to be aggregated either within a group or all groups together.

The following table lists the keywords that you need to configure.




Length_Average_OSegt

Average length of an Output-Event segment (in bytes) If this value is incorrect, it is adjusted dynamically during the sort However, it is in your interest to give a figure as close as possible to the correct value so as to optimize the sort configuration

Rules for defining the value of Length_Average_OSegt:



Minimum Value Allowed

Maximum Value Allowed Default Value

20 bytes 4000 bytes 500 bytes


P_Tmp_OSegt_Group

The name of the work file containing the Output-Events of a group to be aggregated

P_Tmp_OSegt_Sort_Group

The name of the work file containing the sorted Output-Events of a group to be aggregated

O_Tmp_OSegt_Sort_Session

Name of the work file containing the sorted Output-Events for aggregation by output

The sort keys The table below lists, in decreasing order of priority, the keys you can specify for sorting Output-Event segments.

Order of priority

Field

1 The name of the output associated with the Output-Event

2 The name of the aggregation rule applied to the Output-Event

3 The start date of validity of the version of the aggregation rule applied to the Output-EventThis is calculated from the value of the DAR

4 The values of the aggregation criteriaThese are extracted from the Output-Event in accordance with the version of the aggregation rule applied

As with Input-Events, if the output can be identified from the context, it does not appear in the list of sort keys.

Group managementThis section reminds you about setting parameters in Axway Composer:

Declare the group code technical field in the structures.



Parameter Settings in script.gesKeyword Description/Values


Turnoff_Group No

Note If mono-segment Input-Events are to be aggregated, the group code becomes an implicit criterion for the aggregation of the Input-Events.

Note If you implement a Rule Engine MQSeries or JMS session, you must supply certain parameters that relate specifically to the Group Management option.

Aggregation

Aggregate Input-EventsThis function can ONLY be implemented for file-based implementations of Rule Engine.

Reminder about setting parameters in AI EnablerInput-Events are aggregated by applying the preprocessing steps that are associated with a specific Input-Event type.To this end:

You must export the preprocessing and aggregation rules to Rule Engine.




I_Aggregation_IEvent Yes

I_Exit_Aggregation_IEvent Yes, if you want to use exits for processing during aggregation of the Input-Event segments (See Exits and External Calls Guide)Otherwise, No




Aggregation_Part_IEvent Yes, to get the output from a partial aggregation without truncating the number of segments aggregatedThis approach is recommended for large volumes or large numbers of aggregationsOtherwise, No

Print_Report_Aggregation_IEvent

Yes if you want counter details on the Input-Event aggregationOtherwise, No

Counter_Aggregation_IEvent The name of the file containing the data for the report on the aggregation counters

Report_Detail_Agreg_IEvent Yes if you want details on the Input-Event aggregationOtherwise, No

Detail_Agreg_IEvent The name of the file containing the data to be used in the Input-Event Aggregation Detail report

IEvent_I (required parameter if the session consists solely of an input (T) step)

Name of the output file from an input (E) step or the input file to a subsequent processing (T) step

Aggregate Output-EventsThis function can ONLY be implemented for file implementations of Rule Engine.

Reminder about setting parameters in AI EnablerOutput-Events are aggregated by applying the Mapping Rules and the options associated with the output.

To this end:

1. You must export to Rule Engine the Transformation-Rules associated with the Input-Event types, the outputs associated with the Output-Events and the definitions of the aggregation rules.

2. Moreover, to identify the aggregation rule by the contents of the Output-Event, you must declare the aggregation rule technical field among the Output-Event structures.






P_Aggregation_Osegt_Group

Yes, if you want to aggregate all Output-Event groups combined in the T step

P_Exit_Aggregation_OSegt_Group

Yes, if you want to use exits for processing during aggregation of the Output-Events in step T

O_Aggregation_OSegt Yes, if you want to aggregate the Output-Events in step S

O_Exit_Aggregation_OSegt

Yes, if you want to use exits for processing during the aggregation of the Output-Events in step S (See Exits and External Calls Guide)

Aggregation_Part_OSegt

Yes, to get the output from a partial aggregation without truncating the number of segments aggregatedThis approach is recommended for large volumes or large numbers of aggregationsOtherwise, No

Turnoff_Exit_OSegt l No: if the previous keyword is set to Yes

l Yes: if you are not using an exit to enrich the Output-Events

Print_Report_Aggregation_OSegt<0}

l Yes: to obtain Output-Event aggregation counters

l No: if you are not aggregating the Output-Events

Counter_Aggregation_OSegt

The file containing the data for the report on the aggregation of the Output-Events

Counter_Aggregation_IEvent

File containing Output-Event aggregation report data

Print_Report_Aggreg_Accounting

l Yes: to obtain accounting Output-Event aggregation details

l No: if you are not aggregating the Output-Events

Aggreg_Account File containing data for the accounting Output-Event aggregation details report

O_Exit_Aggregation_OSegt

Yes, if you want to use exits for processing during the aggregation of the Output-Events in step S (See Exits and External Calls Guide)




You must also supply the parameter settings specific to the sort that the procedure runs automatically

Balance checks: standard and with compensation option

Reminder about setting parameters in AI EnablerThe balancing check is applied to the set of Output-Events that are created by the transformation of an Input-Event. It is applied if the check is requested and if the Transformation-Rules that are applied to the Input-Event activate a balancing check, and only for outputs that are associated with this option. If the balance is not achieved, you can choose to create a compensation Output-Event to avoid rejection of the Input-Event.

Due to these constraints, you must:

1. Set the level of balance associated with the relevant Transformation-Rules.

2. Set up a technical field, the balance control code, associated with the Input-Event segment structures.

3. Activate in the Processing-Context-Outs the Balancing check option and the compensation option (if necessary).

Note: To activate the compensation option, you must activate an accounting check first. See Accounting checks and reversals on page 63.

4. Define the method for identifying the Balancing-Rule to apply.

5. Export into Rule Engine the Transformation-Rules, the outputs associated with the Output-Events and appropriate balancing rules.

Moreover, to identify the aggregation rule from the contents of the Output-Event, you must declare the balancing rule technical field among the Output-Event structures. For more details, refer to the section on technical fields in the AI Enabler documentation.There are no additional parameters for you to implement.

Note The compensation Output-Event appears in:

l Reporting documents such as the accounting log and the compensation log

l Session counters (compensation counter per Processing-Context-Out)

l Audit documents



Accounting checks and reversals

Reminder about setting parameters in AI EnablerAccounting and reversal checks are applied to the set of Output-Events associated with Processing-Context-Outs which have accounting processing enabled.

Due to these constraints, you must:

1. Set up a technical field, the balance control code, associated with the structure of Input-Event segments.

2. Activate the Accounting checks in the Processing-Context-Outs.

3. Export to Rule Engine the Transformation-Rules and the Processing-Context-Outs associated with the Output-Events which have the accounting processing option enabled.

In addition, to identify the accounting fields in the Output-Event, you must declare the accounting fields in the Output-Event structures.

There are no additional parameters for you to implement

Links to Sentinel

Environment variablesIf you want to feed the monitoring databases in Axway Sentinel, you must supply the environment variables that govern the transmission of data to Axway Sentinel.

Modify these variables in the rdjexp, rdjmaj, rdjraz and rdjstn run-time procedures.

rdjrazNote Parameters after modification by command line are prioritary. Default parameters are only

applied if there are no monitoring parameters in the command line.



Parameters after modification by command line

Default parameters

Use with return code (RC)

stn_raz[differ]

l stn_raz: starts RAZ monitoring

l differ: deferred monitoring. Saves information in an overflow file.

(Unix/Windows)

stn_raz=noNo RAZ monitoring stn_raz=yesInstant RAZ monitoringstn_raz=yes_differDeferred RAZ monitoring(UNIX/Windows) TKRAZ=NORAZNo RAZ monitoringTKRAZ=RAZInstant RAZ monitoring(MVS)

No RAZ monitoring: No information on the session is sent to Sentinel.

l Phase init: RC=04 - file RDJ_TPSFILE is created.

l Phase end: not executed.Instant RAZ monitoringThe Rule Engine sends the operation reports to Sentinel to allow RAZ monitoring.Phase init&end:

l RC=00 if information is successfully transmitted.

l RC=01: non-transmitted information is stored in the overflow file.

Deferred RAZ monitoringThe Rule Engine sends the operation reports to Sentinel with a delay to allow RAZ monitoring.Phase init&end:RC=00: information is stored in the overflow file.

rdjmajNote Parameters after modification by command line are prioritary. Default parameters are only





Default parameters


stn_maj[differ]

l stn_maj: starts MAJ monitoring


(Unix/Windows)

stn_maj=noNo MAJ monitoring stn_maj=yesInstant MAJ monitoringstn_maj=yes_differDeferred MAJ monitoring(UNIX/Windows) TKMAJ=NOMAJNo MAJ monitoringTKMAJ=MAJInstant MAJ monitoring(MVS)

No MAJ monitoring: No information on the session is sent to Sentinel.


l Phase end: not executed.Instant MAJ monitoringThe Rule Engine sends the operation reports to Sentinel to allow MAJ monitoring.Phase init&end:



Deferred MAJ monitoringThe Rule Engine sends the operation reports to Sentinel with a delay to allow MAJ monitoring.Phase init&end:RC=00: information is stored in the overflow file.

rdjexpNote Parameters after modification by command line are prioritary. Default parameters are only





Default parameters Use with return code (RC)

session[differ]

l session: starts session monitoring


(Unix/Windows)

stn_session=noNo session monitoring stn_session=yesInstant session monitoringstn_session=yes_differDeferred session monitoring(UNIX/Windows) TKSES=NOSESSIONNo session monitoringTKSES=SESSIONInstant session monitoring(MVS)

No session monitoring: No information on the session is sent to Sentinel.


l Phase end: not executed.Instant session monitoringThe Rule Engine sends the operation reports to Sentinel to allow session monitoring.Phase init&end:



Deferred session monitoringThe Rule Engine sends the operation reports to Sentinel with a delay to allow session monitoring.Phase init&end:RC=00: information is stored in the overflow file.




Default parameters Use with return code (RC)

business[differ]

l business: starts business monitoring

l


(Unix/Windows)

stn_business=noNo business monitoring stn_business=yesInstant business monitoringstn_business=yes_differDeferred business monitoring(UNIX/Windows)

No business monitoring: No information on the session is sent to Sentinel.


l Phase end: not executed.Instant business monitoringThe Rule Engine sends the operation reports to Sentinel to allow business monitoring.Phase init&end:



Deferred business monitoringThe Rule Engine sends the operation reports to Sentinel with a delay to allow business monitoring.Phase init&end:RC=00: information is stored in the overflow file.



rdjstn



[raz][maj] [session] [business] [differ|sendoverflow]

l raz: starts RAZ monitoring

l maj: starts MAJ monitoring

l session: starts session monitoring

l business: starts business monitoring


l sendoverflow: sends information from overflow file instantly.

(Unix/Windows)

differ mode: The Rule Engine sends the operation reports to Sentinel with a delay to allow monitoring.For each selected monitoring:

l Phase end: for all but business

l RC=00: information is stored in the overflow file.sendoverflow modeThe Rule Engine sends the operation reports to Sentinel to allow MAJ monitoring.For each selected monitoring:

l RC=00: information is successfully transmitted.


Note These variables are set by default to No.

Sentinel business monitoring

OverviewThe business monitoring feature enables an accountant or any business person to retrieve data that is not directly accessible (debit/credit of large amounts in the case of fraud, for example).

Restriction: business monitoring is only possible in file mode.

Parameter setting In the script.ges file, for each Processing-Context-Out dedicated to Sentinel and related to business monitoring, you must:

l Define the Processing-Context-Out (s) and associated filesYou can use the default file provided with the product to modify and add new definitions

l Include the Business monitoring parameter in each definitionExample:Me(STN)=DEFAUT,“<ME>BusinessMonitoring.seq;BusinessMonitoring=yes”



In the rdjstn.ini file Business Monitoring section, you must indicate the HostName and Port to use for Sentinel.

In the corresponding execution procedures, you must modify, if necessary, the default step provided for sending business monitoring data to Sentinel in the:

l Shell script (UNIX)

l CLP (AS/400)

l Fichier.bat (Windows)

Note The script. ges and rdjstn.ini files as well as the execution procedure are provided with default values by Axway in the SIC installation test deck.

Business monitoring exampleCaution If you change the name of the default recipient in the script.ges procedure provided by

Axway, make sure you also change it in the execution procedure.

UNIX: $EXE/rdjstn business $BRES/OSegt.stn $DAT/descee 2>>$TMP/rdjstn.msg

Windows: "%EXE%\%RDJSUIVI%" business "%BRES%\OSegt.stn" "%DAT%\descee" >"%TMP%\rdjstn.txt"Non: No business information has been sent to Sentinel.

Links to InterPlayOn UNIX or Windows, if you want to recycle the Input-Events that have been placed in anomaly at some point in the operation, set the ews variable to Yes in the rdjexp operating procedure. This allows a file, ap.CRA, to be recovered with the structure expected by Axway InterPlay.

On MVS, the step is already configured to retrieve the IEAEBC file in the format required by Axway InterPlay.

For the operation procedures rdjexp and rdjews, the CRA_CR option enables you to set the structure of the generated file by imposing carriage returns after each Input-Event in error listed in the file.

The commands for each procedure are:

l rdjexp [ews [cra_cr]]

l rdjews [cra_cr]

The following is an example of the syntax using the Windows command line:

%EXE%\rdjews %BRES%\ap.Detail_Anomaly_Rejected_Ievent %BRES%\ap.Anomaly_Ievent %BRES%\ap.Rejected_Ievent%BRES%\ap.CRA %CRA_CR% 2>>%TMP%\rdjews.txt

To enable Phase recycling of Input-Events, you must do the following:



1. Create a zone within the Input-Event structure named in error Code_Phase_Anomaly.

2. Declare the length and position of this zone in the Processing-Context-In.

Enable Phase Recycling by setting Recycling_Phase=Yes.

Links to Rule Engine ServerYou can link Rule Engine and the Rule Engine Server by:

l Creating a new Rule Engine log file for the Rule Engine Server

l Externalizing variables stn_dep and stn_maj in RDJDEP for the Rule Engine Server.

Create a new log file for the Rule Engine ServerAdding a new log file for the Rule Engine Server makes possible to include messages from the console and functional error messages from the rdjfic.msg file structure according to the new log file.

Note All programs called by the rdjexp (rdjreport, rdjstn, rdjsort ...), the rdjdeployement (with rdjmaj) ant the rdjfic.msg files are affected.

Messages from the consoleMessages from the console that can be added are:

l C modules made by printf control parameters

l Different scripts with echo lines

o Windows example: echo% mydate % % % ^ mytime | INFO ^ | ^ | REPORT Tool: 1 >> Return = "% % RDJ_ENGINE_LOG "

o UNIX example: echo "$ TIME_STAMP | INFO | | Runtine Cobol : cobolit " >> " $ RDJ_ENGINE_LOG "

Log file characteristicsThe log file must have the the following characteristics:

l Life cycle: runtime

l Archival procedure planned

l The install log file structure (line type with separator. "|") can be interpreted by the BIRT report.

Add a keyword according to the environmentFor a UNIX/WIN environment the following can be added:



The variable RDJ_ENGINE_LOG can be added to the file rdjenv. You can test the variable at the beginning of shells. If the variable is not defined, use the default value: NAME: <RDJ_EXEC>/script/RuleEngine.log

For an MVS environment, the file is created when the runtime environment is created. The following can be added:

l DDNAME : DD:LOGRDJ

l DSN : <RDJEXEC>.LOGFSQ.RDJ

Externalize variables stn_dep and stn_maj in RDJDEPThe Rule Engine Server needs to parametrize the call of rdjdep. Default values are used when the variables are not provided.

The variables, that can be passed as command line arguments are:

Stn: If yes, stn_dep and stn_maj monitoring is set to yes. Default is no.

Caution stn_dep can be used in container mode onlu. stn_maj can be used on both modes.

Usagerdjdep

Command Description

[default] [stn_maj] execute rdjrch and rdjmaj only with no container

-help display the help

-list -containers display the container list already installed

-clean [stn_dep] clean all the containers installed

-import deploy the configuration

[ -path path_to_

container]

path of the container

-id container_

identifier

id of the container

[%1] [%2] %1 and %2 must be stn_maj (sentinel) or stn_dep (container)


4 Manage transformation anomalies

AccountingIntegrator manages transformations through its components:

l Rule Engine

l Rule Engine Server

l Event Processor

See "Communication in runtime environment" in the AccountingIntegrator User Guide for details.

During and after transformation, different anomalies can occur. This section describes the different levels of integrity that can be set for processing. These levels of integrity enable you to have consistent results whenever incidents of various types occur during processing.

l Reminder about how the Rule Engine works on page 72

l Transformation session on page 41

l Input-Event in anomaly during transformation on page 73

l Input-Event rejected on page 75

l Group of Input-Events rejected on page 76

l Session stopped on page 77

l Transformation errors: Return codes on page 78

Reminder about how the Rule Engine worksThis consistency of processing and result is maintained through the use of a 'hierarchical' approach to errors in the processing, as follows:

l Processing Error

l No anomalies or rejections during transformation

l The Input-Event is placed in anomaly during transformation

l The Input-Event is rejected

l The group of Input-Events is rejected

l The session is stopped



Transformation Errors: Return codesTransformation errors cause a return code to be set when the execution is completed. The return code reflects the most serious error found during transformation.

The table below lists the return codes in ascending order of seriousness / gravity.

Type of Transformation Error Return Code Set

No transformation errors 0 (zero)

Input-Event placed in anomaly during transformation 4

Input-Event rejected 6

Input-Event group rejected 8

Session stopped: Anomaly threshold reached 10

Session stopped: Fault in parameters 12

Session stopped: Incorrect key 14

Session stopped: System error 16

Input-Event in anomaly during transformationThe Input-Event is placed in anomaly when a processing error occurs in one of the component segments during a Transformation-Phase in step T.

The Input-Event in anomaly is associated with the Transformation-Phase during which the anomaly occurred.

CircumstancesThe processing error arose during the Transformation-Phase for one of the following reasons:

Reason Meaning

1 An anomaly was found during the execution of the enrichment and check exit called before the execution of one of the phase rules phase

2 An anomaly is found in the application of a phase rules to a segment of the current Input-Event



Reason Meaning

3 An anomaly is found in the application of a rule to one of the Output-Events generated from the current Input-Event

4 An anomaly is found during the check carried out on one of the Output-Events generated from the current Input-EventThis check can be carried out either by the core code or by an exit

5 The rule does not generate any Output-Events and the option to Check for production of at least one Output-Event per Transformation-Rule is not enabled

Note Note:If all the Transformation-Phases applied to the Input-Event type result in anomalies, the Input-Event is rejected. (See Input-Event rejected on page 75).

ConsequencesReason Meaning

1 All the products of the Transformation-Phase are canceled for all the component segments in the Input-Event

2 The products from the other Transformation-Phases are kept and generated as output, provided that these phases complete properly

3 An anomaly is listed in the report, with a description of its salient features

4 The Input-Event is copied out to the Anomaly_IEvent exchange zone, so that it can be recycled

5 The name of the phase in which the anomaly occurred is written in the Input-Event according to the position and length defined in the Processing-Context-Out if you have declared the technical field Code_Phase_Anomaly

6 The Input-Event is not redirected

7 The Input-Event in anomaly is written to the Anomaly_IEvent file in the results directory

If the most serious error found in the session is an anomaly in an Input-Event, a return code of 4 is set for the execution.

If a rejection threshold is reached, either for Events or groups, this causes the system to stop the session with a return code=10. For more information, refer to Session stopped on page 77.



Input-Event rejectedThe Input-Event is rejected when either:

l An error occurs during processing in Step E or S

l All the Transformation–Phases using the Input-Event concerned are in error in Step T

CircumstancesThe processing error that causes the Input-Event to be rejected may arise for one of the following reasons:

Reason Meaning

1 It cannot be identified

2 No processing is required in the parameter settings for this type of Input-Event

3 There is an anomaly in the restructuring exit for this Input-Event

4 There is an anomaly in the pre-transformation checking and enrichment exit for this Input-Event

5 There is an anomaly in the preprocessing applied

6 All the processing applied to this Input-Event in the Transformation-Phases in step T are placed in anomaly

7 The Input-Event-level balance check fails

8 No Output-Events are generated and the option to Check for the production of at least one Output-Event per Input-Event is not enabled


1 Nothing is generated from the transformation of the Input-Event

2 All the transformation anomalies are printed

3 A copy of the Input-Event is output to the Rejected_IEvent exchange zone, so that it can be recycled



Reason Meaning

4 If the Group Management option is active, the group to which the Input-Event belongs is also rejected

5 If the aggregation option is active, it is the individual Input-Events that are rejected

6 If the most serious error found in the session is a rejected Input-Event, a return code of 6 is set for the execution

7 If a rejection threshold is reached, either for Events or groups, this causes the system to stop the session with a return code=10. (See the tables in Reminder about how the Rule Engine works on page 72 paragraph)

Group of Input-Events rejected This error ONLY occurs if the Group Management option is active (See also Group management on page 194).

CircumstancesThe processing error that causes the group of Input-Event to be rejected may arise for one of the following reasons:

Reason Meaning

1 An Input-Event belonging to the group is rejected

2 The group-level balance check fails


1 Nothing is generated from the transformation of the group

2 All the transformation anomalies are printed

3 The Input-Event group is copied out to the Rejected_IEvent exchange zone, so that it can be recycled



Reason Meaning

4 If the Input-Event Aggregation option is active, it is the individual Input-Events that are rejected

5 If the most serious error found in the session is a rejected group of Input-Events, a return code of 8 is set for the execution

Session stoppedIf the system stops the session, processing is halted, even if there are more Input-Events to process.

CircumstancesThe processing error that causes the session to be stopped may arise for one of the following reasons:

Reason Meaning

1 A system error occurs

2 The checks on the parameter settings fail on startup

3 An anomaly occurs either:

n While the Input-Events are being read in

n During the sort of the Input-Events

n During the sort of the Output-Events

n During aggregation of the Output-Events

n In the restructuring exit for the Output-Events

n While the transformation results are being written

4 The permitted thresholds for anomalies are reached (See the table in Input-Event in anomaly during transformation on page 73)

ConsequencesOnly the validated products are generated.

All the transformation anomalies encountered up to this point are set out in a report.

The return code is either of the following:



l 10 (error threshold breached)

l 12 (configuration error)

l 16 (system error)

Transformation errors: Return codesThe previous sections explain the errors that can arise during an execution of Rule Engine. These errors cause a return code to be set when the execution is completed. The return code reflects the most serious error found during transformation.

The table below lists the return codes in ascending order of seriousness / gravity.

Type of Transformation Error Return Code Set


Input-Event placed in anomaly during transformation 4

Input-Event rejected 6

Input-Event group rejected 8

Session stopped: Anomaly threshold reached 10

Session stopped: Fault in parameters 12

Session stopped: Incorrect key 14

Session stopped: System error 16


5 Implement advanced functions

This section explains how to set the parameters to implement advanced functions. For each function, keywords are defined as well as the corresponding values. These instructions are common to all implementations (File, MQSeries and JMS).

The topics described in this section are:

l Audit mono and multi sessions on page 79

l Phase-specific recycling of Input-Events in anomaly on page 89

l Exits and external calls on page 89

l Set up the transformation environment on page 96

l Optional environment variables setting on page 99

Audit mono and multi sessionsThe standard audit trail can link Input-Event/Output-Event records but only in a single session. With the multi sessions option the link is kept between records from successive sessions when Output-Events from session N are used as Input-Events for session N+1.

The multi sessions option is specified in the AI Enabler where a timestamp identifier is defined in the Input-Event and Output-Event structures. This identifier is referenced in the Processing-Context-In and the Processing-Context-Out.

A reminder about setting parameters in AI EnablerHow the Input-Events are audited depends on the:

l Pre-processing and processing that is defined for that type of Input-Event

l Options that are associated with the Processing-Context-Outs.

For this reason, along with the Input-Event types and their parameter settings, you must also export to Rule Engine the Audit-Rules for the Output-Events and the Processing-Context-Outs.

Auditing enables you to take a snapshot of an Input-Event or Output-Event segment at a given point and assign a stamping identifier (calculated by Rule Engine) which ensures that each segment is uniquely identified. You must define a field in the segment to store this identifier depending on the type and length of identifier you select. Rule Engine calculates the stamping identifier in two ways depending on whether you select Timestamp or Series stamping.



This also applies to multi-sessions audit where you can retrieve, via the audit trail of the Input-Event of the following session, the origin identifier that corresponds to the identifier of the Output-Event of the previous session.

If TimeStamp is set as the type of stamping, the stamping identifier must be alphanumeric, with a length of 25. The identifier must have the following format:

Stamping

code:5

Operation

date: 8

Stamping

time:6

Identifying

character: 1

Stamping

counter: 5

l Configure the stamping code in the Script file

l The operation date is in the form YYYYMMDD

l The stamping time is in the form HHMMSS

l The stamping counter is a base 36 number calculated by Rule Engine

If Series is set as the type of stamping, the identifier is made up of a character, which shows the type of segment being stamped, and a stamping counter. The maximum length of the identifier is 19 characters (1 alphabetic for the segment type identifier + 18 for the numeric counter). In this case, if the stamping counter reaches its upper limit, the system stops the session and a return code of 10 is set.

Parameter settings in script.ges



Stamper The value of the stamper codeThe use of this code allows you to set separate limit values for each type of object that is stampedYou must also set the limit values for the stamping counters in tsc.des


Trace_OSegt

The name of the exchange zone to which the Output-Event traces are written

Trace_IEvent

The name of the exchange zone to which the Input-Event traces are written

Trace The name of the exchange zone to which both the Input and Output-Event traces are written, if you want to store them both in the same exchange zone

Rules to follow:



Rule Meaning

1 If you supply the stamping code, Rule Engine looks up the limits set for the counters in the stamping counter descriptors

2 If you do not supply the stamping code, the segments are stamped sequentially, starting from 000..0001 up to 999..9999The actual number is as long as the space defined for the identifier, as described above

3 If the type of stamping is set to TimeStamp, the timestamp identifier counter used to be limited to 5 characters, which restricted the trace to 99999 for each type of trace.To increase this limit, the counter is now in base 36 instead of decimal.

Tsc.des: The stamping counter descriptorThe stamping code allows upper and lower limits to be set for stamping, where more than one session is to feed the same audit database

For a given stamping code, you must set the limits for each type of segment that is to be stamped. The order for the codes is:

Stamping Code Type of Information Audited

D Audit of an individual Input-Event segment

A Audit of an aggregated Input-Event segment

M Audit of an individual modified Input-Event segment

N Audit of an aggregated modified Input-Event segment

P Audit of an individual Output-Event

T Audit of Output-Events aggregated by group

R Audit of aggregated Output-Events (all groups together)

O Audit of an individual Input-Event segment in anomaly

J Audit of an individual rejected Input-Event segment

For each of the codes, supply the limits for the counter. The syntax for the line in which you supply these is Lower limit for the stamping counter, Upper limit for the stamping counter, date of last stamping, final value of the counter at the last stamping.

Rules to follow for each segment type to be stamped:



Rule Meaning

1 The values that you define for the counters must have the same length as that defined for the stamping counters in the functional context (for the Input-Events and for the outputs)

2 The upper limit must be greater than the lower limit

3 The date of last stamping and the final value of the counter are updated at the end of each session

Example of a stamping descriptor for the stamping code STAMP1:

STAMP1;

000000000000000000,000000000000100000,22/03/1999,000000000000000016;000000000000000000,000000000000100000,22/03/1999,000000000000000006;000000000000000000,000000000000100000,22/03/1999,000000000000000000;000000000000000000,000000000000100000,22/03/1999,000000000000000008;000000000000000000,000000000000100000,22/03/1999,000000000000000008;000000000000000000,000000000000100000,22/03/1999,000000000000000005;000000000000000000,000000000000100000,22/03/1999,000000000000000003;000000000000000000,000000000000100000,22/03/1999,000000000000000000;000000000000000000,000000000000100000,22/03/1999,000000000000000000;

When an Audit-Rule is applied to a segment, the system stamps the segment (that is, assigns a stamping identifier) and also generates an audit trace to store the snapshot of the segment.

Each segment of the audit trace that is built up has the following structure.

l A fixed-length header of 360 characters

l The audit trace (either from Input or Output-Event segments) of up to 4000 characters

This structure is retained when the trace is written out in the various implementations:

l Header + trace (maximum 4360 characters) written to a file record

l Header + trace (maximum 4360 characters) in an MQSeries or JMS message

The segments are only stamped when an auditing rule is to be applied to them.



For a stamping type of TimeStamp, the header in the audit trail for an Input-Event segment has the following format:

Id. Stamp Trace 25

Id. Stamp Orig 25

Id. Stamp Aggreg 25

Stamper

5

(*) 20

Session

25

Date

8

Time

6

Id. Event

9

Source

25

Code Group

34

Code Event

25

Event Version

3

Code Instance

34

Code Segt

25

Phase code

25

Rule Audit

25

Start Date

8

End Date

8

Event Trace

4000 max.

(*) The filler composition depends on the type of rule applied:

l For Stamping code values M or N, Enrichment rule: Rule name (5) + Start date (8) + empty (7)

l For Stamping code value A, Aggregation rule: The 20 first characters of the aggregation rule's name

Note This type of composition does not apply to Input-Events with audit ID "O” or “J”, since they do not include filler information.

For a stamping type of TimeStamp,the header in the audit trail for an Output-Event has the following format:

Id. Stamp Trace 25

Id. Stamp Orig 25

Id. Stamp Aggreg

25

Stamper

5

(*) 20

Session

25

Date

8

Time

6

Id. OSegt

9

Source

25

Filler

121

Phase Code 25

Rule Audit

25

Start Date

8

End Date

8

Osegt Trace

4000 max.

(*) The filler composition depends on the type of rule applied:

l For Stamping code value P, Transformation rule: Rule name (5) + Start date (8) + Financial Case number (2) + Output name number in the Financial Case (2) + empty (3)

l For Stamping code value T or R, Aggregation rule: The 20 first characters of the aggregation rule's name

For a stamping type of Series, the header in the audit trail for an Input-Event segment has the following format:

Id. Stamp Trace19

6

Id. Stamp Orig

19

6

Id. Stamp Aggreg

196

Stamper

25

Session

25

Date

8

Time

6

Id. Event

9

Sender

25

Code Group

34

Code Event

25

Event Version

3

Code Instance

34

Code Segt

25

Phase Code

25

Rule Audit

25

Start Date

8

End Date

8

Event Trace

4000 max.

For a stamping type of Series, the header in the audit trail for an Output-Event has the following format:

Id. Stamp Trace 19

6

Id. Stamp Orig 19 6

Id. Stamp Aggreg 19 6

Stamper

25

Session

25

Date

8

Time

6

Oevent index

9

Sender

25

Filler

121

Phase Code

25

Rule Audit

25

Start Date 8

End Date 8

Osegt Trace

4000 max.

In the above example, we assume that the stamping counter has been defined as 18 numeric characters, which is the maximum permitted length. The 6-character filler that follows each identifier is inserted to obtain the same header length for both types of stamping (Series and TimeStamp).



So, if the stamping counter is defined as 10 numeric characters, the filler after each identifier would have to be 14 in length (11 + 14 = 25).

Placing the auditing rule before the extracted trace allows the system to use the definitions in the rule to 'slice’ the data to identify the fields.

Apart from the segment snapshot, each trace contains the following:

l Stamping identifier

l Identifier of the original segment

l Identifier of aggregated segment

All this information enables you to link all the traces in order to reconstitute the audit trail and analyze the series of processing applied by Rule Engine to these segments.

Description of the Audit Trace

Field Meaning

Stamping identifier

The stamping identifier associated with the trace

Original stamping identifier

The identifier associated with the previous trace, (that is, before aggregation or modification, in the case of Input-Events, or before transformation or aggregation for Output-Events)This field is empty if the stamping code is D

Aggregation stamping identifier

The identifier associated with the trace after aggregation This field is empty if the segment (or the Output-Event) is not aggregated in the session

Activated stamping code

The code set in script.ges (see above)

Activated session code

The code set in script.ges. See Mandatory parameter settings on page 46

Operation date The operation date in YYYYMMDD format

Operation time The operation time in HHMMSS format

Segment (or Output-Event) index number

A sequence number for either the segment processed in the session or the Output-Event generated from an original Input-Event

The activated Processing Context-In code

The code set in script.ges

The following information needs to be supplied only for a trace on an Input-Event segment.



For traces on an Output-Event, a 146-character filler is inserted to ensure that all headers are of the same length:

l The Input-Event group codeSupply this only if the Group Management option is enabled and if the Input-Event that is processed belongs to a group

l The name of the Input-Event type processed

l The version number of the Input-Event processed

l The Input-Event instance code

l The segment code

l A 25-character filler

The following items of information are common to all traces that are extracted:

l The name of the audit ruleThe name used to extract the trace

l The start validity date of the audit rule

l The end validity date of the audit rule

The trace that is extracted consists of up to 4000 characters, which is the maximum length of an Input-Event segment or an Output-Event.

Each stamping identifier contains a stamping character. This is in position 1 for Series and position 20 for TimeStamp.

For a description of each character, see the table in: Tsc.des: The stamping counter descriptor on page 81.

Tracking through the audit trailExample:

In the example below, we are looking for the data that gave rise to the Output-Event bearing the stamping identifier R0087.



The identifier R0087, which is the trace resulting from the aggregation of certain Output-Events, carries the original identifier P0425. In the third column in the diagram, headed 'Aggregation Identifier', we look for all the traces that were the sources for this aggregation.

We find Output-Event traces identified by the following identifiers:

l P0425, P0424 resulting from segment traces with the identifier A0072

l P0422, P0420, P0419, resulting from segment traces with the identifier D0355

The segment trace with the identifier A0072 is itself the result of the aggregation of segment traces with the identifiers: D0549, D0548, D0547 and D0546.

The original data that gave rise to Output-Event R0087 is therefore found in the segment traces with the identifiers D0355, D0546, D0547, D0548 and D0549.



Audit rejects and anomaliesBy default, rejects and anomalies of Input-Events are not tracked.

To track rejects and anomalies, configure process_context_in in the AI Enabler and select Audit of rejects and anomalies.

ExampleIn the case below, two Input Event segments are aggregated in one record. The record is rejected during transformation rule and it produces two new records. Each record has a stampid prefixed with the letter J for rejects.

In the case below, two Input Event segments are aggregated in one record. The record is rejected as an anomaly only in the phase 2 of the transformation rule. It produces two new records. Each record has a stampid prefixed with letter O for anomalies.



RelationshipsTo manage the relationship between InterPlay and Rule Engine for rejects and anomalies, you must configure the multi-session audit.

To configure the multi-session audit, specify the position and length of the original stampId in the process_context_in file in the AI Enabler.



The RuleEngine, will set automatically the value of the Original Stampid in the ap.Cra file used by Interplay

Phase-specific recycling of Input-Events in anomaly

This function allows you to:

l Make Input-Events available for recycling in a way that is specific to the Transformation-Phase in which the anomaly occurred. The name of the phase is written into the Input-Event segments

l Handle Input-Events that are recycled after update. The system only applies the processing steps that associated with the phase in which the anomaly occurred. The name of the phase is either read from the Input-Event segments or defined in the functional context

Reminder about setting parameters in AI EnablerPhase-specific recycling of Input-Events requires you to perform the following operations in the given order:

1. Declare the Anomaly phase code technical field in the segment structures.

2. Activate Phase Recycling in the Processing-Context-Out.

3. Declare the position and length of the Phase in anomaly code technical field.

Exits and external calls

ExitsThe table below shows the exits you can use and what they do:

Possible Actions

1 Reformat the Input-Events on receipt of the messageThis is specific to MQSeries or JMS

2 Restructure the Input-Events

3 Enrich the Input-Events during aggregation



Possible Actions

4 Check and enrich the Input-Events before the Transformation-Phases are applied

5 Check and enrich the Input-Event segments for a specific Transformation-Rule

6 Identify and check the Output-Events

7 Enrich the Output-Events during aggregation by group

8 Enrich the Output-Events during aggregation (all groups together)

9 Restructure the Output-Events

10 Reformat the transformation products before a message is issued. This is specific to MQSeries or JMS

AI Enabler launches the exits related to step T (4 to 6), whereas the other exits are activated in the Script file in the Axway Rule Engine environment.

The table below shows the values that you can use for all the exits listed above, with the exception of the MQSeries-specific and the JMS-specific reformatting exits:

Value Use

Yes_C Activates the C language version of the exit

Yes_Cobol Activates the Cobol language version of the exit

Yes_Rdj53 Exit compatible with version 1.5.3

No The exit is not activated

The following sections describe the keywords to which you assign the above values.

For a full description of the use of these exits, refer to Exits and External Calls Guide, which gives details of the entry points and the data that is exchanged between the main program and these modules.

Reformat the Input-Events on receipt of the message (MQSeries mode only)This exit, written in C, reformats the data contained in Event messages as they are received, before they are processed in any way by a transformation session.

This exit is activated directly by the definition of an Input-Event exchange zone in script.mqs.

Queue= MQS , "Manager=Qmngr;Queue=queuename; Reformatting=Yes,Blocking=Yes;Buffer=nb"



Rules to follow:

1 Reformatting:Optional parameterIf this parameter is not supplied, the exit is not activated

l Yes: The reformatting exit is activated

l No: The reformatting exit is not activated

Reformat the Input-Events on receipt of the message (JMS mode only)This exit, written in C, reformats the data contained in Event messages as they are received, before they are processed in any way by a transformation session.

This exit is activated directly by the definition of an Input-Event exchange zone in script.jms.

Queue= MQS , "Manager=QCF;Queue=queuename; Reformatting=Yes,Blocking=Yes;Buffer=nb"

Rules to follow:

1 Reformatting:Optional parameterIf this parameter is not supplied, the exit is not activated



Restructure Input-Events (File mode only)This exit restructures the Input-Events immediately after they have been read in. It allows you to:

l Create

l Merge

l Re-order

l Delete

l Change the contents of Input-Event segments

This exit can be activated while the Input step (E) is active.

Parameter settings in script.fic and sys.dat




>sys.dat>ScriptConfiguration< Section

I_Exit_Restructuring_IEvent

Yes_C or No


I_Tmp_IEvent_Restructuring

Temporary exchange zone into which the restructured Input-Events are written

Enrich Input-Events during aggregation (File mode only)This exit modifies or enriches the data in the Input-Event segments before and after they are aggregated. It is only activated if the Input-Events are to be aggregated.

This exit can be activated while the Input step (E) is active.

Parameter settings in sys.dat


>ScriptConfiguration< Section Yes_C or Yes_Cobol or Yes_rdj53 or No

E_Exit_Agregation_Cre Yes_rdj53 is compatible with ITR025

Check and enrich Input-Events before transformationThis exit checks or enriches the data in the Input-Event segments before they are processed in the Transformation-Phases.

This exit can be activated while the Processing step (T) is active.




Turnoff_Exit_ISegt

l No

l Yes: Turns the exit off



Check and enrich the Input-Event segments for a specific transformation-RuleThis exit modifies, enriches or checks the data in the Input-Event segments before each application of a change or Transformation-Rule.





Turnoff_Exit_Rule l No


Identify and check Output-EventsThis exit enriches or checks the Output-Events, or identifies the output, before the Output-Events are processed. This exit is enabled in AI Enabler.





Turnoff_Exit_OSegt l No


Enrich Output-Events during aggregation by group (File mode only)This exit enriches the data in the Output-Event segments before and after they are aggregated. It is only activated if the Output-Events are to be aggregated.






>ScriptConfiguration< Section Yes_C or Yes_Cobol or Yes_rdj53 or No

P_Exit_Aggregation_OSegt_Group Yes_rdj53 is compatible with ITR615

Enrich Output-Events during aggregation - All groups together (File mode only)This exit enriches the data in the Output-Events before and after they are aggregated. It is only activated if the Input-Events are to be aggregated.

This exit can be activated while the Output step (S) is active.




O_Exit_Aggregation_OSegt l Yes_C or Yes_Cobol or Yes_rdj53 or No

l Yes_rdj53 is compatible with ITR615

Restructure Output-Events (File mode only)This exit restructures the data in the Output-Event just before they are physically written out. It allows you to:

l Create

l Merge

l Delete

l Change the contents of Output-Events

This exit can be activated while the Output step (S) is active.




O_Exit_Restructuring_OSegt Yes_C or No



Reformat the transformation products before issuing a message (MQSeries mode only)This exit, written in C, reformats the data contained in Output-Event messages and other products immediately before they are sent, after the completion of processing in a transformation session.

This exit is activated directly by the definition of an exchange zone for the product concerned in script.mqs.

Queue= MQS , "Manager=Qmngr;Queue=queuename; Reformatting=Yes,Blocking=Yes;Buffer=nb"

Rules to follow:

1 Reformatting:Optional parameterIf this parameter is not supplied, the exit is not enabled

l Yes: The reformatting exit is enabled

l No: The reformatting exit is not enabled

Reformat the transformation products before issuing a message (JMS mode only)This exit, written in C, reformats the data contained in Output-Event messages and other products immediately before they are sent, after the completion of processing in a transformation session.

This exit is activated directly by the definition of an exchange zone for the product concerned in script.jms.

Queue= MQS , "Manager=QCF;Queue=queuename; Reformatting=Yes,Blocking=Yes;Buffer=nb"

Rules to follow:

1 Reformatting:Optional parameterIf this parameter is not supplied, the exit is not enabled

l Yes: The reformatting exit is enabled

l No: The reformatting exit is not enabled



External callsExternal calls comprise a set of independent modules all stored in the ITR501 module. They are activated automatically by the Data Manipulation Language $SEARCH and $CHECK commands. These are the only keywords which activate the external calls.

In the same way as for the exits, the use of this external call is described in the Rule Engine Exits and External Calls Manual, which gives details of the entry points and the data that is exchanged between the main program and this module.

Implement the Oracle $SEARCH function in a file, MQSeries or JMS-based environmentYou must supply the following variables, in procedure rdjexp, to allow the ITR501 external calls to connect to the database that you want to access:

Name Use

RDJ_EXIT501_ORACLE_SRV Name of the database server to be accessed

RDJ_EXIT501_ORACLE_USER User name for connecting to the database

RDJ_EXIT501_ORACLE_PWD Password associated with the above user name

This module exists in C (ITR501C) and Cobol (ITR501).

For more information on Exits and External calls, refer to the guide Rule Engine Exits and External Calls.

Set up the transformation environment

Session environments and domainsThe session environments and domains allow you to spread the various processing phases across different executions (for example, daily, monthly, quarterly or annual processing)

The session environment activates one or more domains.

Each domain, when activated, executes the Transformation-Phases associated with it.

The session environment is activated in script.ges. If no session environment is specified and only one is defined in the usr.dat file, the Rule Engine runs in the environment defined in the usr.dat file.





Environment_Transformation The name of the session environment activated by the session

The domains activated by the environment must be supplied in usr.dat. Configure the domains in Axway Composer.


>Transformation_Environment<Section

#Environment.;Domain;Processing-Context-Out BATCH;DOM1 ;III.BATCH;DOM2 ;JJJ.

Rules to follow:

Rule Meaning

1 Environment: Required parameterSpecifies the name of the session environment

2 Domain: Required parameterSpecifies the domain that is activated by the associated environmentIf several domains are activated by the same environment, supply a line for each domain

3 Processing-Context-Out. See Implement redirection on page 97

4 The semi-colon ( ; ) is the required delimiter

5 End each line with a period ( . )

Implement redirectionRedirection copies the processed Input-Event to one or more outputs.

The Input-Event is only redirected if ALL phases of the current processing are completed successfully. If the Input-Event is placed in anomaly or rejected, the redirection is canceled for the Input-Event concerned.

If exits are enabled, it is the Input-Event as modified by the exits that is redirected. The only exception to this is the exit applied to enrich the event before the application of a Transformation-Rule.



For example, an Input-Event that is processed in real time at the bank counter must be processed for other applications during the overnight batch run. This means that a copy must be made after the real-time processing.

Redirection is enabled through sys.dat, usr.dat and script.ges.

Parameter settings in sys.dat:

Keyword Description / Values

>Choice< Section

Redirection Yes

Parameter settings in usr.dat:


Section >Environment_Transformation<

#Environment.;Domain;Processing-Context-OutBATCH;DOM1;III.BATCH;DOM2;JJJ.

Rules to follow:

Rule Meaning

1 Processing-Context-Out: Required parameter if redirection is enabledSpecifies the logical name of the exchange zone that is to receive the redirected Input-EventIf you do not specify a Processing-Context-Out for the redirected Input-Event, redirection does not take placeYou can specify more than one Processing-Context-Out for redirected eventsSpecify each Processing-Context-Out on a separate line

2 The semi-colon ( ; ) is the required delimiter

3 End each line with a period ( . )

Parameter settings in script.ges:






IEvent_Redirected (Processing-Context-Out)

The name of the exchange zone to which the redirected Input-Events are writtenIf you have specified more than one Processing-Context-Out for redirected events, define an exchange zone for each output

Detail_Redirection_IEvent

The file containing the data for the report on the redirections that have been effected

Optional environment variables settingProcedures use these variables at runtime. You must define them to enable procedures to reference valid values.

Variable Use

RDJ_CTRL_DATE Check that the Input-Event date is included between 01/01/1900 and 31/12/2099:

l Y,y

l O,o

l N,n (default)

RDJ_REVISION Activate the SVN revision number of each source program:

l YES, OUI

l YES_H, OUI_H

l NO (default)

RDJ_TPSFILE Path of the rdjtps.txt file

PSORT MVS onlySelect sort tool to use in RDJFIC:

l DFSPARM (default): DFSORT

l $ORTPARM: Syncsort



Variable Use

SORT_CODIF MVS onlyBy default, set to CH (EBCDIC characters). Select sort codification to use in RDJFIC:Decimal

l ZD: zoned decimal (no sign)

l PD: packed decimal, signed

l CSF or FS: signed, optionally a floating sign is leading Binary

l BI: unsigned binary

l FI: fixed point signed binary

l FL: signed floating point binary ASCII

l AST: ASCII numeric with a trailing separate sign

l ASL: ASCII numeric with leading separate sign

l AC: unsigned ASCII EBCDIC

l CH: EBCDIC characters

l CSL: EBCDIC numeric with leading separate sign

l CST: EBCDIC numeric with trailing separate sign

l CLO: EBCDIC numeric with a leading overpunch sign

l CTO: EBCDIC numeric with a trailing overpunch sign OtherAQ: alternate collating sequence

RDJ_CALLDYN_[exit name]

Call the exit program on dynamic instead of DLL by default:

l YES, OUI:

l NO (default):



Variable Use

RDJ_SIZE_GROUP_TRACE

Activate the trace of the group management in buffer:

l Y,y,

l O,o

l N (default)

RDJ_SIZE_GROUP_IN Memory size (in bytes or megabytes) of the Input memory buffer of a group:

l nK

l nMDefault value: 2M

RDJ_SIZE_GROUP_OUT

Memory size (in bytes or megabytes) of the Output memory buffer of a group:

l nK:

l nM:Default value: 2M

RDJ_PACK53 Pack sign behavior:

l O: the Pack sign behavior is the same than in RDJ53

l N (default):

SDE_SIZE_MEM_MAX Memory size (in bytes) of the buffer used by rdjews to generate the ap.Cra file.By default: 8000000

STN_INIT_FILE Path of the rdjstn.ini file


6 Set parameters for MQSeries and JMS implementations

This sections contains specific instructions for setting parameters for an MQSeries-based or JMS-based implementations of Rule Engine.

The topics described in this section are:

l Set MQSeries-specific or JMS-specific parameters in script.mqs on page 102

l Structure of the messages transmitted on page 103

l Read and produce messages on page 104

l Messages in anomaly on page 105

l Structure of the messages generated on page 105

l Use an exit to reformat Input-Event messages and transformation products on page 108

l Manage groups with MQSeries or JMS on page 108

l Utilities for accessing the MQSeries or JMS exchange zones on page 111

l RuleEngineJMS and IBM-MQSeries implementation on page 129

The MQSeries or JMS queue prefix is determined by the environment variable QRDJ_PREF, which is automatically referenced by the installation kit.

Set MQSeries-specific or JMS-specific parameters in script.mqs

To implement a session, you must define the Queue Rule Engine and the mode in which it is to operate. You can do this in the script.mqs (for MQSeries) or in the script.jms (for JMS).



MQS (LOCAL_MANAGER)

The name of the local manager (for MQSeries) or QCF (for JMS)The maximum length of the name is:

l 4 alphanumeric characters for MVS (MQSeries only)

l 48 alphanumeric characters for UNIX




MQS (MODE) Functioning mode of the Rule Engine in an MQSeries or JMS implementationImmediate (default value): Once started, the Rule Engine processes messages from its queue of Input-Events and is put on hold when the queue is empty. To stop it, you must send a specific administration message.Delayed: Once started, the Rule Engine processes messages from its queue of Input-Events and stops automatically when the queue is empty.

MQS (CONVERSION)

Request to convert Input-Event messages

l Yes: (the default value): The messages are automatically converted

l No: The Input-Event messages received are not converted

MQS(FILE_LOT_INCOMPLET)

Name of the queue to which messages from incomplete Input-Event groups are written

MQS (FILE_MSG_UNREADABLE)

Name of the queue to which unreadable or suspect Input-Event messages are written

Structure of the messages transmittedMessages containing Input-Events to be transformed must be structured in the fixed format as defined in this section.

The context and structure of the message must follow certain rules if the Manage Groups option is enabled. For more information, refer to Manage groups with MQSeries or JMS on page 108.

The message context is not subject to any special rules if you have not activated the Group Management option.

However, whatever options you activate, you must follow the rules set out below.

Rules to follow for each message to be transmitted:

1 All segments of one Input-Event must be transported in a single message

2 The maximum length of a message depends on the version of the MQSeries or the JMS broker you are using. It is set by MQSeries at 100 MB for MQSeries V7

3 Several (complete) Input-Events can be transported by a single messageIn this case the last segment of the message is the last segment of the last Input-Event in the message

The data carried by the Input-Event message must be formatted as shown in the following table:



Field Length Value

Filler 64 characters

Number of segments 7 characters Number of segments in the message (N)

Length of segment 1 4 characters

Segment 1 1 to 4000 characters

… …

… …

Length of segment N 4 characters

Segment N 1 to 4000 characters

Note The number of segments and the length of each segment are expressed as long data types (PIC X or CHAR).

Read and produce messagesAt any given time, a single work unit is open to manage the entire set of data. Thus, the integrity of the data is ensured by the MQSeries mechanisms for committing or rolling back a unit of work.

Committing a unit of work:

Group Management Option is ...

A work unit is committed ...

Enabled When all Input-Events belonging to a group have been transformed with no rejections or anomalies

Disabled After processing each Input-Event

Rolling back a work unit:

Group Management Option is ...

A work unit is backed out ...

Enabled When one Input-Event in the group is rejectedThe purpose of backing out at this point is to cancel the products generated by the transformation of other Input-Events in the group

Disabled No backout is performed



Messages in anomaly

Unreadable messagesA message is unreadable when either:

l The format of the message does not match the format expected by Rule Engine

l The message exceeds the size set for the buffer

An unreadable message is written out to the queue reserved for unreadable messages. For more information, refer to Set MQSeries-specific or JMS-specific parameters in script.mqs on page 102.

It is up to the administrator to try to correct or recycle such messages.

Suspect messagesA message is suspect if its BACKCOUNTER exceeds:

l 2, if it does not belong to a group

l 3, if it belongs to a group

A suspect message is written out to the same queue as unreadable messages. For more information, refer to Set MQSeries-specific or JMS-specific parameters in script.mqs on page 102 .

It is up to the administrator to try to correct or recycle suspect messages.

Structure of the messages generatedThe message context generated for a given product is formed as follows:

l MsgId is a unique value assigned by Rule Engine MQSeries or JMS

l CodeCharSetId is set to 0 (zero)The format is obtained from MQSTR

l CorrelId is set to spaces, except when the Group Management option is enabled For more information, refer to Manage groups with MQSeries or JMS on page 108

l The other elements in the context are identical to the context associated with the Input-Event being processed

The following table shows the format of the data element of the message:



Data Element Number of Characters

Meaning


Product number 2 characters The code number that identifies the type of product carried by the message

Processing-Context-Out name

25 characters Name of the Processing-Context-Out for the product, if one exists.This field is filled for Output-Events and redirected Input-Events


Number of elements

7 characters Number (N) of elements of the product contained in the message

Length of element 1

4 characters

Element 1 1 to 4000 characters (as defined in the previous field)

... …

… …

Length of element N

4 characters

Element N 1 to 4000 characters (as defined in the previous field)

A number that is assigned by Rule Engine identifies each product generated. You can transfer the data stored in a queue to a file, using the administration tools supplied.

The table below shows the product numbers assigned to each type of product.

Note Important note:You can store no more than 2 compatible products in the same queue. For details of compatibility, see the following table.

Product Number

Description of Product Keyword in script.mqs or script.jms

Compatible Product Number

01 The Input-Event to be transformed IEvent (Sender)



Product Number

Description of Product Keyword in script.mqs or script.jms

Compatible Product Number

02 Output-Events broken down by Processing-Context-Out

OSegt(Name_Output) 02 (different Processing-Context-Out)

03 Redirected Input-Events broken down by Processing-Context-Out

IEvent_Redirected (Name_Output)

03 (different Processing-Context-Out)

04 Input-Events placed in anomaly during transformation

IEvent_Anomaly 05

05 Input-Events rejected during transformation

IEvent_Rejected 04

06 Modified Input-Events IEvent_Modified

07 Audit traces extracted from the processed Input-Events

Trace_IEvent 16

08 Data for report on transformation anomaly details

Detail_Anomaly_Rejection_IEvent

09 Data for report on redirection details Detail_Redirection_IEvent

10 Data for report on transformation details

Detail_Transformation

11 Data for report on transformation counters

Counter_Transformation

12 Data for report on operation counters

Rule_Counter

13 Data for customized reports Detail_Print_Customized

15 Data for the account log report Log_Account

16 Audit traces extracted from the Output-Events generated

Trace_OSegt 07



Use an exit to reformat Input-Event messages and transformation products

The reformatting exit allows you to:

l Decrypt, decompress and reformat the Input-Event messages as they are received and before you start the Rule Engine MQSeries or JMS native functions.

l Encrypt, compress and reformat the Output-Event messages before they are sent and after you run the Rule Engine MQSeries or JMS native functions.

You call the exit for each queue declared in script.mqs or script.jms.

Parameter settings in script.mqs or script.jmsQueue= MQS,"Manager=Qmngr;Queue=queuename; Reformatting=Yes, Blocking =Yes; Buffer = nb"

Rules to follow:

1 Reformatting: Calls the exit to reformat the message either after it is received (for Input-Events) or before it is sent (for the transformation products)Reformatting is an optional parameter. If you do not specify it, Rule Engine does not activate the exit.



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

Manage groups with MQSeries or JMSTo manage groups, you must set further parameters in addition to those required for the basic implementation.

The message context must follow the following rules:

1 Each message in the group must have a unique MsgId. This allows it to be re-read if it is rejected

2 All message that carry Input-Events from the same group must share the same CorrelId



3 If a message CorrelId is blank, the Input-Events that it carries do not belong to any group

Each message that is to be sent must obey the following rules:

1 All segments of one Input-Event must be carried in a single message

2 The maximum length of a message depends on the version of MQSeries or JMS broker you are usingIt is set by MQSeries at 100 MB for MQSeries V7

3 Several (complete) Input-Events, belonging to the same group, can be transported by a single message

4 A group of Input-Events is carried by 1 to N messages

The data carried by the Input-Event message must be formatted as shown in the following table:

Field Length Value

Sequence number

12 characters Sequence number giving the position of the message in the group

End-of-group flag

1 character Set to F for the last message in the group


Number of segments

7 characters Number of segments in the message (N)

Length of segment 1

4 characters

Segment 1 1 to 4000 characters

… …

… …

Length of segment N

4 characters



Field Length Value

Segment N 1 to 4000 characters

Note Note:The sequence number, end-of-group flag, number of segments and length of each segment are expressed as long data types (PIC X or CHAR).

Define a complete groupA group of Input-Events is complete when:

l The system finishes reading the last message in the group (end-of-group flag = F)

l The number of messages processed with the same CorrelId equals the sequence number in the final message of the group

Define an incomplete groupA group is incomplete if one of the above conditions is not fulfilled.

Each time the system receives an incomplete group, it checks the incomplete groups queue. If it finds the remainder of the group in this queue, it processes the entire group. Otherwise, the system sends messages to this queue until it receives the remaining messages.



MQS (TimeOut) Maximum time, in seconds, allowed between receiving two messages in the same groupIf this threshold is exceeded, the system declares the group incomplete

MQS (FILE_ GROUP_INCOMPLETE)

Name of the queue to which the system writes those messages that carry incomplete Input-Event groups

Reproduce a groupTo reproduce a group, you write the CorrelId of the processed Input-Event group back into the contexts of the output messages.

Rule Engine automatically reproduces Input-Event groups for queues that contain:

l Input-Events placed in anomaly during transformation

l Rejected Events



l Modified Input-Events

l Redirected Input-Events

Reproducing groups is optional for queues of Output-Events generated by the transformation of an Input-Event group. The system reproduces groups for each queue declared in script.mqs or script.jms.

Parameter settings in script.mqs or script.jms for a queue of Output-EventsQueue= MQS , "Manager=Qmngr;Queue=queuename; Reproduction_group=Yes;Blocking=Yes;"

Rules to follow:

1 Reproduction_group: Writes the CorrelId value of the group of Input-Events processed back to the context of the output queueReproduction_group is an optional parameter. If you do not specify it, Rule Engine does not activate group reproduction.

l Yes: Enables the reproduction of groups

l No: The reproduction of groups is not enabled

Utilities for accessing the MQSeries or JMS exchange zones

A number of utilities are provided with the package to help you to fine-tune a session.

The table below shows what these utilities allow you to do:

Action UNIX/Windows Command MVS Command

Empty (or purge) queues Rdjcleanmqs/rdjcleanjm RDJCLNS

Generate a message to stop the session Rdjstopmqs/ rdjcleanjms RDJSTO

Transfer data from a file to a queue Rdjputmqs/ rdjcleanjms] RDJPUT

Transfer data from a queue to a file Rdjgetmqs/ rdjcleanjms] RDJGET

The installation procedure defines the default values of the parameter settings for each utility provided.

Note You must adapt the parameters in these procedures to your environment.



Empty queues: rdjcleanmqs, rdjcleanjms

PurposeTo empty the queues, either on input or output.

These queues have the same names as the queues created when you installed the product.

ParametersThe table below shows the names of the queues created during the installation process. You can change the queue names, or add or delete names, to suit your implementation environment.

Data Contained in the Queue <br />(Keyword + Description)

UNIX/

Windows

Queue

Name

MVS Queue Name

Queue Name

IEvent(Sender): The Input-Event to be transformed

RDJ.IEVENT RDJ.IEVENT RDJ.IEVENT

OSegt (0): Generated Output-Events associated with Processing-Context-Out 0

RDJ.OSEGT.0 RDJ.OSEGT0 RDJ.OSEGT.0








UNIX/

Windows

Queue

Name

MVS Queue Name

Queue Name
















UNIX/

Windows

Queue

Name

MVS Queue Name

Queue Name



OSegt (A): Generated Output-Events associated with Processing-Context-Out A

RDJ.OSEGT.A RDJ.OSEGTA RDJ.OSEGT.A

OSegt (B): Generated Output-Events associated with Processing-Context-Out B

RDJ.OSEGT.B RDJ.OSEGTB RDJ.OSEGT.B

OSegt (C): Generated Output-Events associated with Processing-Context-Out C

RDJ.OSEGT.C RDJ.OSEGTC RDJ.OSEGT.C

OSegt (D): Generated Output-Events associated with Processing-Context-Out D

RDJ.OSEGT.D RDJ.OSEGTD RDJ.OSEGT.D

OSegt (E): Generated Output-Events associated with Processing-Context-Out E

RDJ.OSEGT.E RDJ.OSEGTE RDJ.OSEGT.E




UNIX/

Windows

Queue

Name

MVS Queue Name

Queue Name

OSegt (F): Generated Output-Events associated with Processing-Context-Out F

RDJ.OSEGT.F RDJ.OSEGTF RDJ.OSEGT.F

OSegt (G): Generated Output-Events associated with Processing-Context-Out G

RDJ.OSEGT.G RDJ.OSEGTG RDJ.OSEGT.G

OSegt (H): Generated Output-Events associated with Processing-Context-Out H

RDJ.OSEGT.H RDJ.OSEGTH RDJ.OSEGT.H

OSegt (I): Generated Output-Events associated with Processing-Context-Out I

RDJ.OSEGT.I RDJ.OSEGTI RDJ.OSEGT.I

OSegt (J): Generated Output-Events associated with Processing-Context-Out J

RDJ.OSEGT.J RDJ.OSEGTJ RDJ.OSEGT.J




UNIX/

Windows

Queue

Name

MVS Queue Name

Queue Name

OSegt (Default): Generated Output-Events associated with a Processing-Context-Out for which there is no exchange zone

RDJ.OSEGT.DEFAULT RDJ.OSEGTZ RDJ.OSEGT.DEFAULT

IEvent_Redirected (I): Redirected Input-Events associated with Processing-Context-Out I

RDJ.IEVENT.REDIRECTED.I RDJ.IEVRDI RDJ.IEVENT.REDIRECTED.I

IEvent_Redirected (J): Redirected Input-Events associated with Processing-Context-Out J

RDJ.IEVENT.REDIRECTED.J RDJ.IEVRDJ RDJ.IEVENT.REDIRECTED.J

IEvent_Modified: Input-Events modified by the session

RDJ.IEVENT.MODIFIED RDJ.IEVMOD RDJ.IEVENT.MODIFIED

IEvent_Anomaly: Input-Event that causes a transformation anomaly

RDJ.IEVENT.ANOMALY RDJ.IEVANO RDJ.IEVENT.ANOMALY




UNIX/

Windows

Queue

Name

MVS Queue Name

Queue Name

IEvent_Rejected: Input-Events rejected during transformation

RDJ.IEVENT.REJECTED RDJ.IEVREJ RDJ.IEVENT.REJECTED

Trace_IEvent: Extracted Input-Event traces

RDJ.TRACE.AUDIT RDJ.TRACES RDJ.TRACE.AUDIT

Trace_OSegt: Extracted Output-Event traces

RDJ.TRACE.AUDIT RDJ.TRACES RDJ.TRACE.AUDIT

Detail_Anomaly_Rejection_IEvent: Report on transformation anomaly details

RDJ.DETAIL.ANOMALY RDJ.DETANO RDJ.DETAIL.ANOMALY

Detail_Redirection_IEvent: Report on redirection details

RDJ.DETAIL.REDIRECTION

RDJ.DETRED RDJ.DETAIL.REDIRECTION

Detail_Transformation: Report on transformation results details

RDJ.DETAIL.TRANSFORMATION

RDJ.DETTRA RDJ.DETAIL.TRANSFORMATION

Counter_Transformation: Transformation counters report

RDJ.TRANSFORMATION.COUNTER

RDJ.CNTTRA RDJ.TRANSFORMATION.COUNTER




UNIX/

Windows

Queue

Name

MVS Queue Name

Queue Name

MQS (FILE_GROUP_INCOMPLETE): Groups of Input-Events that were incomplete when read

RDJ.INCOMPLETED.GROUP RDJ.GRPANO RDJ.INCOMPLETED.GROUP

MQS (FILE_MSG_UNREADABLE): Unreadable or suspect messages

RDJ.UNREADABLE.MESSAGE

RDJ.UNREAD RDJ.UNREADABLE.MESSAGE

SyntaxThe procedure calls program rdjcleanmqs,rdjcleanjms / RDJCLN, which has the following run-time syntax:

l UNIX Syntax with MQseries:$EXE/rdjcleanmqs, Local_Manager Queue

l UNIX Syntax with JMS:$EXE/rdjcleanjms Local_Manager Queue

l MVS Syntax:

//RDJCLEAN EXEC PGM=RDJCLEAN,//PARM=' Local_Manager Queue '

You must supply the parameters in the order shown:

l Local_Manager:Name of the local queue manager (MQSeries) or QCF (JMS)

l Queue: Name of the queue to empty

If an anomaly occurs during execution, the system stores a message reporting the anomaly in $TMP/rdjcleanmqs.msg.



Stop the session: rdjstopmqs,rdjstopjms / RDJSTO

PurposeThis procedure stops an Rule Engine MQSeries or JMS session, if the stop mode is set to Immediate. It builds a stop message and writes it to the Input-Event queue that is to be processed by the session.

This message has the highest priority, consequently the system:

l Processes it before any of the queued Input-Event messages

l Stops the session as soon as it completes a work unit (that is, either a commit at the end of an Input-Event or commit or rollback at the end of a group of Input-Events)

When you start a session, the system automatically purges the Input-Event queue of any stop messages before it reads in the Input-Events.

ParametersThe Input-Event queue to be processed has the name that was used at installation time. RDJ.IEVENT.

You must modify the values in the procedure to fit your own implementation.

SyntaxThe procedure calls program rdjstopmqs,rdjstopjms/RDJSTO, which has the following run-time syntax.

l UNIX Syntax with MQSeries:

$EXE/rdjstopmqs Local_Manager Queue

l UNIX Syntax with JMS:

$EXE/rdjstopjms Local_Manager Queue

l MVS Syntax:

//RDJSTOP EXEC PGM=RDJSTOP,//PARM=' Local_Manager Queue '

You must supply the parameters in the order shown:

Order N° Parameter Use

1 Local_Manager Name of the local queue manager



Order N° Parameter Use

2 Queue The name of the Input-Event queue that is to be processedThe stop message is stored in this queue

If an anomaly occurs during execution, the system stores a message reporting the anomaly in $TMP/rdjstopmqs.msg (for MQSeries) or $TMP/rdjstopjms.msg (for JMS).

Transferring data from a file to a queue: rdjputmqs,rdjputjms /RDJPUT

PurposeThis procedure takes data from a file and creates an Input-Event queue with it in the format expected by the package.

ParametersThe Input-Event queue to be processed has the name that was given at installation time. RDJ.IEVENT

The file of Input-Events has the name that was given at installation time: IEvent.seq (UNIX/Windows) or DD:IEVENT (MVS).

You must modify the values in the procedure to fit your own implementation.

SyntaxThe procedure calls the program rdjputmqs,rdjputjms/RDJPUT, which has the following run-time syntax.

l UNIX Syntax with MQseries: $EXE/rdjputmqs Local_Manager Queue File IEvent_Keys Group_Key Root_MsgId Message_

Length Message_Format [Remote_Manager]

l UNIX Syntax with JMS: $EXE/rdjputjms Local_Manager Queue File IEvent_Keys Group_Key Root_MsgId Message_Length Message_Format

[Remote_Manager]

l MVS Syntax: //RDJPUT EXEC PGM=RDJPUTC,//PARM='Local_Manager Queue File IEvent_Keys Group_Key -//Root_MsgId Message_Length

Message_Format [Remote_Manager]'

You must supply the parameters in the order shown below:



Order N°

Parameter Use

1 Local_Manager

Name of the local queue manager

2 Queue Name of the Processing-Context-Out queue

3 File Name of the Input-Event file that is to be transferred

4 IEvent_Keys

The set of fields that identify an instance of an Input-Event

l Each field is defined by its length and position in the file record. The sets of values (that is, a position and a length) are separated from each other by ampersands (&)

l Each position value must be in the range 1 - 4000. Each length value must be in the range 1 - 256

l A break in the sequence of the values of these fields marks the start of a new Input-Event in the file

l To indicate a mono-segment Input-Event, set the parameter to MONO

5 Group_Key Specifies the group key

l If you activated the Group Management option, define in this parameter the position and length of the group code in the file records

l This key indicates where the break between groups in the file is to be found

l The system uses the value of this field to build the CorrelId in the messages sent. The maximum length is 24 characters

l If you did not activate the Group Management option, set this field to N. In this case, the CorrelId is not set.

6 Root_MsgId

The root of the MsgId. Maximum 5 charactersThe MsgId of the message is built by concatenating this root with the date and time at which the message is sent (Example: SESSN19971201175608)

7 Message_Length

The maximum length (in KB) of the messages to be sentMust be in the range 1 - 4096KB

8 Message_Format

The format of the message. Values can be STRING or NONE



Order N°

Parameter Use

9 Remote_Manager

The name of the remote manager if the Processing-Context-Out queue is remote.This is an optional parameter

If an anomaly occurs during execution, the system stores a message reporting the anomaly in $TMP/rdjputmqs.msg (for MQSeries) or $TMP/rdjputjms.msg (for JMS).

Examples:

l In UNIX with MQSeries: $EXE/rdjputmqs HPX4 RDJ.IEVENT IEvent.seq "1,6&12,7" "25,20" VAC01 16 string

l In UNIX with JMS: $EXE/rdjputjms HPX4 RDJ.IEVENT IEvent.seq "1,6&12,7" "25,20" VAC01 16 string

l In MVS: //RDJPUT EXEC PGM=RDJPUTC,// PARM='MQME RDJ.IEVENT DD:IEVENT "1,6&12,7" "25,20" VAC01 16 STRING '//*//CRE DD

DSN=&ENVRDJ.CRE,DISP=SHR//SYSOUT DD SYSOUT=*//SYSPRINT DD

SYSOUT=*

Note You must sort the Input-Event file (using the keys that define an Input-Event and an Input-Event group). You must perform the sort externally, before you start the procedure.

The system uses a single unit of work is used for processing the file.

For a big file, you may reach the limit for the number of messages in a unit of work. In this case the unit of work is backed out and canceled. There are two ways to avoid this. Either:

l Increase the value of Message_Length so as to decrease the number of messages

l Chop the file into several smaller files

The system generates a return code when it completes the execution. You can test the return code via JCL or a shell program. The return code reports the level of the most serious error found during execution.

The table below shows the possible values, which are the identical for all systems:

Type of Error Encountered Associated Return Code


File empty or MQSeries warning or JMS warning 4

System error 16

If the return code is anything other than 0, the systems sends a message to the standard output on UNIX or to SYSPRINT on MVS.



Transferring data from a queue to a File: rdjgetmqs,rdjgetjms/RDJGET

PurposeTo create files from data held in a queue. Each file contains a transformation product in the defined format.

ParametersMode_Open_File

The Mode_Open_File parameter specifies the mode in which data is to be written to the procedure output file:

l C = Create mode

l A = Append mode

The queues names were created during the installation process. The resulting files are created in the results directory.

The table below shows the names of the queues and the files the system creates. You can change these file names in the procedure, or add or delete names, to suit your implementation environment.

Data Contained in the Queue (Keyword + Description)

UNIX /Windows Queue Name

MVSQueue Name

UNIX/Windows Data File Created/ Context File

OSegt (0): Generated Output-Events associated with output 0

RDJ.OSEGT.0 RDJ.OSEGT0 OSegt0.seqOSegt0.ctx


RDJ.OSEGT.1 RDJ.OSEGT1 OSegt1.seqOsegt1.ctx


RDJ.OSEGT.2 RDJ.OSEGT2 Osegt2.seqOsegt2.ctx





MVSQueue Name
















OSegt (A): Generated Output-Events associated with output A

RDJ.OSEGT.A RDJ.OSEGTA OsegtA.seqOsegtA.ctx





MVSQueue Name


Osegt (B): Generated Output-Events associated with output B

RDJ.OSEGT.B RDJ.OSEGTB OsegtB.seqOsegtB.ctx

OSegt (C): Generated Output-Events associated with output C

RDJ.OSEGT.C RDJ.OSEGTC OsegtC.seqOsegtC.ctx

OSegt (D): Generated Output-Events associated with output D

RDJ.OSEGT.D RDJ.OSEGTD OsegtD.seqOsegtD.ctx

OSegt (E): Generated Output-Events associated with output E

RDJ.OSEGT.E RDJ.OSEGTE OsegtE.seqOsegtE.ctx

Osegt (F): Generated Output-Events associated with output F.

RDJ.OSEGT.F RDJ.OSEGTF OsegtF.seqOsegtF.ctx

OSegt (G): Generated Output-Events associated with output G.

RDJ.OSEGT.G RDJ.OSEGTG OsegtG.seqOsegtG.ctx

OSegt (H): Generated Output-Events associated with output H.

RDJ.OSEGT.H RDJ.OSEGTH OsegtH.seqOsegtH.ctx

OSegt (I): Generated Output-Events associated with output I.

RDJ.OSEGT.I RDJ.OSEGTI OsegtI.seqOsegtI.ctx





MVSQueue Name


OSegt (J): Generated Output-Events associated with output J.

RDJ.OSEGT.J RDJ.OSEGTJ OsegtJ.seqOsegtJ.ctx

OSegt (Default): Generated Output-Events associated with an output for which there is no exchange zone.

RDJ.OSEGT.DEFAULT RDJ.OSEGTZ Osegtdef.seqOSegtdef.ctx

IEvent_Modified: Input-Events modified by the session.

RDJ.IEVENT.MODIFIED RDJ.IEVMOD ap.Modified_IEventmodifIE.ctx

IEvent_Anomaly: Input-Event that causes a transformation anomaly.

RDJ.IEVENT.ANOMALY RDJ.IEVANO ap.Anomaly_IEventAnoIE.ctx

IEvent_Rejected: Input-Events rejected during transformation.

RDJ.IEVENT.REJECTED RDJ.IEVREJ ap.Rejected_IEventRejectIE.ctx

Trace_IEvent: Extracted Input-Event traces.

RDJ.TRACE.AUDIT RDJ.TRACES ap.Tracetrace.ctx

Trace_OSegt: Extracted Output-Event traces.

RDJ.TRACE.AUDIT RDJ.TRACES ap.Tracetrace.ctx

IEvent_Redirected (I): Redirected Input-Events associated with output I.

RDJ.IEVENT.REDIRECTED.I RDJ.IEVRDI RedirIEI.seqRedirIEI.ctx





MVSQueue Name


IEvent_Redirected (J): Redirected Input-Events associated with output J.

RDJ.IEVENT.REDIRECTED.J RDJ.IEVRDJ RedirIEJ.seqRedirIEJ.ctx

Detail_Anomaly_Rejection_IEvent: Report on details of transformation anomalies.

RDJ.DETAIL.ANOMALY RDJ.DETANO ap.Detail_Anomaly_Reject_IEventdetano.ctx

Detail_Redirection_IEvent: Report on details of redirections.

RDJ.DETAIL.REDIRECTION RDJ.DETRED ap.Detail_Redirected_IEventDetRedir.ctx

Detail_Transformation: Report on details of results of transformation.

RDJ.DETAIL.TRANSFORMATION RDJ.DETTRA ap.Detail_TransformationDetTrans.ctx

Counter_Transformation: Report on transformation counters.

RDJ.TRANSFORMATION.COUNTER

RDJ.CNTTRA ap.Transformation_CounterCounttra.ctx

MQS (FILE_GROUP_INCOMPLETE) Groups of Input-Events that were incomplete when read.

RDJ.INCOMPLETED.GROUP RDJ.GRPANO IncompletedGroupIncompletedGroup.ctx

Account_Log RDJ.LOG.ACCOUNT RDJ.LOGACC Ap.LogAccountLogAccount.ctx

The SIC validation procedure uses the files of the Context message for Windows and UNIX platforms only.



SyntaxThe procedure calls program rdjgetmqs,rdjgetjms / RDJGET, which has the following run-time syntax:

l UNIX Syntax with MQSeries: $EXE/rdjgetmqs Local_Manager Queue Conversion Mode_Open_File Product_File [Message_Context_File]

l UNIX Syntax with JMS: $EXE/rdjgetjms Local_Manager Queue Conversion Mode_Open_File Product_File [Message_Context_File]

l MVS Syntax: //RDJCLEAN EXEC PGM=RDJGETC,// PARM=' Local_Manager Queue Conversion Mode_Open_File -// Product_File

[Message_Context_File]'

You must supply the parameters in the order shown below:

Order N°

Parameter Use

1 Local_Manager

Name of the local queue manager

2 Queue Name of the queue to be transferred

3 Conversion Request for automatic conversion of the messages

l C: The data in the messages is converted

l N:The data in the messages is transferred without conversion

4 Mode_Open_File

The mode in which the output (results) file is to be opened

l C:The file is opened in Create mode

l A: The file is opened in Append mode

5 Product_File Name of the results file (For example, Output-Events, Redirected Input-Events, Print data)

6 Message_Context_File

(optional parameter)Name of the file containing information about the context and technical header of each message (For example, CorrelId, MsgId, Product number)

If an anomaly occurs during execution, the system stores a message reporting the anomaly in $TMP/rdjgetmqs.msg (for MQSeries) or $TMP/rdjgetjms.msg(for JMS).

Examples

l Under UNIX with MQSeries: $EXE/rdjgetmqs HPX4 RDJ.ME.1 C A OSegt1.prod OSegt1.ctx



l Under UNIX with JMS: $EXE/rdjgetjms HPX4 RDJ.ME.1 C A OSegt1.prod OSegt1.ctx

l Under MVS: //RDJGET1 EXEC PGM=RDJGETC,// PARM='MQME RDJ.ME.1 N C DD:OSEGT1PROD'//*//OSEGT1PROD DD

DSN=&ENVRDJ.OSEGT1.PROD,DISP=(NEW,CATLG),// SPACE=(CYL,

(2,3),RLSE),// UNIT=SYSDA, VOL=SER=8SOP04,//

DCB=(RECFM=VB,LRECL=4004)//SYSOUT DD SYSOUT=*//SYSPRINT DD

SYSOUT=*

Note A return code is generated on completion of execution. You can test it using JCL or a shell program. The return code reports the level of the most serious error found during execution. The table below shows the possible values, which are the identical for all systems:

Type of Error Encountered Associated Return Code


File empty or MQSeries warning or JMS warning 4

System error 16

If the return code is anything other than 0, a message is sent to the standard output in UNIX or to SYSPRINT under MVS.

RuleEngineJMS and IBM-MQSeries implementation

When you install Rule Engine JMS, the message broker set by default is ACTIVEMQ.

To implement using the message broker IBM-MQSeries, it is recommended that you install a new Rule Engine JMS runtime environment and that you modify it following the steps specified below.

In this document:

l MQM_HOME refers to the environment of the product MQSeries server

l HOME refers to the user's home directory

Generate the JNDI file using JMSAdminThis generation is used to define JMS objects in relation to MQSeries objects.

To generate the JNDI file:

1. Create the JNDI folder on page 130

2. Load the JMS environment (UNIX only) on page 130



3. Update the file JMSAdmin.config on page 130

4. Create the JMS objects definition file using the editor on page 132

5. Execute the JMSAdmin utility on page 134

6. Check the generation of the JNDI file in the JNDI folder on page 135

Create the JNDI folderThe JNDI folder contains the generated JNDI file.

It is recommended that you create the JNDI folder in the directory RDJ_EXEC/script as shown below.

<RDJ_EXEC>/script>mkdir JNDI-IBM

<RDJ_EXEC>

Load the JMS environment (UNIX only)To load the JMS environment, run the following command:

<MQM_HOME>/java/bin>. setjmsenv

MQ_JAVA_INSTALL_PATH is /usr/mqm/java

MQ_JAVA_DATA_PATH is /var/mqm

MQ_JAVA_LIB_PATH is /usr/mqm/java/lib

CLASSPATH is

:/usr/mqm/java/lib/com.ibm.mq.jar:/usr/mqm/java/lib/com.ibm.mqjms.jar:/u

sr/mqm/samp/java/base:/usr/mqm/samp/java/jms

<MQM_HOME>/java/bin>

Update the file JMSAdmin.configThe file JMSAdmin.config is in the directory <MQM_HOME>/java/bin

Modify the following variables in the file JMSAdmin.config :

l INITIAL_CONTEXT_FACTORY – describes the JMS objects in a "flat" file of type fscontext. See example below.

l PROVIDER_URL – indicates the location of the JNDI file created earlier.

Caution In Windows, you must use slashs (/) instead of antislashs (\) for the paths.

# ------------------------------------------------------------

# IBM Websphere MQ Support for Java Message Service



# This is the default configuration file for the Websphere MQ Classes

for

# Java Message Service Administration Tool.

#

# %PUB_START%

# Licensed Materials - Property of IBM

#

# 5724-H72, 5655-L82, 5724-L26

#

# (c) Copyright IBM Corp. 2002, 2005

#

# US Government Users Restricted Rights - Use, duplication or

# disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

# %PUB_END%

# ------------------------------------------------------------

#

# The following line specifies which JNDI service provider is in use.

# It currently indicates an LDAP service provider. If a different

# service provider is used, this line should be commented out and the

# appropriate one should be uncommented.

#

INITIAL_CONTEXT_FACTORY=com.sun.jndi.fscontext.RefFSContextFactory

#

# The following line specifies the URL of the service provider's initial

# context. It currently refers to an LDAP root context. Examples of a

# file system URL and WebSphere's JNDI namespace are also shown,

commented

# out.

#

PROVIDER_URL=file://<RDJ_EXEC>/script/JNDI-IBM

#

# The following line specifies the security authentication model in use,

# and may be 'none' (for anonymous authentication), 'simple', or 'CRAM_

MD5'.

#

SECURITY_AUTHENTICATION=none

#

# If you don't have SECURITY_AUTHENTICATION=none, then JMSAdmin will

# prompt you for the User DN and password. If you want to bypass these

# prompts then you can specify one or both of the values here. Since

# the password here is in cleartext this is not normally recommended



# except for testing. You should replace these values with your own.

#

#PROVIDER_USERDN=cn=Manager,o=ibm,c=uk

#PROVIDER_PASSWORD=secret

#

#

# The following line determines whether to use an InitialDirContext, or

an

# InitialContext. Takes value of TRUE or FALSE.

#USE_INITIAL_DIR_CONTEXT=TRUE

#

# The following line specifies a prefix to add to names when carrying

out operations such

# as lookup/bind.

#NAME_PREFIX=cn=

#

# The following line specifies a marker at which names will be truncated

when viewing

# the contents of the Context.

#NAME_READABILITY_MARKER=..

Create the JMS objects definition file using the editorManually create the JMS objects definition file and add the lines below using the editor. These lines are used to define the JMS objects in relation to the MQSeries objects created later.

Sample file: <HOME>/JMS.RE

Replace the following strings in the JMS objects definition file:

l <HOSTNAME> : hostname of the UNIX/WIN machine hosting MQSeries

l <PORT> : port listener MQ number – default : 1415

l <JMS_CHL> : name of channel between JMS and MQSeries

l <QMGR_NAME> : name of the MQSeries queue manager for the environment <RDJ_EXEC> (*)

l <QRDJ_PREF> : MQSeries queue prefix for the environment <RDJ_EXEC> (*)

(*) For simplicity, use the same values for the JMS objects and the MQSeries objects.

DEFINE qcf(<QMGR_NAME>) qmgr(<QMGR_NAME>) host(<HOSTNAME>) port(<PORT>)

transport(CLIENT) CHANNEL(<JMS_CHL>)

DEFINE Q(<QRDJ_PREF>.DETAIL.ANOMALY) qmgr(<QMGR_NAME>) QU(<QRDJ_

PREF>.DETAIL.ANOMALY)



DEFINE Q(<QRDJ_PREF>.DETAIL.REDIRECTION) qmgr(<QMGR_NAME>) QU(<QRDJ_

PREF>.DETAIL.REDIRECTION)

DEFINE Q(<QRDJ_PREF>.DETAIL.TRANSFORMATION) qmgr(<QMGR_NAME>) QU(<QRDJ_

PREF>.DETAIL.TRANSFORMATION)

DEFINE Q(<QRDJ_PREF>.IEVENT) qmgr(<QMGR_NAME>) QU(<QRDJ_PREF>.IEVENT)

DEFINE Q(<QRDJ_PREF>.IEVENT.AGGREGATION.COUNTER) qmgr(<QMGR_NAME>) QU

(<QRDJ_PREF>.IEVENT.AGGREGATION.COUNTER)

DEFINE Q(<QRDJ_PREF>.IEVENT.ANOMALY) qmgr(<QMGR_NAME>) QU(<QRDJ_

PREF>.IEVENT.ANOMALY)

DEFINE Q(<QRDJ_PREF>.IEVENT.MODIFIED) qmgr(<QMGR_NAME>) QU(<QRDJ_

PREF>.IEVENT.MODIFIED)

DEFINE Q(<QRDJ_PREF>.IEVENT.REDIRECTED.I) qmgr(<QMGR_NAME>) QU(<QRDJ_

PREF>.IEVENT.REDIRECTED.I)

DEFINE Q(<QRDJ_PREF>.IEVENT.REDIRECTED.J) qmgr(<QMGR_NAME>) QU(<QRDJ_

PREF>.IEVENT.REDIRECTED.J)

DEFINE Q(<QRDJ_PREF>.IEVENT.REJECTED) qmgr(<QMGR_NAME>) QU(<QRDJ_

PREF>.IEVENT.REJECTED)

DEFINE Q(<QRDJ_PREF>.IEVENT_TRACE.AUDIT) qmgr(<QMGR_NAME>) QU(<QRDJ_

PREF>.IEVENT_TRACE.AUDIT)

DEFINE Q(<QRDJ_PREF>.INCOMPLETED.GROUP) qmgr(<QMGR_NAME>) QU(<QRDJ_

PREF>.INCOMPLETED.GROUP)

DEFINE Q(<QRDJ_PREF>.INITQ) qmgr(<QMGR_NAME>) QU(<QRDJ_PREF>.INITQ)

DEFINE Q(<QRDJ_PREF>.LOG.ACCOUNT) qmgr(<QMGR_NAME>) QU(<QRDJ_

PREF>.LOG.ACCOUNT)

DEFINE Q(<QRDJ_PREF>.LOG.COMPENSATION) qmgr(<QMGR_NAME>) QU(<QRDJ_

PREF>.LOG.COMPENSATION)

DEFINE Q(<QRDJ_PREF>.OSEGT.0) qmgr(<QMGR_NAME>) QU(<QRDJ_PREF>.OSEGT.0)










DEFINE Q(<QRDJ_PREF>.OSEGT.A) qmgr(<QMGR_NAME>) QU(<QRDJ_PREF>.OSEGT.A)

DEFINE Q(<QRDJ_PREF>.OSEGT.AGGREGATION.COUNTER) qmgr(<QMGR_NAME>) QU

(<QRDJ_PREF>.OSEGT.AGGREGATION.COUNTER)

DEFINE Q(<QRDJ_PREF>.OSEGT.B) qmgr(<QMGR_NAME>) QU(<QRDJ_PREF>.OSEGT.B)

DEFINE Q(<QRDJ_PREF>.OSEGT.BUSINESS) qmgr(<QMGR_NAME>) QU(<QRDJ_

PREF>.OSEGT.BUSINESS)

DEFINE Q(<QRDJ_PREF>.OSEGT.C) qmgr(<QMGR_NAME>) QU(<QRDJ_PREF>.OSEGT.C)



DEFINE Q(<QRDJ_PREF>.OSEGT.D) qmgr(<QMGR_NAME>) QU(<QRDJ_PREF>.OSEGT.D)

DEFINE Q(<QRDJ_PREF>.OSEGT.DEFAULT) qmgr(<QMGR_NAME>) QU(<QRDJ_

PREF>.OSEGT.DEFAULT)

DEFINE Q(<QRDJ_PREF>.OSEGT.E) qmgr(<QMGR_NAME>) QU(<QRDJ_PREF>.OSEGT.E)

DEFINE Q(<QRDJ_PREF>.OSEGT.F) qmgr(<QMGR_NAME>) QU(<QRDJ_PREF>.OSEGT.F)

DEFINE Q(<QRDJ_PREF>.OSEGT.G) qmgr(<QMGR_NAME>) QU(<QRDJ_PREF>.OSEGT.G)

DEFINE Q(<QRDJ_PREF>.OSEGT.H) qmgr(<QMGR_NAME>) QU(<QRDJ_PREF>.OSEGT.H)

DEFINE Q(<QRDJ_PREF>.OSEGT.I) qmgr(<QMGR_NAME>) QU(<QRDJ_PREF>.OSEGT.I)

DEFINE Q(<QRDJ_PREF>.OSEGT.J) qmgr(<QMGR_NAME>) QU(<QRDJ_PREF>.OSEGT.J)

DEFINE Q(<QRDJ_PREF>.OSEGT_TRACE.AUDIT) qmgr(<QMGR_NAME>) QU(<QRDJ_

PREF>.OSEGT_TRACE.AUDIT)

DEFINE Q(<QRDJ_PREF>.RULE.COUNTER) qmgr(<QMGR_NAME>) QU(<QRDJ_

PREF>.RULE.COUNTER)

DEFINE Q(<QRDJ_PREF>.TRACE.AUDIT) qmgr(<QMGR_NAME>) QU(<QRDJ_

PREF>.TRACE.AUDIT)

DEFINE Q(<QRDJ_PREF>.TRANSFORMATION.COUNTER) qmgr(<QMGR_NAME>) QU(<QRDJ_

PREF>.TRANSFORMATION.COUNTER)

DEFINE Q(<QRDJ_PREF>.UNREADABLE.MESSAGE) qmgr(<QMGR_NAME>) QU(<QRDJ_

PREF>.UNREADABLE.MESSAGE)

END

Execute the JMSAdmin utilityTo execute the JMSAdmin utility:

1. Connect to the user administration MQSeries : mqm.

2. Run the command below using the previously created file.

<MQM_HOME>/java/bin> JMSAdmin < <HOME>/JMS.RE

5724-H72, 5655-L82, 5724-L26 (c) Copyright IBM Corp. 2002,2005. All

Rights Reserved.

Starting Websphere MQ classes for Java(tm) Message Service

Administration

InitCtx>

InitCtx>

InitCtx>

Etc …

Stopping Websphere MQ classes for Java(tm) Message Service

Administration

<MQM_HOME>/java/bin>



Check the generation of the JNDI file in the JNDI folderTo check the generation of the JNDI file, folow the example below.

<RDJ_EXEC>/script/JNDI-IBM> ll -a

total 208

drwxr-xr-x 2 mqm mqm 4096 Mar 18 16:22 .

drwxrwxrwx 14 mqm mqm 4096 Mar 18 16:12 ..

-rw-r--r-- 1 mqm mqm 90233 Mar 18 16:22 .bindings

rs37:/home/mqm/JNDI-RH>

Update the RuleEngine JMS runtime environmentYou must physically create the MQSeries objects that have been previously defined in the JMSAdmin.config file and establish the connection between JMS and MQSeries.

To update the runtime environment:

1. Create and start the MQSeries queue manager <QMGR_NAME>

2. Create the MQSeries objects

<RDJ_EXEC>/script>rdjadmmqs cre

==============================================================

==

R D J A D M

==============================================================

==

Setting Environment Variable for JMS Manager

Environment Variable GES set to : jms

Environment Variable COBOL_PROVIDER set to : microfocus

Environment Variable RDJ_HOME set to : <RDJ_HOME>

Environment Variable RDJ_EXEC set to : <RDJ_EXEC>

Environment Variable RDJ_LANG set to : english

Environment Variable QMGR_NAME set to : <QMGR_NAME>

Environment Variable QRDJ_PREF set to : <QRDJ_PREF>

Environment Variable MQ_BROKER set to : MQSERIES

Environment Variable MQ_URL set to : file:<RDJ_

EXEC>/script/jndi-IBM

Creation of queues associated to the manager XRDJ.TRUNK.SIMU

Creation of a local queue



5724-H72 (C) Copyright IBM Corp. 1994, 2005. ALL RIGHTS

RESERVED.

Démarrage de MQSC pour le gestionnaire de files d'attente

XRDJ.TRUNK.SIMU.

1 : DEFINE QLOCAL(<QRDJ_PREF>.IEVENT) REPLACE +

: DESCR('IEvent queue in entry of RDJ') +

: DEFPSIST(YES) +

: MAXDEPTH(9999999) +

: MAXMSGL(4194304) +

: NOSHARE +

: DEFSOPT(EXCL) +

: NOTRIGGER +

: USAGE(NORMAL)

AMQ8006: La file d'attente WebSphere MQ a été créée.

Une commande MQSC lue.

Aucune erreur de syntaxe dans les commandes.

Toutes les commandes MQSC correctes ont été traitées.



RESERVED.


XRDJ.TRUNK.SIMU.

1 : DEFINE QLOCAL(<QRDJ_PREF>.OSEGT.0) REPLACE +

: DESCR('OSegt queue in output 0 of RDJ') +

: DEFPSIST(YES) +

: MAXDEPTH(9999999) +

: MAXMSGL(4194304) +

: NOSHARE +

: DEFSOPT(EXCL) +

: NOTRIGGER +

: USAGE(NORMAL)

AMQ8006: La file d'attente WebSphere MQ a été créée.

Une commande MQSC lue.

Aucune erreur de syntaxe dans les commandes.

Toutes les commandes MQSC correctes ont été traitées.



RESERVED.


XRDJ.TRUNK.SIMU.

Etc …

3. Create the channel between JMS and MQSeries: <JMS_CHL>



<RDJ_EXEC>/script>runmqsc <QMGR_NAME>


RESERVED.


XRDJ.TRUNK.SIMU.

dis CHL(*) chltype(svrconn)

1 : dis CHL(*) chltype(svrconn)

AMQ8414: Affichage des détails relatifs au canal.

CHANNEL(SYSTEM.AUTO.SVRCONN) CHLTYPE(SVRCONN)

AMQ8414: Affichage des détails relatifs au canal.

CHANNEL(SYSTEM.DEF.SVRCONN) CHLTYPE(SVRCONN)

define CHL(<JMS_CHL>) chltype(SVRCONN) mcauser('mqm')

3 : define CHL(<JMS_CHL>) chltype(SVRCONN) mcauser('mqm')

AMQ8014: Le canal WebSphere MQ a été créé.

<RDJ_EXEC>/script>

4. Start the listener MQ in temporary mode: port <PORT> - default: 1415

lola(hareng):/home/hareng>runmqlsr -m <QMGR_NAME> -t TCP -p

1415&

[1] 19461

lola(hareng):/home/hareng>5724-H72 (C) Copyright IBM Corp.

1994, 2005. ALL RIGHTS RESERVED.

Check the monitoring: port 1415:

lola(hareng):/home/hareng>grep 1415 /etc/services

esg2_Integratorpool30 11415/tcp

bucxib2_integrator_tracer 51415/tcp

bucxib2_integrator_tracer 51415/tcp

lola(hareng):/home/hareng>netstat -a | grep 1415

tcp 0 0 *:1415 *:* LISTEN

lola(hareng):/home/hareng>

5. Edit the following variable in the rdjenv file located in the directory <RDJ_EXEC>/script :

MQ_BROKER: indicate MQSERIES instead of ActiveMQ (default delivery)

Test in the RuleEngine JMS runtime environment This environment is ready to run with the MQSeries message broker.



The machine hosting MQSeries is not necessarily the same as the one hosting Rule Engine.

To change the machine hosting MQSeries:

l Define the same MQSeries objects (Queue Manager, Prefixe, Channel, Port listener)

l Modify the JNDI file: Replace the value of <HOSTNAME> in the JNDI folder using one of the following methods:

o M1 not recommended: make this change directly in the generated file .bindings of the JNDI file.

o M2 standard: repeat the step of generating the JNDI file by modifying the JMS object creation file.

Main errors

Error code 8002

Console : ### classe com/axway/JMQCONN non trouvee ###

Rdjcleanjms.msg : UNABLE TO CONNECT TO THE LOCAL MANAGER

'XRDJ.TRUNK.SIMU': ERROR CODE 8002.

Cause : MQ_EXTDIRS does not contain all the files *.jar (wrapper + IBM)

Error code 9001



Cause : Wrong URL in jndi.properties / valeur de java.naming.provider.url

Error code 9002



Cause: URL Connection error / check information in JNDI QCF file (host,qmgr ..)

Example: Wrong host (sun30 instead of lola)


7 Standard reports

The contents of each report and the circumstances in which they are produced are described below. To activate / deactivate a report, set the relevant parameter for each type of report to YES / NO in the script.ges file.

UNIX/Windows Name

MVS Name

Description When Produced

transcnt.edi CNTTRA Transformation statistics

This file exists at all times, but may be empty

dettrans.edi DETTRA Transformation details


detano.edi DETANO Transformation anomalies


detredir.edi DETRED Redirected Input-Events


ieagrcnt.edi CNTAGI Input-Event aggregation counters

This report is only produced if the Aggregate Input-Events option is enabled

osagrcnt.edi CNTAGO Output-Event aggregation counters

This report is only produced if the Aggregate Output-Events option is enabled

accntlog.edi LOGACC Output-Event account log

This report is only produced if the Accounting processing option is enabled

Log_Compensation.edi

LOGCPS Compensation log This report is only produced if the Log compensation option is enabled

cptrg.edi CNTRUL

Input-Event processing summary by Rule


- DETAGI (*)

Input-Event aggregation details

This report is only produced if the Aggregate Input-Events option is enabled


7 Standard reports

UNIX/Windows Name

MVS Name

Description When Produced

accntagr.edi DETAGO Output-Event aggregation details

This report is only produced if the Output-Event aggregation option is enabled

(*): MVS only.

These reports are to be found in files with an .edi file extension in the edi directory (on UNIX and Windows machines). On an MVS machine, the files are produced by default in the EDILIB library.

These reports are produced in two stages:

l Rule Engine produces files containing the information that is to be printed

l The Report module reads these files and formats the reports

The Report module enables you to prepare and customize each report using a predefined template.

General appearanceAll reports have a common header with the same general layout.

The illustration below shows the information that you will find in this header:

Below this header you will see the tables of data for the report. Each report contains one or more tables of subject-specific data, as described in the remainder of this chapter.

StatisticsThis report lists the processing that was applied to the various types of Input-Event encountered during the session. In the script.ges file, set the parameter: PRINT_TRANSFORMATION_REPORT to YES to activate the TC1 Counters Report, or NO to deactivate it


7 Standard reports

It makes use of the ap.Transformation_Counter intermediate data file. The report provides statistics by:

l Input-Event type (counters TC2 and TC3)

l Input-Event and segment types (counters TC1 ,TC4, and TC5 when the group is rejected)

TC1 counters

Title: TC1 COUNTERS REPORTA new table is started on a change of value in the following set of variables:

l Group code: The group code for the current Input-Event

l Input-Event code: The type of the current Input-Event

l Input-Event version: The version number of the current Input-Event

Each table ends with a Total line, which gives the total for that table.

The table below shows the information contained in the columns of this table:

Column Name Meaning

Domain Name of the domain activated for this session

Phase Name of the phase activated in the session for this Input-Event type

Segment Name of the segment associated with the current Input-Event type

Rule Name of the rule applied to the segment named in the previous column

TR Rule type applied to the segment:

l 0: (Zero), a Enrichment-Rule was applied

l 1: A Transformation-Rule was applied

l 2: An audit rule was applied

Start Date and End Date

Start and end dates for the validity of the version of the rule

Output-Events Number of Output-Events generated, if a Transformation-Rule was applied

Anomalies Number of anomalies detected when a rule was applied

Rules Number of times the rule was applied to this segment type. This is the number of segments processed


7 Standard reports

TC2 counters


l Group code: The group code for the current Input-Event (providing Batch Management option is activated)

l Input-Event code:The type of the current Input-Event

l Input-Event version:The version number of the current Input-Event



Column Name Meaning

Input-Events Delivered

Number of Input-Events (as named in the report header) read (delivered) during the session

Input-Events Rejected

Number of Input-Events rejected during transformation in the session

Input-Events Redirected

Number of Input-Events redirected during the session

Input-Events modified

Number of Input-Events to which one or more Enrichment-Rules have been applied during the session

TC3 counters

Title: TC3 COUNTERS REPORTA new table is displayed for each set of :





The table below shows the information contained in the columns of this table.


7 Standard reports

Column Name Meaning

Input-Events Delivered

Number of Input-Events (as named in the report header) read (delivered) during the session

Input-Events Rejected

Number of Input-Events rejected during transformation in the session

Input-Events Redirected

Number of Input-Events redirected during the session

Input-Events Modified

Number of Input-Events to which one or more Enrichment-Rules have been applied during the session

TC4 counters







Column Name

Meaning

Segment Name of the segment type associated with the Input-Event that was processed in the session

Segments Delivered

Number of segments of the above type, delivered in the session, for the Input-Event type named in the report header

Segments Rejected

Number of segments of the above type that gave rise to a processing anomaly


7 Standard reports

TC5 counters







Column Name

Meaning

Segment Name of the segment type associated with the Input-Event that was processed in the session

Segments Rejected

Number of segments of the above type that gave rise to a processing anomaly of group

Transformation details

Title: TRANSFORMATION DETAILIn the script.ges file, set the parameter: PRINT_DETAIL_TRANSFORMATION to YES to activate the Transformation Detail Report, or NO to deactivate it.

This report details the content of Output-Events and modified segments produced by transforming each of the Input-Events delivered to the session. It uses the ap.Detail_Transformation intermediate data file.

This is an extensive report, which is normally used to tune the parameter settings. It is recommended that you deactivate it in production. This report can be empty if no Output-Event nor updated record is generated.

The report gives the following information for each segment of each Input-Event processed:

l Contents of the processed segment on page 145

l Properties and contents of the Output-Event produced on page 146

l Contents of the modified segment on page 146, if an Enrichment-Rule is applied.


7 Standard reports

Transformation detail – HeaderThe header for each of these three tables contains the following information

Label Meaning

Input-Event Code Name of the type of Input-Event processed

Input-Event Version Version number of the Input-Event type processed

Instance (optional value)

Instance code identifying the Input-Event processed

Group (optional value)

Code for the group to which the processed Input-Event belongs

Segment N° Sequence number of the segment within the Input-Event processed

Segment Status Status of the segment at the time that the Transformation-Rule is applied:

l Delivered:The contents of the segment have not been transformed by a Enrichment-Rule

l Modified:The contents of the segment have been transformed by a Enrichment-Rule

Segment Code Name of the type of segment processed

Domain Name of the active domain

Phase The name of the phase that was executed

Rule Code Name of the rule applied

Rule Version Start and end dates for the validity of the version of the rule that was applied

Contents of the processed segmentThis report displays the values of each of the fields that make up the processed segment. The table below lists these fields.

Column Name Meaning

Symbolic Field Name

Name of the field in the structure.


7 Standard reports

Column Name Meaning

Label Description of the field.

Field Value Value of the field in the current segment. This may be empty if the value has not been supplied.

Properties and contents of the Output-Event producedThis table is preceded by the sub-title: Output-Event(s) Produced by the Segment and contains the following information:

l Output-Event number: Order number of the Output-Event in the Transformation-Rule

l Financial-Case number:Order number of the Financial-Case in a Transformation-Rule

l Mapping Rule number:Order number for the Mapping Rule within the Output-Event in a Transformation-Rule

l Aggregation-Rule:Name of the Aggregation-Rule (if aggregation is activated and the Rule applied)

l Version:Dates delimiting the validity period in which the Rule is applicable

l Audit-Rule:Name of the Audit-Rule (if auditing is activated and the Rule applied)

Contents of the modified segmentThis table is preceded by the sub-title: Modified segment.

The contents of the modified segment are displayed in the report. The layout is the same as for the contents of the current segment, described above).

Transformation anomalies

Title: INPUT-EVENT ANOMALIES AND REJECTIONS REPORTThis report is produced automatically; you do not need to set any special parameters in the script.ges file.

This report lists the properties of each anomaly that was found during the session. It uses the ap.Detail_Anomaly_Reject_IEvent intermediate data file. This report may be empty if no anomalies were found during transformation.


7 Standard reports

The information is presented in the following blocks:

l General information

l The Input-Event identifiers

l The anomaly identifiers

l A description of the rule

l System identifiers

l The content of the segment

Certain blocks of information may be empty, depending on the type of anomaly found.

General informationThis information identifies the anomaly within the anomalies file:

Label Displayed

Meaning

Anomaly Number

Sequence number of the anomaly. Identifies the anomaly as the nth found in the session

Input-Event in Error

Sequence number of the Input-Event in error. Identifies the Input-Event as the nth found to be in anomaly in the session

Segment Sequence Number

Sequence number of the segment within the Input-Event. Identifies it as the nth segment in the processed Input-Event

Input-Event identifiersThis information identifies the Input-Event in anomaly:

Label Displayed Meaning

Group Code Code of the group to which the Input-Event belongs (optional information)


Input-Event Version The version number of the Input-Event processed

Input-Event Instance Code

Instance code of the Input-Event in anomaly (optional information)


7 Standard reports

Anomaly identifiersThis information allows a diagnosis of the problem with the Input-Event.

Display label Meaning

Anomaly Type The anomaly type may be one of the following:

l Rule: The execution of a rule was terminated by an anomaly

l Input-Event rejected: The Input-Event being processed was rejected

Generation Level The point at which the anomaly was detected:

l Principal:The anomaly found causes the Input-Event to be placed in anomaly (or rejected)

l Secondary: The anomaly described is caused by a principal anomaly or relates to an anomaly found earlier


7 Standard reports

Display label Meaning

Origin of rejection Reason the Input-Event was rejected (if the anomaly type is Input-Event rejected):

l Identification of Input-Events:The Input-Event type that was to be processed could not be identified

l Identification of the segment: One of the Input-Event segments could not be identified

l Input-Event check: A check that was applied to the Input-Event (through an exit) failed

l All phases in anomaly: The execution of each of the phases associated with the Input-Event type was terminated by an anomaly

l Balance at Input-Event level:The balance check at Input-Event level failed

l Output-Event check: An Output-Event check (through an exit) failed

l Segment audit: The application of an audit rule to a segment caused an anomaly

l Phase recycling: The Input-Event was recycled and the application of the phase is in anomaly

l Input-Event with no Output-Event:The transformation of the Input-Event produced no Output-Events and the IEvent_No_Output keyword is set to No

l Balance at group level: The balance check at group level failed

Error code The code of the error detected

Error and additional description

Description of the anomaly

Phase code Name of the phase in which the error occurred. Optional information

Domain code Name of the domain that was active when the anomaly occurred

Segment code Type of segment found to be in anomaly during processing


7 Standard reports

Description of the anomalyThis information identifies precisely the processing that was underway when the anomaly occurred. The information supplied varies with the type of processing:

Processing in anomaly

Information displayed

Enrichment-Rule Rule code (the name of the Enrichment-Rule that was applied)Rule version (the start and end dates that define the period of validity of the version of the rule)

Output-Event generation rule (Transformation-Rule) If Detection Level = Financial-Case

If Detection Level = Mapping Rule

Rule code, that is, the name of the Transformation-Rule that was appliedRule version, that is, the start and end dates that define the period of validity of the version of the ruleDetection level: execution Financial-Case or Mapping RulePriority code (identifies the execution priority level of the Financial-Case)Financial-Case code (the number of the Financial-Case)Financial-Case code (the number of the Financial-Case)Output-Event mapping order (the order in which it is created)Minimum Field Position (minimum position of the field in the structure)Output-Event segment structure code (name of the structure used by the Output-Event)

Segment audit Rule code (name of the audit rule applied to the Output-Event)Rule version, (the start and end dates that define the period of validity of the version of the rule)

Segment aggregation Rule code (name of the aggregation rule applied to the segment)Rule version, (the start and end dates that define the period of validity of the version of the rule)

Output-Event audit Rule code (name of the audit rule applied to the Output-Event)Rule version, that is, the start and end dates that define the period of validity of the version of the ruleInformation on the Transformation-Rule that generated the Output-Event: name, rule version, Financial-Case number, Mapping Rule order, Output-Event structure


7 Standard reports

Processing in anomaly

Information displayed

Output-Event Aggregation

Rule code (name of the aggregation rule applied to the Output-Event)Rule version, that is, the start and end dates that define the period of validity of the version of the ruleInformation on the Transformation-Rule that generated the Output-Event: name, rule version, Financial-Case number, Mapping Rule order, Output-Event structure

Balancing check on Output-Events (at rule level)

Rule code (name of the balancing rule applied to the Output-Events)Rule version (start and end dates that define the period of validity of the version of the rule)Information on the Transformation-Rule that generated the Output-Events: name, rule version, Financial-Case number, Mapping Rule order, Output-Event structure

Enrichment of the Output-Event by an exit

Information on the Transformation-Rule that generated the Output-Event: name, rule version, Financial-Case number, Mapping Rule order, Output-Event structure

Accounting check on an Output-Event

Rule code (name of the Transformation-Rule that was applied)

Rule without an Output-Event

Rule version (start and end dates that define the period of validity of the version of the rule)

System identifiersThis is the diagnostic information that the Axway support staff will require, if you need support.

Contents of the segmentThis information is not displayed if the Input-Event or segment cannot be identified. Instead, the following message is displayed: The segment format is unknown.

The report displays the values of each of the fields that make up the processed segment. The table below lists these fields:

Column Name Meaning

Field code Name of the field in the structure

Field label Description of the field in the structure


7 Standard reports

Column Name Meaning

Field position Position of the field in the structure

Field length Length of the field in the structure

Field data type Internal data type of the field in the structure

Field Value Value of the field in the current segmentThis may be empty if the value has not been supplied

Caution This report does not display the results of the Pre-calculations in the Transformation-Rules.

The fields are displayed in alphabetical order. On MVS you can display the information in the order in which the fields are defined in the structure, by replacing the EDDETANO printing step with the following lines:

//RGCLCR DD DSN=SOP$TEST.SHRRDJ.XRDJ11.DATFVS.RGCLCR.CLST,DISP=SHR//DESCEE DD DSN=SOP$TEST.SHRRDJ.XRDJ11.DATFVS.DESCEE.CLST,DISP=SHR

By:

//RGCLCR DD

DSN=SOP$TEST.SHRRDJ.XRDJ11.DATFAX.RGCLCR.AIX.PATH,DISP=SHR//DESCEE

DD DSN=SOP$TEST.SHRRDJ.XRDJ11.DATFAX.DESCEE.AIX.PATH,DISP=SHR

Note The prefix « SOP$TEST.SHRRDJ.XRDJ11 » is specific to the Axway environment.

Redirection of Input-Events

Title: INPUT-EVENT REDIRECTION REPORTIn the script.ges file, set the parameter: PRINT_REDIRECTION_IEvent to YES to activate the Input-event Redirection Report, or NO to deactivate it.

It lists the properties of the redirection events, broken down by Input-Event type. It uses the ap.Detail_Redirected_IEvent intermediate data file.

A new table is started on a change in the value of the Input-Event group code.



7 Standard reports

Column Name

Meaning

Input-Event

Name of the type of Input-Event that was redirected in this session, within the current group type

Version Version number of the type of Input-Event that was redirected in this session, within the current group type

Instance Instance code of the redirected Input-Event

Domain Name of the domain that triggered the redirection

Output Name of the output to which the Input-Event was redirectedThis output is found in script.ges under IEvent_Redirected (Processing-Context-Out)

Input-Event aggregation counters – File specificThis report sets out the results of the aggregation applied to the Input-Events in the session. It uses the ap.IEvent_Aggregation_Counter intermediate data file.

In the script.ges file, set the parameter Print_Report_Aggregation_IEVENT to YES to activate the Input-Event Aggregation Counters Report, or NO to deactivate it.

It uses the ap.IEvent_Aggregation_Counter intermediate data file. The report provides aggregation statistics by:

l Input-Event type

l Segment type for each Input-Event

This report is only produced if the Aggregate Input-Events option is enabled.

Aggregation counters by Input-Event

Title: Input-Event Aggregation Counters ReportA new table is started on a change in the value of the group code.




7 Standard reports

Column Name Meaning


Input-Event Version The version number of the Input-Event processed

Read Number of this type of Input-Event read during the session

Rejected Number of this type of Input-Event rejected during the session

Result Number of Input-Events resulting from the aggregation

Aggregation Counters by Segment

Title: Segment Aggregation Counters ReportA new table with the following set of variables is generated for each separate element in the group:

l Group code:The group code for the current Input-Event

l Input-Event code:The type of the current Input-Event




Column Name Meaning

Segment code Name of the type of Input-Event segment processed

Rule Code Name of the aggregation rule applied to the segment. Optional information

Rule Start and Finish


Read Number of segments read for this type of Input-Event

Rejected Number of segments rejected for this type of Input-Event

Result Number of segments resulting from aggregation for this type of Input-Event


7 Standard reports

Output-Event aggregation counters – File specific

This report sets out the results of the aggregation applied to the Output-Events in the session. It uses the ap.OSegt_Aggregation_Counter intermediate data file.

In the script.ges file, set the parameter: Print_Report_Aggregation_OSegt to YES to activate the Output-Event Aggregation Counters Report, or NO to deactivate it.

The report provides aggregation statistics broken down by Processing-Context-Out. It is only produced if the option to aggregate Output-Events is enabled.

Title: Output-Event Aggregation Counters Report A new table is generated for each separate element in the group (optional information).



Column Name Meaning

Output Name of the output associated with the Output-Events processed

Rule Code Name of the aggregation rule applied to the Output-Events. Optional information

Rule Start and Finish


Read Number of Output-Events read

Result Number of Output-Events resultialso ng from the aggregation

Account LogThis report concerns the:

l Logical journal: accntlog_log.edi (LOGACCL on MVS) ;

l Physical journal: accntlog_phy.edi (LOGACCP on MVS).

This report provides information on the accounting-type Output-Events produced during the session. It uses the ap.Log_Account intermediate data file.

In the script.ges file, set the parameter PRINT_LOG_ACCOUNT to YES to activate the Accounting Log Report, or NO to deactivate it.


7 Standard reports

This report is only produced if the Accounting processing option is enabled.

Note The account log processes also the compensation Output-Events.

Title: Account LOG reportThe information is laid out in a header and a detail list.

Account Log - HeaderThe header provides the following information:

Heading Meaning

GROUP CODE Code for the group processedThis is displayed if the Group Management option is enabled

INSTANCE CODE Code for the instance of the Input-Event. The field may be empty

Account Log - Detail linesMeaning Meaning

OUTPUT-EVENT Number of the Output-Event produced

ACCOUNTING REFERENCES Values of the account references extracted from the Output-EventThe values are separated by semi-colons (;)

ACCOUNT Account number

TOTAL DEBITS Total debits (if any)

TOTAL CREDITS Total credits (if any)

Compensation LogThis report concerns the compensation journal: Log_Compensation.edi (EDLOGCPS/EDI on MVS).

This report provides information on the compensation Output-Events produced during the session. It uses the ap.Log_Compensation intermediate data file.

To activate / deactivate the Compensation Log Report, set the parameter: PRINT_ LOG_COMPENSATION to YES / NO in the script.ges file.

This report is only produced if the Accounting processing and Compensation options are enabled.


7 Standard reports

Title: Compensation LOG reportThe information is laid out in a header and a detail list.

Compensation Log - HeaderThe header provides the following information:

Heading Meaning

GROUP CODE Code for the group processedThis is displayed if the Group Management option is enabled

INSTANCE CODE Code for the instance of the Input-Event. The field can be empty

PROCESSING-CONTEXT-OUT

Subtotal of debits calculated from the beginning of the Input-Event

Compensation Log - Detail linesHeading Meaning

OUTPUT-EVENT Output-Event code or number:C1 – compensation at rule levelC2 – compensation at Input-Event levelC3 – compensation at group level

DEBIT AMOUNT Debit amount for the Output-Event

CREDIT AMOUNT Credit amount for the Output-Event

ACCOUNTING REFERENCES Values of the account references extracted from the Output-EventThe values are separated by semi-colons (;)

ACCOUNT Account number

TOTAL DEBITS Total debits (if any)

TOTAL CREDITS Total credits (if any)


7 Standard reports

Counter summaryThis report summarizes the Input-Event processing performed during the session. It provides transformation statistics by:

l Input-Event type

l Input-Event segment

It uses the ap.Rule_Counter intermediate data file.

To activate / deactivate the Counter Summary by Rule Report, set the parameter: PRINT _REPORT_RULE_COUNTER to YES / NO in the script.ges file.

Title: COUNTER SUMMARY BY RULE REPORT

All the information is summarized in a single table, presented in columns as described below:

Column Name Meaning

Input-Event Name of the type of Input-Event that was redirected in this session, within the current group type

SegmentRuleRule Start and FinishReadValidRejectedOutput-Event

Name of the segment belonging to the given Input-EventName of the Rule applied to the above segment Start and end validity dates for the rule appliedNumber of segments read during the sessionNumber of valid segments during the sessionNumber of segments rejected during the sessionNumber of Output-Events generated, if the Rule in question is a Transformation-Rule

The table ends with a Total line, which gives the cumulative number of counters for the entire table.

Where the processing occurs without any rejections, the report only shows the Transformation- or Enrichment-Rules. Where rejections occur, the other Rules (Aggregation, Audit and Balancing) are also included in the counters.

Where the cause of the rejection cannot be identified, Rule Engine displays the value “*****” instead of the name of the Rule.

Input-Event aggregation detailed reportThis report summarizes the results of aggregation applied to Input-Events during the session. It uses the DETAGI intermediate data file.

In the script.ges file, set the parameter Print_Detail_Agreg_Ievent to YES to activate the Input-event Redirection Report, or NO to deactivate it.

The report provides the following details of the aggregation process:


7 Standard reports

l Input-Event Aggregation-Rule

l Input-Event type

This report is only produced if Input-Event Aggregation is activated.

Title: INPUT-EVENT AGGREGATION DETAIL REPORT A new table is generated for each separate element in the group and comprises the following details:

l TYPE AGREG CRE: 2 possible values:

l EXTRACRE: aggregation extra-CRE

l INTRACRE: aggregation intra-CRE (refer toInput-Event aggregation counters – File specific on page 153)

l CODE REGLE: Code for the Aggregation-Rule applied

l VERSION: Validity period for the Aggregation-Rule applied.

l CRITERES D’AGREGATION:Aggregation criteria


The information contained in the columns of this table is set out as follows:

Column Name Meaning

Input-Event identifier Input-Event name

Amount1 Amount, numbered 1, read from the Input-Event





Decimal points

You can display the amounts in decimal format by indicating the number of decimal points required (from 0 to 9) in the PARM zone in the REPORT module.

Output-Event aggregation detailed reportThis report summarizes the results of the aggregation process applied to Output-Events during the session. It uses the ap.Accounting_Aggregation intermediate data file.

In the script.ges file, set the parameter Detail_Osegt_Aggregated to YES to activate the Output-Event Aggregation Report, or NO to deactivate it.


7 Standard reports

It provides the following details of the aggregation process:

l Account

l Direction code

l Sign

l Aggregation criteria

This report is only produced if the Output-Event aggregation option is enabled.

It is activated for a given Processing-Context-Out which has the following two options applied:

l Rule aggregation on the amounts to aggregate

l Valid accounting checks for :

l Account

l Amount

l Direction

l Sign

Title: OUTPUT-EVENT AGGREGATION DETAIL REPORTA new table with the following details is generated for each separate Output-Event the in group:

l Account: Account number

l Direction: Direction code

l Sign: Sign for the amount

l Aggregationcriteria

The last line of each table presents the cumulative total of all the amounts in the body of the table.

The information contained in the columns of this table is set out as follows:

Column Meaning

REFERENCE Output-Event reference read

CREDIT Amount read from an individual Output-Event with a credit direction code

DEBIT Amount read from an individual Output-Event with a debit direction code

TOTAL Total and direction code of the aggregated Output-Event

NUMBER Number of Output-Events included in the aggregation

The report only displays a single debit or credit total.


7 Standard reports

Reformatting using exitsYou can use the ITR615 exit to reformat lines in the report as follows:

1. Process type 5 in this exit enables you to reformat the 62-character zone LLLIGNE starting from position 47.

2. Display the amounts in decimal format by indicating the number of decimal points required (from 0 to 9) in the zone LLNBDECIM.The decimal separator is a comma (,). By default the value is fixed at zero (no decimal places).

Activate exit ITR615 in the script file when you launch the report using the following syntax: Detail_Osegt_Aggregated = OUI[exit615].


8 BIRT reports

The BIRT (or Business Intelligence and Reporting Tools) reporting tool is an open source reporting system for Web applications that is integrated into Eclipse.

It is used in the Manager to:

l Standardize the reports creation mode.

l Make user modifications easier.

l Select different file formats (PDF, Word, HTML, Excel ...).

l Take into account multi-encoding (Latin, UTF-16).

Runtime prerequisites:

l BIRT 2.6.1

l Java 1.6

BIRT processThe BIRT reporting tool includes two elements:

l A design tool (Report Designer) to create the report from one or more data sources.

l A runtime (Report Engine) to generate the printed reports from the configuration file.

The new tool does not affect the existing reporting modes but is integrated in the product as an additional reporting mode. Reporting is activated or not depending on specific options that you specify in the reporttool.properties script file.

Reports are generated in 3 steps:

l The Rule Engine produces the intermediate files.

l The reporttool utility creates intermediate files that are compatible with BIRT.

l The BIRT tool takes the data into account and formats the reports according to the report description file (.rptdesign).

The reports are stored in the .edi file as suffixed files depending on the selected format.


8 BIRT reports

Report names and activation conditionsBIRT Report Name Description When Produced

TransformationCounter Transformation statistics At all times, but can be empty

DetailTransformation Transformation details At all times, but can be empty

DetailAnomaly Transformation anomalies At all times, but can be empty

IEventRedirections Redirected Input-Events At all times, but can be empty

IEventAggregationCounter Input-Event aggregation counters

If the Aggregate Input-Events option is enabled

OSegtAggregationCounter Output-Event aggregation counters

If the Aggregate Output-Events option is enabled

LogAccount Output-Event account log If the Accounting processing option is enabled

RuleCounter Input-Event processing summary by Rule

At all times, but can be empty

AccountingAggregation Output-Event aggregation details

If the Output-Event aggregation option is enabled

BIRT directoriesIn the Rule Engine environment, BIRT uses the following directory tree structure:

<RDJ_HOME>

tools/utl/lib reporttool directories (jar)

<RDJ_EXEC>

script reporttool.cmd and rdjexp shells (including BIRT calls)

dat Input files (CSV) used in the datasets


8 BIRT reports

utl reporttool.properties parameter filerptdesign report description files

edi Product reports

Additional environment variables are defined in the reporttool.cmd file in the .script directory.

Define the report propertiesThe report properties are located in the reporttool.properties file.

Item Property Description

BIRT environment birt.engine.dir Directory for the BIRT Runtime ReportEngine

Report environment

report.encoding Input file encoding mode:

l ISO-8859-1

l UTF-8

l UTF-16LE

l UTF-16BE

report.language Language used in the reports

report.resource.home Resource file directory including:resource.propertie

s

aiStyles.rptlibrar

yAxwayLogo.gif

report.tmp.dir Temporary working directory

report.data.dir CSV input file

report.result.dir Directory that contains the PDF results file


8 BIRT reports


report.format.default Report default formats:

l pdf

l html

l xls

l doc

l ps

l ppt

script.file Path to the script.fic file

Report activation (0/1: deactivate/activate)

report.activated.AccountingAggregation AccountingAggregation report

report.activated.DetailAnomaly DetailAnomaly report

report.activated.DetailIeventAggregation DetailIeventAggregation report

report.activated.DetailTransformation DetailTransformation report

report.activated.IEventAggregationCounter

IEventAggregationCounter report

report.activated.IEventRedirections IEventRedirections report

report.activated.LogAccount LogAccount report

report.activated.OSegtAggregationCounter

OSegtAggregationCounter report

report.activated.PhyAccount PhyAccount report

report.activated.RuleCounter RuleCounter report

report.activated.TransformationCounter TransformationCounter report


8 BIRT reports


Data source list report.data.source.N Where N = 1, 2, 3, …The Data Source parameter includes 2 attributes separated by a comma:DataSourceName – Data source name in the rtdesign fileDataSourceHome– Root directory of the datasource

Image list report.image.url.N Where N = 1, 2, 3…:The image parameter includes 2 attributes separated by a comma:NomImage – Image name in the rtdesign fileURLImage – URL of the image

Parameter list report.parameter.N Where N = 1, 2, 3…The parameter includes 2 attributes separated by a comma:NomParam – Parameter name in the rtdesign fileValeurParam – Parameter value in the rtdesign file

Report modification prerequisitesBefore you start, it is highly recommended that you have background knowledge of the basic BIRT functionalities and that you use the following actions with caution. For more details, refer to the BIRT User documentation or the BIRT online documentation.

Make a backup copy of the initial files so that if there are any problems, you can roll back to the previous state.

Reorganize the data displayEach report is described in a file with a rptdesign file name extension (for example: DetailAnomaly.rptdesign).The file is located in the “.tools” directory.


8 BIRT reports

1. Log in the BIRT interface.

2. Select File > File Open.

3. Modify and visualize the report.

4. Click Save.

Use stylesAll reports use the same styles that are centralized in the aiStyles.rptLibrary directory. Consequently you can modify the report styles once and for all.

You define style use as follows.

Use imagesYou can integrate as many images as you wish in the reports. The report tool enables you to define the path to the image file via the report.image.url.N parameter in the reporttool.properties. When you generate a report, the logo defined in the header is called Logo. By default, it is the Axway logo.

To replace an image by another, you change the path to the image file in the report.image.url.N parameter. When you generate the report, the report tool integrates the new image.


8 BIRT reports

Define report labelsYou define the report labels in the file resource.properties file and thus can easily localize them. Each language corresponds to a specific properties file:

l resource_fr.properties: French resource file

l resource_en.properties: English resource file

If necessary, you can update these files via any editor but with a restriction. You are not allowed to modify the keywords in the left panel.


9 Implement the Rule Engine using permanent files

This section describes how to set up the implementation of the product via permanents files and tables.

l Overview on page 169

l Script.ges: Syntax and commands on page 169

l Optional table updates on page 173

OverviewThe implementation parameter settings are held in the following sets of files:

l Files updated automatically through transfers from AI Enabler

l Script files that describe the production configuration.

Update the latter set of files to match your production environment. These files are:

l script.ges:Implementation script

l mvt.mvt: Rules configurations, Tables and Variables resulting from the exchange

l sys.dat: Functional context generated by the sender

l usr.dat: Transformation-Domains resulting from the exchange

Script.ges: Syntax and commands

SyntaxYou set the parameters by assigning values to keywords. These keywords are divided into sections.

For example:

>Configuration<

DEFINE DAT = "<RDJ_EXEC>/dat"

#--------------------------------------

# Session configuration



SESSION = RDJ_INSTALLATION

# Date undefined : default value = current date

DATE_OPERATION = 22/03/1996

# Identifier stamping (with Auditing choice actived)

STAMPER = COMPOSTEUR1

#----------------------------------------

# Repository definition

REPOSITORY = "<DAT>/ref.dat"

Environment_Transformation = Batch

Turnoff_Group = No

Turnoff_Exit_IEvent = No

Turnoff_Exit_ISegt = No

Turnoff_Exit_Rule = No

Turnoff_Exit_OSegt = No

Rules to follow:

Rule Meaning

1 Each section name is enclosed in less than (>) and greater than (<) symbols: >Section_Name<

2 Keywords belonging to one section cannot be associated with another section

3 You must not change the names used for keywords and sections

4 Assign values to each keyword that you use as follows: keyword_name = "keyword_value"

5 Assign values to options as follows: option_keyword = Yes (or No)The spaces between a keyword and its value are ignored

6 Spaces between a keyword and its value are ignored

7 You can comment out an unused keyword by placing a hash (#) sign in front of it. The default value of the keyword is then usedFor example:>Configuration<#--------------------------------------# Configuration of stepsStep= IPO# I_Exit_Restructuring_IEvent= No



Rule Meaning

8 The keywords are not case sensitive. For example, step is the same keyword as Step or STEP

9 The values that you assign to keyword (between quotes) ARE case sensitive and are applied exactly as you enter them. For example, hello, Hello and HELLO are three different values

Script commandsCommands Purpose

Define Defines variablesThe variables are local to the transformation or extraction run

Include Includes another script in the current one

Display Displays a comment during execution

Define variables in the >Script.ges< sectionYou can use the variables as follows:

l In the script, to avoid repeating a directory name that is common to more than one exchange zone

l In the Transformation-Rules (variables with different initialization periods)

Define Variable_Name = "Variable_Value"

l Variable_Name: Specifies the name of the variable

l Variable_Value: Specifies the value of the variable at the start of the session

Rules to follow:

Rule Meaning

1 You can define more than one variable. Just include a line for each variable, each with a different variable name

2 The value of the variable must be enclosed in double quotes ("value")

3 A variable that you use in the script is subsequently referenced as follows: <Variable_Name>



Important Variables:

Variable Name Use

THIS_FILE

Defined automatically Indicates the current script

THIS_LINE

Defined automatically Indicates the current line number in the script

REF Frequently used. Sometimes indicates a referenceIf this variable is not defined in the script, the value of the REF environment variable is used on a UNIX or NT machine

Include a script file into the >Script.ges< sectionInserting a script file allows you to use values already defined in another file.

Include "File_Name" ,"Section_Name"

l File_Name:Specifies the name of the file containing the keywords that are to be included

l Section_Name:Optional parameter. Indicates the name of the section to be included If this parameter is not supplied, the system looks for the >Script< section in the file

Rules to follow:

Rule Meaning

1 The file that is to be included may itself contain an inclusion from a third file. This inclusion is not copied into the target file if it already exists there. An example would be a common section that is defined for all sessions

2 You can embed up to 50 inclusions

3 Only one section is analyzed each time a file is opened

Display a commentThis command displays a comment when it is executed.

Display "Comment_text"

Where Comment_text is the comment that is displayed when this command is executed.



Optional table updatesThe purpose of this function is to help you to update tables that are large (several thousands of lines) and updated frequently (daily, for example). To do this, you can use the direct update available in Rule Engine.

This function must be used for tables for which you have set the Rule Engine option entries handled by Rule Engine.

The procedure is:

1. Export the table structure from AI Enabler to Rule Engine. Update Rule Engine by running the RDJMAJ from the files produced during the exchange.

2. On successful completion of the first step, create an update file in Rule Engine containing the data values to be updated.

3. Update the parameter settings by running the RDJMAJ procedure with the update file.

Create an update fileThe update file must be saved in:

l $RDJ_EXEC/dat directory for UNIX

l %RDJ_EXEC%\dat directory for Windows

l <RDJ_EXEC>.DATLIB.MVTRDJ for MVS

It must be called mvt.mvt (UNIX and Windows) or mvtmaj (MVS).

You cannot add entries to an existing internal table (partial update). The only possible action is to replace the table (complete update).

The update file contains the description of the user table (table name, argument characteristics and associated value) as well as a list of entries (argument/value pair) that the table will include.

This file comprises two table header lines (command delete and create table) and a set of lines that represent each table entry (argument/value pair). The line length is limited to 105 characters.

Axway Rule Engine enables you to manage entries that have:

l arguments up to 128 characters long

l associated values up to 256 characters long

However, it is also possible to manage arguments limited to 17 characters to enable processing of RDJ V8 internal tables.

Syntax of mvt.mvt fileThe mvt.mvt is a sequential file composed of two sections:



l Header: This is a two-line description of the table, that is, the table name and characteristics of the argument and value

l Set of lines where each line represents a table entry within this table, that is, an argument/ value pair

The length of each of these lines is limited to 105 characters.

Rule Engine can handle arguments of up to 128 characters long with associated values of up to 256 characters. However to ensure compatibility with RDJ V8 tables, Rule Engine has a special procedure for handling arguments limited to 17 characters. The following sections describe the syntax of the headers and table entry lines in tables with arguments limited to 17 characters and those with arguments exceeding 17 characters.

Header syntax: Tables with arguments limited to 17 charactersThe illustration below shows the required syntax for the header. The TAB header code at the beginning of the line indicates that this is an update to an internal table whose argument does not exceed 17 characters.

Specifying header fieldsNote The fields must be in the position shown in the illustration to be read correctly by the

parameter update procedure. Fill unused fields with blanks to maintain the correct positioning of the subsequent fields. You must supply values for all fields.

The table below explains how to specify each field in the header.

Field Position Length Value

Table name

4 8 Name of the table that you want to update




Update code

36 1 Type of update:

0:

If the line contains:

l The table name, header code and update code, 0 corresponds to a request to delete the entire table.

l All elements, 0 represents a request to delete the argument and value of the table entry indicated on that line.

1: Requests the creation of an internal table2: Requests the modification of an internal tableSPACE(char.): Automatically handled by the update program

Fast access code

39 1 Fast access mode loads the corresponding table entry into memory during the initialization of the Input-Event Transformation Phase:

Y: Activates fast accessN: Disables fast access

BLANK: If you do not specify a code, Rule Engine applies the default value, that is, Y.

Argument class

40 1 Data class of the table entry argument to search for:

l N: Numeric

l D: Date

l A: Alphanumeric

Argument length

41 2 Length of the table entry argument to search for (two numeric characters depending on the data class):

l Between 01 and 17 for Numeric and Alphanumeric

l Either 06 or 07 for Date




Value class

43 1 Data class of the table entry value to search for:

l N: Numeric

l D: Date

l A: AlphanumericNote: You can only change the characteristics of the table if it does not contain any table entries already.

Value length

44 3 Value length: Three numeric characters between 001 and 256.Note: You can only change the characteristics of the table if it does not contain any table entries already.

Table header label

47 30 Table header label: Between 1-30 alphanumeric characters.

Table check

77 1 Set the code :

l Y: to activate the check on the existence of the Table

l N: to deactivate the check on the existence of the Table

l BLANK: default value

Header syntax: Tables with arguments exceeding 17 charactersThe illustration below shows the required syntax for the header. The TBL header code at the beginning of the line indicates that this is an update to an internal table whose argument is between 18 and 128 characters.

The table below explains how to specify each field in the header.


Table name

4 8 Name of the table that you want to update




Update code

36 1 Type of update:

0:

If the line contains:

n The table name, header code and update code, 0 corresponds to a request to delete the entire table.

n All elements, 0 represents a request to delete the argument and value of the table entry indicated on that line.

1: Requests the creation of an internal table2: Requests the modification of an internal tableSPACE(char.): Automatically handled by the update program

Fast access code




Argument class

40 1 Data class of the table entry argument to search for:

l N: Numeric

l D: Date

l A: Alphanumeric

Argument length

41 3 Length of the table entry argument to search for: three numeric characters between 018 and 128

Value class

44 1 Data class of the table entry value to search for:

l N: Numeric

l D: Date

l A: AlphanumericNote: You can only change the characteristics of the table if it does not contain any table entries already.




Value length

45 3 Value length: three numeric characters between 001 and 256.Note: You can only change the characteristics of the table if it does not contain any table entries already.

Table header label

48 30 Table header label: between 1-30 alphanumeric characters.

Table Check

78 1 Set the code as follows:

l Y: Activates ExistenceTable check

l N: Disables ExistenceTable checkBLANK: If you do not specify a code

Table entry syntax: Tables with arguments limited to 17 charactersThe illustration below shows the required syntax for each table entry. The TAB header code at the beginning of the line indicates that this is an update to an internal table whose argument does not exceed 17 characters.

Specifying table entry fieldsNote The fields must be in the position shown in the illustration to be read correctly by the


The table below explains how to specify each field in the table entry.


Argument 12 Search argument whose characteristics you have specified in the header.

Expiry date 29 7 Date at which the table entry value ceases to be validExpress this date in the format CYYMMDD




Update code 36 1 Type of update whose characteristics you specified in the header

Suffix 37 2 Line identifier for a table entry. This means you can express the value of a table entry in four separate lines, each of 64 characters, making a total of 256 characters. Set the suffix as either of the following, depending on which of the four lines contains the description of the table entry:

l P1

l P2

l P3

l P4

Fast access code




Table entry value and associated comments

40 64 Table entry value: Set the value of the table entry that corresponds to the argument.The characteristics of the table entry value are set in the header.Comments: To include any comments, you must prefix them with an exclamation mark (!) to distinguish them from the table entry value. You can define an alternative character to use as a comment marker during the Rule Engine installation procedure.The start position of the comment cannot be less than the length of the value +one character.



Table entry syntax: Tables with arguments exceeding 17 charactersThe illustration below shows the required syntax for each table entry. The TBL header code at the beginning of the line indicates that this is an update to an internal table whose argument is between 18 and 128 characters.

Specify table entry fieldsNote The fields must be in the position shown in the illustration to be read correctly by the


The table below explains how to specify each field in the table entry.


Argument 12 Search argument represented by an incremential index that delimits the different arguments.

Expiry date 29 7 Date at which the table entry value ceases to be validExpress this date in the format CYYMMDD

Update code 36 1 Type of update whose characteristics you specified in the header

Suffix 37 2 Line number that corresponds to one of the following elements:

l Table argument: suffix A1 or A2

l Value of table entry: suffix P1, P2, P3 or P4




Fast access code 39 1 Fast access mode loads the corresponding table entry into memory during the initialization of the Input-Event Transformation Phase:



Table entry value and associated comments

40 64 Table entry value: Set the value of the table entry that corresponds to the argument.The characteristics of the table entry value are set in the header.Comments: To include any comments, you must prefix them with an exclamation mark (!) to distinguish them from the table entry value. You can define an alternative character to use as a comment marker during the Rule Engine installation procedure.The start position of the comment cannot be less than the length of the value +one character.

Refer to the table entry syntax table for explanations of how to specify each field in the table entry. For more information, refer to Section Table entry syntax: Tables with arguments limited to 17 characters on page 178.

Sample definition This example updates the AGT_BAFI table, which has an argument of 6 alphanumeric characters and a value of 89 alphanumeric characters:

l By adding a BAMMCD argument

l By changing the DTMM05 argumentTo do this, the entry is first deleted and the new value then added.

And this is an example of a table with an argument that exceeds 17 characters.



Specifying a VALDEF default value for tables with an argument limited to 17 characters:

Specifying a VALDEF default value for tables with an argument that exceeds 17 characters:

Execute procedure rdjmajThe results of running rdjmaj are made available in a number of reports.

The reports on anomalies found during update of the parameter settings are stored in the edi directory (under UNIX or NT) and in files with the .EDI extension (under MVS).

The following reports are available:

l Report on the content of the update file: listmvt.edi

l Report on anomalies found in the update file, to allow diagnosis of problems: errmvt.edi, ano400.edi ,errtra.edi

Report on the update of the parameter settings: iexplmaj.edi.


10 Appendices

These appendices describe the the files required by the Rule Engine as well as the sender’s functional context.

UTF-16 implementation details Accounting Integrator uses the UTF-16 plane 0 in where each character is stored on 2 bytes. In this storage mode, you:

l Can encode on a single byte a great number of unrecognized characters

l Cannot encode graphical characters that are defined on 4 bytes.

AI Enabler characteristicsBefore you can process your UTF-16 data in the Rule Engine, you must set the configuration parameters of your UTF-16 Server in the AI Enabler.

You define the encoding attributes in the Folder description and enter the configuration parameters in the Finance objects. You can enter UTF-16 data in the arguments of user tables as well as in the associated values.

As soon as your configuration is validated, it is deployed on the Rule Engine(s) in disconnected mode.

For more information on parameter settings and compatibility rules, refer to the AI Enabler online documentation.

RestrictionsYou are not allowed to:

l Enter UTF-16 characters in objects identifiers. They can only contain ASCII characters.

l Use UTF-16 characters to create a mapping expression. You can, however, enter your UTF-16 expression in the Initial value of a Variable then use this Variable in your mapping expression (the maximum number of objects for this type is increased to 5000).

l Use packed data in UTF-16 Folders.

l Enter more than 110 characters (220 bytes) in the argument of a user table entry.


10 Appendices

Rule EngineIn the Rule Engine, the following files are in UTF-16 format:

l Configuration files forwarded to the Rule Engine (ctx.mvt and mvt.mvt files).

l Session input files, including the script. fic file.

Restriction: In MVS, the rdjenv file remains in EBCDIC format; in Windows or UNIX, environmment variables are in ASCII format.

l Component files (Output-Events, anomalies, reports)

Exits and external calls have been adapted to process UTF-16 data.

RestrictionsYou can only use TABLEL table files.

The Turbo version is not available in this mode.

TerminologyThe requirement for structure compatibility is mentioned in several chapters in this documentation. Two or more structures are said to be compatible when the major fields in these structures share a common definition. That is, when the internal position, length and data types of the structures are identical.

Required files for the Rule EngineRule Engine looks for its parameter settings in a set of files created at installation time and updated by the automatic extraction transfer procedures. These files are to be found in the dat directory (or library).

Note Note:Their names are fixed. They cannot be deleted or moved.

List of files:

Windows / UNIX MVS

aig.fmt DETANO

cptagrc.fmt CNTAGI

cptagrm.fmt CNTAGO

detme.fmt DETTRA


10 Appendices

Windows / UNIX MVS

cpttrad.fmt CNTTRA

etatcpt_log.fmt LOGACL

etatcpt_phy.fmt LOGACP

Log_Compensation.fmt LOGCPS

AgrCompt.fmt DETAGO

AgrCre.fmt DETAGI

cptrg.fmt CNTRUL

desc.mvt Not used

defvar DEFVAR

descee DESCEE

ferreur ERREUR

lexploit LIBXPL

mapcre MAPCRE

param PARAME.SYS

ref.dat REFEXP

rgclcr RGCLCR

rgclin RGCLIN

rgclee RGCLEE

rgtr RGTRDN or RGTRDT (MVS only)

rgtrin RGTRIN

script.fic SCRIPT

script.mqs SCRIPT

script.jms Not used

script.ora Not used


10 Appendices

Windows / UNIX MVS

sys.dat SYSEXP

table TABLES

tabtr.seq TABTRD

tsc.des TSCDES

usr.dat USREXP

xrefrg XREFRG

mvt.mvt MVTRDJ

demtrav.seq DEMTRV

IEvent.seq IEVEBC

Functional context generated by the sender parameter settings

The parameter settings of the sender, set via AI Enabler, form the functional context of a Rule Engine session.

These settings are built in sys.dat by extraction from the sender.

This section discusses the assignment of values to these parameters to allow you to easily check the validity of the functional context by reference to the parameters defined in AI Enabler for the sender before extraction.

Logical organizationTo activate a given function, you often need to supply several parameters belonging to different sections.

The illustration below shows the keywords that you need to supply in the various cases in the different sections of the functional context. The details of the keywords in script.ges are explained in the following chapters.


10 Appendices

Figure 6. Figure 1: Logical organization

SyntaxThe keywords of the functional context are divided into sections.

For example:


10 Appendices

>Choice<Aggregation=YesAuditing=NoRedirection=NoMulti_Period=No#Group=NoBalancing_Check=NoRecycling_Phase=NoAccounting_Processing=No

Rules to follow:

Each section name is enclosed in less than (>) and greater than (<) symbols: >section_name<

You assign values to all the keywords for a given sender by appending the name of the sender to the section name.>Section_Name.Sender_Name<For example:>Choice.SENDER1<Aggregation=NoKeywords belonging to one section cannot be associated with another section.

1. You must not changes the names used for keywords and sections.

2. You assign a value to each keyword that you want to use as follows: keyword_name = keyword_value.

Tabulated values are not allowed.

The spaces between a keyword and its value are not significant.

To comment out an unused keyword, precede it with a hash (#) sign. When you do this, the system uses the default value.

For example:

<Choice<

#Group=No

Balancing_Check=No

Recycling_Phase=No

Recycling_Phase=No

3. Keywords are not case sensitive. For example, redirection is the same keyword as Redirection or REDIRECTION.

4. The values that you assign to keywords ARE case sensitive and are applied exactly as you enter them. For example, hello, Hello and HELLO are three different values.

Mandatory configuration settingsThese settings relate to:

l Handling versions of Input-Event types

l The properties of Input-Events to be transformed

l Processing multi-segment Input-Events

l Processing mono-segment Input-Events

l The properties of the Output-Events produced


10 Appendices

Handling versions of Input-Event types in sys.datDuring transformation, the version of an Input-Event type can be identified in the following ways:

l Directly, through its numberor

l By relating a date to a period of validity of a version of an Input-Event type

Settings

Section + Keyword Keyword Value

Section + Keyword to Input

Properties of the Keyword to Input

>Ident_Type<

Type_Version_IEvent (typing of the version of the Input-Event type to process)

NumberDate

Defining a version via a date

An IEvent type version is defined by a date as follows, each IEvent type version being defined for one (or more) specific validity periods.

If the value of the date…

Then…

is within one of the validity periods

the IEvent type version associated with the validity period is usedè In the graphic : date 1, version 1

falls within several validity periods

the IEvent type version with the oldest start date is usedè In the graphic : date 3, version 1

does not fall within any validity period

the associated IEvent cannot be processed and is rejected by the transformation session è In the graphic : date 2, no version selected


10 Appendices

Figure 7. Definition of an IEvent type version definition by date

Properties of Input-Events to be transformedThis section explains how Rule Engine identifies the various fields that characterize an Input-Event. These methods of identification flow from the structures that have been defined for Input-Event segments.

Each of these technical fields can be identified in the following ways:

l Segment:Use this method if the field is defined in the basic structure (supplied by the sender application or the Input-Event restructuring exit)

l Context:Use this method in all other cases




>Ident_Type<

Code_IEvent (a means of identifying the name of the type of Input-Event to process)

Segment Context

>Fixed<Position_Code_IEvent and Length_Code_IEvent>Value<Code_IEvent

Maximum length = 25

IEvent_Version (a means of identifying the version of the Input-Event type to process)

Segment Context

>Fixed<Position_Version_IEvent, Length_Version_IEvent and Type_Version_IEvent>Value<IEvent_Version

Maximum length = 3 for a numeric or 10 for a date. Numeric or date, depending on the type.


10 Appendices




Code_Segt (a means of identifying the name of the segment type to process in the Input-Event)

Segment Context

>Fixed<Position_Code_Segt,Length_Code_Segt>Value<Code_Segt

Maximum length = 25

>Choice<

Multi_Period Yes No

If one or more versions of the Input-Event type to be processed are valid over more than one period. In all other cases.

Rules to follow:

1 Each technical field has a specific method of identificationFor each technical field, supply either the >Value< or the >Fixed< section, depending on your chosen method of identification

2 The position and length elements in the field identifier, when added together, must in all cases be equal to or less than 4001

3 If the date is supplied as a Date data type, the length must be 10 and it must be in the form DD/MM/YYYY

4 If the date is supplied as a Numeric data type, it must be in the form YYYYMMDD, CYYMMDD or YYMMDD, (depending on its length, which may be 8, 7 or 6)

Processing multi-segment Input-Events The table below shows the parameter settings that allow Input-Events with more than one segment to be handled.


10 Appendices




>Ident_Type<

Code_Instance (a means of identifying the instance of the Input-Event type to process)

Segment Context

>Fixed<Position_Code_Instance,Length_Code_Instance andType_Code_Instance>Value<Code_Instance

Maximum length = 34 Data type = A or N

>Limit<

Segt_IEvent 0 The segments of the Input-Event processed must be associated with the same instance code value

Note A segment with a blank instance code is treated as a mono-segment Input-Event. This gives the flexibility to process mono and multi-segment Input-Events in the same session.

A multi-segment Input-Event may contain up to 999 segments.

Processing mono-segment Input-Events These settings limit Rule Engine to handling Input-Events comprising a single segment. In this case the instance code in an Input-Event is not used.

Section + Keyword

Keyword Value



>Limit<

Segt_IEvent 1 Each Input-Event contains a single segment


10 Appendices

Properties of the Output-Events to processThis section explains how Rule Engine identifies the output code that characterizes an Output-Event.

This method of identification flows from the structures that have been defined for Output-Events.

Section + Keyword Keyword Value Section + Keyword to Input


>Ident_Type<

Code_Output (a means of identifying the output code associated with each Output-Event)

OSegt Context ExitStructure (1st character of the segment structure code)

>Fixed<Position_Code_Output,Length_Code_Output>Value<Code_Output

Maximum length = 25

Rules to follow:

1 The sum of Position + Length in this definition must be less than or equal to 4001

Management parameters

This section explains the DAR identification method. This information is required for the rules that are associated with the Input-Events and those associated with the Output-Events.

Section + Keyword

Keyword Value



>Ident_Type<


10 Appendices

Section + Keyword

Keyword Value



Date_Application_Rule

Segment Context

>Fixed<Position_Date_Application_RuleLength_Date_Application_RuleType_Date_Application_Rule

Maximum length = 10 or 8 Data type = Date or Numeric Supply the operational date of script.ges. See table below.

Rules to follow:

1 If the DAR is given in a numeric data type, its length may be 8 (YYYYMMDD), 7 (CYYMMDD) or 6 (YYMMDD)

2 If the DAR is given in Date data type, its length must be 10 characters, with a format of DD/MM/YYYY

Group managementSection + Keyword

Keyword Value



>Choice<

Group Yes

>Ident_Type<

Code_Group Segment Context

>Fixed<Position_Code_GroupLength_Code_Group Type_Code_Group >Value<Code_Group

Maximum length = 34Data type = A or N


10 Appendices

Aggregate Input-EventsSection + Keyword Keyword Value

>Choice<

Aggregation Yes

Aggregate Output-EventsSection + Keyword

Keyword Value

> Enrich_Exit <

OSegt Yes, if the P_Exit_Aggregation_OSegt_Group keyword in script.ges is set to Yes

>Choice<

Aggregation Yes

>Ident_Type<

Rule_Aggregation OSegt. The name of the rule is included in the structure of the Output-EventOutput. The name of the rule is associated with the output.

Balancing checkSection + Keyword Keyword

ValueSection + Keyword to Input


>Choice<

Balancing_Check Yes

>Ident_Type<


10 Appendices




Code_Balance_Check(field associated with the Input-Event type)

Segment Context

>Fixed<Position_Code_Balance_Check,>Value<Code_Balance_Check

Length = 1 The balancing check is only enabled by the value 1

Rule_Balancing (identifies the balancing rule associated with the Output-Events)

OSegt Output

The name of the rule is included in the structure of the Output-Event The name of the rule is associated with the output

Rule_Balancin_Compens (identifies the balancing compensation rule associated with the Output-Events)

OSegt Output

The name of the rule is included in the structure of the Output-Event The name of the rule is associated with the output

Accounting checks and reversals

Accounting checks


>Choice<

Accounting_Processing Yes


10 Appendices

Reversals




>Choice<

Accounting_Processing Yes

>Ident_Type<

Code_Reversal (field associated with the Input-Event type)

Segment Context

>Fixed<Position_Code_Reversal>Value<Code_Reversal

Parameter settings for system tuningThis section explains the keywords used during system tuning. These keywords are to be found in sys.dat.

Checking numeric values in mapped fields

Section + Keyword

Value Meaning

>Check<

Numeric Yes

No

Mapped fields that are defined as numeric are checked for numeric content in Output-Events or modified segmentsThe Input-Event is placed in anomaly if the check failsThe above check is not madeIf a field that is defined as numeric does not contain a numeric value, the transformation may be terminated with a system error

Checking for the existence of table keys

Section + Keyword

Value Meaning

>Check<


10 Appendices

Section + Keyword

Value Meaning

Existence_Table

Yes

No

For a table to which access is controlled by the session, the Input-Event being processed is placed in anomaly if a table key cannot be found.The processing is deemed to be correct, whatever the type of access control.

For details of this function, refer to the section on tables in the Axway Composer Reference Guide.

Check for the existence of rules

Section + Keyword

Value Meaning

>Check<

Existence_Rule

Yes

No

Rule Engine checks at the beginning of the session that the configuration contains the rules that are specified for processing, for pre-processing of Input-Events, and for the processing associated with outputs

These include aggregation, transformation, modification, audit and balancing rules. If the check fails on any rule, the session is not startedIf a rule that is required for processing is missing from the configuration, the Input-Event in question is rejected (placed in anomaly) when it is processed

This option allows you to ensure that you have all the required parameters before you start the processing.It helps to avoid anomalies in the processing caused by the absence of a rule that may be required for processing a large number of Input-Events.

Caution This check is applied for all Input-Event types with parameters on-line, even if these parameters are not required for the session. To enable this option, you require a full set of parameters.

Optimizing the writing of Output-Events

Section + Keyword

Value Meaning

>Optimization<


10 Appendices

Section + Keyword

Value Meaning

Length_OSegt Yes

No

When it is written out, the length of the Output-Event matches that of its structureThe Output-Event is padded with blanks to a fixed length of 4000 characters

>Optimization<

RTrim_OSegt Yes

No

When it is written out, the Output-Event is truncated if the rightmost characters in the structure are blanksWhen it is written out, the length of the Output-Event matches that of its structure

AuditSection + Keyword

Keyword Value

Section + Keyword to be Input


>Choice<

Auditing Yes >Auditing<

>Auditing<

Position_Identifier_Stamping

NNNN (<=4000)

The start position for the stamping identifier in the Input-Event segment

Length_Identifier_Stamping

NN (maximum 25 characters)

Length of the stamping identifier (see below)

Type_Counter_Stamping

NumericPacked

Data type of the stamping counter (see below)

Stamping_Identifier_Completed

Yes No

Any value in the field that contains the stamping identifier is replaced by the recalculated valueThe existing value is retained


10 Appendices

Section + Keyword

Keyword Value



Type_Stamping StampingSeries

See belowSee below

>Ident_Type<

Rule_Audit Output OSegt Structure

Name of the audit rule associated with the output Name of the audit rule contained in the Output-Event Name of the audit rule = name of the Output-Event structure

>Multi sessions audit<

Position_Identifier_Stamping_Origin

NNNN (<=4000)

The start position for the stamping identifier in the Input-Event segment

Length_Identifier_Stamping_Origin

NN (maximum 25 characters)

Length of the stamping identifier (see below)

Type_Counter_Stamping_Origin

NumericPacked

Data type of the stamping counter (see below)

Type_Stamping_Origin

StampingSeries

See belowSee below

Rules:

1 The start position and length of the field containing the stamping identifier, when added together must not exceed 4001 characters


10 Appendices

2 Length_Identifier_Stamping: If TimeStamp is set as the stamping type, the stamping identifier must be alphanumeric, with a length of 25 characters. The identifier must have the following format:

l The operation date is in the form YYYYMMDD

l The stamping time is in the form HHMMSSIn this case, when the stamping counter reaches its upper limit, the stamping time in the identifier is updated to the current time and the counter is reset to 00001If Series is set as the stamping type, the identifier is made up of a character, which shows the type of segment being stamped, and a stamping counter. The maximum length of the identifier is 19 characters (1 alphabetic for the segment type identifier + 18 for the numeric counter)

In this case, the system stops the session if the stamping counter reaches its upper limit. A return code of 10 is set

3 Type_Counter_Stamping: Specify the data type of the numeric counter that is to form the stamping identifier

4 Stamping_Identifier_Completed: If the Input-Event comes out of a session in which the Audit option is enabled, the segments are already stampedThis option allows you to do one of the following: Retain the existing value of the stamping identifier (value No)oRecalculate the stamping value for the current session and overwrite the existing stamp

Phase-specific recycling of Output-Events in anomaly

Section + Keyword

Keyword Value



>Choice<


10 Appendices

Section + Keyword

Keyword Value



Recycling_Phase Yes >Ident_Type< Code_Phase_Anomaly

>Ident_Type<

Code_Phase_Anomaly

Segment Context

>Fixed<Position_Code_Phase_Anomaly,Length_Code_Phase_Anomaly >Value<Code_Phase_Anomaly

Start position and length of the area from which the name of the phase is read and to which the name of the phase in anomaly is written for recycling

Name of the phase executed for all Input-Events processed

Rules to follow:

1 The sum of Position + Length must not exceed 4001

2 Maximum length of the phase name is 25 alphanumeric characters

ExitsChecking and enriching Input-Events before the transformation phases

This exit checks, enriches or modifies the data in the Input-Event segments before they are processed in the transformation phases.


10 Appendices

Keyword Description/Values Compatible with Step ...

Section >Exit_Enrich<

Segment Yes_C or Yes_Cobol or Yes_rdj53 or NoYes_rdj53: Compatible with ITR506.2

P

Checking and enriching the Input-Event segments for a specific transformation Rule

This exit modifies, enriches or checks the data in the Input-Event segments before each application of a change or transformation rule.



Rule Yes_C or Yes_Cobol or Yes_rdj53 or No.Yes_rdj53: Compatible with ITR506.2.

T

Identifying and checking Output-Events

This exit enriches or checks the Output-Events, or identifies the output, before the Output-Events are processed.



OSegt Yes_C or Yes_Cobol or Yes_rdj53 or No.Yes_rdj53: Compatible with ITR506.3.

T

Anomalies and rejections from transformationChecking for production of Output-Events

Section + Keyword

Value Meaning

>Authorization<


10 Appendices

Section + Keyword

Value Meaning

Rule_No_Output Yes

No

It is acceptable for a transformation rule to produce no Output-EventsIf a transformation rule runs without producing Output-Events, the Input-Event is placed in anomaly

>Limit<

Stop_Phase_First_Anomaly

Yes

No

As soon as an anomaly is detected in a phase, the subsequent rules in the phase are not appliedThe subsequent rules are applied to detect any further anomaliesThis option is useful during testing to optimize the correction of errors

Rejected events

Section + Keyword

Value Meaning

>Authorization<

IEvent_No_Output

Yes

No

It is acceptable for an Input-Event to be transformed without producing any Output-EventsIf an Input-Event is transformed without producing Output-Events, the Input-Event is rejected

Rejecting a group of Input-Events

Section + Keyword

Value Meaning

>Limit<

IEvent_Group_Rejected

n

0 (zero)

Processing of the group is stopped if n Input-Events are rejectedAll Input-Events in the group are processed, regardless of how many Input-Events are rejectedThis allows the maximum number of anomalies to be detected

Stopping the session

Section + Keyword

Value Meaning

>Limit<


10 Appendices

Section + Keyword

Value Meaning

IEvent_Rejected

n

0 (zero)

The system stops the session if the threshold of n rejected Input-Events is reachedThe transformation continues to the end however many Input-Events are rejected

Group_Rejected

n

0 (zero)

The system stops the session if the threshold of n rejected Input-Event groups is reachedThe transformation continues to the end however many Input-Event groups are rejected

Percentage_IEvent_Rejected

P% 0 (zero)

The session is declared invalid, and a return code of 10 is set, if the final percentage of Input-Events rejected is equal to or greater than P%. P may be any value from 0 through 100The session is deemed to be valid whatever percentage of the Input-Events are rejected


Documents

AccountingIntegrator Reference Guide