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 1Figure 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
