@ARMCBOYNTON 

This is a great topic, and we are just getting deeper into this issue ourselves.

I recently asked some questions about adding custom enumerations to a report, and along those lines we figured out how we could do a lot of customizing in the RDF in order to generate flexible _REP Views and _RPI Packages. But that also means the RDF file departs from the .report file in such a way that if you were to regenerate the RDF from the .report, changes would be lost.

I have done some more playing around with the .report file to see how dynamic you can make various Properties (e.g. for parameters). Other than calling methods, there does not appear to be much you can do to make properties dynamic. For example, if I wanted a date parameter to default to today's date, putting SYSDATE in the "Default" property for the parameter (in IFS Developer Studio) doesn't work. When I bring up the report from "Order Report", the literal "SYSDATE" appears in the data parameter. I also tried global variables like #NOW#, and it just put “#NOW#” in the field by default.

In other words, while you can call a method in various properties, I do not know how to make a dynamic expression or use other (native) Oracle functions/procedures. That means the .report file is good for defining the structure of the data, but beyond that you need to directly edit the RDF (and break from what the .report file auto-generates).

We are just getting started with this, though, so if anyone can point to better documentation on these sorts of operations, that would be great. Right now our main focus is to understand how far we can get with the .report, then where we need to start modifying the RDF for more advanced, dynamic customizations. At the end of the day it all becomes _REP views and _RPI packages, so it is fairly easy to check and see if things look right.

So, yes, we do use IFS Developer Studio, as it is good for generating the basics and setting up the right linkages into the IFS operational reporting framework with component names, LU names, data fields, parameters, etc. And the editor is decent for modifying and deploying the RDF. From there, I would use SQL Developer to debug if I needed to step through a method in the deployed _RPI package. Once we settle on a final .report and RDF, we will probably go ahead and put both under source control so we can see what we started with (the .report file) and what we ended up with (the RDF).

Like I said, a good topic to discuss -- hope folks will correct me where I've said anything wrong and add their own experience/insights to the thread!

Thanks,
Joe Kaufman