Salesforce

Migration Tool - Magic xpi 3.x and Above to Magic xpi 4.x (Magic xpi 4.13)

Printable View
« Go Back

Information

 
Created BySalesforce Service User
Approval Process StatusPublished
Objective
Description

Migration Tool - Magic xpi 3.x and Above to Magic xpi 4.x

Migrating a V3.x project to Magic xpi 4.x is automatic, and as such does not require a specific migration procedure. The Migration wizard automatically opens when you open an existing .ibs file.

The Migration tool supports projects that were developed in Magic xpi 3.x and above. If you developed your project in a prior version, you need to go through the Magic xpi 2.5 to 3.x Migration tool in order to upgrade your project to Magic xpi 3.x before you can migrate the project.

Steps Required Before Migration

  • Ensure that you back up your project files before you migrate your project.

  • Before migrating a project, make sure that all XSD files used by the Data Mapper are available in their declared location. Since version: 4.5a

  • If your Magic xpi 4.1 project is checked into a Source Control product, first get the entire project using the Source Control product and then migrate it.

  • If the object names in your projects are in the language of your locale (such as flow names or variable names in German), the locale of the machine must match the locale used in the project when doing the migration. In addition, the magic.ini file’s [MAGIC_ENV]ExternalCodePage flag must also match the used locale.

Migration Wizard

The Settings screen includes three fields:

  • Magic xpi project file: The file that you want to convert. By default, this field points to the location of the ibs file that you opened.

  • Converted project location: The location where you want to save the converted project. By default, this field points to the default location defined for Magic xpi 4.x projects.

  • Log will be saved at: The location where you want to save the log for this migration. By default, this field points to the <Magic xpi 4.x installation>\Runtime\log\migration.log file. This field supports files with the .log or .txt extension.

When the process finishes, the Summary screen will indicate whether the process succeeded or failed. You can also select to view the conversion log.

A new project will be created with a file name that indicates that it is a migrated project.

Steps Required After Migration

uniPaaS steps and Component SDK steps that were created in uniPaaS need to be migrated manually to Magic xpa.

  • Web Service servers need to be deployed manually after migration.

  • External files need to be copied to the new project's location according to the old project's hierarchy.

  • If a project is referring to files outside the project folder using the relative path, then after migration the references are not restored in the newly created projects. To restore the references, open and save all Data Mappers that use the external references. To find such Data Mappers, run Checker on the project.

  • The migration process does not change any .ini files or its values. To use new values, after migration, delete or rename the old ifs.ini file and build the project. A new ifs.ini file will be created with new values.

  • If you had logical names defined in your Magic.ini file (not in the ifs.ini file), when migrating a project add the logical names (environment variables) to the Magic.ini or ifs.ini file. If the environment variables are project specific, you can add them to the project's ifs.ini file. For non-project specific environment variables, copy them to the Magic.ini file. Note that Magic xpi 4.6 is project centric, meaning that the Studio loads the environment variables from the ifs.ini file.

  • If the Invoke Flow utility uses an expression containing hard-code IDs, it might not point to the correct ID after the migration process, since these IDs may change during the migration. It is recommended to use the dedicated functions, such as GetFlowID and GetBPID, which calculate the ID at runtime based on the flow or business process name.

  • If the SpecialExpReturnNull flag is not already present in the migrated project's ifs.ini file, you should add it to that file's [MAGIC_SPECIALS] section and set it to Y to maintain backward compatibility with projects created in earlier versions of Magic xpi or iBOLT. This flag maintains backward compatibility when comparing a variable that has a Null value to an empty value.

  • If your migrated project has any user-defined components, the folder containing them must be copied from its old location to the new location. Any changes to the Resource_types.xml and Service_types.xml files that are connected to user-defined components must be done manually.

  • If you migrate your project from an earlier version that did not contain a specific component, the component will not be available in your migrated project even after the migration process. You will need to add the component manually.

  • JD Edwards World resource definitions should be updated with a library if such definitions do not exist.

  • The JD Edwards Enterprise One configuration has been simplified and now uses a dedicated class loader. It is no longer required to list all of the jar files in the Magic.ini classpath. Refer to the Configuring the JD Edwards Enterprise One Connector topic for specific instructions.

  • Due to major changes in the Salesforce metadata API, you will have to reconfigure the Metadata CRUD method's Update and Delete operations.

  • When upgrading directly from V3.1 SP1, you need to redefine the password fields in your resources.

  • In an upgraded Magic xpi 4.5 or 4.5a project, you cannot modify an existing SAPB1 resource to use a SAP HANA database. You need to create a new SAPB1 resource instead.

License Considerations

Magic xpi 4.x requires a dedicated license. Magic xpi 3.x licenses will not work with Magic xpi 4.x.

In Magic xpi 4.x, the license mechanism now supports a combination of floating and fixed license thread allocation. By default, all projects use the floating mechanism, but it is possible to reserve a fixed amount of licenses for a project using the ReservedLicenseThreads flag in the [MAGICXPI_GS] section of the ifs.ini file.

For example, if your license has 20 threads, and your first project is defined with 10 workers and the ReservedLicenseThreads flag is set to 5, then the project will reserve 5 threads but will be able to use another 5 threads from the license pool. If a second project starts, it will be able to reserve up to 15 threads only, since 5 threads were already reserved by the first project. Threads that are not reserved by any of the projects remain in the license pool and can be used by any project when required.

Notes for Migration

  • To provide backward compatibility, objects in expressions that use special characters are wrapped with the objOldName function. The special characters are: [space] ~ ` ! @ # , % ^ & * - = + ( ) { } [ ] | " ? / \ < > ; or more than one period (.). Periods, ^ (circumflexes) and closing parentheses are changed to _ (underscores) when they appear inside an object's name. Once the project is migrated, you cannot add special characters to the object and you cannot change an object name that contains special characters, unless you delete all of the special characters in the name. The one exception for this behavior is for flat files, where you can create field names with special characters – but these must be wrapped with the objOldName function when using an expression.

  • The Text Area tool is no longer supported. However, any text from migrated projects is saved in the Comments property in the flow's Properties pane for easy reference.

  • The DB wizard information is not migrated in the project migration process except for the final SQL statement, as a part of the Data Mapper schema.

  • UDS, ODS, PSS, and Data Converter definitions are now considered objects in Magic xpi 4.6. Therefore, when migrating UDS, ODS, PSS, and Data Converter definitions, a U., O., P., and V. prefix are added to the relevant definition. For example, UDS is now U.UDS1. After migration, if these definitions contained 30 characters, the last two characters will be cut off. If after this truncation there is a name duplication, the third character will be renamed.

  • During migration, if text is found in the project's files describing a relative path (for example, ../../), an entry will be written in the log file that a relative path was created that might point to the wrong location.

  • The Data Mapper is now a separate source file. All Data Mappers will have an .mpr extension.

  • If a migrated project contains more than one flow with the same name, it will be renamed with a _n suffix starting from 2. For example, if there are three flows named Flow1 in a project created in a previous version, the flows will be named after migration as follows: Flow1, Flow1_2, and Flow1_3.

  • Up until Magic xpi 4.1, you could use NOT without parentheses, for example: NOT C.UserString ='111'. In Magic xpi 4.6, the parentheses are mandatory. When you run the Checker on a migrated project, parentheses are added to NOT expressions, for example: NOT (C.UserString ='111'). However, the parentheses will be seen only when you open the Expression Editor after the Checker process and when you make a change to the expression or click the Verify or OK button.

  • Magic xpi 4.1 performed various corrections for dates and times in the Expression Editor. In Magic xpi 4.6, the only change that is made automatically is changing a two character year into a four character year. In addition, the separator for dates and times must match the separators defined in the Magic.ini file.

SharedValSet and SharedValGet Functions

In version prior to Magic xpi 4, the SharedValSet and SharedValGet functions may have been utilized in user components. In such a case, you need to manually change the SharedValSet and SharedValGet functions to one of the new functions listed below. This ensures that the values are retrieved from the Space and not from a single process. These new functions are:

  • SharedValSetA (A represents Alpha)

  • SharedValSetN (N represents Numeric)

  • SharedValSetD (D represents Date)

  • SharedValSetB (B represents BLOB)

  • SharedValSetT (T represents Time)

  • SharedValSetL (L represents Logical)

  • SharedValGetGS (GS represents GigaSpaces)

In Magic xpi 4 and above, the SharedValGetGS function returns a value from the Space (that is, from the project), which can be comprised of one or more processes. In previous versions, the SharedValGet function returned a value from a single process, where one project was comprised of a single process. Therefore, it is highly recommended not to use this function in Magic xpi 4 and above if more than one server is running per project.

If you have used the Component SDK to develop polling triggers, you should create an empty program called 'LOAD_TRIGGER', and set its End task condition to Yes and the Evaluate condition to Before.

Encoding

Prior to Magic xpi 4.0a, Unicode content was loaded from the file system "as is", including its BOM content. When this BLOB was served as the HTTP response, it was sent with its BOM to the consumer.

Since Magic xpi 4.0a, Unicode content is loaded to the corresponding Unicode BLOB, and the BOM is removed in the process. If this BLOB is served as the HTTP response, it will not include the BOM. This may prevent the client from identifying the response's content encoding.

It is therefore recommended that you process Unicode content in one of the following ways:

The FTP component's Get Operating System method returns Unicode data. In Magic xpi 3.4, it returned ANSI data.

Reference
Attachment 
Attachment