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.
Lars Kjaersgaard
Studio 1.7
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.
Apart from rearranging the UI of the Extraction Map, these terms have also changed:
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:
Director Client 1.7
Director Runtime 1.7
In the case of Partitioned Unload, the unloaded files are placed in sub-folders per Partition.
Tracker 1.7
Interfaces 1.7
Engine Framework 1.7
Visual Studio Extension 1.7
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.