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.

Figure 1: Logical organization

Syntax

The keywords of the functional context are divided into sections.

For example:

>Choice<Aggregation=YesAuditing=NoRedirection=NoMulti_Period=No#Group=NoBalancing_Check=NoRecycling_Phase=NoAccounting_Processing=No

Rules to follow:

Each section name is enclosed in less than (>) and greater than (<) symbols:
>section_name<

You assign values to all the keywords for a given sender by appending the name of the sender to the section name.>Section_Name.Sender_Name<For example:>Choice.SENDER1<Aggregation=NoKeywords belonging to one section cannot be associated with another section.

  1. You must not changes the names used for keywords and sections.
  2. You assign a value to each keyword that you want to use as follows: keyword_name = keyword_value.
  3. Tabulated values are not allowed.
  4. The spaces between a keyword and its value are not significant.
  5. To comment out an unused keyword, precede it with a hash (#) sign. When you do this, the system uses the default value.
  6. For example:
  7. <Choice<
  8. #Group=No
  9. Balancing_Check=No
  10. Recycling_Phase=No
  11. Recycling_Phase=No
  12. Keywords are not case sensitive. For example, redirection is the same keyword as Redirection or REDIRECTION.
  13. The values that you assign to keywords ARE case sensitive and are applied exactly as you enter them. For example, hello, Hello and HELLO are three different values.

Mandatory configuration settings

These settings relate to:

  • Handling versions of Input-Event types
  • The properties of Input-Events to be transformed
  • Processing multi-segment Input-Events
  • Processing mono-segment Input-Events
  • The properties of the Output-Events produced

Handling versions of Input-Event types in sys.dat

During transformation, the version of an Input-Event type can be identified in the following ways:

  • Directly, through its number
    or
  • By relating a date to a period of validity of a version of an Input-Event type

Settings

Section + Keyword Keyword Value Section + Keyword to Input Properties of the Keyword to Input

>Ident_Type<

Type_Version_IEvent

(typing of the version of the Input-Event type to process)

Number

Date

 

 

Defining a version via a date

An IEvent type version is defined by a date as follows, each IEvent type version being defined for one (or more) specific validity periods.

If the value of the date… Then…

is within one of the validity periods

the IEvent type version associated with the validity period is used
è In the graphic : date 1, version 1

falls within several validity periods

the IEvent type version with the oldest start date is used
è In the graphic : date 3, version 1

does not fall within any validity period

the associated IEvent cannot be processed and is rejected by the transformation session
è In the graphic : date 2, no version selected

Definition of an IEvent type version definition by date

Definition of an IEvent type version definition by date

Properties of Input-Events to be transformed

This section explains how Rule Engine identifies the various fields that characterize an Input-Event. These methods of identification flow from the structures that have been defined for Input-Event segments.

Each of these technical fields can be identified in the following ways:

  • Segment:Use this method if the field is defined in the basic structure (supplied by the sender application or the Input-Event restructuring exit)
  • Context:Use this method in all other cases
Section + Keyword Keyword Value Section + Keyword to Input Properties of the Keyword to Input

>Ident_Type<

     

Code_IEvent

(a means of identifying the name of the type of Input-Event to process)

Segment

 

 

Context

>Fixed<

Position_Code_IEvent and Length_Code_IEvent

>Value<

Code_IEvent

 

 

Maximum length = 25

IEvent_Version

(a means of identifying the version of the Input-Event type to process)

Segment

 

 

 

 

Context

>Fixed<

Position_Version_IEvent, Length_Version_IEvent

 

and Type_Version_IEvent

>Value<

IEvent_Version

 

 

Maximum length = 3 for a numeric or 10 for a date.

 

 

Numeric or date, depending on the type.

Code_Segt (a means of identifying the name of the segment type to process in the Input-Event)

Segment

 

 

 

 

Context

>Fixed<

Position_Code_Segt,

Length_Code_Segt

>Value<

Code_Segt

 

 

 

Maximum length = 25

>Choice<

     

Multi_Period

Yes

 

 

 

 

No

 

If one or more versions of the Input-Event type to be processed are valid over more than one period.

 

In all other cases.

Rules to follow:

   

1

Each technical field has a specific method of identification
For each technical field, supply either the >Value< or the >Fixed< section, depending on your chosen method of identification

2

The position and length elements in the field identifier, when added together, must in all cases be equal to or less than 4001

3

If the date is supplied as a Date data type, the length must be 10 and it must be in the form DD/MM/YYYY

4

If the date is supplied as a Numeric data type, it must be in the form YYYYMMDD, CYYMMDD or YYMMDD, (depending on its length, which may be  8, 7 or 6)

Processing multi-segment Input-Events

The table below shows the parameter settings that allow Input-Events with more than one segment to be handled.

Section + Keyword Keyword Value Section + Keyword to Input Properties of the Keyword to Input

>Ident_Type<

Code_Instance

(a means of identifying the instance of the Input-Event type to process)

Segment

 

 

 

 

 

 

Context

>Fixed<

Position_Code_Instance,

Length_Code_Instance and

Type_Code_Instance

>Value<

Code_Instance

 

 

 

Maximum length = 34

 

Data type = A or N

>Limit<

Segt_IEvent

0

 

The segments of the Input-Event processed must be associated with the same instance code value

Note   A segment with a blank instance code is treated as a mono-segment Input-Event.
This gives the flexibility to process mono and multi-segment Input-Events in the same session.

A multi-segment Input-Event may contain up to 999 segments.

Processing mono-segment Input-Events

These settings limit Rule Engine to handling Input-Events comprising a single segment. In this case the instance code in an Input-Event is not used.

Section + Keyword Keyword Value Section + Keyword to Input Properties of the Keyword to Input

>Limit<

Segt_IEvent

1

 

Each Input-Event contains a single segment

Properties of the Output-Events to process

This section explains how Rule Engine identifies the output code that characterizes an Output-Event.

This method of identification flows from the structures that have been defined for Output-Events.

Section + Keyword Keyword Value Section + Keyword to Input Properties of the Keyword to Input

>Ident_Type<

Code_Output

(a means of identifying the output code associated with each Output-Event)

OSegt

 

 

 

 

Context

 

Exit

Structure (1st character of the segment structure code)

>Fixed<

Position_Code_Output,

Length_Code_Output

>Value<

Code_Output

 

 

 

Maximum length = 25

 

Rules to follow:

   

1

The sum of Position + Length in this definition must be less than or equal to 4001

Management parameters

This section explains the DAR identification method. This information is required for the rules that are associated with the Input-Events and those associated with the Output-Events.

Section + Keyword Keyword Value Section + Keyword to Input Properties of the Keyword to Input

>Ident_Type<

Date_Application_Rule

Segment

 

 

 

 

 

 

Context

>Fixed<

Position_Date_

Application_Rule

Length_Date_

Application_Rule

Type_Date_

Application_Rule

 

 

 

 

Maximum length = 10 or 8

 

Data type = Date or Numeric

 

Supply the operational date of script.ges. See table below.

Rules to follow:

   

1

If the DAR is given in a numeric data type, its length may be 8 (YYYYMMDD), 7 (CYYMMDD) or 6 (YYMMDD)

2

If the DAR is given in Date data type, its length must be 10 characters, with a format of DD/MM/YYYY

 

Related Links