Collector concepts

When you retrieve data from the input document into the restructuring process as it is, you cannot alter the data or apply any kind of logic on it before it is restructured. After the restructure process, you can alter the data.

Sometimes, you need to alter the data before it goes into the restructure process. The only way to do this without any limitations is to use ordinary mapping logic to collect the data to be restructured. You can use these examples to restructure the data to create a new virtual element that you can use for tasks such as sorting and grouping, converting amounts, and filtering out data.

For example:

• Use substring values.

• Use correct IDs from BODs depending on attribute values.

• Use several different input elements, such as elements within a choice.

When you have all data in your specified format, link the data to the Collector function similar to how you link the data to a UVJ function. The purpose of the Collector function is to store your altered data in memory so you can restructure them.

The Collector function can only exist in a loop, because you need to have a set of records to sort them. If you have a nested data structure, for example, a set of employees each having a set of time transactions, you must use nested collector loops. For the Restructure function, the Collector function is also aware of its context through the nested loops. For example, the Collector function for the time transactions knows to which employee the time transactions belongs, through the Collector function for the employee in the outer loop.

When linking elements and attributes from the input document directly to the Restructure functions, an invisible automatic mapping is run just before the outmost restructure loop begins to run. The collector loops replace this invisible automatic mapping. In both cases, the purpose is to collect data to restructure.

When using Collector functions, you must link output parameters for the Collector functions to the Restructure functions. These links are dashed because these are not ordinary data links. If you say, "I can use this data". For example, it is preferable to say, "I can use /EmployeeCollectLoop/TimeCollectLoop/Collector_1/Date from the collected data". The rest of the restructure logic is the same as when using data directly from the input document.

You cannot mix data from the input document and data from Collector functions. You must choose one of these two ways of retrieving data for all Restructure functions within a nested restructure loop structure. All data to be restructured must belong to the same data structure, otherwise there is no common context. You can link data from the input document to the Collector functions, and you can also use Collector functions with other data, for example, data retrieved through M3 API calls or database operations. In summary, there is no common context between Collector functions and the input document.

When using Collector functions, you cannot add input control links to Restructure function headers. Input control links are only used for the automatic mapping from the input document. You have already defined the collector loops that fulfill the same purpose.

After data is collected through the Collector functions, the data is sorted before the (outmost) restructure loop starts. Then, the restructure logic is the same as described in Restructure function. The restructure logic only differs on how you get the data to restructure.