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 .

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.

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 Exits and external calls.
  • 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 Exits and external calls.
    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.

Related Links