Skip to main content

Integration Rules

Integration Rules are defined using "VIRTUAL Datasets" in Integration Framework. And while most often they are used to integrate two systems (one 'source' to a different 'destination'), there really are no limitations. For instance, you can use an Integration Rule to import data from multiple (two or more) systems, manipulate the data (by validating, changing, reformatting, etc.) and then exporting it into multiple destination systems. Or you can use an Integration Rule as an “application server,” to read and manipulate data from a source system and write it back to that same system (in this scenario, the 'source' is equal to the 'destination').

You can integrate the following between systems, by defining and running an Integration Rule:

  • Import data into a Sigmafine Server
  • Export data from a Sigmafine Server
  • Move data from a source to a destination system
  • Synchronize object lists or hierarchies between systems

Note: Integration rules and virtual datasets are unique to every Integration Framework architecture, so it is important that your old system be available for reference to replicate the same configuration in your new environment.

When defining an Integration Rule, you build integration paths by configuring only those steps required for the data integration; this is done using a bi-level structure:

  • The main level is an Integration Rule Group, which is a container that holds an assembly of Integration Rules.
  • The secondary level is the Integration Rule itself, which is the actual Integration Rule object.
Rules for Defining an Integration Rule (VIRTUAL Dataset)​
  • Integration Rule limitations are only for licensed systems and named connections for the Integration Framework.
  • Integration Rules are used to exchange data between systems (import/export). Therefore, we strongly suggest avoiding the use of Integration Rules for writing data inside the Sigmafine cases, and instead use the Data Reference for those types of integrations.
  • In order to define and use an Integration Rule, at least one group has to be defined. The “group” is only a logical aggregation, so there are no functional limitations among Integration Rules defined across different groups.
  • In order to delete an Integration Rule Group, all belonging Integration Rules must be deleted first.

Note: Due to the customization capabilities in Integration Framework, we cannot provide a step-by-step procedure on how to create a bi-directional integration between two commercial or legacy systems. However, we can (and do) cover all the possible tools and features that can be used to accomplish that task.

Integration Rule Caching and scheduling Service Support​

Integration Rules support caching service (in order to speed-up the tasks) and scheduling services (in order to run the Integration Rule in unattended mode).

Integration Rule Logging and Error Tracking​

Integration rules support an advanced log/trace feature so that you can review executions and errors.

There are two types of executions:

  • Standard-mode: The Integration Rule runs based on the scheduling system.
  • Preview-mode: The Integration Rule runs in attended mode through a specific function.

Each step of an Integration Rule can be debugged and previewed independently so that you can review the execution before scheduling the final execution through scheduling services.