Relationships

Let's take a look at how Relationships work in the Target Map. 

Say we have a Business Object and that the Business Object have quite a few interface fields.

Let's also say, for example, it has a number identifying that particular Business Object, like a Customer. There'll probably be more interface fields associated with the Business Object. Since the Customer number is what identifies one Customer in the Target Map, you can mark it as a key field. 

Let's say then that this Customer can have one or more addresses like a primary residential address, but maybe also holiday homes and so on. For the sake of the example, let's say for each address, apart from the information of the address itself, we also define an interface field that we want an address number. 

Since this is what identifies one address for this Customer, it is also marked as a key field in the Target Map. Now, as the migration is processing this Customer, we've also said that we want a row in a target object in the target system.

And one of the fields of this row is the internal ID of this address. In the target system. So when mapping the Customer we have used a mapping rule to calculate the value for this ID. So far so good. 

This works well. Now comes along another Business Object like Account. The Account also has interface fields. For sure it'll have an account number and map that will be marked as a key in the Target Map. And it will also have a field that identifies the Customer that owns the account. 

Let's say that the account has a child Business Object called Statement that also has a list of interface fields and one of the interface fields on the Statement will be the number of the address to send this statement to. 

So far so good. When the account is processing in the migration we are going to create a target object and one of the fields on this target object is going to point to the internal ID of the address that this statement must be sent to. 

Next, we want the address ID and this is where things kind of stop because the address ID was calculated when the customer was migrating. This is not an interface value. At this point how do we get hold of it? 

In comes the Relationship. The way to do this is that on the Business Object Statement, you then define a Relationship and you tell the Target Map that this relationship points to the child address under customer. 

Relationship once defined on Statement pointing to the address, the target map will go from address and upwards and it will collect all the key fields that it sees. 

In our example above we have two keys. The Target Map will show you the key for this address. You have to provide a customer number and you have to provide an address number in order to point out exactly which address is it you want.

Now, like many other places in the Target Map and in Studio as such, you now have to assign a value to look up the customer and the address. In this case, you choose an interface value for the customer number and you would pick up the interface field from Account that is the owner you would also for the address number pick an interface value and here you would choose the address number field of the state. 

When the account migration is actually processing. It will pick up the interface fields on the account for the owner and on the statement for the address number. It would use those two values to look up the customer and in the customer find the correct address. 

Once you have created this bridge, this link, you can then gain access to the values that were calculated during the customer by migration and retrieve them in order to assign them to target fields in the account. 

You could say logically - you get the value from there, but of course, it is really going all the way along the relationship. This is how this is mapped. Studio provides great assistance in order to make sure you get this right, looking a bit forward when this is actually executing in the Runtime, the target engine knows about this relationship. 

When the Customer is being migrated by the target engine, it knows that somebody somewhere needs the value of this field. We will actually cache it, put it aside, so when the account comes along, it is not going to go through a long, complicated process, it is simply just going to go out in the cache and pick up the value. 

That's one execution aspect of a Relationship. Another very important execution aspect of the Relationship is that the target engine now knows that there is a dependency between one specific account and one specific customer. 

The target engine will ensure that this Customer is migrated. Before the Account. The value of this ID field will be calculated and cached by the time the account comes by and needs the value. 

For more have a look at this video on Relationships.