Mounting Profile as Subnode in Source Structure
You can use the context menu on a node or field of the destination structure to insert an existing profile (its destination structure) as a subnode in the source structure.
Requirements for a Profile to Be Mounted
A profile can be mounted if
uses the normal data mapper (not the simple one).
(The options Enter output channels for each record and Incorporate IU must not be set.)
Requirements for a Mounting Profile
A profile can mount another profile if
Mounting a Profile
A profile can be mounted via the context menu of any field and node in the destination structure.
Another dialogue appears.
(1) Select the profile to be mounted.
(2) Specify a unique prefix and node name for the source structure. Note: The prefix ensures that all field names in the source structure remain unique, since two included profiles could use an identical field name, for example. The prefix has the effect that you get two distinct names prefix1.fieldname and prefix2.fieldname. This also allows you to include the same profile twice if you use a different prefix. The node name can then be the same. See (6).
(3) This will mount the profile.
As a result, on the one hand, the function call sub profile for source tree (a,b,c,d,e,f,g,h) is placed on your node/field in the destination structure. Parameters a, b and h are set automatically (see there).
On the other hand, you will then see the following substructure in the source structure. If further profiles are mounted, they also end up under the blue node _IncludedSubProfiles_.
(4) The attributes of nodes and fields of the mounted profile are locked. However, you can modify them manually if you click on the lock if only minor details in the mounted profile have changed. Otherwise, you should use the synchronisation (described below).
(5) If changes have been made to the mounted profile, you can synchronise them automatically.
(6) See note in (2).
Calling a Profile and Data Flow
You can delete fields and nodes in the substructure if you only need a partial view of the data, but the data is always transferred completely.
You can map with this substructure as you are used to. The substructure is filled with data by calling function call sub profile for source tree (a,b,c,d,e,f,g,h). The data always comes from the destination structure of the mounted profile and not from its Integration Unit, etc.
Note: The substructure _IncludedSubProfiles_ is not displayed in mapping tests, but the data sent to it is shown in a separate tab there.
You can fill a substructure with data as often as you like by repeatedly calling the above function. The function can be inserted at any position (even multiple times). The result set of the previous function call can be removed via parameter g of the function (see there). As a result, you simply get multiplicities of the substructure, or to put it more concretely, multiple occurrences of the node prefix.Node_from_profile. You can then use a path on prefix.Node_from_profile in the destination structure to read that data, just as you already know it from 'normal' mappings. Please do not place the path on prefix.nodename.
The included partial structures are filled with data in the order the respective function is called. If the function has not been called yet in the destination structure, the included structure will not have data in it. In this case, it would therefore not make sense to place a path on a node (e.g. prefix.Node_from_profile here) whose partial structure (e.g. prefix.nodename here) has not been filled with data yet.
Important note: It is the responsibility of the user/developer to avoid endless loops (or to handle them appropriately) when using the subprofile mechanism described here! It is possible, for example, to create a profile 1 that includes profile 2 and profile 3. If you then include profile 1 in profile 2, you will get an endless loop.
Hierarchical Structures
As you may have noticed, the included profiles in the source structure are all 'flat'. Although they have nestings in themselves, you cannot insert a profile 1 first and then a profile 2 into profile 1. Nestings of this kind, i.e. the construction of a hierarchical overall structure, are achieved through mapping and the hierarchical structuring of the destination structure. And these methods are all familiar to you from 'normal' mappings. Specifically, the data from profile 2 can be inserted below/inside the data from profile 1 in the destination structure.
Example Profiles
Import the following two profiles and set them on active. Profile_2 includes Profile_1 (adjust the names accordingly). The profiles are relatively meaningless. They are just a simple example of what has been explained above. Note: If you do not use a database alias hub, you might have to adjust that in phase 1 of the profiles.
Application Example
Let's assume profile 2 gets a number of items in an order. You could then go through the articles in the destination structure, like you already know from 'normal' mappings, and call a profile 1 (included in the source structure), which provides you with additional information about the respective article (the current price, the current stock in the warehouse, etc.). So profile 1 can be built by anyone as a service profile and you can use it in your profile to enrich your own information. So you only give profile 1 an item number, for example, and get back the desired data, without having to know what happens in the background, such as database queries or accesses to an ERP system. You also do not have to worry about changes in how those other systems are accessed. Your profile 2 can stay the same and only profile 1 has to be maintained if necessary. So just the way you want it in a service-oriented architecture.