I’ve been searching the forums and I have not found a thread covering the following situation. Please guide me to the correct post if it exists. I have a result-set that requires me to derive a sub-total from a child table. The data source is my own app and is not calling out to a REST service. So for simplicity, let’s begin our conversation with an Order/Details relationship. I want to provide a Data Grid result of “Order #”, “Order Date”, “Order Total Costs”, where the total cost is a summation of the costs for each detail. I started off with a non-persisted entity holding the three values and I use a Microflow to loop through the details to calculate the “Order Total Costs”. I set the rows in the grid to a count of 20. The problem comes into play that I want to provide pagination and sorting on this grid. By choosing a Microflow, it appears I loose the capability of sorting and paging. So I tried List View with the app store’s “List View controls”. Thought maybe the Header sort and pagination would work. Then the error came back “This widget is only compatible with list view data source type, ‘Database’ and ‘XPath’.” (It would be nice if the IDE would let you know as you associate the controls to a list view using Microflows early on rather than it runtime, yet that is another conversation.) Perhaps I could figure out how to do the aggregations for XPath. It might be simple enough for my scenario here, but my real solution has a more complicated calculation going on in the Microflow beyond a sum. I look forward to suggestions and guidance. Peace, Keith Nicholson
Stop doing the calculation at presentation time, start doing the calculation (asynchronous if performance is an issue) every time the orderdetail changes. This will make your life easier. Now the OrderTotalCosts becomes just another attribute.
Editted: If you read only few times compared to the number of orderline updates than it is far less resource intensive to only calculate once the read-action is started. Still you can first recalculate the OrderTotalCost and store its value in the attribute before you show the report.
Tim v Steenbergen
Another approach: instead of sourcing the grid (or list view ) with a microflow, open the page with a microflow. In the opening microflow, do the calcs, refresh the records, etc. Then your page can use Xpath or receive a context object to display the totals.
This was more of a simple example for a view that will only be done weekly across a multiple set of tables. The user can accept delay for the query versus all the work to calculate, every time a new detail is added for an order, which can grow across a number of weeks, multiple times a day. Seems like that would create more locks on the transaction during writing.