Define a function

Before you can use a Custom Function, you need to inform the integration engine that such a new function exists. This task is called function definition and is accomplished in Axway Mapping Services.

When defining a function in Axway Mapping Services, you create a new object within an entity and folder. The main purpose of function definition is to inform the integration engine about:

  • The name to be used to call the function
  • The number and the classes of arguments passed to the function
  • The class of the value returned by the function

Unlike built-in functions, the names of your Custom Functions must start with capital letters.

All of the code that determines whether a year is a leap year or not, resides in a Custom Function that is named IsLeapYear. In the preceding examples, you can see various calls to that function using complete or short names. The rules for naming the Custom Function in Axway Mapping Services are the same as for other Axway Mapping Services objects. For details refer to section Name objects.

To define the IsLeapYear Custom Function:

  1. In Axway Mapping Services workbench, in the left frame, select the Extended Objects folder and then the Functions subfolder.
  2. Use the context menu to create the new function:
  3. Creating a new function
  4. From the context menu, you get the following wizard:
  5. Wizard for selecting the custom function category
  6. Follow the wizard and choose the category of the function and after next the name of the function. Click on Finish.
  7. In the Parameters tab, that you can access by double-click on the new function, define the function parameters if needed.
  8. Defining the function parameters in the Parameters tab
  9. Each line in the list defines a parameter: you must name each parameter and define the class expected. In the example above, only one parameter is defined whose name is year and that accepts a whole number value (class I).
  10. Close the window and confirm modification by saving.

The list of parameters you define here is commonly known as the list of formal parameters. When the integration engine evaluates an expression containing a call to the Custom Function, it replaces each formal parameter by the value of the corresponding expression you state in the function call; these are called real parameters. In the following expression, the expression %year + 8 adds 8 to the value of the variable year:

IsLeapYear(%year + 8)

The result is a real parameter of the call to function IsLeapYear. This first real parameter is bound to the formal parameter year which is defined in the picture above. Basically, formal parameters are function-related, while real parameters are caller-related.

After the Custom Function definition is complete, you can use this Custom Function in your expressions: the integration engine accepts expressions with calls to IsLeapYear when checking your work.

You can place calls to the Custom Functions you defined in any DML Block expression. You inform the integration engine server of the kind of value your Custom Function returns (using the Class field of the General tab) and what value it can accept for parameter expressions.

This means that you have certain use limitations: the following table lists examples of acceptable and unacceptable calls:

Call OK/NOK Description
IsLeapYear("1987")

not OK

Class S of real argument "1987" is not compatible with class I of formal argument year.

IsLeapYear(1963+true) OK

The Boolean literal true is promoted to the whole number 1 then added to 1963 to obtain 1964 which is an acceptable class I value for parameter.

4*IsLeapYear(1987)

OK

Class B of the value returned by the function can be converted to class I to perform *.

"leap:" + IsLeapYear(1988)

OK

The returned value is implicitly promoted to the string "1" which is appended to "leap:" for form the final string “leap:1”.

Related Links