Migrating eDeveloper Components (Magic xpi 4.9)
This topic describes the steps required to manually migrate eDeveloper components, including user-defined components, from iBOLT V2.5 to Magic xpi V3.x uniPaaS components. The migration differs depending on how you created the component in iBOLT V2.5.
This is only applicable for eDeveloper step components, since eDeveloper triggers are not supported in the migration.
If you created the eDeveloper component by dragging the eDeveloper service into the flow area, then the component will be converted to a uniPaaS service when migrating to Magic xpi.
To migrate your component code:
-
Convert the component from eDeveloper V9 to Magic xpi uniPaaS components using uniPaaS's V9Converter.exe utility.
-
Copy the methods’ code from the converted uniPaaS component to a new Magic xpi component, or use the Call by Name option to call the program in the uniPaaS ECF file.
-
The Migration utility creates a log file in the installation’s Logs directory. Check the Migration Log file for variable name changes and other problems encountered during the migration process.
-
If the eDeveloper V9 component references any flow variables, then it should be taken care of as mentioned in the Variable-Related Changes section below.
Interface Changes
The following parameters were removed:
P_ActivationString, P_ActivationBlob, P_transaction, P_SysCall, P_userstatuscode, P_ReturnAction, P_UserString, P_UserBlob, P_UserXML, P_ErrorCode, P_ReturnSetupData
You will have to change your code if you used the P_ActivationString and P_ActivationBlob to pass data between Magic xpi and the eDeveloper service.
The following parameters were added:
Behavior Changes:
The UserXXX variables (UserString, UserCode, UserXML and UserBlob) are no longer sent as arguments. These variables can be accessed using the uniPaaS GetParam() and SetParam() functions.
To let you access flow variables in your Magic xpi uniPaaS component, the following functions were added:
|
getVarValue
|
Returns the value of the specified flow variable. The function accepts two arguments: Variable name and an indication of variable type (F stands for flow variable). You must define a returned value argument type (String, BLOB, Numeric, etc.) according to the input flow variable type. Example: getVarValue(VariableName, ‘F’)
|
|
setAlphaVar
|
Sets the value of the specified Alpha flow variable. The function accepts two arguments: Variable name and Variable value. Example: setAlphaVar(VariableName, ‘Test’)
|
|
setNumVar
|
Sets the value of the specified Numeric flow variable. The function accepts two arguments: Variable name and Variable value. Example: setNumVar(VariableName, 10)
|
|
setBlobVar
|
Sets the value of the specified BLOB flow variable. The function accepts two arguments: Variable name and Variable value. Example: setBlobVar(VariableName, ‘BLOB data’)
|
|
setLogicalVar
|
Sets the value of the specified Logical flow variable. The function accepts two arguments: Variable name and Variable value. Example: setLogicalVar(VariableName, 'T'Log)
|
|
setDateVar
|
Sets the value of the specified Date type flow variable. The function accepts two arguments: Variable name and Variable value. Example: setDateVar(VariableName, '01/01/1992'Date)
|
|
setTimeVar
|
Sets the value of the specified Time type flow variable. The function accepts two arguments: Variable name and Variable value. Example: setTimeVar(VariableName, '12:00:00'Time)
|
You can continue to work with context and global variables (for example, SetParam() or SharedValSet()) in the same way as before.
