We planned to use Materialized IH Summary datasets in our application. As per the requirement, we need to read the complete IH records (Time Period set to 'All time') with proper filter conditions and aggregations, so that the dataset will return a smaller number of IH records. There will be around 50 datasets in the application. In one strategy, we import around 20 datasets to check different contention rules.
In the Production environment, all outbound communications will be done as part of Batch execution and all inbound communications will be done with real-time API calls. Also, there will some real-time API calls to capture the responses from customers. Hence, while Batch is running, we will be hitting with real-time API calls. As we are planned to use Materialized IH Summary datasets, they will be aggregated when there is a new IH inserted each time.
I have some questions about performance in the Production environment:
While the batch is running and in parallel aggregating of dataset will also happen. How will this impact the Batch run performance?
What sort of a performance impact would a growing IH cause while using an "Import Interaction history summary" shape in strategies (As I mentioned above, we use around 20 datasets in a strategy)
(1) It will affect the performance of batch to some extent. The cost though should be lower than reading from IH directly to aggregate as was previously the case.
(2) The goal of IH Summaries is to try and minimize the cost of a growing IH. To maximize performance though, see if you can minimize the number of distinct datasets. It is far better to have one dataset covering two use cases but may require further aggregation in the strategy vs. having two distinct datasets.
e.g. if you have one dataset with keys Issue, Group and Name for 30 days and a second dataset which only needs aggregates on Issue for 30 days, it is better to create one dataset for both use cases on Issue, Group and Name. In the strategy take the aggregates for Issue, Group, Name and group by and aggregate on Issue for the second use case.
Note that we have made it easier in 8.6+ to reduce the number of datasets. Each aggregate in each dataset can now have its own time range...rather than only allowing one time range for all aggregates per dataset.
Let me know if this answer helps.