In relation to the iterative process of migFx - illustrated below - in the last section of exercises you have been in the step Test & Feedback, analyzing the Events that were fired during the iteration of the Card Business Object.

 



In fact, in earlier exercises, you have covered each of the steps in the process, so there is really nothing new here. The aim of this section of the training exercises is to tie it all together by letting you solve some of the Events that occurred in your iteration of Card as well as in earlier iterations of Customer and Account.


Let's start out with the last Event I0025 - Card Status ({0}) is unknown in the previous exercise. A large count of Card Business Object instances is rejected due to an unknown CardStatus Blocked. It turned out the root cause is that this CardStatus is missing in the static Valueset CardStatus in the Studio Target Map.


Agreed resolution

Let's assume you - or other members of the migration team - have had a dialogue with a specialist from the Target System. 

It turns out that the CardStatus Blocked is actually valid in the Target System, but it is just no longer used actively. This is the original reason the CardStatus was not added to the Valueset. However, since the CardStatus is in fact valid, the migration team has decided simply to add it to the Valueset to resolve the Event.


Another point is that the Severity Reject Root for an unknown CardStatus is deemed too high. In case of an unknown CardStatus only the CardStatus child Business Object instance should be rejected, not the entire Card. So the Severity of the Event must be changed from Reject Root to Reject Child.


Modify Mapping

  1. Open the Workshop Target Map in Studio.

  2. Locate and open the Event I0025 and change the Severity from Reject Root to Reject Child
  3. Open the Valueset CardStatus and add the CardStatus Blocked

  4. Validate and ensure you have no validation errors (alt-v or Main Menu -> Project -> Validate)

  5. Publish to Generator (alt-g or Main Menu -> Project -> Publish to Generator)
    1. The path in the publish dialog should already be correct as you have already set this up in an earlier exercise - Studio remembers this path. If not, this is the correct path: D:\MigFx\Workshop\Training\Trainees\TraineeXX\MigFx\VisualStudio\Workshop\Projects\Workshop\Workshop.TargetEngine\PublishedTarget.xml where XX is your Trainee number
    2. Click the Publish button to publish the mapping to the Generator
  6. Check in your changes


It is worth noting that the static Valueset CardStatus was modified by typing the new CardStatus directly in Studio. The data content of all static Valuesets is 'baked into' the generated Target Engine. This has implications for a later step in this exercise, when the migration of the affected Cards is iterated.


Generate Code

  1. Open the Workshop Solution in Visual Studio

  2. Locate and right-click the Workshop.TargetEngine project in the Solution Explorer

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

  4. The dialog shows the path to the published file in the project. This should be the same path as above in Studio and the dialog should show that the file is very new, as you just created it from Studio. If the file is older than expected, the path in Studio may be wrong. In that case, copy the path from the Generator dialog and go back to Studio and publish again, this time pasting the path into the publish dialog
  5. Click the Ok button to generate the engine code


Rule Implementation

In this case, all the modifications necessary have been done by modifying in Studio. There are no manual rule implementations to modify.


Deployment & Execution

Now the new code for the target Engine has been generated, it's time to deploy the engine in the migFx runtime.


Deployment

  • Locate and right-click the Workshop.TargetEngine project in the Solution Explorer

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

  • Check both restart and Deploy and click the Ok button to deploy the Target Engine, restart the Track and run the Target Engine setup
 It is important to run the Setup job because we modified the data content of the static Valueset CardStatus in the Target Map above. The Target Engine carries the modified data compiled into the engine. If the Setup job wasn't run, there would be a misalignment between the Valueset data in the migration database of the Track, and the Target Engine.

But there is no danger of executing anything with this misalignment. If any job is submitted to execute the Target Engine to import any Business Object now, the migFx runtime would detect the misalignment and fail the job like this:s
 

Execution

Finally everything is ready to iterate the import of the Cards that fired the Event I0025. The Portal Operations makes it trivial to pick out just these Card to import: 

  1. Go to the panel Target / Events
  2. Select the Event I0025 on the Card Business Object
  3. Click the Import button to submit a job to import the affected Cards
  4. Go to the Job List to follow the progress of the job. Note that already now - real-time while the job is executing (click Refresh)- you can verify that the Card is no longer being rejected


Publish Result

When the job finishes the iteration of the Cards that fired Event I0025 is finished. It is now time to publish the results of the iteration to the Portal.

  1. In the Portal Operations go to panel Administration / Manage
  2. Check the Tracker Publish radio button and click the Submit button
  3. In the dialog, select the Portal Operations tab, move the Card Business Object from the Available to the Selected list box and click the Ok button to submit the Publish job
  4. Verify in the Job List that the job completes successfully


Test & Feedback

Go to the Tracker and view the Event list for Card:


 

The count for Event I0025 is now zero and the state has changed to Done. 


In the exercise introducing the Tracker interface, this state - as well as the other list states - is explained: Exercise 5.2 – Get Familiar with the Portal User Interface.


If you're happy with the result, then commit your changes to the Repository.

What happened here?

Congratulations, you have just completed a complete iteration cycle of migFx! 


Combined with the last section of exercises, we hope this has given you an impression of the unique capabilities of migFx:

  1. Robust support for the discovery and analysis of Events and issues in the migration
  2. Ease of locating and correcting the root cause in the mapping 
  3. Rapid process of correcting the mapping, generating the code and deploying the new engine with complete confidence that the modifications in the mapping are correctly implemented
  4. Ease of iterating the migration for just the Card Business Objects that were affected by the selected Event - and nothing else