Preparing Your Project for Migration (Magic xpi 4.13)
Before migrating your application, it is recommended that you go through your application and identify unsupported features, to make sure that no information gets lost during the migration process. Projects should be saved in .mdd format.
Projects developed using Magic xpi versions prior to V2.5 SP8, and that include components with an Internal interface, must be manually converted to a Method interface before the migration process. These components are:
-
Email
-
File Management
-
FTP
-
JMS
-
MSMQ
-
System i Connector
-
WebSphere MQ
The Data Mapper requires special attention and preparation before migration, as explained below.
Magic xpi has a set of strict mapping rules that are applied to the migrated Data Mapper. Mappings that violate these rules are deleted. These rules are explained in detail in the Data Mapper Rules topic.
Careful preparation of the V2.5 Data Mapper before migrating can ensure that you avoid problems later on. Before you start the migration process, you are strongly advised to review the following considerations:
-
Always map the multi occurrence compounds (database, flat file, or XML repeatable compounds) to each other. If you do not do this, Magic xpi automatically maps one for you, which might be not the one you intended to use. This is shown below.
-
Source variables in Magic xpi are treated as multi occurrence compounds. In iBOLT V2.5, the mapping shown below (on the left side) was possible. However, in Magic xpi the connection marked below in red is deleted, because you cannot map values from two or more repeatable Sources to one Destination.
In iBOLT V2.5, the use of the Issuer variable in the Destination node's IssuerID expression eliminates the need for the connection and prevents it from being deleted upon completion of the migration process.
-
In Magic xpi, you cannot map more than one repeatable compound in the Source to a repeatable compound in the Destination. If you have an XML Source in iBOLT V2.5 where two or more sibling repeatable compounds are mapped to one repeatable Destination, you need to modify the XSD so that only one of the sibling compounds is a multi instance compound. The remainder of the sibling compounds should be single instance compounds. In the example below, you need to set Compound1 in the XSD as single occurrence. If not, the connection between a2 to IssuerID is lost.
Preparing SQL Statements
Ensure that the database field names are identical to the names used in the SQL statement.
Using SQL Functions
Make sure that all internal SQL functions in your SQL statement use an alias. For example:
SELECT sum(id) FROM ticket should be converted to SELECT sum(id) AS sum_id FROM ticket.
Matching the SQL Statement Case
If the database fields are all uppercase or lowercase, you can use the Upper/Lower case conversion facility that is available in the Migration utility. If there is a mix of uppercase and lowercase, you should modify the statement in iBOLT V2.5 to match the fields' case.
Removed and Renamed Functions
Terminology Changes
