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. 


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

The value for the Constant is provided in Studio and 'baked into' the resulting engine
The value is supplied in thPortal Operations at runtime

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. 


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:

The Object is shown as a parent with one or more children. While this maybe makes less sense in this training setup, it does become useful if the copy function of the Source Map in Studio is brought into play.

This ability to copy a Business Object in the Source Map is not part of the exercises, but it was touched upon at the end of Exercise 2.7 - Map Business Object CardStatus. If the 3 copies of Account given in the sample in this exercise were part of the setup, Object: Account would have 3 children in the Objects list:
  • Object: Account
    • Current
    • Portfolio
    • Guarantee  
This would allow you to export each separately.
The count of Business Object instances in the staging tables (as defined by the Discriminator on the Card Business Object in the Source Map)
The number of Business Object instances dropped during the Export. The Business Object is dropped if a Severity Drop is assigned to a raised Flag when exporting a Business Object
The number of Business Object instances that were Rejected during the Export by firing an Event with Severity Reject Root
The number of Business Object instances that were Exported successfully
Any difference between Source and the sum of Dropped, Rejected and Exported. Any difference indicates that not all Business Object instances have been processed

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:

Available / Selected
Move Business Objects to the Selected box to include in the job(s) being submitted.
If you know the key of a given instance of a Business Object, you can supply it here to process only this instance. The key is subject to an Sql like query and should at a minimum be pre- and suffixed with the Sql wildcard %.
Choose what to include:
  • All: All instances
  • Rejects: Only Rejected instances
  • Difference: Any instances in the Differences column
Wait for Debug
If checked, the job will be submitted but immediately pause until a debugger is attached. Allows you to debug your manual rule implementations.
Type a number to limit the instances processed by the job.
Fast Track
Only available when exporting. For each instance, the Portal Operations runtime will:
  • Execute the Source Engine
  • Execute the Target Engine immediately,
  • Only store the Target result. Unless the instance is Rejected, then everything is stored as normal
Profiling Level
The generated code is instrumented and in addition, migFx provides you with the possibility to instrument manual rule implementations. If a Profiling Level other than None is chosen, this instrumentation is activated and will log elapsed time in the execution tree. Useful to locate potential bottlenecks if the migration is suddenly performing badly.

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.


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 ancestorsSame as above, but with the inclusion of ancestors
One job with ancestors and descendantsSame 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