Profile in source structure (sub profile)
You can use the context menu on a node or field of the target structure to insert an existing profile (its target structure) as a subnode in the source structure (substructure).
Requirements for a profile to be added (subprofile)
A profile can be added if
it is active and not suspended,
uses the normal data mapper (not the simple one).
(The options Enter output channels for each record and Incorporate IU must not be set.)
A profile with a time-driven Input Agent of type HTTP must not have checkbox Activate parallel processing set.
Requirements for an added profile
A profile can add another profile if
it does not use document type "XML" with the "V4" parser.
Adding a subprofile
A profile can be added via the context menu (→ Add profile as sub node in source tree) of any field and node in the target structure. Another dialogue will appear.
(1) Select the profile to be added.
(2) Specify a unique prefix and a node name for the substructure. Note: The prefix ensures that all field/node names in the source structure remain unique, since two included profiles could use an identical field/node name, for example. The prefix has the effect that you get two distinct names prefix1.fieldname and prefix2.fieldname, for example. This also allows you to include the same profile twice.
(3) This will add the profile.
Result
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 target 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.
(4) The attributes of nodes and fields of the subprofile are locked. However, you can modify them manually if you click on the lock if only minor details in the subprofile have changed. Otherwise, you should use the synchronisation (described below).
(5) If changes have been made to the subprofile, you can synchronise them automatically via the context menu of the node (here sub1.generate_random_number) → Synchronize with profile .
Passed variables (and lists and maps)
The variables of the calling profile are passed to the subprofile. See section Passed Variables, Lists and Maps (Profile Chains and Sub Profiles). There you will also find a description of how to pass lists and maps (and all variables of the calling profile in a map).
1:1 mapping
In a 1:1 mapping, the substructure is not transferred.
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 target 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 target structure.
Application example
Let's assume profile 2 gets a number of items in an order. You could then go through the articles in the target 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.
Example profiles
Example 1
Following are two simple example profiles for illustration.
Profile-Generate_random_number.pak (Import first and set active.)
Profile-Call_subprofile_1.pak (Phases 4, 5 and 6 of the subprofile are not executed and its backup file is deleted. Have another look at the description of function call sub profile for source tree (a,b,c,d,e,f,g,h))
First, perform a mapping test in profile Call_subprofile_1 (a test file is included). At first there is not much to see there. We only see that the subprofile has been called successfully because the field target_field, on which the subprofile call takes place, has received the return value true. The substructure with the data of the subprofile is not displayed.
However, there is a separate tab in the mapping dialogue where you can see the data that the subprofile provides.
Example 2
Next, we simply call the function twice in succession and look at the result. The substructure is then filled with data twice. So just the way you know it, if you read in two positions of an order, for example.
Example 3
Now we also call the function twice, but we delete the data of the previous call with parameter g in the second function call. So we only get the data of the second call in the substructure.
In the target structure, the data of the substructure is mapped (look at the path). When you do a mapping test, you see one set of data. But in the subprofile calls tab you can see the data of both subprofile calls (as in the previous example).
Example 4
In this example, we also call the function twice, but we now use parameter j in the first function call to store the result of the subprofile in the internal cache. In the second function call, we then use parameter k to use the cache contents instead of calling the subprofile again.
When you perform a mapping test, you see one record. In the subprofile calls tab, you can also see only one subprofile call.
See Also
Section Adding Lists and Maps in Source Structure (→ " _ClipboardData_" )
Section Automated Workflows (→ Vertical integration with sub profiles).
Section Nested and networked profiles.