AccountingIntegrator Version October Reference Guide

Transcription

1 AccountingIntegrator Version October 2018 Reference Guide

2 Copyright 2018 Axway All rights reserved. This documentation describes the following Axway software: Axway AccountingIntegrator 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.

3 Contents Preface 9 Who should read this document 9 Related documentation 9 Accessibility 10 Screen reader support 10 Support for high contrast and accessible use of colors 10 What's new 11 Documentation 11 1 Rule Engine model 12 Rule Engine within the information system 12 Communication between applications 13 Specify the Processing-Context-Ins 13 Specify the Processing-Context-Outs 13 Specify the sessions 14 Physical organization 14 Input data 15 Procedures 16 Output data 17 Communication between sites 18 Process phases in Rule Engine 20 Read in the Input-Events 22 Input-Event restructuring exit 23 Identify Input-Events 24 Sort Input-Events 25 Preprocess Input-Events (spyglass A) 25 Input-event aggregation exit 26 Enrich and check Input-Events (spyglass B) 27 Process Input-Events (spyglass C) 28 Process Output-Events (spyglass D) 30 Input-Event / Group Level Checks (spyglass E) 31 Sort Output-Events 32 Aggregate Output-Events (spyglass F) 33 Output-Event aggregation exit 33 Output-Event restructuring exit 34 Write the transformation products 34 AccountingIntegrator Reference guide 3

4 2 Session general procedure 35 Change the Rule Engine license key 35 Deploy configuration containers 35 Manage Rule Engine configurations with the Repository 36 Import configuration into the Repository 36 Repository commands 36 Transformation session 41 3 Implement the functions 43 Steps in a transformation session and sys.dat file 43 File Mode 46 MQSeries mode and JMS mode 46 Mandatory parameter settings 46 Environment variables 46 General Options in script.ges 47 Physical characteristics in script.ges 48 Define an exchange zone 50 Rules 50 Define a virtual exchange zone in script.ges 51 Define a queue-type exchange zone for MQSeries in script.mqs or for JMS in script.jms 51 Define a file-based exchange zone in script.file 52 Internal sorts 53 Common parameters 53 Sort properties 54 Sort Input-Events 55 Sort Output-Events 57 Group management 58 Parameter Settings in script.ges 59 Aggregation 59 Aggregate Input-Events 59 Aggregate Output-Events 60 Balance checks: standard and with compensation option 62 Reminder about setting parameters in AI Enabler 62 Accounting checks and reversals 63 Reminder about setting parameters in AI Enabler 63 Links to Sentinel 63 Environment variables 63 Sentinel business monitoring 68 Links to InterPlay 69 Links to Rule Engine Server 70 Create a new log file for the Rule Engine Server 70 Externalize variables stn_dep and stn_maj in RDJDEP 71 AccountingIntegrator Reference guide 4

5 4 Manage transformation anomalies 72 Reminder about how the Rule Engine works 72 Transformation Errors: Return codes 73 Input-Event in anomaly during transformation 73 Circumstances 73 Consequences 74 Input-Event rejected 75 Circumstances 75 Consequences 75 Group of Input-Events rejected 76 Circumstances 76 Consequences 76 Session stopped 77 Circumstances 77 Consequences 77 Transformation errors: Return codes 78 5 Implement advanced functions 79 Audit mono and multi sessions 79 A reminder about setting parameters in AI Enabler 79 Audit rejects and anomalies 87 Phase-specific recycling of Input-Events in anomaly 89 Reminder about setting parameters in AI Enabler 89 Exits and external calls 89 Exits 89 External calls 96 Set up the transformation environment 96 Session environments and domains 96 Implement redirection 97 Optional environment variables setting 99 6 Set parameters for MQSeries and JMS implementations 102 Set MQSeries-specific or JMS-specific parameters in script.mqs 102 Structure of the messages transmitted 103 Read and produce messages 104 Messages in anomaly 105 Unreadable messages 105 Suspect messages 105 Structure of the messages generated 105 Use an exit to reformat Input-Event messages and transformation products 108 Parameter settings in script.mqs or script.jms 108 Manage groups with MQSeries or JMS 108 Define a complete group 110 Define an incomplete group 110 AccountingIntegrator Reference guide 5

6 Reproduce a group 110 Parameter settings in script.mqs or script.jms for a queue of Output-Events 111 Utilities for accessing the MQSeries or JMS exchange zones 111 Empty queues: rdjcleanmqs, rdjcleanjms 112 Stop the session: rdjstopmqs,rdjstopjms / RDJSTO 119 Transferring data from a file to a queue: rdjputmqs,rdjputjms /RDJPUT 120 Transferring data from a queue to a File: rdjgetmqs,rdjgetjms/rdjget 123 RuleEngineJMS and IBM-MQSeries implementation 129 Generate the JNDI file using JMSAdmin 129 Update the RuleEngine JMS runtime environment 135 Test in the RuleEngine JMS runtime environment Standard reports 139 General appearance 140 Statistics 140 TC1 counters 141 TC2 counters 142 TC3 counters 142 TC4 counters 143 TC5 counters 144 Transformation details 144 Transformation detail Header 145 Contents of the processed segment 145 Properties and contents of the Output-Event produced 146 Contents of the modified segment 146 Transformation anomalies 146 General information 147 Input-Event identifiers 147 Anomaly identifiers 148 Description of the anomaly 150 System identifiers 151 Contents of the segment 151 Redirection of Input-Events 152 Input-Event aggregation counters File specific 153 Aggregation counters by Input-Event 153 Aggregation Counters by Segment 154 Output-Event aggregation counters File specific 155 Account Log 155 Account Log - Header 156 Account Log - Detail lines 156 Compensation Log 156 Compensation Log - Header 157 Compensation Log - Detail lines 157 Counter summary 158 AccountingIntegrator Reference guide 6

7 Input-Event aggregation detailed report 158 Output-Event aggregation detailed report 159 Reformatting using exits BIRT reports 162 BIRT process 162 Report names and activation conditions 163 BIRT directories 163 Define the report properties 164 Report modification prerequisites 166 Reorganize the data display 166 Use styles 167 Use images 167 Define report labels Implement the Rule Engine using permanent files 169 Overview 169 Script.ges: Syntax and commands 169 Syntax 169 Script commands 171 Define variables in the >Script.ges< section 171 Include a script file into the >Script.ges< section 172 Display a comment 172 Optional table updates 173 Create an update file 173 Syntax of mvt.mvt file 173 Execute procedure rdjmaj Appendices 183 UTF-16 implementation details 183 AI Enabler characteristics 183 Rule Engine 184 Terminology 184 Required files for the Rule Engine 184 Functional context generated by the sender parameter settings 186 Logical organization 186 Syntax 187 Mandatory configuration settings 188 Group management 194 Aggregate Input-Events 195 Aggregate Output-Events 195 Balancing check 195 Accounting checks and reversals 196 Parameter settings for system tuning 197 AccountingIntegrator Reference guide 7

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

9 Preface This document describes the features of the AccountingIntegrator component Rule Engine and its implementation using the AI Enabler. Who should read this document This 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 documentation The AccountingIntegrator documentation set includes the following documents: AccountingIntegrator User Guide Rule Engine User Guide AI Enabler User Guide AccountingIntegrator Installation Guide Rule Engine Reference Guide Rule Engine Operations Guide z/os Rule Engine Exits and External Calls Rule Engine Error Messages Guide Rule Engine Installation Guide z/os Rule Engine Installation Guide OS/400 Accounting Integration User Guide AccountingIntegrator Reference guide 9

10 Accessibility Axway strives to create accessible products and documentation for users. This documentation provides the following accessibility features: Screen reader support Support for high contrast and accessible use of colors Screen reader support Alternative text is provided for images whenever necessary. The PDF documents are tagged to provide a logical reading order. Support for high contrast and accessible use of colors The documentation can be used in high-contrast mode. There is sufficient contrast between the text and the background color. The graphics have the right level of contrast and take into account the way color-blind people perceive colors. AccountingIntegrator Reference guide 10

11 What's new The AccountingIntegrator Rule Engine includes the following new features: 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. 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. 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. 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. 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. 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 New AccountingIntegrator User Guide with information regarding the Rule Engine use with the new Rule Engine Server. New Rule Engine User Guide in HTML including all the information contained in the Rule Engine PDF guides. New AccountingIntegrator Installation Guide with installing information regarding the AccountingIntegrator product. AccountingIntegrator Reference guide 11

12 Rule Engine model 1 This section describes where the Rule Engine is located in the information system and how processes are set up. Rule Engine within the information system Rule Engine provides the following implementation modes: File mode: input data and corresponding output data are stored in files in Latin (ASCII, EBCDIC) or UTF-16 format MQSeries mode: input data and corresponding output data are stored in messages in Latin (ASCII, EBCDIC) 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: The number of Rule Engine implementations you want The machine on which each Rule Engine is to run The type of implementation for each Rule Engine This 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: The installation environment, that is, the directories or physical libraries into which you intend to install 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. AccountingIntegrator Reference guide 12

13 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: By table By external calls and using the functions of the associated language. For more information, refer to Rule Engine Exits and External Calls Guide. 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 applications You 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-Ins Identify the applications that produce information for input to Rule Engine. For each of these applications, list: How to identify each of the technical fields associated with the Input-Events sent (identification of the technical data in the flow) The processing options to be executed 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-Outs Identify the applications that receive the data output from Rule Engine. AccountingIntegrator Reference guide 13

14 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: The structure to be expected in the incoming data The type of checks to be carried out on the data The processing options to be executed The exits to be developed 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 sessions Knowledge 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: AccountingIntegrator Reference guide 14

15 1 Rule Engine model Figure 1. Physical organization The various elements are grouped by category: Input Data Procedures Output Data Input data Directory System files (SYS for MVS) Executable files (EXE for MVS) Contents System files: The system context, including all the Rule Engine options supplied Error messages: contains descriptions of all errors generated during processing Executables for all required transformations AccountingIntegrator Reference guide 15

16 1 Rule Engine model Directory Report templates (FMT for MVS) Configuration files (REF et DAT for MVS) Contents Templates for all reports: Results of redirection Details of transformation anomalies Input-Event aggregation counters Details of Input-Event aggregation Aggregation counters for accounting Output-Event Details of Output-Event aggregation Transformation counters Transformation counters summary Details of modified Input and Output-Events generated in a session Account log 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 JMS The data to be processed by the procedures. You can configure the names. Procedures Continuous use The JCLLIB or SCRIPT directory (or library) contains the run-time procedures: Procedure Purpose For continuous use rdjexp rdjews rdjstn Procedure for transforming Input-Events into Output-Events Syntax : rdjexp [txt/pdf/html] [session] [audit] [business] [ews] txt : file *.edi report format (by default) Procedure for creating a file of Input-Events in anomaly, to be passed to Axway InterPlay Procedure for gathering tracking information to be sent to Sentinel AccountingIntegrator Reference guide 16

17 1 Rule Engine model Procedure Purpose For use during tuning rdjmaj rdjrch rdjtrf rdjedr rdjrgt rdjmnt Procedure for automatic compilation of the Rule Engine environment parameter settings, to be run after export from AI Enabler 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 Procedure for extracting the configuration settings in the form of an input file Procedure for printing the contents of the compiled parameter files Procedure for extracting the configuration settings in the form of an RGTR file Procedure for updating the compilation of the configuration file For use during installation rdjraz rdjsic Procedure for reinitializing the environment, used to create an empty site: Under DAT, only the supplied files are re-initialized Procedure for running and managing the SIC (Information and verification system) installation process Output data Directory 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: The descriptors (sys.dat) The compiled rules and tables AccountingIntegrator Reference guide 17

18 1 Rule Engine model Directory Contents BRS bres The products generated by rdjexp: The Output-Events Modified Events Redirected Events Input-Events in anomaly during transformation Rejected Events Input-Event traces Output-Event traces Communication between sites This 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: Either in connected mode via the Broadcast Agent in the AI Enabler interface 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: AccountingIntegrator Reference guide 18

19 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. AccountingIntegrator Reference guide 19

20 1 Rule Engine model Process phases in Rule Engine The 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. AccountingIntegrator Reference guide 20

21 1 Rule Engine model Figure 2. Figure 2: Processing phases Characteristics This core function carries out consistency checks on the settings supplied. AccountingIntegrator Reference guide 21

22 1 Rule Engine model Process The parameter settings you provide configure Rule Engine at the start of the session. The system runs consistency checks on the major options at this point to avoid any anomalies that may bring the transformation process to a halt. For example, the system checks the definitions of: Stamping identifiers for consistency with the audit option chosen The position of fields when they are to be identified by segment What happens if an error occurs? The system halts the session with a configuration error, return code = 12. Read in the Input-Events Characteristics This core function can be configured via script.ges for the relevant type of exchange zone. Process File Mode The file is read sequentially, taking into account either the position and length or the fixed values of the Input-Event identifiers, in the following decreasing order of priority: The group code, if you activated the group management option The name of the Input-Event type The version number of the Input-Event type The occurrence of an Input-Event is identified by an identical set of values for: The name of the Input-Event type The version number of the Input-Event type The instance code A change in any of these values indicates a new occurrence of an Input-Event. An Input-Event group is identified by the value of the group code, which is the same for all Input- Events in the group. A change in this value indicates a change of Event group. AccountingIntegrator Reference guide 22

23 1 Rule Engine model MQSeries mode and JMS mode The system reads through the queue in order of arrival. Each instance of an Input-Event must be described completely within a given message. However, a single message may contain more than one instance of an Input-Event. For more information, refer to Read and produce messages 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 Characteristics This optional function is activated through script.ges. For more information, refer to Rule Engine Exits and External Calls. Process The exit processes the Input-Event segments in the order in which they are input into Rule Engine. This exit enables you to: Create Merge Re-order Delete Change the contents of Input-Event segments What happens if an error occurs? The system rejects the Input-Event that is being processed (return code = 6). If an error occurs during the restructuring process, this causes the system to stop the session (return code = 16). AccountingIntegrator Reference guide 23

24 1 Rule Engine model Identify Input-Events Characteristics This core function can be configured for each technical field via the associated Processing-Context- In. For each technical field, identification by: segment means that the system picks out the identifier in the segment by its position and length, as defined for the associated Processing Context-In context means that the value of the identifier is unique within the session and referenced by a constant supplied by the associated Processing Context-In Rule Engine looks for the following fields. Field type The identifiers related to the Input-Event type The Input-Event processing parameters Contents Name of the Input-Event type Version of the Event type Name of the segment type Instance code (if present) Group code (if present) Balancing check code Reversal code Anomaly phase code. The Input-Event is to be recycled back through the Transformation-Phase Process The point at which the system carries out this identification depends on the options that you activated for the session. If all options are activated, the system runs the identification immediately before the sort. However, if you have not activated the sort option, the identification is carried out immediately before pre-processing. Similarly, if you have not activated the Input-Event aggregation option, identification is carried out immediately before processing. The system carries out the identification for each segment it encounters. AccountingIntegrator Reference guide 24

25 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 Characteristics This 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. What happens if an error occurs? The system halts the session with a system error (return code = 16). Preprocess Input-Events (spyglass A) Characteristics This optional function is enabled through script.ges when you specify preprocessing for the Input- Event types that are to be processed. Process The system preprocesses the Input-Event segments in the order in which they emerge from the sorting process. For more details, refer to Sort Input-Events on page 25. The processing comprises: Input-Event audit before aggregation Input-Event aggregation Input-Event audit after aggregation AccountingIntegrator Reference guide 25

26 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: Segments belonging to a single Input-Event, if the Input-Event being processed is multisegment For mono-segment Input-Events, segments belonging to more than one Input-Event. If you set the Group Management option, the system aggregates the Input-Events by group. The group code is an implicit criterion for aggregation. The system can extract an audit trace for each individual segment emerging from the sort process, provided that you configured this option for the preprocessing of the relevant Input-Event type. The individual segments are then aggregated in accordance with their associated aggregation rule. An audit trace can also be extracted for the aggregated segment emerging from the aggregation process, provided you configured this option for the preprocessing of the Input-Event type. What happens if an error occurs? The system rejects the Input-Event that is being processed (return code = 6). If you have set the Group Management option, the group to which the Event belongs is itself rejected. In this case, the systems sets a return code = 8, which takes priority over the return code = 6. If a rejection threshold is reached, either for Input-Events or groups, this causes the system to stop the session with a return code = 10. Input-event aggregation exit This optional function is enabled through sys.dat during Input-Event aggregation. You must activate the Input-Event aggregation option. For details, see Axway Rule Engine Exits and External Call. The exit processes the segments in the order in which they are input into Rule Engine. What happens if an error occurs? The system rejects the Input-Event that is being processed (return code = 6). If you have set the Group Management option, the group to which the Event belongs is itself rejected. In this case, the systems sets a return code = 8, which takes priority over the return code = 6. If a rejection threshold is reached, either for Input-Events or groups, this causes the system to stop the session with a return code = 10. A more serious error causes the session to stop with a return code = 16. AccountingIntegrator Reference guide 26

27 1 Rule Engine model Enrich and check Input-Events (spyglass B) Characteristics This core function includes certain optional operations, which are configured in sys.dat. The core operations check the Input-Events that are to be transformed. These operations take place before transformation and check that: The parameters specify only processes that are valid for the Input-Event type that is to be processed The Input-Event type to be processed is valid for the DAR The optional operations allow you to: Activate an exit to enrich or check Input-Event segments Check for the existence of the rules that are to be applied Process The order in which the system enriches and checks Input-Events depends on the processing that has already been applied to them, such as sorting, preprocessing, restructuring by exits, and so on. The Input-Events are enriched and checked one at a time. Rule Engine loads an instance of an Input-Event into memory, that is, all the segments of the Input-Event, and enriches and checks them in accordance with the configuration settings. What happens if an error occurs? The system places the Input-Event being processed in anomaly for the Transformation-Phase in which the error occurred (return code= 4). If the Input-Event being processed is placed in anomaly for all the Phases, the system rejects the Input-Event (return code= 6). If you set the Group Management option, the system places the group to which the Input-Event belongs itself placed in anomaly or rejects it. In this case, the system sets a return code = 8, which takes priority over the return codes 4 or 6. If a rejection threshold is reached, either for Input-Events or groups, this causes the system to stop the session with a return code = 10. If the error is more serious, the system stops the session with an error code = 16. AccountingIntegrator Reference guide 27

28 1 Rule Engine model Process Input-Events (spyglass C) Characteristics This core function applies the rules for processing the various Input-Event types. Process The system processes the Input-Event segments in the order in which they were enriched and checked, if applicable. In the same way as explained above, the Input-Events are processed one at a time. Rule Engine loads an instance of an Input-Event into memory, that is, all the segments of the Input-Event, and checks and processes them in accordance with the configuration settings. The system applies processing according to the follow rules: If you configured more than one phase, the system executes them in the alphabetical order of the phase names Within a phase, the system applies rules in the order in which you configured them for the Input-Event type The system applies each rule to all segments of one type before it applies the next phase rule Rule Engine stores in memory all data relating to the Input-Event currently being processed until it finishes processing that Input-Event. This data comprises: The Input-Event itself (all segments) Any anomalies that arise The Output-Events generated The traces extracted The segments modified Illustration of the processing applied Input-Event type: COMM_RECEP (commissions due). This Input-Event type consists of two segment types: COMM_FCPS (Commissions on mutual funds) COMM_GENE (Commissions due, all types) The phases to apply to this Input-Event type are as follows. AccountingIntegrator Reference guide 28

29 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: 12 COMM_GENE segments 6 COMM_FCPS segments 5 COMM_GENE segments The system executes the phases in the following sequences: Phase Rule Applied Number of Applications Segment Type Processed 1 - The ADMINISTRATION phase this being the first phase name in alphabetical order FST01 6 COMM_FCPS FST02 6 COMM_FCPS AccountingIntegrator Reference guide 29

30 1 Rule Engine model Phase Rule Applied Number of Applications Segment Type Processed 1ST01 17 ( ) COMM_GENE 1ST02 17 ( ) COMM_GENE 2 - The COST_ACCOUNTING phase, the next phase name in alphabetical order XRC01 6 COMM_FCPS 2RC01 17 ( ) COMM_GENE 3 - The COST_ACCOUNTING phase, the next phase name in alphabetical order FRC01 6 COMM_FCPS FRC11 6 COMM_FCPS 1RC01 17 ( ) COMM_GENE 1RC11 17 ( ) COMM_GENE What happens if an error occurs? The system places the Input-Event it is processing in anomaly in the Transformation-Phase in which the processing error occurred (return code=4). If the Input-Event being processed is placed in anomaly for all the Phases, the system rejects the Input-Event (return code= 6). If you activate the Group Management option, Rule Engine rejects or places in anomaly the group to which the Input-Event belongs. In this case, a return code = 8 is set, taking priority over the return codes 4 or 6. If a rejection threshold is reached, either for Input-Events or groups, this causes the system to stop the session with a return code = 10. If the error is more serious, the system stops the session with an error code = 16. Process Output-Events (spyglass D) Characteristics This core function includes certain optional operations, which are configured for the associated Processing Context-In. AccountingIntegrator Reference guide 30

31 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. Process Rule Engine processes Output-Events sequentially. For each Output-Event, the processing is applied in the following order: Core processing: Identifying the associated Processing-Context-Out Optional processing: o o o o o Checking or enrichment by exit Accounting processing Balancing checks by rule Extracting the trace or a traceability check Aggregation or an aggregability check What happens if an error occurs? The Input-Event from which the Output-Event was created that gave rise to the processing error is placed in anomaly. Also, the products of the phase that created the Output-Event are canceled (return code=4). If the Input-Event from which the Output-Event is derived is placed in anomaly for all the Phases, the Input-Event is rejected (return code= 6). If the Group Management option is enabled, the group to which the Input-Event belongs is itself placed in anomaly or rejected. In this case, a return code = 8 is set, taking priority over the return codes 4 or 6. If a rejection threshold is reached, either for Input-Events or groups, this causes the system to stop the session with a return code = 10. If the error is more serious, the system stops the session with an error code = 16. Input-Event / Group Level Checks (spyglass E) Characteristics This core function is applied in accordance with the options activated for the session. AccountingIntegrator Reference guide 31

32 1 Rule Engine model Process Checks are carried out at Input-Event level when all the Transformation-Phases are applied to an instance of an Input-Event. This involves: Balancing checks at Input-Event level Verification of authorization to manage Input-Events without producing Output-Events, if no Output-Events result from the transformation of the Input-Event Placing Events in anomaly, or rejecting them, depending on what happens during processing Checks at group level are applied to the Input-Events that belong to the same group. This is done as the Input-Events are processed. This involves: Balancing checks at group level (at end of group) Possible rejections, depending on what happens during processing. What happens if an error occurs? The Input-Event being processed is placed in anomaly for the Transformation-Phase in which the processing error occurred (return code= 4). If the Input-Event being processed is placed in anomaly for all the Phases, the Input-Event is rejected (return code= 6). If you have set the Group Management option, the group to which the Event belongs is itself rejected. In this case, the systems sets a return code = 8, which takes priority over the return codes 4 or 6. If a rejection threshold is reached, either for Input-Events or groups, this causes the system to stop the session with a return code = 10. If the error is more serious, the system stops the session with an error code = 16. Sort Output-Events Characteristics This function is enabled automatically if the Aggregate Output-Events option is enabled. What happens if an error occurs? The system halts the session with a system error (return code = 16). AccountingIntegrator Reference guide 32

33 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. Process The segments are processed in sets built from the output from the sort process. They may or may not contain Output-Events from the processing of a single group, depending on the parameters set. An audit trace is extracted for each individual Output-Event that emerges from the sort, provided that this option has been enabled for the Processing-Context-Out associated with the Output-Event. The individual Output-Events are subsequently aggregated in the manner specified in the aggregation rule. An audit trace is extracted for each aggregated Output-Event that emerges from the aggregation process, provided that this option has been enabled for the Processing-Context-Out associated with the Output-Event. Output-Event aggregation exit This optional function is enabled through sys.dat during Output-Event aggregation, providing the Output-Event aggregation option is enabled. Refer to 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). AccountingIntegrator Reference guide 33

34 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. Process The Output-Event restructuring exit processes Output-Events in the order in which they are generated. This exit allows you to: Create Merge Re-order Delete Change the contents of Output-Events What happens if an error occurs? The system halts the session with a system error (return code = 16). Write the transformation products Characteristics This core function is enabled through script.ges. Process The results of a transformation session are made available in the exchange zones which you have defined in the >Script.ges< section of script.ges. What happens if an error occurs? The system halts the session with a system error (return code = 16). AccountingIntegrator Reference guide 34

35 Session general procedure 2 This chapter describes how to use the deployment tool and presents the execution steps of a transformation session. Change the Rule Engine license key You 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 containers This 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: Checks the container prerequisites Copies the Rule Engine repository files(ctx.mvt and mvt) of the container in the <RDJ_ EXEC>/dat execution environment AccountingIntegrator Reference guide 35

36 2 Session general procedure Updates the Rule Engine(rdjmaj and rdjrch) 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: 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. 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 Repository The 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: an application name an identifier (configuration identifier) When imported into the Repository, the internal table files are associated to: an application name a configuration identifier an identifier (table identifier) Repository commands There are Repository commands to: Import configurations into the Repository on page 37 Export configurations from the Repository on page 38 List configurations from the Repository on page 38 Clean configurations from the Repository on page 39 AccountingIntegrator Reference guide 36

37 2 Session general procedure Import configurations into the Repository To 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 configurations The 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: That there is no configuration with same identifier in the repository. Otherwise an error is displayed. AccountingIntegrator Reference guide 37

38 2 Session general procedure 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 Repository To 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 Repository To 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. AccountingIntegrator Reference guide 38

39 2 Session general procedure Clean configurations from the Repository To 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 from 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. 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. Example The 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 aiconfig1 aiconfig2 aiconfig3 Internal table value COA.mvt, CURRENCY.mvt, RATE.mvt COA.mvt COA.mvt, CURRENCY.mvt The import folder must have the structure described in the picture below: AccountingIntegrator Reference guide 39

40 2 Session general procedure 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: AccountingIntegrator Reference guide 40

41 2 Session general procedure 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 session To 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 AccountingIntegrator Reference guide 41

42 2 Session general procedure 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 AccountingIntegrator Reference guide 42

43 Implement the functions 3 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: Rule Engine Installation Guide (zos) Rule Engine Installation Guide OS400 In this section: Steps in a transformation session and sys.dat file on page 43 Mandatory parameter settings on page 46 Define an exchange zone on page 50 Internal sorts on page 53 Group management on page 58 Aggregation on page 59 Balance checks: standard and with compensation option on page 62 Accounting checks and reversals on page 63 Links to Rule Engine Server on page 70 Links to Sentinel on page 63 Links to InterPlay on page 69 Implement advanced functions on page 79 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] (*)] AccountingIntegrator Reference guide 43

44 3 Implement the functions 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. AccountingIntegrator Reference guide 44

45 3 Implement the functions 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. AccountingIntegrator Reference guide 45

46 3 Implement the functions File Mode A session requires you to activate at least one of the three possible steps: INPUT (E) PROCESSING (T) 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 mode Rule Engine MQSeries or JMS require you to run all three steps (E, T, and S) together. Mandatory parameter settings To 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: Definitions of environment variables General options in script.ges The physical characteristics in script.ges Environment variables These 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 RDJ_HOME RDJ_EXEC Use Reference directory (or library) containing all the reference objects (For example, error files and executables) Run-time environment containing the objects to be processed (For example options, objects to read and to produce) AccountingIntegrator Reference guide 46

47 3 Implement the functions Variable RDJ_LANG QRDJ_PREF Use Reference language (French or English) If this variable is not set, English is used by default MQSeries or JMS queue prefix (Rule Engine MQSeries or JMS) This mandatory variable is automatically referenced by the installation kit General Options in script.ges Keyword >Script< Section insert <THIS FILE>, Script.File Description/Values 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 Session Date_Operation Repository Environment_ Transformation Specify the DAT directory (or library) in which the parameter files are located Specify the name of the active transformation session Specify this date in the format dd/mm/yyyy If it is not defined, the system date is used Specify the name of the technical context for the transformation Specify the name of the transformation environment activated by the session UNIX only The 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: Codification = ASCII Codification = EBCDIC (default value if this parameter is not present in the sys.dat file) AccountingIntegrator Reference guide 47

48 3 Implement the functions Physical characteristics in script.ges Defining the processing Context-In Keyword Description/Values >Script.Ges< Section Input_Event (Name_Sender) IEvent _I (Name_ Sender) IEvent _ Redirected (I) The name of the exchange zone containing the Input-Events to be processed and the Processing Context-In identifier Processing Context-In identifier preceded by the name of either the: Output file in Step E Input file in the next step TS Mandatory for a session without Step TS (Configured as E) 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 Keyword Description/Values Script.Ges< Section OSegt (Processing- Context-Out) The name of the exchange zone associated with the Processing-Context- Out that is specified in brackets Output-Events Business Monitoring Processing-Context-Outs dedicated to Sentinel must include the following parameter: BusinessMonitoring=yes Example: 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 AccountingIntegrator Reference guide 48

49 3 Implement the functions Keyword OSegt _P (required in a session with no step S: that is, configured as ET) Description/Values Name of the output file from a T step or the input file to a subsequent S step Rules for defining exchange zones: Associate each Processing-Context-Out for Output-Events processed in a session with an exchange zone You may associate more than one Processing-Context-Out with the same exchange zone If an exchange zone is missing, when the Output-Events are written out as follows: o o The Output-Events concerned are written to the OSegt exchange zone, if one is defined 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 IEvent_Anomaly IEvent_Rejected IEvent_Modified Trace_ IEvent Trace_ OSegt Detail_Transformation Counter_Transformation Rule_Counter Detail_Redirection_IEvent Detail_Anomaly_Rejection_ IEvent Type of Data Input-Events placed in anomaly during transformation Input-Events rejected during transformation Contents of Input-Events modified during transformation Contents of traces generated by the Input-Events during the session Contents of traces generated by the Output-Events during the session Information required for report on transformation details Information required for report on transformation counters Information required for the transformation summary report Information required for report on Input-Event redirection Information for report on transformation anomalies and rejections AccountingIntegrator Reference guide 49

50 3 Implement the functions Keyword Counter_Aggreg_IEvent Detail_ Aggregation_IEvent Counter_ Aggregation_OSegt Aggreg_Account Log_Account Log_Compensation Type of Data Information required for report on Input-Event aggregation counters Information required for report on Input-Event aggregation details Information required for report on Output-Event aggregation counters Information required for report on Output-Event aggregation details Information required for the accounting journal report 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 zone In 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". Rules Type_EZ is required and may take the following values. Value VIRTUAL MQS DEFAUT Use Virtual output MQSeries-type or JMS-type exchange zones 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. AccountingIntegrator Reference guide 50

51 3 Implement the functions Define a virtual exchange zone in script.ges You 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: During tuning 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.jms A 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: Rule Engine: The name of the remote manager (if there is one) for the queue containing the data to be read or written: o o Optional parameter Maximum length of the manager name: 48 Characters for UNIX/WIN, 4 characters for MVS (MQSeries only) 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 o Required parameter Maximum length of the queue name: 48 characters Blocking: Request to block the product by message (optional parameter): o o Yes: Each message is filled with the maximum number of elements possible 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 AccountingIntegrator Reference guide 51

52 3 Implement the functions 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. Buffer: Size in KB of the message input (or output) buffer for this queue (optional parameter) o o If this parameter is missing, the buffer is set to the length of the longest message associated with the queue The value nb must be in the range 1 (minimum) to 4096 (maximum) 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.file A 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 zone Name_of_File: Name of the file (path and name in UNIX or DD name in MVS) that contains the data to be read or written. Required parameter. Maximum length of the file name: 128 characters. Examples: 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" AccountingIntegrator Reference guide 52

53 3 Implement the functions File containing modified Input-Events, on an MVS machine: IEvent_Modified = DEFAULT, "DD:IEVMOD" File containing generated Output-Events, associated with the output ACCOUNTING, on a UNIX machine: OSegt (ACCOUNTING) = DEFAULT, "/xrdj/_rdjfil/result/osegt_ accnt.seq" Internal sorts Procedure rdjexp can sort: Input-Events This sort can be configured to match the physical properties of the Input-Events to be processed. Output-Events The 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 parameters You 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 Keyword Description/Values >ScriptConfiguration< Section Memory_ Sort Amount of memory in KB to be reserved for the sort module This amount of memory is allocated at the beginning of the sort and freed at the end By default, 5000KB of memory is allocated AccountingIntegrator Reference guide 53

54 3 Implement the functions Keyword Length_ Average_ ISegt Length_ Average_ OSegt Description/Values Average length of an Input-Event segment (number of bytes) If this value is incorrect, the system adjusts it automatically during the sorting process However, 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) Average length of an Output-Event segment (number of bytes) If this value is incorrect, the system adjusts it automatically during the sorting process However, it is recommended that you set a relevant size in order to optimize the sort configuration >Script.Ges< Section Sort_Tmp1 Name of the first temporary work file Sort_Tmp2 Name of the second temporary work file Optimize the sort Rules The sort module uses both the reserved memory and the work files to sort the data: 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. To reconfigure the sort, change the settings for the amount of memory and the number of segments. Sort properties The 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. AccountingIntegrator Reference guide 54

55 3 Implement the functions 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 ) / (200 * AvLng) Where: SMAX = Volume in KB of the total data to be sorted AvLng= Average length in KB of the data segments to be sorted Example: If AvLng is 2 KB and SMAX is KB Then Memory_Sort is at least 2590 KB. Sort Input-Events You 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 sorts In any of the following situations, a sort is mandatory: If all the segments of an Input-Event do not occur consecutively in an input file 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 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. AccountingIntegrator Reference guide 55

56 3 Implement the functions Parameter settings in script.ges and sys.dat Keyword Description/Values >Configuration< Section 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 sort However, 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 AccountingIntegrator Reference guide 56

57 3 Implement the functions 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 segment This 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 segment This 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-Events A 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. Parameter settings in script.ges and sys.dat Keyword Description/Values >ScriptConfiguration< Section 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: AccountingIntegrator Reference guide 57

58 3 Implement the functions Minimum Value Allowed Maximum Value Allowed Default Value 20 bytes 4000 bytes 500 bytes >Script.ges< Section P_Tmp_OSegt_ Group P_Tmp_OSegt_Sort_ Group O_Tmp_OSegt_Sort_ Session The name of the work file containing the Output-Events of a group to be aggregated The name of the work file containing the sorted Output-Events of a group to be aggregated 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-Event This is calculated from the value of the DAR 4 The values of the aggregation criteria These 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 management This section reminds you about setting parameters in Axway Composer: Declare the group code technical field in the structures. AccountingIntegrator Reference guide 58

59 3 Implement the functions Parameter Settings in script.ges Keyword Description/Values >Configuration< Section Turnoff_Group No Note Note If mono-segment Input-Events are to be aggregated, the group code becomes an implicit criterion for the aggregation of the Input-Events. 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-Events This function can ONLY be implemented for file-based implementations of Rule Engine. Reminder about setting parameters in AI Enabler Input-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. Parameter settings in script.ges and sys.dat Keyword Description/Values >ScriptConfiguration< Section I_Aggregation_IEvent I_Exit_Aggregation_IEvent Yes Yes, if you want to use exits for processing during aggregation of the Input-Event segments (See Exits and External Calls Guide) Otherwise, No AccountingIntegrator Reference guide 59

60 3 Implement the functions Keyword Aggregation_Part_IEvent Print_Report_Aggregation_ IEvent Counter_Aggregation_IEvent Report_Detail_Agreg_IEvent Detail_Agreg_IEvent IEvent_I (required parameter if the session consists solely of an input (T) step) Description/Values Yes, to get the output from a partial aggregation without truncating the number of segments aggregated This approach is recommended for large volumes or large numbers of aggregations Otherwise, No Yes if you want counter details on the Input-Event aggregation Otherwise, No The name of the file containing the data for the report on the aggregation counters Yes if you want details on the Input-Event aggregation Otherwise, No The name of the file containing the data to be used in the Input-Event Aggregation Detail report Name of the output file from an input (E) step or the input file to a subsequent processing (T) step Aggregate Output-Events This function can ONLY be implemented for file implementations of Rule Engine. Reminder about setting parameters in AI Enabler Output-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. AccountingIntegrator Reference guide 60

61 3 Implement the functions Parameter settings in script.ges and sys.dat Keyword Description/Values >ScriptConfiguration< Section P_Aggregation_Osegt_ Group P_Exit_Aggregation_ OSegt_Group O_Aggregation_OSegt Yes, if you want to aggregate all Output-Event groups combined in the T step Yes, if you want to use exits for processing during aggregation of the Output-Events in step T Yes, if you want to aggregate the Output-Events in step S O_Exit_Aggregation_ OSegt Aggregation_Part_ 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) Yes, to get the output from a partial aggregation without truncating the number of segments aggregated This approach is recommended for large volumes or large numbers of aggregations Otherwise, No Turnoff_Exit_OSegt No: if the previous keyword is set to Yes Yes: if you are not using an exit to enrich the Output-Events Print_Report_ Aggregation_OSegt<0} Yes: to obtain Output-Event aggregation counters No: if you are not aggregating the Output-Events Counter_Aggregation_ OSegt Counter_Aggregation_ IEvent The file containing the data for the report on the aggregation of the Output-Events File containing Output-Event aggregation report data Print_Report_Aggreg_ Accounting Yes: to obtain accounting Output-Event aggregation details No: if you are not aggregating the Output-Events Aggreg_Account O_Exit_Aggregation_ OSegt File containing data for the accounting Output-Event aggregation details report 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) AccountingIntegrator Reference guide 61

62 3 Implement the functions Keyword Description/Values 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 Enabler The 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 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: Reporting documents such as the accounting log and the compensation log Session counters (compensation counter per Processing-Context-Out) Audit documents AccountingIntegrator Reference guide 62

63 3 Implement the functions Accounting checks and reversals Reminder about setting parameters in AI Enabler Accounting 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 variables If 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. rdjraz Note Parameters after modification by command line are prioritary. Default parameters are only applied if there are no monitoring parameters in the command line. AccountingIntegrator Reference guide 63

64 3 Implement the functions Parameters after modification by command line Default parameters Use with return code (RC) stn_raz[differ] stn_raz: starts RAZ monitoring differ: deferred monitoring. Saves information in an overflow file. (Unix/Windows) stn_raz=no No RAZ monitoring stn_raz=yes Instant RAZ monitoring stn_raz=yes_ differ Deferred RAZ monitoring (UNIX/Windows) TKRAZ=NORAZ No RAZ monitoring TKRAZ=RAZ Instant RAZ monitoring (MVS) No RAZ monitoring: No information on the session is sent to Sentinel. Phase init: RC=04 - file RDJ_TPSFILE is created. Phase end: not executed. Instant RAZ monitoring The Rule Engine sends the operation reports to Sentinel to allow RAZ monitoring. Phase init&end: RC=00 if information is successfully transmitted. RC=01: non-transmitted information is stored in the overflow file. Deferred RAZ monitoring The 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. rdjmaj Note Parameters after modification by command line are prioritary. Default parameters are only applied if there are no monitoring parameters in the command line. AccountingIntegrator Reference guide 64

65 3 Implement the functions Parameters after modification by command line Default parameters Use with return code (RC) stn_maj[differ] stn_maj: starts MAJ monitoring differ: deferred monitoring. Saves information in an overflow file. (Unix/Windows) stn_maj=no No MAJ monitoring stn_maj=yes Instant MAJ monitoring stn_maj=yes_ differ Deferred MAJ monitoring (UNIX/Windows) TKMAJ=NOMAJ No MAJ monitoring TKMAJ=MAJ Instant MAJ monitoring (MVS) No MAJ monitoring: No information on the session is sent to Sentinel. Phase init: RC=04 - file RDJ_TPSFILE is created. Phase end: not executed. Instant MAJ monitoring The Rule Engine sends the operation reports to Sentinel to allow MAJ monitoring. Phase init&end: RC=00 if information is successfully transmitted. RC=01: non-transmitted information is stored in the overflow file. Deferred MAJ monitoring The 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. rdjexp Note Parameters after modification by command line are prioritary. Default parameters are only applied if there are no monitoring parameters in the command line. AccountingIntegrator Reference guide 65

66 3 Implement the functions Parameters after modification by command line Default parameters Use with return code (RC) session[differ] session: starts session monitoring differ: deferred monitoring. Saves information in an overflow file. (Unix/Windows) stn_session=no No session monitoring stn_session=yes Instant session monitoring stn_session=yes_ differ Deferred session monitoring (UNIX/Windows) TKSES=NOSESSION No session monitoring TKSES=SESSION Instant session monitoring (MVS) No session monitoring: No information on the session is sent to Sentinel. Phase init: RC=04 - file RDJ_ TPSFILE is created. Phase end: not executed. Instant session monitoring The Rule Engine sends the operation reports to Sentinel to allow session monitoring. Phase init&end: RC=00 if information is successfully transmitted. RC=01: non-transmitted information is stored in the overflow file. Deferred session monitoring The 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. AccountingIntegrator Reference guide 66

67 3 Implement the functions Parameters after modification by command line Default parameters Use with return code (RC) business[differ] business: starts business monitoring differ: deferred monitoring. Saves information in an overflow file. (Unix/Windows) stn_business=no No business monitoring stn_business=yes Instant business monitoring stn_business=yes_ differ Deferred business monitoring (UNIX/Windows) No business monitoring: No information on the session is sent to Sentinel. Phase init: RC=04 - file RDJ_ TPSFILE is created. Phase end: not executed. Instant business monitoring The Rule Engine sends the operation reports to Sentinel to allow business monitoring. Phase init&end: RC=00 if information is successfully transmitted. RC=01: non-transmitted information is stored in the overflow file. Deferred business monitoring The 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. AccountingIntegrator Reference guide 67

68 3 Implement the functions rdjstn Parameters after modification by command line [raz][maj] [session] [business] [differ sendoverflow] raz: starts RAZ monitoring maj: starts MAJ monitoring session: starts session monitoring business: starts business monitoring differ: deferred monitoring. Saves information in an overflow file. sendoverflow: sends information from overflow file instantly. (Unix/Windows) Use with return code (RC) differ mode: The Rule Engine sends the operation reports to Sentinel with a delay to allow monitoring. For each selected monitoring: Phase end: for all but business RC=00: information is stored in the overflow file. sendoverflow mode The Rule Engine sends the operation reports to Sentinel to allow MAJ monitoring. For each selected monitoring: RC=00: information is successfully transmitted. RC=16: non-transmitted information is stored in the overflow file. Note These variables are set by default to No. Sentinel business monitoring Overview The 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: Define the Processing-Context-Out (s) and associated files You can use the default file provided with the product to modify and add new definitions Include the Business monitoring parameter in each definition Example: Me(STN)=DEFAUT, <ME>BusinessMonitoring.seq;BusinessMonitoring=yes AccountingIntegrator Reference guide 68

69 3 Implement the functions 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: Shell script (UNIX) CLP (AS/400) 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 example Caution 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 InterPlay On 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: rdjexp [ews [cra_cr]] 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: AccountingIntegrator Reference guide 69

70 3 Implement the functions 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 Server You can link Rule Engine and the Rule Engine Server by: Creating a new Rule Engine log file for the Rule Engine Server Externalizing variables stn_dep and stn_maj in RDJDEP for the Rule Engine Server. Create a new log file for the Rule Engine Server Adding 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 console Messages from the console that can be added are: C modules made by printf control parameters 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 characteristics The log file must have the the following characteristics: Life cycle: runtime Archival procedure planned The install log file structure (line type with separator. " ") can be interpreted by the BIRT report. Add a keyword according to the environment For a UNIX/WIN environment the following can be added: AccountingIntegrator Reference guide 70

71 3 Implement the functions 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: DDNAME : DD:LOGRDJ DSN : <RDJEXEC>.LOGFSQ.RDJ Externalize variables stn_dep and stn_maj in RDJDEP The 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. Usage rdjdep Command [default] [stn_maj] Description 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) AccountingIntegrator Reference guide 71

72 Manage transformation anomalies 4 AccountingIntegrator manages transformations through its components: Rule Engine Rule Engine Server 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. Reminder about how the Rule Engine works on page 72 Transformation session on page 41 Input-Event in anomaly during transformation on page 73 Input-Event rejected on page 75 Group of Input-Events rejected on page 76 Session stopped on page 77 Transformation errors: Return codes on page 78 Reminder about how the Rule Engine works This consistency of processing and result is maintained through the use of a 'hierarchical' approach to errors in the processing, as follows: Processing Error No anomalies or rejections during transformation The Input-Event is placed in anomaly during transformation The Input-Event is rejected The group of Input-Events is rejected The session is stopped AccountingIntegrator Reference guide 72

73 4 Manage transformation anomalies Transformation Errors: Return codes Transformation 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 No transformation errors Return Code Set 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 transformation The 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. Circumstances The 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 AccountingIntegrator Reference guide 73

74 4 Manage transformation anomalies 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-Event This 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). Consequences Reason 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. AccountingIntegrator Reference guide 74

75 4 Manage transformation anomalies Input-Event rejected The Input-Event is rejected when either: An error occurs during processing in Step E or S All the Transformation Phases using the Input-Event concerned are in error in Step T Circumstances The 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 Consequences Reason Meaning 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 AccountingIntegrator Reference guide 75

76 4 Manage transformation anomalies 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). Circumstances The 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 Consequences Reason Meaning 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 AccountingIntegrator Reference guide 76

77 4 Manage transformation anomalies 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 stopped If the system stops the session, processing is halted, even if there are more Input-Events to process. Circumstances The 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: While the Input-Events are being read in During the sort of the Input-Events During the sort of the Output-Events During aggregation of the Output-Events In the restructuring exit for the Output-Events 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) Consequences Only 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: AccountingIntegrator Reference guide 77

78 4 Manage transformation anomalies 10 (error threshold breached) 12 (configuration error) 16 (system error) Transformation errors: Return codes The 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 No transformation errors Return Code Set 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 AccountingIntegrator Reference guide 78

79 Implement advanced functions 5 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: Audit mono and multi sessions on page 79 Phase-specific recycling of Input-Events in anomaly on page 89 Exits and external calls on page 89 Set up the transformation environment on page 96 Optional environment variables setting on page 99 Audit mono and multi sessions The 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 Enabler How the Input-Events are audited depends on the: Pre-processing and processing that is defined for that type of Input-Event 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. AccountingIntegrator Reference guide 79

80 5 Implement advanced functions 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 Operation Stamping Identifying Stamping code:5 date: 8 time:6 character: 1 counter: 5 Configure the stamping code in the Script file The operation date is in the form YYYYMMDD The stamping time is in the form HHMMSS 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 Keyword Description/Values >Configuration< Section Stamper The value of the stamper code The use of this code allows you to set separate limit values for each type of object that is stamped You must also set the limit values for the stamping counters in tsc.des >Script.Ges< Section Trace_ OSegt Trace_ IEvent Trace The name of the exchange zone to which the Output-Event traces are written The name of the exchange zone to which the Input-Event traces are written 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: AccountingIntegrator Reference guide 80

81 5 Implement advanced functions 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 up to The 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 for each type of trace.to increase this limit, the counter is now in base 36 instead of decimal. Tsc.des: The stamping counter descriptor The 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 D A M N P T R O J Type of Information Audited Audit of an individual Input-Event segment Audit of an aggregated Input-Event segment Audit of an individual modified Input-Event segment Audit of an aggregated modified Input-Event segment Audit of an individual Output-Event Audit of Output-Events aggregated by group Audit of aggregated Output-Events (all groups together) Audit of an individual Input-Event segment in anomaly 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: AccountingIntegrator Reference guide 81

82 5 Implement advanced functions 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; , ,22/03/1999, ; , ,22/03/1999, ; , ,22/03/1999, ; , ,22/03/1999, ; , ,22/03/1999, ; , ,22/03/1999, ; , ,22/03/1999, ; , ,22/03/1999, ; , ,22/03/1999, ; 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. A fixed-length header of 360 characters 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: Header + trace (maximum 4360 characters) written to a file record 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. AccountingIntegrator Reference guide 82

83 5 Implement advanced functions Id. Stamp Trace 25 For a stamping type of TimeStamp, the header in the audit trail for an Input-Event segment has the following format: Id. Stamp Orig 25 Id. Stamp Aggreg 25 Stamper (*) Session Date Time Id. Source Code Code Event Code Code Phase Rule Start End Event Event Group Event Version Instance Segt code Audit Date Date Trace (*) The filler composition depends on the type of rule applied: For Stamping code values M or N, Enrichment rule: Rule name (5) + Start date (8) + empty (7) For Stamping code value A, Aggregation rule: The 20 first characters of the aggregation rule's name max. 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 Id. Stamp Orig Id. Stamp Aggreg Stamper (*) Session Date Time Id. OSegt Source Filler Phase Code Rule Audit Start Date End Date Osegt Trace max. (*) The filler composition depends on the type of rule applied: 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) 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 Trace 19 6 Id. Stamp Orig 19 6 Id. Stamp Aggreg 19 6 Stamper Session Date Time Id. Sender Code Code Event Code Code Phase Rule Start End Event Event Group Event Version Instance Segt Code Audit Date Date Trace For a stamping type of Series, the header in the audit trail for an Output-Event has the following format: max. Id. Stamp Trace Id. Stamp Orig Id. Stamp Aggreg Stamper Session Date Time Oevent index Sender Filler Phase Code Rule Audit Start Date End Date Osegt Trace 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). AccountingIntegrator Reference guide 83

84 5 Implement advanced functions So, if the stamping counter is defined as 10 numeric characters, the filler after each identifier would have to be 14 in length ( = 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: Stamping identifier Identifier of the original segment 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 Stamping identifier Original stamping identifier Aggregation stamping identifier Activated stamping code Activated session code Operation date Operation time Segment (or Output-Event) index number The activated Processing Context-In code Meaning The stamping identifier associated with the trace 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 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 The code set in script.ges (see above) The code set in script.ges. See Mandatory parameter settings on page 46 The operation date in YYYYMMDD format The operation time in HHMMSS format A sequence number for either the segment processed in the session or the Output-Event generated from an original Input-Event The code set in script.ges The following information needs to be supplied only for a trace on an Input-Event segment. AccountingIntegrator Reference guide 84

85 5 Implement advanced functions For traces on an Output-Event, a 146-character filler is inserted to ensure that all headers are of the same length: The Input-Event group code Supply this only if the Group Management option is enabled and if the Input-Event that is processed belongs to a group The name of the Input-Event type processed The version number of the Input-Event processed The Input-Event instance code The segment code A 25-character filler The following items of information are common to all traces that are extracted: The name of the audit rule The name used to extract the trace The start validity date of the audit rule 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 trail Example: In the example below, we are looking for the data that gave rise to the Output-Event bearing the stamping identifier R0087. AccountingIntegrator Reference guide 85

86 5 Implement advanced functions 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: P0425, P0424 resulting from segment traces with the identifier A0072 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. AccountingIntegrator Reference guide 86

87 5 Implement advanced functions Audit rejects and anomalies By 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. Example In 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. AccountingIntegrator Reference guide 87

88 5 Implement advanced functions Relationships To 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. AccountingIntegrator Reference guide 88

89 5 Implement advanced functions 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: 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 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 Enabler Phase-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 Exits The table below shows the exits you can use and what they do: Possible Actions 1 Reformat the Input-Events on receipt of the message This is specific to MQSeries or JMS 2 Restructure the Input-Events 3 Enrich the Input-Events during aggregation AccountingIntegrator Reference guide 89

90 5 Implement advanced functions 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 Yes_C Yes_Cobol Use Activates the C language version of the exit Activates the Cobol language version of the exit Yes_Rdj53 Exit compatible with version 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" AccountingIntegrator Reference guide 90

91 5 Implement advanced functions Rules to follow: 1 Reformatting: Optional parameter If this parameter is not supplied, the exit is not activated Yes: The reformatting exit is activated 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 parameter If this parameter is not supplied, the exit is not activated Yes: The reformatting exit is activated No: The reformatting 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: Create Merge Re-order Delete 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 AccountingIntegrator Reference guide 91

92 5 Implement advanced functions Keyword Description/Values >sys.dat>scriptconfiguration< Section I_Exit_Restructuring_ IEvent Yes_C or No >Script.ges< Section 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 Keyword >ScriptConfiguration< Section E_Exit_Agregation_Cre Description/Values Yes_C or Yes_Cobol or Yes_rdj53 or No Yes_rdj53 is compatible with ITR025 Check and enrich Input-Events before transformation This 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. Parameter settings in script.ges Keyword Description/Values >Configuration< Section Turnoff_Exit_ ISegt No Yes: Turns the exit off AccountingIntegrator Reference guide 92

93 5 Implement advanced functions Check and enrich 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. This exit can be activated while the Processing step (T) is active. Parameter settings in script.ges Keyword Description/Values >Configuration< Section Turnoff_Exit_Rule No Yes: Turns the exit off Identify and check Output-Events This exit enriches or checks the Output-Events, or identifies the output, before the Output-Events are processed. This exit is enabled in AI Enabler. This exit can be activated while the Processing step (T) is active. Parameter settings in script.ges Keyword Description/Values >Configuration< Section Turnoff_Exit_OSegt No Yes: Turns the exit off 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. This exit can be activated while the Processing step (T) is active. Parameter settings in sys.dat AccountingIntegrator Reference guide 93

94 5 Implement advanced functions Keyword >ScriptConfiguration< Section P_Exit_Aggregation_OSegt_Group Description/Values Yes_C or Yes_Cobol or Yes_rdj53 or No 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. Parameter settings in sys.dat Keyword Description/Values >ScriptConfiguration< Section O_Exit_Aggregation_OSegt Yes_C or Yes_Cobol or Yes_rdj53 or No 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: Create Merge Delete Change the contents of Output-Events This exit can be activated while the Output step (S) is active. Parameter settings in sys.dat Keyword Description/Values >ScriptConfiguration< Section O_Exit_Restructuring_OSegt Yes_C or No AccountingIntegrator Reference guide 94

95 5 Implement advanced functions 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 parameter If this parameter is not supplied, the exit is not enabled Yes: The reformatting exit is enabled 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 parameter If this parameter is not supplied, the exit is not enabled Yes: The reformatting exit is enabled No: The reformatting exit is not enabled AccountingIntegrator Reference guide 95

96 5 Implement advanced functions External calls External 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 environment You 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 RDJ_EXIT501_ORACLE_SRV RDJ_EXIT501_ORACLE_USER RDJ_EXIT501_ORACLE_PWD Use Name of the database server to be accessed User name for connecting to the database 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 domains The 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. AccountingIntegrator Reference guide 96

97 5 Implement advanced functions Keyword Description/Values >Configuration< Section 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. Keyword Description/Values >Transformation_Environment<Section #Environment.;Domain;Processing-Context-Out BATCH;DOM1 ;III. BATCH;DOM2 ;JJJ. Rules to follow: Rule Meaning 1 Environment: Required parameter Specifies the name of the session environment 2 Domain: Required parameter Specifies the domain that is activated by the associated environment If 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 redirection Redirection 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. AccountingIntegrator Reference guide 97

98 5 Implement advanced functions 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: Keyword Description/Values Section >Environment_Transformation< #Environment.;Domain;Processing-Context-Out BATCH;DOM1;III. BATCH;DOM2;JJJ. Rules to follow: Rule Meaning 1 Processing-Context-Out: Required parameter if redirection is enabled Specifies the logical name of the exchange zone that is to receive the redirected Input- Event If you do not specify a Processing-Context-Out for the redirected Input-Event, redirection does not take place You can specify more than one Processing-Context-Out for redirected events Specify 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: Keyword Description/Values >Script.Ges< Section AccountingIntegrator Reference guide 98

99 5 Implement advanced functions Keyword IEvent_Redirected (Processing-Context- Out) Detail_Redirection_ IEvent Description/Values The name of the exchange zone to which the redirected Input-Events are written If you have specified more than one Processing-Context-Out for redirected events, define an exchange zone for each output The file containing the data for the report on the redirections that have been effected Optional environment variables setting Procedures use these variables at runtime. You must define them to enable procedures to reference valid values. Variable RDJ_CTRL_DATE Use Check that the Input-Event date is included between 01/01/1900 and 31/12/2099: Y,y O,o N,n (default) RDJ_REVISION Activate the SVN revision number of each source program: YES, OUI YES_H, OUI_H NO (default) RDJ_TPSFILE PSORT Path of the rdjtps.txt file MVS only Select sort tool to use in RDJFIC: DFSPARM (default): DFSORT $ORTPARM: Syncsort AccountingIntegrator Reference guide 99

100 5 Implement advanced functions Variable SORT_CODIF Use MVS only By default, set to CH (EBCDIC characters). Select sort codification to use in RDJFIC: Decimal ZD: zoned decimal (no sign) PD: packed decimal, signed CSF or FS: signed, optionally a floating sign is leading Binary BI: unsigned binary FI: fixed point signed binary FL: signed floating point binary ASCII AST: ASCII numeric with a trailing separate sign ASL: ASCII numeric with leading separate sign AC: unsigned ASCII EBCDIC CH: EBCDIC characters CSL: EBCDIC numeric with leading separate sign CST: EBCDIC numeric with trailing separate sign CLO: EBCDIC numeric with a leading overpunch sign CTO: EBCDIC numeric with a trailing overpunch sign Other AQ: alternate collating sequence RDJ_CALLDYN_[exit name] Call the exit program on dynamic instead of DLL by default: YES, OUI: NO (default): AccountingIntegrator Reference guide 100

101 5 Implement advanced functions Variable RDJ_SIZE_GROUP_ TRACE Use Activate the trace of the group management in buffer: Y,y, O,o N (default) RDJ_SIZE_GROUP_IN Memory size (in bytes or megabytes) of the Input memory buffer of a group: nk nm Default value: 2M RDJ_SIZE_GROUP_ OUT Memory size (in bytes or megabytes) of the Output memory buffer of a group: nk: nm: Default value: 2M RDJ_PACK53 Pack sign behavior: O: the Pack sign behavior is the same than in RDJ53 N (default): SDE_SIZE_MEM_MAX STN_INIT_FILE Memory size (in bytes) of the buffer used by rdjews to generate the ap.cra file. By default: Path of the rdjstn.ini file AccountingIntegrator Reference guide 101

102 Set parameters for MQSeries and JMS implementations 6 This sections contains specific instructions for setting parameters for an MQSeries-based or JMSbased implementations of Rule Engine. The topics described in this section are: Set MQSeries-specific or JMS-specific parameters in script.mqs on page 102 Structure of the messages transmitted on page 103 Read and produce messages on page 104 Messages in anomaly on page 105 Structure of the messages generated on page 105 Use an exit to reformat Input-Event messages and transformation products on page 108 Manage groups with MQSeries or JMS on page 108 Utilities for accessing the MQSeries or JMS exchange zones on page 111 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). Keyword Description/Values >Configuration< Section MQS (LOCAL_ MANAGER) The name of the local manager (for MQSeries) or QCF (for JMS) The maximum length of the name is: 4 alphanumeric characters for MVS (MQSeries only) 48 alphanumeric characters for UNIX AccountingIntegrator Reference guide 102

103 6 Set parameters for MQSeries and JMS implementations Keyword MQS (MODE) MQS (CONVERSION) Description/Values Functioning mode of the Rule Engine in an MQSeries or JMS implementation Immediate (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. Request to convert Input-Event messages Yes: (the default value): The messages are automatically converted No: The Input-Event messages received are not converted MQS(FILE_ LOT_ INCOMPLET) MQS (FILE_ MSG_ UNREADABLE) Name of the queue to which messages from incomplete Input-Event groups are written Name of the queue to which unreadable or suspect Input-Event messages are written Structure of the messages transmitted Messages 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 message In 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: AccountingIntegrator Reference guide 103

104 6 Set parameters for MQSeries and JMS implementations 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 messages At 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... Enabled Disabled A work unit is committed... When all Input-Events belonging to a group have been transformed with no rejections or anomalies After processing each Input-Event Rolling back a work unit: Group Management Option is... Enabled Disabled A work unit is backed out... When one Input-Event in the group is rejected The purpose of backing out at this point is to cancel the products generated by the transformation of other Input-Events in the group No backout is performed AccountingIntegrator Reference guide 104

105 6 Set parameters for MQSeries and JMS implementations Messages in anomaly Unreadable messages A message is unreadable when either: The format of the message does not match the format expected by Rule Engine 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 messages A message is suspect if its BACKCOUNTER exceeds: 2, if it does not belong to a group 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 generated The message context generated for a given product is formed as follows: MsgId is a unique value assigned by Rule Engine MQSeries or JMS CodeCharSetId is set to 0 (zero) The format is obtained from MQSTR 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 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: AccountingIntegrator Reference guide 105

106 6 Set parameters for MQSeries and JMS implementations Data Element Number of Characters Meaning Filler 13 characters 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 Filler 24 characters Number of elements Length of element 1 7 characters Number (N) of elements of the product contained in the message 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 Description of Product Keyword in Compatible Number script.mqs or Product Number script.jms 01 The Input-Event to be transformed IEvent (Sender) AccountingIntegrator Reference guide 106

107 6 Set parameters for MQSeries and JMS implementations Product Description of Product Keyword in Compatible Number script.mqs or Product Number script.jms 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 Input-Events rejected during transformation IEvent_Rejected Modified Input-Events IEvent_Modified 07 Audit traces extracted from the processed Input-Events Trace_IEvent 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 12 Data for report on operation counters Counter_ Transformation 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 AccountingIntegrator Reference guide 107

108 6 Set parameters for MQSeries and JMS implementations Use an exit to reformat Input-Event messages and transformation products The reformatting exit allows you to: Decrypt, decompress and reformat the Input-Event messages as they are received and before you start the Rule Engine MQSeries or JMS native functions. 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.jms Queue= 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. Yes: The reformatting exit is activated No: The reformatting exit is not activated For more information, refer to the guide Rule Engine Exits and External Calls. Manage groups with MQSeries or JMS To 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 AccountingIntegrator Reference guide 108

109 6 Set parameters for MQSeries and JMS implementations 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 using It 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 End-of-group flag 12 characters Sequence number giving the position of the message in the group 1 character Set to F for the last message in the group Filler 51 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 AccountingIntegrator Reference guide 109

110 6 Set parameters for MQSeries and JMS implementations 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 group A group of Input-Events is complete when: The system finishes reading the last message in the group (end-of-group flag = F) The number of messages processed with the same CorrelId equals the sequence number in the final message of the group Define an incomplete group A 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. Keyword Description/Values >Configuration< Section MQS (TimeOut) MQS (FILE_ GROUP_ INCOMPLETE) Maximum time, in seconds, allowed between receiving two messages in the same group If this threshold is exceeded, the system declares the group incomplete Name of the queue to which the system writes those messages that carry incomplete Input-Event groups Reproduce a group To 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: Input-Events placed in anomaly during transformation Rejected Events AccountingIntegrator Reference guide 110

111 6 Set parameters for MQSeries and JMS implementations Modified Input-Events 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-Events Queue= 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 queue Reproduction_group is an optional parameter. If you do not specify it, Rule Engine does not activate group reproduction. Yes: Enables the reproduction of groups 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. AccountingIntegrator Reference guide 111

112 6 Set parameters for MQSeries and JMS implementations Empty queues: rdjcleanmqs, rdjcleanjms Purpose To empty the queues, either on input or output. These queues have the same names as the queues created when you installed the product. Parameters The 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 UNIX/ MVS Queue Queue Name Contained in the Queue Windows Name <br /> (Keyword + Description) 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 OSegt (1): Generated Output-Events associated with Processing- Context-Out 1 RDJ.OSEGT.1 RDJ.OSEGT1 RDJ.OSEGT.1 OSegt (2): Generated Output-Events associated with Processing- Context-Out 2 RDJ.OSEGT.2 RDJ.OSEGT2 RDJ.OSEGT.2 AccountingIntegrator Reference guide 112

113 6 Set parameters for MQSeries and JMS implementations Data UNIX/ MVS Queue Queue Name Contained in the Queue Windows Name <br /> (Keyword + Description) Queue Name OSegt (3): Generated Output-Events associated with Processing- Context-Out 3 RDJ.OSEGT.3 RDJ.OSEGT3 RDJ.OSEGT.3 OSegt (4): Generated Output-Events associated with Processing- Context-Out 4 RDJ.OSEGT.4 RDJ.OSEGT4 RDJ.OSEGT.4 OSegt (5): Generated Output-Events associated with Processing- Context-Out 5 RDJ.OSEGT.5 RDJ.OSEGT5 RDJ.OSEGT.5 OSegt (6): Generated Output-Events associated with Processing- Context-Out 6 RDJ.OSEGT.6 RDJ.OSEGT6 RDJ.OSEGT.6 OSegt (7): Generated Output-Events associated with Processing- Context-Out 7 RDJ.OSEGT.7 RDJ.OSEGT7 RDJ.OSEGT.7 OSegt (8): Generated Output-Events associated with Processing- Context-Out 8 RDJ.OSEGT.8 RDJ.OSEGT8 RDJ.OSEGT.8 AccountingIntegrator Reference guide 113

114 6 Set parameters for MQSeries and JMS implementations Data UNIX/ MVS Queue Queue Name Contained in the Queue Windows Name <br /> (Keyword + Description) Queue Name OSegt (9): Generated Output-Events associated with Processing- Context-Out 9 RDJ.OSEGT.9 RDJ.OSEGT9 RDJ.OSEGT.9 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 AccountingIntegrator Reference guide 114

115 6 Set parameters for MQSeries and JMS implementations Data UNIX/ MVS Queue Queue Name Contained in the Queue Windows Name <br /> (Keyword + Description) 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 AccountingIntegrator Reference guide 115

116 6 Set parameters for MQSeries and JMS implementations Data UNIX/ MVS Queue Queue Name Contained in the Queue Windows Name <br /> (Keyword + Description) 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 AccountingIntegrator Reference guide 116

117 6 Set parameters for MQSeries and JMS implementations Data UNIX/ MVS Queue Queue Name Contained in the Queue Windows Name <br /> (Keyword + Description) 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 AccountingIntegrator Reference guide 117

118 6 Set parameters for MQSeries and JMS implementations Data UNIX/ MVS Queue Queue Name Contained in the Queue Windows Name <br /> (Keyword + Description) 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 Syntax The procedure calls program rdjcleanmqs,rdjcleanjms / RDJCLN, which has the following run-time syntax: UNIX Syntax with MQseries:$EXE/rdjcleanmqs, Local_Manager Queue UNIX Syntax with JMS:$EXE/rdjcleanjms Local_Manager Queue MVS Syntax: //RDJCLEAN EXEC PGM=RDJCLEAN,//PARM=' Local_Manager Queue ' You must supply the parameters in the order shown: Local_Manager:Name of the local queue manager (MQSeries) or QCF (JMS) 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. AccountingIntegrator Reference guide 118

119 6 Set parameters for MQSeries and JMS implementations Stop the session: rdjstopmqs,rdjstopjms / RDJSTO Purpose This 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: Processes it before any of the queued Input-Event messages 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. Parameters The 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. Syntax The procedure calls program rdjstopmqs,rdjstopjms/rdjsto, which has the following run-time syntax. UNIX Syntax with MQSeries: $EXE/rdjstopmqs Local_Manager Queue UNIX Syntax with JMS: $EXE/rdjstopjms Local_Manager Queue 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 AccountingIntegrator Reference guide 119

120 6 Set parameters for MQSeries and JMS implementations Order N Parameter Use 2 Queue The name of the Input-Event queue that is to be processed The 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 Purpose This procedure takes data from a file and creates an Input-Event queue with it in the format expected by the package. Parameters The 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. Syntax The procedure calls the program rdjputmqs,rdjputjms/rdjput, which has the following run-time syntax. UNIX Syntax with MQseries: $EXE/rdjputmqs Local_ Manager Queue File IEvent_Keys Group_Key Root_MsgId Message_ Length Message_Format [Remote_Manager] UNIX Syntax with JMS: $EXE/rdjputjms Local_Manager Queue File IEvent_ Keys Group_Key Root_MsgId Message_Length Message_Format [Remote_Manager] 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: AccountingIntegrator Reference guide 120

121 6 Set parameters for MQSeries and JMS implementations 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 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 (&) Each position value must be in the range Each length value must be in the range A break in the sequence of the values of these fields marks the start of a new Input-Event in the file To indicate a mono-segment Input-Event, set the parameter to MONO 5 Group_Key Specifies the group key If you activated the Group Management option, define in this parameter the position and length of the group code in the file records This key indicates where the break between groups in the file is to be found The system uses the value of this field to build the CorrelId in the messages sent. The maximum length is 24 characters 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 7 Message_ Length 8 Message_ Format The root of the MsgId. Maximum 5 characters The MsgId of the message is built by concatenating this root with the date and time at which the message is sent (Example: SESSN ) The maximum length (in KB) of the messages to be sent Must be in the range KB The format of the message. Values can be STRING or NONE AccountingIntegrator Reference guide 121

122 6 Set parameters for MQSeries and JMS implementations 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: In UNIX with MQSeries: $EXE/rdjputmqs HPX4 RDJ.IEVENT IEvent.seq "1,6&12,7" "25,20" VAC01 16 string In UNIX with JMS: $EXE/rdjputjms HPX4 RDJ.IEVENT IEvent.seq "1,6&12,7" "25,20" VAC01 16 string In MVS: //RDJPUT EXEC PGM=RDJPUTC,// PARM='MQME RDJ.IEVENT DD:IEVENT "1,6&12,7" "25,20" VAC01 16 STRING '//*//CRE DSN=&ENVRDJ.CRE,DISP=SHR//SYSOUT DD SYSOUT=*//SYSPRINT DD SYSOUT=* DD 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: Increase the value of Message_Length so as to decrease the number of messages 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 No transformation errors 0 (zero) 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. AccountingIntegrator Reference guide 122

123 6 Set parameters for MQSeries and JMS implementations Transferring data from a queue to a File: rdjgetmqs,rdjgetjms/rdjget Purpose To create files from data held in a queue. Each file contains a transformation product in the defined format. Parameters Mode_Open_File The Mode_Open_File parameter specifies the mode in which data is to be written to the procedure output file: C = Create mode 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 UNIX /Windows Queue MVS UNIX/Windows in the Queue Name Queue Data File Created/ (Keyword + Name Context File Description) OSegt (0): Generated Output- Events associated with output 0 RDJ.OSEGT.0 RDJ.OSEGT0 OSegt0.seq OSegt0.ctx OSegt (1): Generated Output- Events associated with output 1 RDJ.OSEGT.1 RDJ.OSEGT1 OSegt1.seq Osegt1.ctx OSegt (2): Generated Output- Events associated with output 2 RDJ.OSEGT.2 RDJ.OSEGT2 Osegt2.seq Osegt2.ctx AccountingIntegrator Reference guide 123

124 6 Set parameters for MQSeries and JMS implementations Data Contained UNIX /Windows Queue MVS UNIX/Windows in the Queue Name Queue Data File Created/ (Keyword + Name Context File Description) OSegt (3): Generated Output- Events associated with output 3 RDJ.OSEGT.3 RDJ.OSEGT3 Osegt3.seq Osegt3.ctx OSegt (4): Generated Output- Events associated with output 4 RDJ.OSEGT.4 RDJ.OSEGT4 Osegt4.seq Osegt4.ctx OSegt (5): Generated Output- Events associated with output 5 RDJ.OSEGT.5 RDJ.OSEGT5 Osegt5.seq Osegt5.ctx OSegt (6): Generated Output- Events associated with output 6 RDJ.OSEGT.6 RDJ.OSEGT6 Osegt6.seq Osegt6.ctx OSegt (7): Generated Output- Events associated with output 7 RDJ.OSEGT.7 RDJ.OSEGT7 Osegt7.seq Osegt7.ctx OSegt (8): Generated Output- Events associated with output 8 RDJ.OSEGT.8 RDJ.OSEGT8 Osegt8.seq Osegt8.ctx OSegt (9): Generated Output- Events associated with output 9 RDJ.OSEGT.9 RDJ.OSEGT9 Osegt9.seq Osegt9.ctx OSegt (A): Generated Output- Events associated with output A RDJ.OSEGT.A RDJ.OSEGTA OsegtA.seq OsegtA.ctx AccountingIntegrator Reference guide 124

125 6 Set parameters for MQSeries and JMS implementations Data Contained UNIX /Windows Queue MVS UNIX/Windows in the Queue Name Queue Data File Created/ (Keyword + Name Context File Description) Osegt (B): Generated Output- Events associated with output B RDJ.OSEGT.B RDJ.OSEGTB OsegtB.seq OsegtB.ctx OSegt (C): Generated Output- Events associated with output C RDJ.OSEGT.C RDJ.OSEGTC OsegtC.seq OsegtC.ctx OSegt (D): Generated Output- Events associated with output D RDJ.OSEGT.D RDJ.OSEGTD OsegtD.seq OsegtD.ctx OSegt (E): Generated Output- Events associated with output E RDJ.OSEGT.E RDJ.OSEGTE OsegtE.seq OsegtE.ctx Osegt (F): Generated Output- Events associated with output F. RDJ.OSEGT.F RDJ.OSEGTF OsegtF.seq OsegtF.ctx OSegt (G): Generated Output- Events associated with output G. RDJ.OSEGT.G RDJ.OSEGTG OsegtG.seq OsegtG.ctx OSegt (H): Generated Output- Events associated with output H. RDJ.OSEGT.H RDJ.OSEGTH OsegtH.seq OsegtH.ctx OSegt (I): Generated Output- Events associated with output I. RDJ.OSEGT.I RDJ.OSEGTI OsegtI.seq OsegtI.ctx AccountingIntegrator Reference guide 125

126 6 Set parameters for MQSeries and JMS implementations Data Contained UNIX /Windows Queue MVS UNIX/Windows in the Queue Name Queue Data File Created/ (Keyword + Name Context File Description) OSegt (J): Generated Output- Events associated with output J. RDJ.OSEGT.J RDJ.OSEGTJ OsegtJ.seq OsegtJ.ctx OSegt (Default): Generated Output- Events associated with an output for which there is no exchange zone. RDJ.OSEGT.DEFAULT RDJ.OSEGTZ Osegtdef.seq OSegtdef.ctx IEvent_Modified: Input-Events modified by the session. RDJ.IEVENT.MODIFIED RDJ.IEVMOD ap.modified_ievent modifie.ctx IEvent_Anomaly: Input-Event that causes a transformation anomaly. RDJ.IEVENT.ANOMALY RDJ.IEVANO ap.anomaly_ievent AnoIE.ctx IEvent_Rejected: Input-Events rejected during transformation. RDJ.IEVENT.REJECTED RDJ.IEVREJ ap.rejected_ievent RejectIE.ctx Trace_IEvent: Extracted Input- Event traces. RDJ.TRACE.AUDIT RDJ.TRACES ap.trace trace.ctx Trace_OSegt: Extracted Output- Event traces. RDJ.TRACE.AUDIT RDJ.TRACES ap.trace trace.ctx IEvent_Redirected (I): Redirected Input-Events associated with output I. RDJ.IEVENT.REDIRECTED.I RDJ.IEVRDI RedirIEI.seq RedirIEI.ctx AccountingIntegrator Reference guide 126

127 6 Set parameters for MQSeries and JMS implementations Data Contained UNIX /Windows Queue MVS UNIX/Windows in the Queue Name Queue Data File Created/ (Keyword + Name Context File Description) IEvent_Redirected (J): Redirected Input-Events associated with output J. RDJ.IEVENT.REDIRECTED.J RDJ.IEVRDJ RedirIEJ.seq RedirIEJ.ctx Detail_Anomaly_ Rejection_ IEvent: Report on details of transformation anomalies. RDJ.DETAIL.ANOMALY RDJ.DETANO ap.detail_anomaly_ Reject_IEvent detano.ctx Detail_Redirection_ IEvent: Report on details of redirections. RDJ.DETAIL.REDIRECTION RDJ.DETRED ap.detail_redirected_ IEvent DetRedir.ctx Detail_ Transformation: Report on details of results of transformation. RDJ.DETAIL.TRANSFORMATION RDJ.DETTRA ap.detail_ Transformation DetTrans.ctx Counter_ Transformation: Report on transformation counters. RDJ.TRANSFORMATION. COUNTER RDJ.CNTTRA ap.transformation_ Counter Counttra.ctx MQS (FILE_ GROUP_ INCOMPLETE) Groups of Input- Events that were incomplete when read. RDJ.INCOMPLETED.GROUP RDJ.GRPANO IncompletedGroup IncompletedGroup.ctx Account_Log RDJ.LOG.ACCOUNT RDJ.LOGACC Ap.LogAccount LogAccount.ctx The SIC validation procedure uses the files of the Context message for Windows and UNIX platforms only. AccountingIntegrator Reference guide 127

128 6 Set parameters for MQSeries and JMS implementations Syntax The procedure calls program rdjgetmqs,rdjgetjms / RDJGET, which has the following run-time syntax: UNIX Syntax with MQSeries: $EXE/rdjgetmqs Local_Manager Queue Conversion Mode_Open_File Product_File [Message_Context_File] UNIX Syntax with JMS: $EXE/rdjgetjms Local_Manager Queue Conversion Mode_Open_File Product_File [Message_Context_File] MVS Syntax: //RDJCLEAN EXEC PGM=RDJGETC,// PARM=' Local_ Manager Queue Conversion Mode_Open_File -// [Message_Context_File]' Product_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 C: The data in the messages is converted 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 C:The file is opened in Create mode 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 Under UNIX with MQSeries: $EXE/rdjgetmqs HPX4 RDJ.ME.1 C A OSegt1.prod OSegt1.ctx AccountingIntegrator Reference guide 128

129 6 Set parameters for MQSeries and JMS implementations Under UNIX with JMS: $EXE/rdjgetjms HPX4 RDJ.ME.1 C A OSegt1.prod OSegt1.ctx 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 No transformation errors 0 (zero) 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: MQM_HOME refers to the environment of the product MQSeries server HOME refers to the user's home directory Generate the JNDI file using JMSAdmin This generation is used to define JMS objects in relation to MQSeries objects. To generate the JNDI file: 1. Create the JNDI folder on page Load the JMS environment (UNIX only) on page 130 AccountingIntegrator Reference guide 129

130 6 Set parameters for MQSeries and JMS implementations 3. Update the file JMSAdmin.config on page Create the JMS objects definition file using the editor on page Execute the JMSAdmin utility on page Check the generation of the JNDI file in the JNDI folder on page 135 Create the JNDI folder The 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.config The file JMSAdmin.config is in the directory <MQM_HOME>/java/bin Modify the following variables in the file JMSAdmin.config : INITIAL_CONTEXT_FACTORY describes the JMS objects in a "flat" file of type fscontext. See example below. 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 AccountingIntegrator Reference guide 130

131 6 Set parameters for MQSeries and JMS implementations # 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 AccountingIntegrator Reference guide 131

132 6 Set parameters for MQSeries and JMS implementations # 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 editor Manually 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: <HOSTNAME> : hostname of the UNIX/WIN machine hosting MQSeries <PORT> : port listener MQ number default : 1415 <JMS_CHL> : name of channel between JMS and MQSeries <QMGR_NAME> : name of the MQSeries queue manager for the environment <RDJ_EXEC> (*) <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) AccountingIntegrator Reference guide 132

133 6 Set parameters for MQSeries and JMS implementations 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.1) qmgr(<qmgr_name>) QU(<QRDJ_PREF>.OSEGT.1) DEFINE Q(<QRDJ_PREF>.OSEGT.2) qmgr(<qmgr_name>) QU(<QRDJ_PREF>.OSEGT.2) DEFINE Q(<QRDJ_PREF>.OSEGT.3) qmgr(<qmgr_name>) QU(<QRDJ_PREF>.OSEGT.3) DEFINE Q(<QRDJ_PREF>.OSEGT.4) qmgr(<qmgr_name>) QU(<QRDJ_PREF>.OSEGT.4) DEFINE Q(<QRDJ_PREF>.OSEGT.5) qmgr(<qmgr_name>) QU(<QRDJ_PREF>.OSEGT.5) DEFINE Q(<QRDJ_PREF>.OSEGT.6) qmgr(<qmgr_name>) QU(<QRDJ_PREF>.OSEGT.6) DEFINE Q(<QRDJ_PREF>.OSEGT.7) qmgr(<qmgr_name>) QU(<QRDJ_PREF>.OSEGT.7) DEFINE Q(<QRDJ_PREF>.OSEGT.8) qmgr(<qmgr_name>) QU(<QRDJ_PREF>.OSEGT.8) DEFINE Q(<QRDJ_PREF>.OSEGT.9) qmgr(<qmgr_name>) QU(<QRDJ_PREF>.OSEGT.9) 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) AccountingIntegrator Reference guide 133

134 6 Set parameters for MQSeries and JMS implementations 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 utility To 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> AccountingIntegrator Reference guide 134

135 6 Set parameters for MQSeries and JMS implementations Check the generation of the JNDI file in the JNDI folder To 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 Mar 18 16:22.bindings rs37:/home/mqm/jndi-rh> Update the RuleEngine JMS runtime environment You 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 AccountingIntegrator Reference guide 135

136 6 Set parameters for MQSeries and JMS implementations 5724-H72 (C) Copyright IBM Corp. 1994, 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( ) + : MAXMSGL( ) + : 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. Creation of a local queue 5724-H72 (C) Copyright IBM Corp. 1994, ALL RIGHTS RESERVED. Démarrage de MQSC pour le gestionnaire de files d'attente XRDJ.TRUNK.SIMU. 1 : DEFINE QLOCAL(<QRDJ_PREF>.OSEGT.0) REPLACE + : DESCR('OSegt queue in output 0 of RDJ') + : DEFPSIST(YES) + : MAXDEPTH( ) + : MAXMSGL( ) + : 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. Creation of a local queue 5724-H72 (C) Copyright IBM Corp. 1994, ALL RIGHTS RESERVED. Démarrage de MQSC pour le gestionnaire de files d'attente XRDJ.TRUNK.SIMU. Etc 3. Create the channel between JMS and MQSeries: <JMS_CHL> AccountingIntegrator Reference guide 136

137 6 Set parameters for MQSeries and JMS implementations <RDJ_EXEC>/script>runmqsc <QMGR_NAME> 5724-H72 (C) Copyright IBM Corp. 1994, ALL RIGHTS RESERVED. Démarrage de MQSC pour le gestionnaire de files d'attente 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] lola(hareng):/home/hareng>5724-h72 (C) Copyright IBM Corp. 1994, ALL RIGHTS RESERVED. Check the monitoring: port 1415: lola(hareng):/home/hareng>grep 1415 /etc/services esg2_integratorpool /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. AccountingIntegrator Reference guide 137

138 6 Set parameters for MQSeries and JMS implementations The machine hosting MQSeries is not necessarily the same as the one hosting Rule Engine. To change the machine hosting MQSeries: Define the same MQSeries objects (Queue Manager, Prefixe, Channel, Port listener) Modify the JNDI file: Replace the value of <HOSTNAME> in the JNDI folder using one of the following methods: o o M1 not recommended: make this change directly in the generated file.bindings of the JNDI file. 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 Cause : MQ_EXTDIRS does not contain all the files *.jar (wrapper + IBM) Error code 9001 Rdjcleanjms.msg : UNABLE TO CONNECT TO THE LOCAL MANAGER 'XRDJ.TRUNK.SIMU': ERROR CODE Cause : Wrong URL in jndi.properties / valeur de java.naming.provider.url Error code 9002 Rdjcleanjms.msg : UNABLE TO CONNECT TO THE LOCAL MANAGER 'XRDJ.TRUNK.SIMU': ERROR CODE Cause: URL Connection error / check information in JNDI QCF file (host,qmgr..) Example: Wrong host (sun30 instead of lola) AccountingIntegrator Reference guide 138

139 Standard reports 7 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 MVS Description When Produced Name Name transcnt.edi CNTTRA Transformation statistics dettrans.edi DETTRA Transformation details detano.edi DETANO Transformation anomalies detredir.edi DETRED Redirected Input- Events ieagrcnt.edi CNTAGI Input-Event aggregation counters osagrcnt.edi CNTAGO Output-Event aggregation counters accntlog.edi LOGACC Output-Event account log This file exists at all times, but may be empty This file exists at all times, but may be empty This file exists at all times, but may be empty This file exists at all times, but may be empty This report is only produced if the Aggregate Input-Events option is enabled This report is only produced if the Aggregate Output-Events option is enabled 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 This file exists at all times, but may be empty - DETAGI (*) Input-Event aggregation details This report is only produced if the Aggregate Input-Events option is enabled AccountingIntegrator Reference guide 139

140 7 Standard reports UNIX/Windows MVS Description When Produced Name Name 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: Rule Engine produces files containing the information that is to be printed 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 appearance All 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. Statistics This 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 AccountingIntegrator Reference guide 140

141 7 Standard reports It makes use of the ap.transformation_counter intermediate data file. The report provides statistics by: Input-Event type (counters TC2 and TC3) Input-Event and segment types (counters TC1,TC4, and TC5 when the group is rejected) TC1 counters Title: TC1 COUNTERS REPORT A new table is started on a change of value in the following set of variables: Group code: The group code for the current Input-Event Input-Event code: The type of the current Input-Event 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 Domain Phase Segment Rule TR Meaning Name of the domain activated for this session Name of the phase activated in the session for this Input-Event type Name of the segment associated with the current Input-Event type Name of the rule applied to the segment named in the previous column Rule type applied to the segment: 0: (Zero), a Enrichment-Rule was applied 1: A Transformation-Rule was applied 2: An audit rule was applied Start Date and End Date Output-Events Anomalies Rules Start and end dates for the validity of the version of the rule Number of Output-Events generated, if a Transformation-Rule was applied Number of anomalies detected when a rule was applied Number of times the rule was applied to this segment type. This is the number of segments processed AccountingIntegrator Reference guide 141

142 7 Standard reports TC2 counters Title: TC2 COUNTERS REPORT A new table is started on a change of value in the following set of variables: Group code: The group code for the current Input-Event (providing Batch Management option is activated) Input-Event code:the type of the current Input-Event 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 Input-Events Delivered Input-Events Rejected Meaning Number of Input-Events (as named in the report header) read (delivered) during the session 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 REPORT A new table is displayed for each set of : Group code: The group code for the current Input-Event Input-Event code: The type of the current Input-Event 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. AccountingIntegrator Reference guide 142

143 7 Standard reports Column Name Input-Events Delivered Input-Events Rejected Meaning Number of Input-Events (as named in the report header) read (delivered) during the session 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 Title: TC4 COUNTERS REPORT A new table is started on a change of value in the following set of variables: Group code: The group code for the current Input-Event Input-Event code: The type of the current Input-Event 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 Segment Segments Delivered Segments Rejected Meaning Name of the segment type associated with the Input-Event that was processed in the session Number of segments of the above type, delivered in the session, for the Input- Event type named in the report header Number of segments of the above type that gave rise to a processing anomaly AccountingIntegrator Reference guide 143

144 7 Standard reports TC5 counters Title: TC5 COUNTERS REPORT A new table is started on a change of value in the following set of variables: Group code: The group code for the current Input-Event Input-Event code: The type of the current Input-Event 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 Segment Segments Rejected Meaning Name of the segment type associated with the Input-Event that was processed in the session Number of segments of the above type that gave rise to a processing anomaly of group Transformation details Title: TRANSFORMATION DETAIL In 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: Contents of the processed segment on page 145 Properties and contents of the Output-Event produced on page 146 Contents of the modified segment on page 146, if an Enrichment-Rule is applied. AccountingIntegrator Reference guide 144

145 7 Standard reports Transformation detail Header The header for each of these three tables contains the following information Label Meaning Input-Event Code Input-Event Version Instance (optional value) Name of the type of Input-Event processed Version number of the Input-Event type processed Instance code identifying the Input-Event processed Group (optional value) Code for the group to which the processed Input-Event belongs Segment N Segment Status Sequence number of the segment within the Input-Event processed Status of the segment at the time that the Transformation-Rule is applied: Delivered:The contents of the segment have not been transformed by a Enrichment-Rule Modified:The contents of the segment have been transformed by a Enrichment-Rule Segment Code Domain Phase Rule Code Rule Version Name of the type of segment processed Name of the active domain The name of the phase that was executed Name of the rule applied Start and end dates for the validity of the version of the rule that was applied Contents of the processed segment This report displays the values of each of the fields that make up the processed segment. The table below lists these fields. Column Name Symbolic Field Name Meaning Name of the field in the structure. AccountingIntegrator Reference guide 145

146 7 Standard reports Column Name Label Field Value Meaning Description of the field. 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 produced This table is preceded by the sub-title: Output-Event(s) Produced by the Segment and contains the following information: Output-Event number: Order number of the Output-Event in the Transformation-Rule Financial-Case number:order number of the Financial-Case in a Transformation-Rule Mapping Rule number:order number for the Mapping Rule within the Output-Event in a Transformation-Rule Aggregation-Rule:Name of the Aggregation-Rule (if aggregation is activated and the Rule applied) Version:Dates delimiting the validity period in which the Rule is applicable Audit-Rule:Name of the Audit-Rule (if auditing is activated and the Rule applied) Contents of the modified segment This 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 REPORT This 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. AccountingIntegrator Reference guide 146

147 7 Standard reports The information is presented in the following blocks: General information The Input-Event identifiers The anomaly identifiers A description of the rule System identifiers The content of the segment Certain blocks of information may be empty, depending on the type of anomaly found. General information This information identifies the anomaly within the anomalies file: Label Displayed Anomaly Number Input-Event in Error Segment Sequence Number Meaning Sequence number of the anomaly. Identifies the anomaly as the n th found in the session Sequence number of the Input-Event in error. Identifies the Input-Event as the n th found to be in anomaly in the session Sequence number of the segment within the Input-Event. Identifies it as the n th segment in the processed Input-Event Input-Event identifiers This information identifies the Input-Event in anomaly: Label Displayed Group Code Input-Event Code Input-Event Version Input-Event Instance Code Meaning Code of the group to which the Input-Event belongs (optional information) Name of the type of Input-Event processed The version number of the Input-Event processed Instance code of the Input-Event in anomaly (optional information) AccountingIntegrator Reference guide 147

148 7 Standard reports Anomaly identifiers This information allows a diagnosis of the problem with the Input-Event. Display label Anomaly Type Meaning The anomaly type may be one of the following: Rule: The execution of a rule was terminated by an anomaly Input-Event rejected: The Input-Event being processed was rejected Generation Level The point at which the anomaly was detected: Principal:The anomaly found causes the Input-Event to be placed in anomaly (or rejected) Secondary: The anomaly described is caused by a principal anomaly or relates to an anomaly found earlier AccountingIntegrator Reference guide 148

149 7 Standard reports Display label Origin of rejection Meaning Reason the Input-Event was rejected (if the anomaly type is Input-Event rejected): Identification of Input-Events: The Input-Event type that was to be processed could not be identified Identification of the segment: One of the Input-Event segments could not be identified Input-Event check: A check that was applied to the Input-Event (through an exit) failed All phases in anomaly: The execution of each of the phases associated with the Input-Event type was terminated by an anomaly Balance at Input-Event level: The balance check at Input-Event level failed Output-Event check: An Output-Event check (through an exit) failed Segment audit: The application of an audit rule to a segment caused an anomaly Phase recycling: The Input-Event was recycled and the application of the phase is in anomaly 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 Balance at group level: The balance check at group level failed Error code Error and additional description The code of the error detected Description of the anomaly Phase code Domain code Segment code Name of the phase in which the error occurred. Optional information Name of the domain that was active when the anomaly occurred Type of segment found to be in anomaly during processing AccountingIntegrator Reference guide 149

150 7 Standard reports Description of the anomaly This information identifies precisely the processing that was underway when the anomaly occurred. The information supplied varies with the type of processing: Processing in anomaly Enrichment-Rule Output-Event generation rule (Transformation- Rule) If Detection Level = Financial-Case If Detection Level = Mapping Rule Segment audit Segment aggregation Output-Event audit Information displayed 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) Rule code, that is, the name of the Transformation-Rule that was applied Rule version, that is, the start and end dates that define the period of validity of the version of the rule Detection level: execution Financial-Case or Mapping Rule Priority 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) 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) 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) 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 rule Information on the Transformation-Rule that generated the Output- Event: name, rule version, Financial-Case number, Mapping Rule order, Output-Event structure AccountingIntegrator Reference guide 150

151 7 Standard reports Processing in anomaly Output-Event Aggregation Balancing check on Output-Events (at rule level) Enrichment of the Output-Event by an exit Accounting check on an Output-Event Information displayed 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 rule Information on the Transformation-Rule that generated the Output- Event: name, rule version, Financial-Case number, Mapping Rule order, Output-Event structure 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 Information on the Transformation-Rule that generated the Output- Event: name, rule version, Financial-Case number, Mapping Rule order, Output-Event structure 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 identifiers This is the diagnostic information that the Axway support staff will require, if you need support. Contents of the segment This 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 Field code Field label Meaning Name of the field in the structure Description of the field in the structure AccountingIntegrator Reference guide 151

152 7 Standard reports Column Name Field position Field length Field data type Field Value Meaning Position of the field in the structure Length of the field in the structure Internal data type of the field in the structure Value of the field in the current segment This 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 REPORT In the script.ges file, set the parameter: PRINT_REDIRECTION_IEvent to YES to activate the Inputevent 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. The table below shows the information contained in the columns of this table: AccountingIntegrator Reference guide 152

153 7 Standard reports Column Name Input- Event Version Instance Domain Output Meaning Name of the type of Input-Event that was redirected in this session, within the current group type Version number of the type of Input-Event that was redirected in this session, within the current group type Instance code of the redirected Input-Event Name of the domain that triggered the redirection Name of the output to which the Input-Event was redirected This output is found in script.ges under IEvent_Redirected (Processing-Context- Out) Input-Event aggregation counters File specific This 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: Input-Event type 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 Report A new table is started on a change in the value of the group code. 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: AccountingIntegrator Reference guide 153

154 7 Standard reports Column Name Input-Event Code Input-Event Version Read Rejected Result Meaning Name of the type of Input-Event processed The version number of the Input-Event processed Number of this type of Input-Event read during the session Number of this type of Input-Event rejected during the session Number of Input-Events resulting from the aggregation Aggregation Counters by Segment Title: Segment Aggregation Counters Report A new table with the following set of variables is generated for each separate element in the group: Group code:the group code for the current Input-Event Input-Event code:the type of the current Input-Event 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 Segment code Rule Code Rule Start and Finish Read Rejected Result Meaning Name of the type of Input-Event segment processed Name of the aggregation rule applied to the segment. Optional information Start and end dates for the validity of the version of the rule Number of segments read for this type of Input-Event Number of segments rejected for this type of Input-Event Number of segments resulting from aggregation for this type of Input- Event AccountingIntegrator Reference guide 154

155 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). 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 Output Rule Code Rule Start and Finish Read Result Meaning Name of the output associated with the Output-Events processed Name of the aggregation rule applied to the Output-Events. Optional information Start and end dates for the validity of the version of the rule Number of Output-Events read Number of Output-Events resultialso ng from the aggregation Account Log This report concerns the: Logical journal: accntlog_log.edi (LOGACCL on MVS) ; 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. AccountingIntegrator Reference guide 155

156 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 report The information is laid out in a header and a detail list. Account Log - Header The header provides the following information: Heading GROUP CODE INSTANCE CODE Meaning Code for the group processed This is displayed if the Group Management option is enabled Code for the instance of the Input-Event. The field may be empty Account Log - Detail lines Meaning OUTPUT-EVENT ACCOUNTING REFERENCES ACCOUNT TOTAL DEBITS TOTAL CREDITS Meaning Number of the Output-Event produced Values of the account references extracted from the Output-Event The values are separated by semi-colons (;) Account number Total debits (if any) Total credits (if any) Compensation Log This 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. AccountingIntegrator Reference guide 156

157 7 Standard reports Title: Compensation LOG report The information is laid out in a header and a detail list. Compensation Log - Header The header provides the following information: Heading GROUP CODE INSTANCE CODE PROCESSING-CONTEXT- OUT Meaning Code for the group processed This is displayed if the Group Management option is enabled Code for the instance of the Input-Event. The field can be empty Subtotal of debits calculated from the beginning of the Input- Event Compensation Log - Detail lines Heading OUTPUT-EVENT DEBIT AMOUNT CREDIT AMOUNT ACCOUNTING REFERENCES ACCOUNT TOTAL DEBITS TOTAL CREDITS Meaning Output-Event code or number: C1 compensation at rule level C2 compensation at Input-Event level C3 compensation at group level Debit amount for the Output-Event Credit amount for the Output-Event Values of the account references extracted from the Output-Event The values are separated by semi-colons (;) Account number Total debits (if any) Total credits (if any) AccountingIntegrator Reference guide 157

158 7 Standard reports Counter summary This report summarizes the Input-Event processing performed during the session. It provides transformation statistics by: Input-Event type 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 Input-Event Segment Rule Rule Start and Finish Read Valid Rejected Output-Event Meaning Name of the type of Input-Event that was redirected in this session, within the current group type Name of the segment belonging to the given Input-Event Name of the Rule applied to the above segment Start and end validity dates for the rule applied Number of segments read during the session Number of valid segments during the session Number of segments rejected during the session Number 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 report This 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: AccountingIntegrator Reference guide 158

159 7 Standard reports Input-Event Aggregation-Rule 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: TYPE AGREG CRE: 2 possible values: EXTRACRE: aggregation extra-cre INTRACRE: aggregation intra-cre (refer toinput-event aggregation counters File specific on page 153) CODE REGLE: Code for the Aggregation-Rule applied VERSION: Validity period for the Aggregation-Rule applied. CRITERES D AGREGATION:Aggregation criteria Each table ends with a Total line, which gives the total for that table. The information contained in the columns of this table is set out as follows: Column Name Input-Event identifier Amount1 Amount2 Amount3 Amount4 Amount5 Meaning Input-Event name Amount, numbered 1, read from the Input-Event Amount, numbered 2, read from the Input-Event Amount, numbered 3, read from the Input-Event Amount, numbered 4, read from the Input-Event Amount, numbered 5, 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 report This 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. AccountingIntegrator Reference guide 159

160 7 Standard reports It provides the following details of the aggregation process: Account Direction code Sign 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: Rule aggregation on the amounts to aggregate Valid accounting checks for : Account Amount Direction Sign Title: OUTPUT-EVENT AGGREGATION DETAIL REPORT A new table with the following details is generated for each separate Output-Event the in group: Account: Account number Direction: Direction code Sign: Sign for the amount 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 REFERENCE CREDIT DEBIT TOTAL NUMBER Meaning Output-Event reference read Amount read from an individual Output-Event with a credit direction code Amount read from an individual Output-Event with a debit direction code Total and direction code of the aggregated Output-Event Number of Output-Events included in the aggregation The report only displays a single debit or credit total. AccountingIntegrator Reference guide 160

161 7 Standard reports Reformatting using exits You 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 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]. AccountingIntegrator Reference guide 161

162 BIRT reports 8 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: Standardize the reports creation mode. Make user modifications easier. Select different file formats (PDF, Word, HTML, Excel...). Take into account multi-encoding (Latin, UTF-16). Runtime prerequisites: BIRT Java 1.6 BIRT process The BIRT reporting tool includes two elements: A design tool (Report Designer) to create the report from one or more data sources. 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: The Rule Engine produces the intermediate files. The reporttool utility creates intermediate files that are compatible with BIRT. 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. AccountingIntegrator Reference guide 162

163 8 BIRT reports Report names and activation conditions BIRT 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 OSegtAggregationCounter Input-Event aggregation counters Output-Event aggregation counters If the Aggregate Input-Events option is enabled If the Aggregate Output-Events option is enabled LogAccount Output-Event account log If the Accounting processing option is enabled RuleCounter AccountingAggregation Input-Event processing summary by Rule Output-Event aggregation details At all times, but can be empty If the Output-Event aggregation option is enabled BIRT directories In the Rule Engine environment, BIRT uses the following directory tree structure: <RDJ_HOME> tools/utl/lib reporttool directories (jar) <RDJ_EXEC> script dat reporttool.cmd and rdjexp shells (including BIRT calls) Input files (CSV) used in the datasets AccountingIntegrator Reference guide 163

164 8 BIRT reports utl edi reporttool.properties parameter file rptdesign report description files Product reports Additional environment variables are defined in the reporttool.cmd file in the.script directory. Define the report properties The 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: ISO UTF-8 UTF-16LE 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 AccountingIntegrator Reference guide 164

165 8 BIRT reports Item Property Description report.format.default Report default formats: pdf html xls doc ps ppt Report activation (0/1: deactivate/activat e) script.file report.activated.accountingaggregation Path to the script.fic file AccountingAggregation report report.activated.detailanomaly report.activated.detailieventaggregation report.activated.detailtransformation report.activated.ieventaggregationcounte r report.activated.ieventredirections report.activated.logaccount report.activated.osegtaggregationcounte r report.activated.phyaccount report.activated.rulecounter report.activated.transformationcounter DetailAnomaly report DetailIeventAggregation report DetailTransformation report IEventAggregationCounter report IEventRedirections report LogAccount report OSegtAggregationCounter report PhyAccount report RuleCounter report TransformationCounter report AccountingIntegrator Reference guide 165

166 8 BIRT reports Item Property Description 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 file DataSourceHome 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 file URLImage 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 file ValeurParam Parameter value in the rtdesign file Report modification prerequisites Before 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 display Each report is described in a file with a rptdesign file name extension (for example: DetailAnomaly.rptdesign).The file is located in the.tools directory. AccountingIntegrator Reference guide 166

167 8 BIRT reports 1. Log in the BIRT interface. 2. Select File > File Open. 3. Modify and visualize the report. 4. Click Save. Use styles All 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 images You 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. AccountingIntegrator Reference guide 167

168 8 BIRT reports Define report labels You define the report labels in the file resource.properties file and thus can easily localize them. Each language corresponds to a specific properties file: resource_fr.properties: French resource file 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. AccountingIntegrator Reference guide 168

169 Implement the Rule Engine using permanent files 9 This section describes how to set up the implementation of the product via permanents files and tables. Overview on page 169 Script.ges: Syntax and commands on page 169 Optional table updates on page 173 Overview The implementation parameter settings are held in the following sets of files: Files updated automatically through transfers from AI Enabler Script files that describe the production configuration. Update the latter set of files to match your production environment. These files are: script.ges:implementation script mvt.mvt: Rules configurations, Tables and Variables resulting from the exchange sys.dat: Functional context generated by the sender usr.dat: Transformation-Domains resulting from the exchange Script.ges: Syntax and commands Syntax You set the parameters by assigning values to keywords. These keywords are divided into sections. For example: >Configuration< DEFINE DAT = "<RDJ_EXEC>/dat" # # Session configuration AccountingIntegrator Reference guide 169

170 9 Implement the Rule Engine using permanent files 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 used For example: >Configuration<# # Configuration of stepsstep= IPO# I_Exit_Restructuring_ IEvent= No AccountingIntegrator Reference guide 170

171 9 Implement the Rule Engine using permanent files 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 commands Commands Define Include Display Purpose Defines variables The variables are local to the transformation or extraction run Includes another script in the current one Displays a comment during execution Define variables in the >Script.ges< section You can use the variables as follows: In the script, to avoid repeating a directory name that is common to more than one exchange zone In the Transformation-Rules (variables with different initialization periods) Define Variable_Name = "Variable_Value" Variable_Name: Specifies the name of the variable 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> AccountingIntegrator Reference guide 171

172 9 Implement the Rule Engine using permanent files Important Variables: Variable THIS_ FILE Name Use Defined automatically Indicates the current script THIS_ LINE Defined automatically Indicates the current line number in the script REF Frequently used. Sometimes indicates a reference If 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< section Inserting a script file allows you to use values already defined in another file. Include "File_Name","Section_Name" File_Name:Specifies the name of the file containing the keywords that are to be included 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 comment This 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. AccountingIntegrator Reference guide 172

173 9 Implement the Rule Engine using permanent files Optional table updates The 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 file The update file must be saved in: $RDJ_EXEC/dat directory for UNIX %RDJ_EXEC%\dat directory for Windows <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: arguments up to 128 characters long 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 file The mvt.mvt is a sequential file composed of two sections: AccountingIntegrator Reference guide 173

174 9 Implement the Rule Engine using permanent files Header: This is a two-line description of the table, that is, the table name and characteristics of the argument and value 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 characters The 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 fields Note 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 AccountingIntegrator Reference guide 174

175 9 Implement the Rule Engine using permanent files Field Position Length Value Update code 36 1 Type of update: If the line contains: 0: The table name, header code and update code, 0 corresponds to a request to delete the entire table. 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 table 2: Requests the modification of an internal table SPACE Automatically handled by the update program (char.): 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 access N: 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: N: Numeric D: Date A: Alphanumeric Argument length 41 2 Length of the table entry argument to search for (two numeric characters depending on the data class): Between 01 and 17 for Numeric and Alphanumeric Either 06 or 07 for Date AccountingIntegrator Reference guide 175

176 9 Implement the Rule Engine using permanent files Field Position Length Value Value class 43 1 Data class of the table entry value to search for: N: Numeric D: Date A: Alphanumeric Note: You can only change the characteristics of the table if it does not contain any table entries already. Value length Table header label Table check 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: Between 1-30 alphanumeric characters Set the code : Y: to activate the check on the existence of the Table N: to deactivate the check on the existence of the Table BLANK: default value Header syntax: Tables with arguments exceeding 17 characters The 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. Field Position Length Value Table name 4 8 Name of the table that you want to update AccountingIntegrator Reference guide 176

177 9 Implement the Rule Engine using permanent files Field Position Length Value Update code 36 1 Type of update: If the line contains: 0: The table name, header code and update code, 0 corresponds to a request to delete the entire table. 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 table 2: Requests the modification of an internal table SPACE Automatically handled by the update program (char.): 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 access N: 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: N: Numeric D: Date 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: N: Numeric D: Date A: Alphanumeric Note: You can only change the characteristics of the table if it does not contain any table entries already. AccountingIntegrator Reference guide 177

178 9 Implement the Rule Engine using permanent files Field Position Length Value Value length Table header label Table Check 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: between 1-30 alphanumeric characters Set the code as follows: Y: Activates ExistenceTable check N: Disables ExistenceTable check BLANK: If you do not specify a code Table entry syntax: Tables with arguments limited to 17 characters The 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 fields Note 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 table entry. Field Position Length Value 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 valid Express this date in the format CYYMMDD AccountingIntegrator Reference guide 178

179 9 Implement the Rule Engine using permanent files Field Position Length Value 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: P1 P2 P3 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: Y: Activates fast access N: Disables fast access BLANK: If you do not specify a code, Rule Engine applies the default value, that is, Y. Table entry value and associated comments 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. AccountingIntegrator Reference guide 179

180 9 Implement the Rule Engine using permanent files Table entry syntax: Tables with arguments exceeding 17 characters The 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 fields Note 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 table entry. Field Position Length Value 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 valid Express 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: Table argument: suffix A1 or A2 Value of table entry: suffix P1, P2, P3 or P4 AccountingIntegrator Reference guide 180

181 9 Implement the Rule Engine using permanent files Field Position Length Value 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 access N: Disables fast access BLANK: If you do not specify a code, Rule Engine applies the default value, that is, Y. Table entry value and associated comments 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: By adding a BAMMCD argument By changing the DTMM05 argument To 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. AccountingIntegrator Reference guide 181

182 9 Implement the Rule Engine using permanent files 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 rdjmaj The 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: Report on the content of the update file: listmvt.edi 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. AccountingIntegrator Reference guide 182

183 Appendices 10 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: Can encode on a single byte a great number of unrecognized characters Cannot encode graphical characters that are defined on 4 bytes. AI Enabler characteristics Before 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. Restrictions You are not allowed to: Enter UTF-16 characters in objects identifiers. They can only contain ASCII characters. 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). Use packed data in UTF-16 Folders. Enter more than 110 characters (220 bytes) in the argument of a user table entry. AccountingIntegrator Reference guide 183

184 10 Appendices Rule Engine In the Rule Engine, the following files are in UTF-16 format: Configuration files forwarded to the Rule Engine (ctx.mvt and mvt.mvt files). 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. Component files (Output-Events, anomalies, reports) Exits and external calls have been adapted to process UTF-16 data. Restrictions You can only use TABLEL table files. The Turbo version is not available in this mode. Terminology The 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 Engine Rule 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 aig.fmt cptagrc.fmt cptagrm.fmt detme.fmt MVS DETANO CNTAGI CNTAGO DETTRA AccountingIntegrator Reference guide 184

185 10 Appendices Windows / UNIX cpttrad.fmt etatcpt_log.fmt etatcpt_phy.fmt Log_Compensation.fmt AgrCompt.fmt AgrCre.fmt cptrg.fmt desc.mvt defvar descee ferreur lexploit mapcre param ref.dat rgclcr rgclin rgclee rgtr rgtrin script.fic script.mqs script.jms script.ora MVS CNTTRA LOGACL LOGACP LOGCPS DETAGO DETAGI CNTRUL Not used DEFVAR DESCEE ERREUR LIBXPL MAPCRE PARAME.SYS REFEXP RGCLCR RGCLIN RGCLEE RGTRDN or RGTRDT (MVS only) RGTRIN SCRIPT SCRIPT Not used Not used AccountingIntegrator Reference guide 185

186 10 Appendices Windows / UNIX sys.dat table tabtr.seq tsc.des usr.dat xrefrg mvt.mvt demtrav.seq IEvent.seq MVS SYSEXP TABLES TABTRD TSCDES USREXP XREFRG MVTRDJ DEMTRV 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 organization To 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. AccountingIntegrator Reference guide 186

187 10 Appendices Figure 6. Figure 1: Logical organization Syntax The keywords of the functional context are divided into sections. For example: AccountingIntegrator Reference guide 187