ReportWORQ has several options for bursting reports to multiple users.
If the list of reports/users is short and doesn’t change often it’s usually easier to use the Enable for Bursting option with one or more parameters. With this approach you provide a finite list of entries (or Burst Sets) for ReportWORQ to generate and manually choose a contact from the ReportWORQ address book. While this option is easy to understand and use, it doesn’t provide any dynamic or self-maintaining features. Meaning that if the list or the recipients change often, then we have to maintain that work in ReportWORQ.
To help make this process dynamic, ReportWORQ has an option in the Parameter Editor sidebar to Create one report per item. When selected ReportWORQ will generate a list of reports for each supplied item in the list, and by using a Subset or MDX Query parameter this list may be dynamically loaded from the planning system. The challenge now becomes, who do we send the report to and how to we tell ReportWORQ? To solve this problem you’ll lean on your Excel skills to load the email address in the generated report using a formula. For Planning Analytics customers this may be a DBRA formula to load the email address from an element attribute associated with the dimension element that the report is being generated. For non-Planning Analytics scenarios this could be as simple as a VLOOKUP on a list that maintained on a hidden worksheet.
I’m excited to share that we’ve purchased Walnut, a new demonstration tool to make it easier for us to walk through these examples. Please have a look through the Walnut example below to see this feature in action.
Hi Andy,
My team is currently on 4.4.0.156. I have a 30 page package that is produced for 150 agents each month, with about 5% changing… In 4.3, I had agent001 - agent150 as recipients to produce all of the packages, and i would update the list in the control cubes from a dynamic subset. Now that we are on json files, is the bursting available in 4.4, so i don’t have to go in and manually check for changes? I didn’t see the fields in the demo but it could be in a different spot.
Thanks,
Andy
These same features existing in version 4, so you should be able to use the same dynamic approach. The simplest example of this is a reporting packet that is running for a single parameter, let’s say AgentCode in your case. In the Report Parameter screens AgentCode would be mapped to a cell location on each report worksheet that required it. Then in the Job Parameters Screen AgentCode would sourced from the dynamic subset. At the bottom of that parameter screen you would choose the option to “Cycle on job” or “One report per item” (the title of that option changed at some point in 4.4). Now, when you run the job a report output would be created for each AgentCode in the subset, changes to the subset would automatically impact the job next time that it is executed.
When taking this approach it usually makes sense to include the AgentCode parameter in the filename to keep the files unique.
Distribution becomes the next issue. With the old technique you had a recipient item where you could store the email address. But now we’re running the list of jobs dynamically, so where can we calculate what email address should receive a report for a given AgentCode. The easiest solution in IBM Planning Analytics is to make an element attribute on the AgentCodes dimension and then place a DBRA in the report to load the email address from the element attribute into a cell in the output report. The value in this cell can then be piped to the TO field (or any other field) using the Job Variables tool.
The configuration of your job may get a little more complicated if each agent report has additional parameters or lists required for producing reports. If that’s the case then we also have a technique called MDX Repeater that could help.
Give this a try and if you would like to spend a little bit of time working through it together let me know.