Batch processing requiring embedded aggregation

This scenario combines the two previously described examples, where an aggregation of data from multiple sources is embedded within a batch processing aggregation.

The scenario is a personnel-based application that creates payslip information for specific employees. The back-end service is represented by a Callout node and requires full employee records, rather than the employee IDs, which arrive at the mediation flow. These employee records are created by the mediation from two sources, an HR system and a Payroll system. The former stores information concerning the employee's name, address, and vacation entitlement, while the latter contains information regarding salary and department.

Design the aggregation

The input to the flow is an array of employee identifiers, while the output is an array of status objects, indicating whether the payslip processing succeeded or not, as shown in Figure 1

Figure 1. Flow input and output

The HR and Payroll systems that are called from within the mediation flow can only handle a single record, as shown in Figure 2.

Figure 2. HR and Payroll Record

The outer aggregation iterates through all the employeeIDs, while the inner aggregation builds a response aggregated from the HR and Payroll services. This is depicted in Figure 3 .

Figure 3. The inner and outer flow

In this case, after the two services have been called successfully, the HRRecord and PayrollRecord must be combined into a single EmployeeRecord. The EmployeeRecord must then be appended to an array of records to comply with the interface for the Payslip service, which is called via the Callout node, as in Figure 4. Consequently, the same model for Shared context as previously described is used.

Figure 4. EmployeeRecord array

After the data has been aggregated and batched, the Payslip service is called, which takes an array of EmployeeRecord objects and returns an array of PayslipStatus objects, as shown in Figure 5.

Figure 5. PayslipStatus object