Greetings,

We are trying to use Report Library as an alternative to E-mail for distribution of sensitive reports. It seems that for users to be able to view reports in the Library, the report must execute in a Domain that the user is part of.

This creates problems for us, we do not want analytical users in that Doamin poking around at the sensitive fexes and breaking them.

So does anyone know how to have the Fex reside in a different domain (protected) and distributed to Library users that aren't part of that domain? Or how to protect the fex?

Thanks for any ideas (I couldn't find anything on FOCALPOINT search).

-- Dan at UNO --

This message has been edited. Last edited by: Rigel7,

Ok, a hack is to move the fex out of MR domains and house in an application directory. When you can schedule it as a EDA RPC through Reportcaster, you have to specify the Library category and the output will show up in users within the Access control list under that specified category instead of the domain where the fex resides.

The security model in play is a bit kludgy. It sure would be nice if I could author the fex in a MR standard report and specify the Library category to use for the users, instead of requiring them to be part of the MR domain.

I hope the new security model in 7.7 or 8.0 overhauls this (but I'm a little nervous of the scope of new security architecture)....

Dan at UNO

Finally, I can help someone!

We had the same problem here. Here's how I did it: (this is a memo I sent to my team)

When setting up reports in the ReportCaster Library, I found that a report must reside in a domain that is available to the user who is trying to access it from the library page of his dashboard. For example, the Clerk of Court has access to the Clerk domain, but not the Default Domain (where we do our development). So, when I set up the schedule to automatically run a report, and then set up the library access list (which defines who can see the report), I expected any user from the Clerk group to see the report in the report library. It didn’t work. Even if you set up the access list and tell it who can see the report, apparently the domain security is still effective. After a lot of research and testing, I found that since the FEX code actually resided in the Default Domain folder, the MR security was keeping it from being visible to the Clerk users. I didn’t want us to have to keep reports in several different folders, so by using the Focal Point forum online, I found a solution.

We have to put a “shell” FEX in the CLERK domain folder, which then –INCLUDEs the report FEX that lives in the Default Domain folder. This fools MR into thinking the report is part of the CLERK domain. So the steps would be:

Create FEX procedure in the Default Domain/Standard Reports/ER Reports folder just like normal.

Create a FEX procedure in the agency domain. This procedure will have only 1 line of code, like

-INCLUDE untitled/app/releasereport_for_clerk_282.fex

Then, when setting up the ReportCaster schedule, you point to the shell FEX which resides in the agency’s domain. I tried this today and it works. We only need to keep 1 copy of a FEX report, which will make maintenance easier.

Well explained Mike!

Excellent tip, Mike.

Would it be possible to extend your idea in order to have a generic FEX wrapper that could be used to run "any" report in "any" domain instead of having one shell FEX for each report that needs to be deployed?

I don't currently have a testing environment to do this but some of you out there with MRE and Report Caster might be able to play a bit with it.

Let's say you create a "runany.fex" procedure in the Default Domain which uses 2 parameters: source domain and fex name of the procedure to run. Something like this (example without any special validations to keep it simple):

-DEFAULTS &RUN_DOMAIN = 'NO_VAL';
-DEFAULTS &RUN_FEX    = 'NO_VAL';
-*
-IF &RUN_DOMAIN NE 'NO_VAL' AND &RUN_FEX NE 'NO_VAL' THEN GOTO :RUN_FEX;
-TYPE Sorry! No MRE domain and/or procedure was provided.
-EXIT
-*
-:RUN_FEX
-SET &RUN_STMT = '-INCLUDE &RUN_DOMAIN.EVAL/app/&RUN_FEX.EVAL';
&RUN_STMT.EVAL

With that in place, it should be a matter of creating a Report Caster task setting appropriate parameters for the report to run. Using Mike's example, the RC task would execute "runany.fex" setting at a minimum the following values:

RUN_DOMAIN  -> untitled
RUN_FEX     -> releasereport_for_clerk_282.fex

As I said, I don't have a way to test this that right now so please bear with me on any syntax errors you might find. This is just intended to illustrate the idea.

Regards,
- Neftali.