It has following parameters:

• resource - Resource for which the aggregation is required like Account. (Path Parameter)
• data - Data of the resource for which the aggregation is to be done like Closing balance for Account. (Query Parameter)
• grouping - Grouping for which the aggregation is required like type of transaction CREDIT or DEBIT. It is not mandatory to specify grouping. If not then default value will be “DEFAULT”. (Query Parameter)
• interval - The interval at which the aggregated data is required like Daily, Monthly. It is not mandatory to specify interval. If not then default value will be “D – Daily”. All available values are D - Daily, W - Weekly, F – Fortnightly, M - Monthly, Q - Quarterly, Y – Yearly. (Query Parameter)
• count - The number of times the aggregated data is required at given intervals. It is not mandatory to specify count. If not then default value will be 1. (Query Parameter)
• q - The generic filtering parameter. (Query Parameter)
• sortBy - sorting parameter to sort q param results. (Query Parameter)
• maxRecords - max records parameter to restrict count of q param results. (Query Parameter)

Now every combination of resource, data and grouping has its own service / implementation and an entry for the same is made in the seed.

Now every combination of resource, data and grouping has its own service / implementation and an entry for the same is made in the seed.

Now initially , the call goes to aggregator REST API with above mentioned parameters from which the control goes to aggregator service. Finally in aggregator service the fully qualified name of the actual service / implementation is fetched from the DB based on the combination of “resource”, “data” and “grouping” and actual aggregation is done.

For every service / implementation, an entry is made in DIGX_FW_CONFIG_ALL_B where prop_id is “resource.data.grouping” and category_id is “AggregatorConfig”. Now for one implementation there can be multiple grouping possible. In that case the prop_id will be “resource.data.grouping1, grouping2, ...groupingN”.

Example

For every service / implementation, an entry is made in DIGX_FW_CONFIG_ALL_B where prop_id is “resource.data.grouping” and category_id is “AggregatorConfig”. Now for one implementation there can be multiple grouping possible. In that case the prop_id will be “resource.data.grouping1, grouping2, ...groupingN”.

• resource - Invoice
• data - Amount
• grouping - Program

Thus, in this case the prop_id will be “invoices.Amount.Program” where prop_value contains the fully qualified name of the service which represents the implementation for the same.

Similarly, if multiple grouping is to be done like based on program and currency, then the prop_id will be “invoice.Amount.Program,Currency” or “invoice.Amount.Currency,Program”.

i.e. In the above case, If the prop_id used is “invoice.Amount.Program,Currency” then from UI grouping should be sent in query parameter as “grouping=Program,Currency”.

**** In case of no grouping required then prop_id will look like “resource.data.DEFAULT” i.e. “invoice.Amount.DEFAULT”

Now, the parameters like q, sortBy and maxRecords are the parameters for QQuery implementation which are used similarly the way they are used in other OBAPI services.

In case of aggregator service , these parameters will be directly passed to the implementation service where they can be used in actual call made to get the original data before aggregation.