Configuration lifecycle

The AccountingIntegrator configuration comes from two sources:

  • AI Enabler
  • Central referential from the company

AI Enabler configuration

It depicts the structures, the formats for data and tables, and the rules to be applied. It is deployed as a set of 1 ctx.mvt + 1 mvt.mvt files.

This configuration is supposed to change rarely, one or two times a year as most, when:

  • Changes in upstream applications happen:
    • Formats modification
    • New applications
    • New formats
  • Changes in downstream applications happen:
    • Formats modification
    • New applications
    • New formats
  • The accounting schemes change or new ones must be applied.
  • The functional validations change.

Central referential from the company

Depicts an extraction from the central referential of the company into internal tables values used for the validation rules inside Rule Engine transformations. The usage of these internal tables is to define, among others:

  • The COA (chart of account), extracted from the GL application
  • The official financial rates values
  • Accounting period table

It is deployed as an mvt.mvt file (not ctx. mvt).

This configuration is supposed to be regularly updated (once a day, or week, month…) each time the origin data changes.

Both the AccountingIntegrator configuration deployed from AI Enabler and the internal tables need to be imported into the Repository. Then, the Rule Engine Server will use them to configure the Rule Engine when a Rule Engine session is started by Rule Engine Server.

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)

Additionnally to the AccountingIntegrator configuration, the input contexts which are exported from AI Enabler using financial export and imported into the Designer as Collection Types, need to be deployed into the Repository in the same application where the AccountingIntegrator configuration was imported.

To publish the AccountingIntegrator configuration from a Test/Pre-production environment the configuration must be exported using the exportAIConfiguration command and imported into the new environmentusing the importAIConfiguration command.

Also the formats containing the Collection Types must be published from the Test/Pre-production environment into the new environment.

Manage multi-configurations

In DatastoreAccountingIntegrator, you can create configuration data for several applications by switching from one application to another. To each application corresponds a namespace.

When the Repository manages several applications, it allows:

  • The service team to handle several customer applications in the same Designer.
  • A customer to manage several copies of its applications or several applications.
  • Multi-tenant architecture with a common Configuration Repository. Instances of DatastoreAccountingIntegrator can be installed on different servers.

Modify a configuration

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.

Application isolation

The application concept is used to define an environment and ensure consistency of the structures.

Related Links