Question
Using Strategies as a computational feature. Does it violate best practises?
Hi, Here is a summary of the use case. We have about 500 or less rows of data(coming from a data type). There are a lot of computations such as group them on the basis of a common attribute(say this results into 10 groups), get group level sum, overall percentage contribution of a specific group considering all groups etc. These are requirements that can be done by looping around the pagelist, creating group level pagelists etc. In short these computations can be achieved by looping around using traditional pega activities or Data transforms. However, I see that these can be achieved in a simpler way by doing all this grouping and summarization within a strategy. We simply feed the 500 rows into a Data flow via a RD and do all the necessary grouping, summation within the strategy an write the result back to a clipboard pagelist.Or in other words, pagelist level summation, totals, groupings etc seem easier and intuitive to draw out in a strategy. The question I want to ask folks out there is that is this a good use case of using a strategy? Purists have an opinion that here we are populating the clipboard first and doing computation in the strategy. The whole logic is neither in an activity nor in a strategy. While I am inclined towards thinking, this is not a classical usage of a strategy, however a strategy canvas is a much easier place to summarize,compare and do manipulations to pagelists, which would otherwise be cumbersome in classical pega.
Hi, Here is a summary of the use case. We have about 500 or less rows of data(coming from a data type). There are a lot of computations such as group them on the basis of a common attribute(say this results into 10 groups), get group level sum, overall percentage contribution of a specific group considering all groups etc. These are requirements that can be done by looping around the pagelist, creating group level pagelists etc. In short these computations can be achieved by looping around using traditional pega activities or Data transforms. However, I see that these can be achieved in a simpler way by doing all this grouping and summarization within a strategy. We simply feed the 500 rows into a Data flow via a RD and do all the necessary grouping, summation within the strategy an write the result back to a clipboard pagelist.Or in other words, pagelist level summation, totals, groupings etc seem easier and intuitive to draw out in a strategy. The question I want to ask folks out there is that is this a good use case of using a strategy? Purists have an opinion that here we are populating the clipboard first and doing computation in the strategy. The whole logic is neither in an activity nor in a strategy. While I am inclined towards thinking, this is not a classical usage of a strategy, however a strategy canvas is a much easier place to summarize,compare and do manipulations to pagelists, which would otherwise be cumbersome in classical pega. Just like you have flows DTs etc, strategies are part of core Pega platform(from 7.2) and hence if a certain part of the computaions are a better fit to a strategy than an activity, why cant we call a data flow from a process and do that in a strategy? It is anyway more visual and easy to understand compared to activities and DTs looping around a lot and creating temporaray pagelists representing groups etc. So What do you guys think?Does this usage of strategies violate any best practices?
***Edited by Moderator Marissa to update platform capability tags****