Add an Output Structure to an Aggregate

Aggregates & Queries
On our radar

Instead of having to use an SQL statement for this:
SELECT {OrderStatus}.[Label], COUNT({Order}.[Id]), '', '' , '' FROM {Order} INNER JOIN {OrderStatus} ON {Order}.[OrderStatusId] = {OrderStatus}.[Id] GROUP BY {OrderStatus}.[Label]

with an output structure of DataPoint for example.

Add the possibility of defining the Output Structure of an Aggregate so it's bind to DataPoint structure directly.  

Created on 27 Jan 2017
Comments (10)

Why would you need to use an advanced SQL for that? The aggregate can do that, and if the definition matches your DataPoint, you should be able to just ListAppendAll the aggregate results to your DataPointList and it will map it over?


Yes, that would be my approach as well. The mapping possibilities in P10 are great for such things. You wouldn't even need a ListAppendAll, just pass the Aggregate output to whatever action uses a DataPoint List and map it right there.

Thanks for the feedback,

I add this idea because with an aggregate, I was unable to map the data from an entity (e.g. Order) directly to a DataPoint List.

Is it possible to map without a for each loop? If so, how?

BTW Kilian, what "mapping possibilities in P10" exists that we can use for this scenario?



Hi Joao,

You just use an assign, and Service Studio asks you how to map. Easy peasy!

Thx Kilian (Y)

Something like this then:

Hi João,

That's indeed what I meant.

Having the mapping occur in the Aggregate is a better approach than adhock mapping in another component's input parameters.  Mapping in the aggregate promotes reuse and also encapsulated the business logic.  Software today is probably at least 30% to 60% mashups of various services (enterprise to micro) into some type composite view that is usual one of the primary focuses of the given application.  Also with OS, the aggregate mapping can be unit tested utilize the existing "Test Values" feature vs waiting at runtime and stepping through the debugger.

Hi Erik,

I totally disagree. Business logic has no place in an Aggregate! Aggregates are for retrieving data, what you do with that data should be in programming logic.

I don't understand how you want to promote "reuse" and "encapsulation" by putting business logic in an aggregate. Reuse and encapsulation is achieved by using Actions, and you can map within your action, and have your output contain the mapped values.

I would like to combine group of attributes to one structure.

Instead of separate custom attributes and the entities.

@Killian: so, a sum of amounts in aggregate is wrong?, that would be businesslogic...

Before Aggregates, I didn't see the need.

Now that I can do basically:


I don't want to make a structure Called "CustomersByName" with "Count" and "Name" in it just to pass this around, then reference that structure. I have seen too many projects severely poisoned with rediculous amounts of single-purpose Structures.

I also don't want a generic "ValueCount" Structure sitting in some generic common "Data Structures" espace with "Count" and "Value" to be used every time I need this.

Being able to use an anonymous Structure... like we do for the parameters, variables, etc. on an as-needed basis, is just fine.