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.

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

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

Stamping code:5

Operation date: 8

Stamping time:6

Identifying character: 1

Stamping counter: 5

  • 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

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

Trace_IEvent

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

Trace

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

Rules to follow:

Rule Meaning

1

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

2

If you do not supply the stamping code, the segments are stamped sequentially, starting from 000..0001 up to 999..9999
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 99999 for each type of trace.To increase this limit, the counter is now in base 36 instead of decimal.

Tsc.des: The stamping counter 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 Type of Information Audited

D

Audit of an individual Input-Event segment

A

Audit of an aggregated Input-Event segment

M

Audit of an individual modified Input-Event segment

N

Audit of an aggregated modified Input-Event segment

P

Audit of an individual Output-Event

T

Audit of Output-Events aggregated by group

R

Audit of aggregated Output-Events (all groups together)

O Audit of an individual Input-Event segment in anomaly
J Audit of an individual rejected Input-Event segment

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

Rules to follow for each segment type to be stamped:

Rule Meaning

1

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

2

The upper limit must be greater than the lower limit

3

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

Example of a stamping descriptor for the stamping code STAMP1:

STAMP1;

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

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

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

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

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

Id. Stamp Trace

25

Id. Stamp Orig
25

Id. Stamp Aggreg

 

25

Stamper

 

5

(*)

 

 

20

Session


25

Date


8

Time


6

Id. Event

9

Source


25

Code Group

34

Code Event

25

Event Version

3

Code Instance

34

Code Segt

25

Phase code

25

Rule Audit

25

Start Date

8

End Date

8

Event Trace

4000 max.

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

  • 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

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

Id. Stamp Trace

 

25

Id. Stamp Orig

 

25

Id. Stamp Aggreg

 

25

Stamper


5

(*)

 

 

20

Session


25

Date


8

Time


6

Id. OSegt

9

Source


25

Filler


121

Phase Code

 

25

Rule Audit

25

Start Date

8

End Date

8

Osegt Trace

4000 max.

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

  • 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


25

Session


25

Date


8

Time


6

Id. Event

9

Sender


25

Code Group

34

Code Event

25

Event Version

3

Code Instance

34

Code Segt

25

Phase Code

25

Rule Audit

25

Start Date

8

End Date

8

Event Trace


4000 max.

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

Id. Stamp Trace

 

19




6

Id. Stamp Orig

 

19




6

Id. Stamp Aggreg

 

19




6

Stamper


25

Session


25

Date


8

Time


6

Oevent index

9

Sender


25

Filler


121

Phase Code

25

Rule Audit

25

Start Date

 

8

End Date

 

8

Osegt Trace

4000 max.

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

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

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

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

  • 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 Meaning

Stamping identifier

The stamping identifier associated with the trace

Original stamping identifier

The identifier associated with the previous trace, (that is, before aggregation or modification, in the case of Input-Events, or before transformation or aggregation for Output-Events)

This field is empty if the stamping code is D

Aggregation stamping identifier

The identifier associated with the trace after aggregation

This field is empty if the segment (or the Output-Event) is not aggregated in the session

Activated stamping code

The code set in script.ges (see above)

Activated session code

The code set in script.ges. See Mandatory parameter settings

Operation date

The operation date in YYYYMMDD format

Operation time

The operation time in HHMMSS format

Segment (or Output-Event) index number

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

The activated Processing Context-In code

The code set in script.ges

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

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

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

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.

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.

Related Links