Hi,

I've created a few Reporting Objects that MRE users will use to create new reports in Report Assist or Power Painter. These Reporting Objects contain Where Clauses that limit data access so any report a user creates will be filtered accordingly.

I want to build some reports in DevStudio and make those available in the Standard Reports folder of the domain. Is there a way I can use the Reporting Object in DevStudio to build reports? When I create a report the only option I have for a data source selection is my list of Master Files. I don't want the report to point to a Master File because then my data filtering won't be in effect.

I can manually add the where clauses to each report but that means a lot of duplicate effort. Plus, if I ever go back and change the where clause in the Reporting Object I'd have to change it in every report too.

Any ideas?

Thanks,

Dan

Dan, i have an idea for you (i can't test it b/c my java just broke),
but put a fex in your OTHER FILES area that contains *only* your IF statements
and use a -INCLUDE in your reporting object, in place of the explicit IF statements.
RUN the RO to see if you get any errors.
If not, then use those same little fexes with -INCLUDE in your standard reports.
That way you only have to modify 1 little fex if the situation changes.

This is actually the same method that the reporting objects functionality uses. It creates JOINs, DEFINEs, WHEREs, etc. as what I refer to as "mini code" that is -INCLUDEd in every fex that uses that reporting object.
There isn't really a way to reference reporting objects in "Standard Reports" but you can create them and share them with every user in the domain (they appear in a Shared Reports tab.)
I use something similar to Susannah's suggestion extensively. If the filtering is your main concern (which is how it appears) then create a FEX (either in the MRE domain or somewhere in you server APPPATH) that only contains the WHERE statements. Then you can -INCLUDE it wherever you need it, and if it ever changess, you only change it once.

Susannah & Darin,

This sounds like a great idea. Can you give me an example of how this 'filter fex file' would look? I'm used to doing things through the GUI.

Thanks!

Dan

your filter fex has just the filter code
You put it in the Other Files section and you give it a meaningful name like SOMEFILTER.FEX

-* this is a filter fex
IF CAR IS 'HUMMER'
IF COUNTRY IS 'BURKINA FASO'
WHERE  whatever

Then in your WHERE section of your Reporting Object, you put

-INCLUDE SOMEFILTER

Then in your Standard Reports that you write,
instead of entering the specific statements:

-* this is a filter fex
IF CAR IS 'HUMMER'
IF COUNTRY IS 'BURKINA FASO'
WHERE  whatever

you put in

-INCLUDE SOMEFILTER 

OK - I created a filter fex in the Other folder called carfilter.fex that looks like this...
WHERE COUNTRY EQ 'JAPAN';

Then I created a procedure in the Standard Reports folder and used the INCLUDE command from the Procedure Editor. The problem with this is that it puts the INCLUDE statement at the very beginning of the procedure so it looks like this...
-INCLUDE app/carfilter.fex
TABLE FILE CAR
PRINT
COUNTRY
CAR
MODEL
HEADING
""
FOOTING
""
ON TABLE SET PAGE-NUM OFF
ON TABLE NOTOTAL
ON TABLE PCHOLD FORMAT HTML
ON TABLE SET HTMLCSS ON
ON TABLE SET STYLE *
UNITS=IN,
SQUEEZE=ON,
ORIENTATION=PORTRAIT,
When the code is in this order the WHERE statement is ignored and you get all rows.

To fix it I had to edit the procedure in the Text Editor and move the INCLUDE statement so the procedure looks like this...
TABLE FILE CAR
PRINT
COUNTRY
CAR
MODEL
HEADING
""
FOOTING
""
-INCLUDE app/carfilter.fex
ON TABLE SET PAGE-NUM OFF
ON TABLE NOTOTAL
ON TABLE PCHOLD FORMAT HTML
ON TABLE SET HTMLCSS ON
ON TABLE SET STYLE *
UNITS=IN,
SQUEEZE=ON,
ORIENTATION=PORTRAIT,

Is this the method you are talking about?

Another method is to use the FILTER command like this on the CAR file:

FILTER FILE CAR
NAME=C_TEST
WHERE COUNTRY EQ 'ENGLAND;
END
-*
SET FILTER=* IN CAR ON
or
SET FILTER=C_TEST IN CAR ON

which can be added prior to any define/table code, but is added in automatically as a screening condition when accessing the CAR file.

That is exactly what we were sugggesting. Requires you to get into the code, but it's pretty simple. Alan's suggestion would also work much the same way without having to use any Dialogue Manager.

Alan,

Yes, the FILTER method worked better than the WHERE clause.

It seems like a lot of effort just to get these pre-defined filters to work in Standard Reports. I mean, it seems like I am manually doing everything the Reporting Object is supposed to do for me.

Perhaps this calls for a New Feature Request to allow Reporting Objects to be used in DevStudio to create Standard Reports.

Is it possible to enter the code for these pre-defined filters in a procedure that is accessed at the MRE User Group level? That way they would be included in any Reporting Object or Standard Report accessed whether we remembered to add them or not.

Thanks,

Dan

I am not great at MRE, but I assume that the filters can be added to the group profile. If I'm wrong, someone will tell me.

I have used filters in conjunction with EDASPROF and GETUSER and also WFC_cookie with good effect. Filters can contain &variables. With a bit of initial setup they can be v. effective.

The problem you are running into here is that you are trying to use certain functionality for something other than its intended use. That's not necessarily a bad thing in my book, as I am a know abuser of various pieces of WF functionality. However, you've got to realize that in that realm, you're on your own.

Reporting objects are created within Managed Reporting to allow users to DEVELOP their own reports based on a predefined template, and these reports are saved to their INDIVIDUAL MY REPORTS folders and can be shared with other MR users within their domains.

You are wanting to use reporting objects OUTSIDE of the individual users' development areas, making them available to ALL users, and then trying to incorporate security for RUNNING those reports. Reporting Objects are NOT made to do that for you.
It can be done, as you have already found, but yes, you have to do a lot of it manually. And NFR's is how WF got to be what it is today. Keep on truckin'.

Darin,

When I say I want to create reports for the STANDARD REPORTS folder I'm not saying I want ALL users to run them. I just want users who are members of the same DOMAIN/GROUP to be able to run them.

The scenario is that we create a separate DOMAIN/GROUP for each customer (group of users). Inside that DOMAIN we create REPORTING OBJECTS in which we define the data access (WHERE CLAUSES) that customer group has. From there we turn them loose with Power Painter or Report Assist and let them create all sorts of reports and share them with other members of the DOMAIN/GROUP.

In addition to the user-created reports we have a couple dozen reports that we have built using DevStudio that we want to give them access to. The ideal place to put them is the STANDARD REPORTS folder.

The problem, as already stated, is that these STANDARD REPORTS do not adhere to the same data restrictions that the REPORTING OBJECTs do.

It seems like Alan's description of defining the FILTERS in a separate procedure file and then including that in both the REPORTING OBJECTS and STANDARD REPORTS is the closest thing I can achieve. My other option is to try and put these FILTERS in a GROUP PROFILE. Before I can try that I need to get with our SE and make some changes to our security settings. Right now we are set to OPSYS which will not allow us to create GROUP PROFILES.

I'll update this thread once I get a chance to try that method.

Thanks,

Dan

Well, there are filters and there are filters.

I like the usage suggestion of the file level filters. Very valuable.


...but just as a point of clarification:
Reporting Objects have two methods of data selection. WHERE statements that are always applied and can't be changed by the end-user(which would be replaced by the above-mentioned file level filter) , and Filters, that are available for the end-user to select 'optionally' and are created as part of the Reporting Object.

quote:

There isn't really a way to reference reporting objects in "Standard Reports"

There is a property for a Reporting Object that says 'Display as Standard Report'. As long as the Reporting Object has a TABLE request or a GRAPH request in it and can be run with no changes you can designate it as a Standard Report. The user running the report can apply the optional filters at run time.

This option can be valuable at times as well.

Hi all,

We finally switched our security mode from OPSYS to LDAP yesterday and now we are able to use Group Profiles in our Windows environment.

It is important to note that the Group Profile name corresponds to a user group in our Active Directory rather than to a group in MRE.

It is also important to note that the name of the group can not include spaces.

There is no obvious place to add a Group Profile so we just added them in the same place that we added user profiles using the Web Console.

After some testing the Group Profiles are performing the same as the user profiles did. The good news is that we only need to maintain a fraction of the profiles we would have if we were still using user profiles.

If the rumors I hear concerning the next major release are true then there will be much better synchronization between Active Directory security and MRE security. I'm looking forward to that!

Dan