In a previous exercise in the last section, you determined that the event I0011 was derived from another Event, E0006.
In turn, Event E0006 rejected a number of Customers, and 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.
Solve Event E0006 - AddressLine {0} is too long. Truncated from ({1}) to ({2})
Looking at Event E0006, it is clear that it is fired in the export because the Source Engine detects that an AddressLine is too 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 way too severe. A more suitable Severity would be a 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
- Open the Workshop Source Map in Studio
- Open the Event E0006 and change the Severity from Reject Root to Warning
- Validate the Source Map and ensure there are no Validation errors
- Publish the Source Map to the Generator
Generate the Engine Code
- Open the Workshop Solution in Visual Studio
- Locate and right click either one of the Workshop.SourceEngine Custom project
- Select MigFx: Generate code... in the context menu
- Verify that the published file is new and click Ok to generate the code
Deploy the Source Engine
- Locate and right click the Workshop.SourceEngine Custom project
- Select MigFx: Deploy... in the context menu
- Check Restart and Run Setup and click Ok to deploy the engine
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 to run the import on the same Customers. However, since the export step clears away Event E0006, it can present a problem afterwards to selecting the same Customers for the import step.
In this situation, after the export step, the Customers will show up in the Portal 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 missing Customers may be too simple and include too many Customers in the iteration.
Itemsets
For this reason, Portal Operations has the facility of Item Sets. An Item Set is simply an identified set of Business Object instances ('items') that can be exported and Imported. An Item Set 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 the 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 Portal Operations 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 see the new Itemset:
Export and Import the Customers
To iterate the Customers of the Itemset:
- Export the Customers from this Item Set by clicking the Export... button to submit a job to export the Customers
- Verify in the Job List that the job completes successfully and the Customers are no longer rejected by the export
- 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
- Verify in the Job List that the job completes successfully and that the Customers have been imported (1)
- 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 caused the Portal to resolve the dependencies and run the import in multiple levels - ensuring that each level completes before starting on the next
Of course, in this exercise 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 Portal Operations panel Administration / Manage and check the Portal Operations 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 published job has been completed, you can return to the Tracker and refresh the Event List for Customer to see that the Severity Event E0006 with Severity Reject Root now has a count of 0. Instead, we now have a new occurrence of the same event with a Severity Warning and a count of 8
Likewise, the Event List for Card and Account Event I0011 now has a count of zero:
If you're happy with the result, then commit your changes to the Repository.
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 Accounts 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 cases 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.