Like we did for the Target Map, let's have a look at the different type of Rules you have at your disposal in the Source Map.
There is also a Severity unique to the Source Map called drop. Finally, since you are no longer a novice in migFx, we'll have a look at the something extremely versatile but at the outset also a bit more difficult to explain: The Bags.
But first the Rules:
This Sketch video explains the rule types in the Target- and Source Map
|Condition Rule||Called before starting the extraction of source data for a child Business Object. If the Condition Rule returns false this child Business Object will be skipped and no data will be produced for the child in the Target interface.|
Note that Condition Rules cannot be called from a root Business Object - only from child Business Objects
|Filter Rule||You can specify one or more Filter Rules to be called for a Source Object. If just one of the Filter Rules returns false the Source Object will be skipped and its Source Fields will not be available|
|Export Rule||Called to calculate the value to be assigned to a Target Interface Field.|
Just like in the Target Map, all these rules can raise Flags, and when a rule is used in a specific context you can decide how to react to these Flags. Including firing an Event, assign a Severity and an Receiver.
In the Target Map you have one more Severity at your disposal. In the Target Map you had
- Reject Root
- Reject Child
- Error, Warning and Information
Here in the Source Map you can also use
- Drop: By assigning the Severity Drop to a Flag anywhere you make the current Business silently go away. No Event will be fired to be shown in the Tracker. You can use this Severity if some condition deep within the Source data renders the current Business Object irrelevant.
Both in the Target Map and also here in the Source Map you have probably noticed a folder node in the Project Explorer tree view - under Rule - called Bag. In addition, when opening the Value drop down in various places, you have seen the value type Bag Property. Bags are very useful but also an advanced subject. So far we have glided silently past and let you wonder all by yourself - but ok then, let's talk about Bags.
The rules you have been using so far
- receive some Parameters,
- can raise some Flags
- and return a value.
They live in the context they are called and then immediately die away. They have no way of storing any state between calls. Imagine for instance in some Business Object you wanted to count the number of a certain child Business Object. The rules would have a hard time doing so, because they can't store state - the count - between calls.
Enter Bags that can store state. A Bag is created the first time it is used in a root Business Object (for instance Customer, Account or Card). While the root Business Object - and all its children - is been processed, the Bag exists and can store state. And it - and its state - is thrown away as soon as the next root Business Object starts processing.
The Bag can have - but does not need to have - one or more Methods, and these Methods can be called anywhere in the mapping you are using rules. In addition to methods, the Bag can have Properties. The properties in turn can be used to assign values to Fields or Parameters. The Methods of the Bag can store state in the Properties.
As an example, let's say that the every child Business Object Statement under the Business Object Account had to deliver a Target Object containing a numeric Sequence Field. This example could look like this
- The Account Business Object calls a method on the Bag - as an Entry Rule - initializing the SequenceNumber Property of the Bag to 0
- Each of the child Business Objects Statement under the Account - as an Entry Rule - calls another Method on the Bag that increments the SequenceNumber Property
- On the Target Object in question under each Business Object Statement, the SequenceNumber is used as a value type Bag Property to assign the value to the Sequence Field
While you of course specify the Methods and Properties of the Bag in Studio so you can use them elsewhere, the Bag must afterwards always be manually implemented. The manual implementation - as all other - can access Valuesets, Constants, other Rules and indeed other Bags and their Methods and Properties.
Here's a sketch video explaining Bags:
What happened here?
Well, nothing really happened, but we did go through the rule types specific to the Source Map, the Condition Rules, the Filter Rules and the Export Rules. In addition you have gained some knowledge of the Bags that combine several Methods with Properties holding state.
In fact, with the Export Rules and Bag Properties you have added value types to your arsenal, so now you have them all:
- Calculated: Use an Export Rule or a Bag Method to calculate the value to assign
- Bag Property: Use the current value of a Bag Property to assign
Finally you also have a new Severity, unique to the Source Map, Drop that will just silently drop the current Business Object from the migration stream.