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. This way, you can use the examples here 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 the format that you want, link the data to the Collector function just as you would link the data to a UVJ function. The purpose of the Collector function is to store your altered data in memory so that it can be restructured.

The Collector function can only exist in a loop, because you need to have a set of records to be able to sort them. If you have a nested data structure, for example a set of employees each having a set of time transactions, you need to 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 executed just before the outmost restructure loop begins to execute. 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. It is more like saying, "I want to use this data". For example, instead of saying, "I want to use /Timesheets/Employee/Time/Date from the input document", you now say, "I want to 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 retrieveing 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 retrieveed 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.