In a previous exercise in the last section, you determined that the event I0011 was derived from another Event, E0006. In turn, the Event E0006 rejected a number of Customers, and the Event I0011 was fired for Cards that depend on these rejected Customers.

So, to resolve Event I0011 on Card, what you really need to do is to resolve the Event E0006 on Customer. 


Returning to the Event List for Card in the Tracker an drilling down to the detail view of one of the Cards firing the Event I0011 lets you jump to the Customer, that was rejected and caused the rejection of this Card:

It's obvious that the Customer was rejected by the Event E0006. Looking at the Items depending on this box, the rejection of this Customer not only caused the rejection of the Card - four Accounts were affected as well. It seems indeed a very good idea to resolve the Event E0006 on Customer - it looks to be the root cause of a lot of grief.

Solve Event E0006 - AddressLine {0} is too long. Truncated from ({1}) to ({2})

Looking at the Event E0006, it is clear that it is fired in the export because the Source Engine detects that an AddressLIne is to long to be accepted by the interface to the Target Engine. The Source Engine actually shortens the AddressLine so it fits - but then proceeds to reject the entire Customer, because the Severity of Event E0006 is set to Reject Root.

This is too severe. A more suitable Severity would be Warning to signal to the Partition Users, that they should either verify the shortened AddressLine or modify the Address in the Source System. So this is what you will do below.

Modify the Mapping

  1. Open the Workshop Source Map in Studio

  2. Open the Event E0006 and change the Severity from Reject Root to Warning

  3. Validate the Source Map and ensure there are no Validation errors

  4. Publish the Source Map to the Generator

Generate the Engine Code

  1. Open the Workshop Solution in Visual Studio

  2. Locate and right click either one of the two Workshop.SourceEngine* projects

  3. Select MigFx: Generate code... in the context menu

  4. Verity that the published file is new and click Ok to generate the code

Deploy the Source Engine

  1.  Locate and right click either one of the 2 Workshop.SourceEngine* projects

  2. Select MigFx: Deploy... in the context menu

  3. Leave the drop down on Training and click Ok to deploy the engine

Restart the Track to load the newly deployed Source Engine

  1. In Director Execution / Track Restart (or Start) the Track

Migrate the affected Customers

By lowering the Severity of Event E0006 from Reject Root to Warning, we now expect the affected Customers to pass and it is time to iterate the migration for these. But there is a little twist here. 

The Customers were rejected by the Source Engine in the Export step. So initially the Customers affected by the Event E0006 must be exported again. Exporting the Customers will of course purge both the Export and Import results - including Events - for the Customers. Following the export of the Customers it is also necessary run the import on the same Customers. However, since the export step clears away the Event E0006, it can present a problem afterwards to select the same Customers for the import step.

In this situation, after the export step, the Customers will show up in the Director as missing under the Import, so in this case it would be reasonable just to import the missing Customers. But bearing in mind that - in a bigger project - you or other team members may be iterating the export of other Customers as well, this approach of just running the import on the Customers may be too simple and include too many Customers in the iteration.


For this reason, the Director has the facility of Itemsets. An Itemset is simply an identified set of Business Object instances ('items') that can be exported and Imported. An Itemset can be created based on the instances that fired a given Event, which is what you will do in this case.     

As a side note: With knowledge of the schema of underlying migration database of the Track, it is in fact possible to supply an Sql query to return the instances to include in an Itemset.

To create an Itemset for the Customers that fired the Event E0006, go to the Director panel Source / Events:

Select the row for the Event E0006 on Customer and click the Item Set button to submit a job to build the Itemset. Verify in the Job List that the job completes successfully.

Go to the panel Execution / Item Sets and click the Refresh button to se the new Itemset:

Export and Import the Customers

To iterate the Customers of the Itemset:

  1. Export the Customers by clicking the Export... button to submit a job to export the Customers

  2. Verify in the Job List that the job completes successfully and the Customers are no longer rejected by the export

  3. Now import the Customers: From the Itemset, ensure that Include descendants is checked, and click the Import button to submit a job to import the Customers

  4. Verify in the Job List that the job completes successfully and that the Customers have been imported (1)

  5. Even though the Itemset only contained the Customers that fired the Event E0006, the automatic resolution of the dependencies born by the relationships in Studio included the dependent Accounts (2) and recursively the Cards (3) depending on the Accounts. And it made sure that the Customers were imported before the Accounts and the Accounts were imported before the Cards.

Of course, in this exercise we were the count of Accounts and Cards to iterate is small - but even so it would be quite complicated to identify the Accounts and Cards to iterate following the correction of the Customers. Imagine a real life migration - it would be even more complex and it is difficult to overstate the value of this automatic resolution of dependencies.

Publish Result

To publish the new result to the Tracker, go to the Director panel Administration / Manage and check the Tracker Publish radio button:

In the dialog, move everything from the Available to the Selected box and click the Ok button to submit a job to publish the result. 

Verify in the Job List that the job completes successfully.

Test & Feedback 

When the publish job has completed, you can return to the Tracker and refresh the Event List for Customer to see that the Severity Event E0006 indeed has changed from Reject Root to Warning:

By drilling down to the single Customer Business Object instances, you can verify that the Customers now are imported successfully:

Likewise, for the Event List for Card you can change the State filter to (all) to verify that the Event I0011 now has a count of zero:

What happened here?

You have been through another iteration of the migFx cycle. This time you solved an Event on Customer that in turn solved some derived Events on both Account and Card. The exercise illustrated the power of the automatic and recursive dependency resolution in migFx by identifying and migrating dependent Account and Cards for you.

The exercise also introduced the Itemset to in effect save a collection of Business Object instances to be Exported and or Imported. The Itemset comes in handy when it is necessary to iterate both the Export and the Import for a set of Business Object instances, because the Export step in many case will purge the Event identifying the instances to be Imported. 

Apart from that, it is also possible to supply an Sql query to pick and choose exactly the items to iterate. But this is a more advanced topic outside the scope of these exercises.