Before you start creating your first rules let's just have a little look at rules in general and what kind of animal they really are.
A Rule is something that can be used in different contexts in the Target Map (and in the Source Map once you get that far). A Rule does a job and has some basic characteristics:
- It is of a specific type, more on this below
- Has a name
- Needs some parameters to do its job
- Does its job and returns a value of a given data type (well most of them returns something)
- May raise 1 or several Flags to signal that something (presumably interesting) happened while doing the job
All rules can come in 2 different flavours:
- Manual rules: In Studio you specify Name, return type, Parameters and Flags. In addition you must specify what the rule is supposed to do. You or somebody else will later implement this rule manually (at a well defined location in the associated Visual Studio c# class library - if you wanna know)
- Lookup rules: In Studio you point out a Valueset for the lookup and point out the lookup columns and the return column. migFx will take care of the rest, including 2 Flags to signal if a row was found or not
A rule has a type and this type defines in what context the rule can be used. In the target Map you can work with the rule types below.
In order to grasp the full meaning of these types, it may help to consider that all this of course ends up in the runtime, executing the migration of Business Objects one at a time. And delving deeper, the execution sequence is
- Business Object
- Interface Fields
- Target Objects
- Target Fields
- Child Business Objects (recurse back to top)
Given this execution sequence, these are the Rule types in the Target Map (the Source Map have other, different, Rule types)
This Sketch video explains the different rule types in the Target Map (and also in the Source Map coming up in a later exercise).
|Entry Rule||Called before starting the processing of a Business Object and can only return a Boolean. If the Entry Rule returns false, the Business Object is skipped and no data will be created for the Target System for this one.|
|Exit Rule||Called after ending the processing of a Business Object and can only return a Boolean. If the Exit Rule returns false, the Business Object is skipped and no data will be created for the Target System for this one.|
Exit rules are often used to cross check the Target data created for the Business Object - and can even inject missing Target data into the migration stream.
|Validation Rule||Validates the value of incoming Interface Fields.|
|Condition Rule||Called before starting the processing of a Target Object. If the Condition Rule returns false, the Target Object is skipped and no data will be created for the Target System for this one.|
|Mapping Rule||Calculates the value for a Target Field.|
All (manual) rules have access to a lot of nice stuff:
- The Business Object hierarchy to inspect values of received Interface Fields and created Target Fields
- Other Rules
- Functionality to inject Target data into the migration stream
We hope that this little primer gives you a foundation to understand the rules of migFx. The exercises that follow are not going to whip you through every single one, but you will get the chance to create and use Validation Rules and Mapping Rules.
However, the Workshop Target map do contain plenty of rules of all types in the mapping of Account and Customer. Please have a look around to see them in use.