In the previous exercises in this section you have prepared the Portal Operations and Runtime to actually migrate Cards. You have:

• Deployed the Source and Target Engine, copying the engine libraries to a common location 
• Restarted the Portal Operations Track causing the Runtime to load your new engines
• Run setup jobs to synchronize the Track and your engine. In this step the Track discovered the new Business Object Card as well as new Source System metadata, Views and Valuesets
• Loaded the staging tables for Source System data, Views and Valusets

So now you are - almost - ready to execute the migration. Well, in fact you are, there is just a little thing you should note at this point. 

Parameters

You probably remember the Constants in Studio and how they came in two flavours:

Before starting any new migration iteration it is prudent to assert that the current values for the Runtime Constants are set correctly. You can see and correct the values for these by selecting Source/Parameters or Target/Parameters in the Portal Operations menu. 

Here as an example are the Target Parameters:

In this case, the values of all the Parameters are correct, so you don't actually have to do anything. 

Process

The migration is a two step process involving Export and Import, entirely corresponding to the separation in Studio of the Source- and Target maps. 

The Source Engine is executing the Export, exporting the Business Object instances from the staging database producing the Export result for each instance:

• Storing the Source Data extracted from the staging database
• Storing the Export Result
• Storing all Events fired

The Target Engine is executing the Import on the exported Business Object instances producing the Target result for each instance:

• Storing the Target Result
• Storing all Events fired

Note that up until now, we have been working with the Business Object as a blue-print for how the migration should work. Now we are switching to execution mode and applying this blue-print to actual instances of the Business Objects. 

Export Business Object Card

Select Source/Objects in the Portal Operations menu to display the Business Objects to Export

Card is present in the list but obviously, no instances are exported yet. The meaning of the columns are:

There are no dependencies in the export of Business Objects. If you exported all 3, Account, Card and Customer, the Portal Operations would submit 3 jobs to run in parallel, one for each. In this exercise, however, you will only submit a job to export the Card Business Object

• Select the Card Business Object
• Click the Export button to show the Business Object Selection dialog

The Business Object Selection Dialog

With minor differences, the Business Object Selection dialog is used to submit jobs in several places in the Portal Operations interface. Let's have a quick look at it:

All you have to do is check that the Card Business Object is the only one in the Selected box and click the Submit button to submit the job.

You can follow the execution of the job in the Job list.

Import Business Object Card

Once the export job has finished it's time to do the import. Select Target/Objects in the Portal Operations menu.

The Objects list looks much the same as the Source/Objects list. The Exported column now shows the number of instances produced by the Export. But there is a fundamental difference between the Export and the Import. While there are no dependencies in the Export between the Business Object instances, there most certainly are dependencies in the Import.

Dependencies

These dependencies are the result of the Relationships between the Business Objects that were defined in the Target Map. After all, if a relationship from the Card Business Object to the Account Business Object is used to pick up a calculated value from an Account instance, this Account instance had better be imported before the dependent Card instance.

The Portal handles the resolution of these dependencies in several, different ways. First of all, there is the Full monty button. By clicking this you simply ask the Portal to import everything automatically resolving the dependencies along the way. 

You can also import only a part of the Business Object instances by selecting Import in the Context Menu to show the Business Object Selection dialog.

This selection dialog looks much like the same dialog for the Export above. There is one difference, though. Instead of the Fast Track option, the dialog now shows different options for handling dependencies, depending on whether one or more Business Objects are selected for Import

One Business Object selected

The Portal Operations and Runtime will submit 1 job to import the instances of the selected Business Object. Any dependencies between the instances will be resolved. A check mark in Include Descendants will cause the Portal Operations to include dependent instances of other Business Objects, even though these were not selected for Import Likewise, a check in Include Ancestor will include the ancestors of the selected Business Objects

Multiple Business Objects selected

The Include Descendants checkbox is replaced with a drop down to select how the import should be executed Separate jobs The Portal Operations and Runtime will submit one job per selected Business Object and not resolve any dependencies. Use this option if you know there are no dependencies or that the iteration will not modify any values relevant for dependencies One job (default) The Portal Operations and Runtime will submit 1 job to import the instances of the selected Business Objects. Any dependencies between the instances will be resolved. One job with descendants The Portal Operations and Runtime will still submit one job to import the selected Business Objects and resolve dependencies as above. But now the Portal Operations will in addition include instances of other Business Objects, even though these were not selected for Import One job with ancestors Same as above, but with the inclusion of ancestors One job with ancestors and descendants Same as above, but with the inclusion of both ancestors and descendants

Dependency resolution is recursive. In fact, the Portal Operations and Runtime simply split the import up into levels. All instances at a given level are imported before proceeding to the next level:

• Level 0: Instances with 0 ancestors
• Level 1: Instances with 1 ancestor
• Level 2: Instances with 2 ancestors
• ....
• Level n: Instances with n ancestors

Do the import

In the case of importing the instances of Business Object Card, it's quite simple. While Card has relationships to both Account and Customer, we know that there are no Business Objects with any Relationship to Card. So you can just select Card for Import and click the Submit button to submit the Import job. In this case, it makes no difference if you check Include Descendants or not.

You can follow the execution of the job in the Job list.

What happened here?

After much ado leading up to this crucial moment it probably turned out to be quite boring to actually migrate the Card Business Object instances by executing the Export and afterwards the Import. But, hey! That's somehow the entire point of all this, to provide a consistent and complete toolset to deliver complete confidence and a logical approach to break down this highly complex problem domain - so in the end the task really ends up being trivial.

Take a moment to reflect on what happened here

• The generated Source- and Target engines - with a bit of help from your manual Rule implementations - have executed exactly what you specified in Studio
• All Events fired due to some Flag being raised have been stored together with the actual values from the migration to be merged into the Event text for presentation
• The data extracted from the Staging database and used for the export of each Business Object instance has been stored
• The Export result delivered by the Source engine for each Business Object instance has been stored
• The Target result delivered by the Target engine for each Business Object instance has been stored

Of course, everything remains somewhat under the hood in the Portal. In the next set of exercises, you will start out by publishing the migration results to the Portal Operations.

But there is actually stuff available already in the Portal Operations: 

• Try to select either Source/Events and/or Target/Events in the Portal Operations menu to see an aggregation of the Events fired in the migration. Notice, that you here as well have an Export or Import button respectively, making it easy to redo the given migration step for all the Business Objects that fired a given event
• On the Export or Import job in the Portal Operations  job list, you can click the Events button to see a list of the Events fired, even as the job is running