Creating an XDS Policy with performance in mind
You are here
Force Data Area ID on SSRS report that doesn't use an AX Query
If you have SSRS reports that are "Classic" SSRS reports that don't use an AX Query, you can still force feed the report a data area Id dynamically to use when running. First, you need a report build in a specific manner. The report needs a hidden parameter that has no default ( in the report itself or specified on the report server ). Below are screen shots with the required configs.
In VS:
And on the AX Report server:
 
Next, You will need a menu item referring to the report you just created. Create this Menu Item like you would for any other SSRS report.
Next, You will need a class to call the menu item and modify the MenuFunction Parameters to default to the current Data Area Id. Below is an example.
class ATOM_DynamicSSRSDataArea { } public static void main(args _args) { menuFunction menuFunction; str menuItemName; Args Args; ; menuItemName = _args.parm(); menuFunction = new MenuFunction(menuItemName, MenuItemType::Output); //Force running from client; if run from server, could crash AOS menuFunction.runOn(1); args = new Args(menuFunction); //The Parameter "DataArea" in the report is being passed in here in the URL string and the report will use that for the data area args.parm("DataArea=" + curExt()); menuFunction.run(args); }
 
 
Next, create a menu item referring to the class above but for the parameter on the Menu Item, reference the Menu Item for the report and have the value for the parameter field be the proper name for the Menu Item. Doing this will pass the real Menu Item you want to be executed to the class by name, the class will add in the data area ID dynamically then display the report.
 
It should be noted that this may not be a very good solution, but it is a functional one. If you have found a better solution, please let me know. Also, there are a few gotcha's. First, every report needs a DataArea parameter for this to work. Next, in the state specified above, the report can't be run directly from the report server since no DataArea is specified on the report; it has to be passed in via a URL string. Also, on the report, if you specified defaults for Data Area IDs, they have to match *exactly* what is passed for the report to not complain. The same goes for parameter names.