Release 2021-08-08

Posted about 3 years ago by Lars Kjaersgaard

Lars Kjaersgaard
Lars Kjaersgaard Admin

Studio 1.7

  • Fix error in Studio when typing a number in the Cardinality Max textbox on the Interface Field list of a Business Object without clearing the * first

  • Add missing validation in Target Map of duplicate Interface Field names on a Business Object

  • Fix error in Studio Source Map validation. If a child Business Object is linking to a Source Object in the Parent Extraction map, that has been removed (for instance a View that has been deleted), the validation failed with a null reference

  • The Project Explorer Treeview for a Business Object has changed. Previously, the Target Objects where direct children of the Business Object whereas child Business Objects were under a Children folder node. This has been reversed, so the Target Objects are under a Target folder node and the child Business Objects are direct children of the parent Business Object

    The Target folder node appears when the first Target Object is added to a Business Object. If a Business Object has no Target Objects yet, it does not have a Target folder node.



  • A new facility in the Target Map to control the processing order of child Business Objects regardless of the order, the children are delivered by the Source Map:


  • Similarly, the ability in the Source Map to control the sequence of the child Business Objects created by the Source Engine has been made more apparent
    • Previously, this could be achieved by adding the columns used by the Child Key as columns in the Pick First list (formerly known as Order by)
    • Now, when working on the root Source Object of a child Business Object, there is a new column in the Child Key list to decide the order
    • At the same time, the layout and terminology of the Extraction Map has been changed. More information and screen shots here
      Apart from rearranging the UI of the Extraction Map, these terms have also changed:
      • Relationship tab has been renamed to Selection (only on the root Source Object on a root Business Object)
      • Relationship has been renamed to Lookup
      • Where Clause has been renamed to Predicate
      • Named Values has been renamed to Predicate Parameters
      • Source Key/Child Key has been renamed to Discriminator (and the Order column added on child Business Objects)
      • Pick First has been renamed to Selector
    • Studio validates that
      • The Selector does not contain any fields that are also part of the Discriminator or the Lookup
      • The Discriminator does not contain any fields that are also part of the Lookup  
      • Refactor all items in place in the repository database
        • Please do a backup of the repository database before running refactor
        • (Studio Install Path)\MigFx.Studio.Refactor FieldOrder --DataSource (Sql Server instance) --InitialCatalog (Repository database) --WorkingFolder (temp working folder) --Commit --CommitMessage "Refactor Field Order"
  • 2 new flags have been added to lookup rules: Not found, all parameters provided and Not found, some parameters not provided



    Especially the new flag Not found, all parameters provided is useful for Validation rules when validating optional Interface Fields. When an Interface Field is used as a parameter to the rule (which is after all quite natural), then this flag will only be raised if a value for the Interface Field has actually been provided. The flag will not be raised if the Interface Field is null.

    To be precise: If no row is found by the lookup rule, the Not found flag will always be raised - this has not changed. But in addition, one of the new flags will be raised, depending on the input parameters to the lookup rule:
    • Flag 3 (Not found, all parameters provided): Raised if none of the input parameters are null
    • Flag 4 (Not found, some parameters not provided): Raised if 1 (or more) of the input parameters are null  

    • Refactor all items in place in the repository database
      • Please do a backup of the repository database before running refactor
      • (Studio Install Path)\MigFx.Studio.Refactor LookupFlags --DataSource (Sql Server instance) --InitialCatalog (Repository database) --WorkingFolder (temp working folder) --Commit --CommitMessage "Refactor Lookup and Relationship flags"
  • Please check the Repository connection after install of Studio 1.7


Director Client 1.7

  • Including Director.ClientService 1.7

  • The Director client now exposes a command line interface that is used by the Visual Studio extension to deploy and debug migFx engines

  • Source files and Valueset files can now be uploaded via the Director client to the correct location for the track on the migration server

  • Unloaded Target files (import) and unloaded export files (export) can now be downloaded from the migration server via the Director client

  • The new Deploy functionality includes some modifications to the master database. Please run the attached Sql script MasterDb.01.sql


Director Runtime 1.7

  • More robust cleaning of invalid xml characters in source xml (Ticket 867)

  • Minor refactor of Migration database to avoid duplicate keys in Setup jobs caused by renames of Views and Metadata Alias in Studio
    • Please run attached MigrationDb.03.sql refactor script on all Migration databases

  • Fussy load of Source Files to the Staging database
    • Column order in the Source File is not important. Column headers in the file are matched by name (not case sensitive) to the field names in the metadata form the Source Map and loaded correctly
    • Nullable columns and Char columns can be omitted from the Source File. A blank column is automatically provided by the loader
    • This behavior is controlled by a new option in the Director:

  • Partitioned unload functionality
    • The unload of exported data and target data by the default unloader included with migFx (unloads Business Objects to xml files) can now be optionally split by Partition and optionally zipped after unload

      In the case of Partitioned Unload, the unloaded files are placed in sub-folders per Partition.

    • This is controlled by 2 new options in the Director Client:
    • Compress Migration Xml controls whether the unloaded files are zipped or not
    • Partitioned Unload can take 3 values
      • No: Do not do Partitioned Unload
      • All: There will always be created a folder for all partitions. Even Partitions that do not have any unloaded items
      • Content: There will only be created a folder for Partition with actual unloaded items
    • These 2 new options are available to custom unloader implementations, but it is important to note that it is the responsibility of a custom unloader to actually do the partitioned unload and the zipping as indicated by the options. Existing custom unloader implementations must be modified accordingly, if partitioned unload is required.

Tracker 1.7

  • Security flaws have been fixed for external users with limited access (to only 1 partition)
    • Search listed items for all partitions regardless of authorization
    • Via directly entering a URL in the browser, a user could access details and xml data for items in unauthorized partitions
  • If there are more than 5 partitions, the Partitions are shown in a dropdown


Interfaces 1.7

  • Fixed error in parse of DB2 formatted timestamp date strings in DB2 reformatter to load source files from DB2 unload (Ticket 892). Released as hotfix 2010-03-01.


Engine Framework 1.7

  • Related changes to 
  • Minor modification to the Xml generated by both the Source Engine and the Target Engine: The root xml element now has partition attribute. This change allows Unloader implementations to separate the unloaded data by Partition. NB: This is a change to the generated xml


Visual Studio Extension 1.7

  • Deploy function has been enhanced to include optional restart of relevant Tracks as well as submit of setup jobs. Read more about the new Deploy here

  • New function to debug engine locally from Visual Studio. Read more about Debug here

  • The version of the Visual Studio Extension also requires manual refactoring of the existing MigFx.config files in any Visual Studio solution containing migFx engines - plus manual updates in the Master database. These manual actions are described in the attached document MigFx.port.pdf

migFx ported to Net 5.0 and netstandard

MigFx version 1.7 generally marks the port of eligible MigFx libraries and programs from the .NET Framework to Net 5.0 / netstandard 2.0. 


Not everything is ported, notably the Windows Forms applications (Studio and Director) plus the existing ASP.NET applications (Tracker and Director Web Services) remain in the .NET Framework but have been upgraded to .NET 4.7.2 in order to be able to access the common libraries that all have been ported to netstandard 2.0.


However, all public interfaces libraries as well as the entire MigFx Director Runtime has been ported.


As part of this overall refactoring, MigFx no longer places any libraries in the Global Assembly Cache (GAC).


This port requires manual refactorings in your existing MigFx installation. These refactorings are described in the attached document: MigFx.Port.pdf.



0 Votes


0 Comments

Login or Sign up to post a comment