Skip to main content

Integration Rule User Functions

User Functions (also called scripts or codes) are advanced objects used to perform a complex action within Integration Rules. These User Functions (this component can be called and used only within an Integration Rule). This component born from the needs to have some ways to:

  • Perform a sophisticated data validation
  • Perform a custom data transformation
  • Implement a business logic stored in other libraries/DLLs (not in other systems)

Basically, a user function is a .NET assembly loaded into the Integration Framework namespace, and executed inside the IF server. Following this concept, the script can link and refer all other .NET libraries and assemblies installed and registered in the IF server machine, allowing the writing of complex scripts referencing other libraries.

Scripts are stored in Integration Framework in two ways:

  • Source code
  • Binary representation

The source code is stored in a special area of the Integration Framework configuration repository. Each piece of code is encrypted at storage level and can be secured by you through an additional protection password (like VBA modules in Microsoft Office).

The binary representation is a cached run-time image of the script. Scripts can be compiled using a standard C# compiler and it is linked in order to create a binary standard .NET assembly DLL. Once you compile the script, the runtime binary image is stored into an IF binary cache and loaded when necessary. The cache is rebuilt every time you recompile the script from the source code*.

Note: Ensure that you do not overlay script executions. When an Integration Rule is running a script, the binary image is locked by Integration Framework. If another script overlaps the currently running script, a compilation error is received. In order to prevent such behavior, you need to stop all the Integration Rules and disable all their triggers.

User Function Types​

In Integration Framework there are three types of user functions. The type simply indicates how the script is used:

  • Clone-Output: Supports either inbound and outbound connections, since it sinks from a source Dataset and outputs the same Dataset structure. This type of script should be used when input and output data structures are exactly the same, but data can be changed. Usually, this scenario is needed for custom or complex data validation rules in order to filter some data (records) through specific business logic. The business logic is included in the script itself and depending on the rule it can be more or less sophisticated.
  • Custom-Output: The same as Clone-Output, except that input and output Dataset structures are different.
  • Input-Only: Supports only the inbound connections, as this type has no output.

For detailed steps on using user functions in Integration Rules please see Using User Functions in Integration Rules.