Input-Event: Start here

About Input-Events

About Input-Events and Datastore

Versions and validity periods

About Input-Events

The Input-Event object serves to define the structure of data in events generated by a Financial-Event. The Financial-Event can, for example, be the deposit of a bank transfer of salaries from the company account to the individual employees' accounts. An Input-Event can comprise multiple segments. You define the structure of these segments via a Business-Document.

In this example, a header segment contains the details of the emitting account and line segments for each employee state the employee name, account number, and the amount to be transferred. A footer segment contains a summary total of the amounts transferred.

An Input-Event that represents an instance of this Financial-Event is thus comprised of one header segment, several line segments and one footer segment. AccountingIntegrator Enabler identifies the Input-Event segments by an instance code and the segment types by a segment code.

The original event occurs in an application upstream from AccountingIntegrator Enabler and is described by the Financial-Event associated with the Input-Event. The Input-Event is, in essence, the technical implementation of this functional description over a given period of time. The Input-Event specifies the:

  • AccountingIntegrator Enabler objects that define the structure of the event (the Business-Documents)
  • processing that AccountingIntegrator Enabler will apply to that structure (via the Aggregation-, Audit-, Balancing-, Enrichment- and Transformation-Rules)
  • validity periods which define when these Rules are applicable

An Input-Event can be:

  • Either mono-segment: a single segment describes the entire event associated with the Input-Event
  • Or multi-segment: the set of segments identified by the same instance code comprises the Input-Event.

A set of different Input-Events can be associated by a group code and processed as a unit. This ensures their consistent management.

About Input-Events and Datastore

This Input-Event is used to define Output-Event structures for Datastore usage.

If you want to store Output-Event data or Output-Event traces data into the Datastore, you must define a fictitious Input-Event:

  • Name
  • Version
  • Validity period
  • Output flag checked
  • Structure: one Business-Document that describes the output Business-Document.
  • Processing: link to the Audit-Rule to be applied to the Output-Event to provide its trace data. This Audit-Rule name has to be the same as the Input-Event name (constraint for the repository).


The computerized form of any Input-Event can be analyzed into one or more segments which you specify on the Structure tab. Consider the example of a transfer representing salary payments to employee accounts. The Input-Event comprises a header segment containing the company details. There are multiple line segments, one for each employee stating the salary amount and the account to credit. The segment type defines the content and format of the record. This is provided by the Business-Document structure. AccountingIntegrator Enabler applies the Rules you specify in the Processing tab to process each Input-Event segment.


To process the information contained in an Input-Event, you associate one or more Rules with the individual segments that make up that Input-Event. During processing, AccountingIntegrator Enabler applies the associated Rules in a specific order. The order depends on the type of Rule, and on the scheduling that you specify for the Rule (pre-processing or processing). For each segment, you can specify the following elements:

Pre-processing the Input-Event

Before the Input-Event passes to the Transformation Phase, you can apply:

  • One Audit-Rule to each of the segments
  • One Aggregation-Rule
  • One Audit-Rule to the set of aggregated segments created by the Aggregation-Rule

Processing the Input-Event

The relationship between Rules and the segments that make up the Input-Event that those Rules process is stated within a Transformation-Phase.

You must associate every Input-Event with at least one Transformation-Phase. If you define more than one Transformation-Phase, AccountingIntegrator Enabler executes them sequentially in ascending alphabetical order and not independently of each other. If during processing, AccountingIntegrator Enabler detects an anomaly in a Phase, it:

  • Places the Input-Event in error for that specific Phase.
  • Places the Phase in error.
  • Proceeds to process the next Phase.

If all Phases are in error, AccountingIntegrator Enabler rejects the Input-Event.

In order for AccountingIntegrator Enabler to process an Input-Event Transformation-Phase, you must reference the Transformation-Domain attached to the Phase in the transformation environment executed in the session. You set the link between the Transformation-Domain and transformation environment in the properties of the Transformation-Domain object. By default, AccountingIntegrator Enabler attaches the Transformation-Domain to a transformation environment named Batch.

For a given Transformation-Phase, a segment type can have:

  • One pre-Audit Rule that sets an audit trace on segments prior to the application of the Enrichment-Rule or Transformation-Rule(s).
  • Several pre-Transformation-Rules which are the core of the processing. If you have enough information in the data segments, you do not need to apply an Enrichment-Rule.
  • One Enrichment-Rule, if needed, to add complementary information to segment data for it to be interpreted and processed by the post-Transformation-Rule(s).
  • One post-Audit-Rule that sets an audit trace on segments emitted by the pre-Transformation-Rule or modified by the Enrichment-Rule, or both.
  • Several post-Transformation-Rules that you apply to the data segments emitted by the Enrichment-Rule.

On the Input-Event Processing tab, the order of the Rules displayed on the screen corresponds to the sequence in which AccountingIntegrator Enabler  Rule Engine schedules and processes them.


If several segment definitions use the same Business-Document, the Audit-Rule to be applied to the different segments must also be the same. When you check the Input-Event, if AccountingIntegrator Enabler detects that more than one Audit-Rule has been specified, it displays the following message: “Warning - More than one Audit-Rule is defined for the xxx Business-Document of the xxx Input-Event. Only one Audit-Rule can be imported in the AIS Designer and used in the AIS Datastore”.

Versions and validity periods

You can create several versions of a single Input-Event object. To do this, you duplicate an existing Input-Event and set each duplicated copy a distinct validity period and version number.

Creating a version of an Input-Event

You can create a maximum of 999 versions of a given Input-Event.

To create a new version:

  1. Right-click the Input-Event that you want to duplicate and select Copy from the contextual menu.
  2. Paste the copied Input-Event in the Input-Event node on the Dictionary tab.

Composer creates an exact copy of the selected Input-Event and assigns it the name of the original Input-Event suffixed with the word Copy.

  1. Open the copied Input-Event and modify the following fields:
Field Modification


Remove the word Copy.

Validity period

Change the Start and End dates as required


Increment the version number. The maximum value you can enter in this field is 999.

  1. Click Apply or Close.

Composer updates the list of Input-Events and displays the duplicated Input-Event with the new version number you assigned.

Setting a validity period

An Input-Event version comprises at least one validity period and at most 500 unconnected validity periods. Each validity period consists of a start date and an end date, with the start date equal to or earlier than the end date.

By default, AccountingIntegrator Enabler assigns the current date as the start date and 31/12/2099 as the end date.

The lifespan of an Input-Event thus begins at the start date of its first validity period (which must be later than or equal to 01/01/1900) and ends at the end date of its last validity period (which must be earlier than or equal to 31/12/2099). The validity periods define the time span during which you can apply a given version of the Input-Event. At a minimum the validity period can be a single day if you specify the same date for the start and end dates.

Using versions and validity periods

Specifying which Input-Event version to use in a session

Use the Processing-Context-In to specify the Input-Event version that a given AccountingIntegrator Enabler session must use to process the events it receives. Use either of the methods described in the following table.

Specify the Input-Event version via... AccountingIntegrator Enabler  Rule Engine then searches for..

The Input-Event version number

the Input-Event with the version number you specified.

A given date

the first Input-Event version with a validity period that includes the date you specified.

If AccountingIntegrator Enabler does not find a suitable version, it rejects the Input-Event.

Interaction between the Input-Event validity period and the DAR

If AccountingIntegrator Enabler  Rule Engine finds a valid version for the Input-Event, it selects the processing Rules whose validity periods intersect those of the Input-Event version. This means that even if valid processing Rules exist, that is their validity periods include the DAR, AccountingIntegrator Enabler  Rule Engine does not take them into account if their validity periods do not intersect that of the Input-Event version.

Where is an Input-Event?

Axway module

AccountingIntegrator Enabler


Integration-Services: Finance tab

Object dependencies

When you define or import an object, it is stored in the metadata repository and is available for reuse by other objects. Typically, the objects that you define exist in a specific object hierarchy. That is, objects:

  • use objects below them in the hierarchy
  • are used by objects above them in the hierarchy

To help you manage the interlinked network of objects, the software provides the Object Dependencies Browser that displays the object dependencies for a selected object.

The following table lists the objects that use and are used by Input-Events.



Are used by

  • None

* In the Dictionary tab only

How you define an Input-Event

Before you define an Input-Event

Before you define an Input-Event, you must create the following objects in the given order:

Defining an Input-Event

Create the Input-Event object from either of the following:

In addition, the Input-Event properties window contains the following tabs:

  • Signature tab
  • Description tab

Defining an Input-Event from within a Financial-Event on the Business View tab

The objective of the Business View is to provide a top-down approach to defining AccountingIntegrator Enabler objects. To use the Business View, you create a set of interdependent objects by creating the dependent object from within the object on which it depends. To apply this concept to the Input-Event, you create the following objects in sequence:

  1. Create a Financial-Event.
  2. From within the Financial-Event, create an Input-Event that references the Financial-Event. You can enter the basic properties of the Input-Event, that is, name, version, label and at least one validity period.
  3. Create a Transformation-Rule for the given Input-Event. Composer then:
  4. dynamically updates the structure of the Input-Event based on the Business-Document that you selected in the Rule. The system creates a segment type in the Input-Event with the same name as the Business-Document.
  5. creates a Transformation-Phase named P1....Pn to attach the Transformation-Rule to the segment type that the system created earlier. If a Transformation-Domain exists, the system attaches the new Phase to this Domain, otherwise the system displays an error message.

The following table summarizes how to create an Input-Event from within a Financial-Event:

Right-click the Financial-Event and select... To...


Create an Input-Event.

When you define the Input-Event from this tab, AccountingIntegrator Enabler only displays the General, Description and Signature tabs because the Business View tab provides only a functional outline of the accounting-related objects. You cannot create an associated Transformation-Rule.

Therefore, you cannot Check the Input-Event object because it is incomplete. To complete the definition of the Input-Event object, you must click Apply or OK and re-open the Input-Event object to display and complete the remaining tabs.(Structure and Processing, and Linked objects)

[FOR DETAILS Defining a Transformation-Rule ]

Filter Business View

Set the validity date for filtering the Input-Events

[FOR DETAILS Filter Date]

Defining an Input-Event from the Dictionary tab

To create the Input-Event from the Dictionary tab, complete the following tabs:

After you define an Input-Event

After you define an Input-Event object, you can:

  • use the Input-Event to supply the parameter settings for production (in association with a Processing-Context-In)
  • send the Input-Event to production

How you use an Input-Event

You can perform all basic operations on Input-Event objects, depending on your user rights. [FOR DETAILS: Working with objects: Start here]

The Input-Event follows the standard object life cycle.

Back to top

Related Links