I would like to be able to share a fex with a domain other than its domain of origin. The fex has published HTML. I'd rather share the fex than copy duplicate fex and HTML into the second domain.
Question is: How do you share fexs across different domains without duplicating the fex or the published HTML..?
a classic and very good question. I depends on your Mre version. in 524 it has become difficult, in all prior versions its easy.
If your fex (FEXA) is in your basic domain (DOMAINA) and you want to call it from DOMAINB, i do it 2 ways.
1) build a fex in domainb with the exact same fexname (for simplicty sake) that looks like this
...now, you can build a launch page for it in domainb and provide whatever custom parms you need, and call that fexB right in its own domain.
The trouble is, if fexA has any embeded -INCLUDE statements, IT NO LONGER WORKS! It has worked inevery version prior to 524. If you change the embeded -INCLUDEs in fexA into full paths, it will work from your guest domainB, but no longer work in your host domainA. [i've opened a case in CSS].
2) another way is to publish a launch page for FEXA right in DOMAINA, and then move it to DOMAINB. The launch page in domainA can be cusomized to provide parms values that are domain specific, and will call the fex from domainA. This works for me, in a very simple case, but isn't fully tested.
Thanks for the response susannah..... I may have left out important info in my original question.... I had tried your #2 option and it does work as long as the individual has access to both domains...... I'm trying to allow a user to run a report without giving the person access to the entire domain......
I tried your option #1 with no luck.... we are currently on 4.3.6 going to 5.2.? this summer. I wasn't sure what the MRNOEDIT command does, is it a 5.2 requirement.
hmm. puzzled. I just went to my 436 app, and ran this exact tiny fex from domainB.:
-SET &MYPARM = 'MYVALUE' ;
works like a charm, using a userid that only has access to domainB, not my default domain(the famous 'untitled').
-MRNOEDIT is not 52-specific. its just code that tells MRE to loosen up for a minute. Its how you access a remote host, for example. And your test0000.fex in the default domain can have embeded -INCLUDEs in them, as long as the include
names the file by its full unc.
You're so right about method2. it doesnt work when i test it further, as you said, signing on as a domain-spec. user. jeez! my hopes for getting 524 MRE to work at all just nosedived!
Sorry.... didn't mean to rain on your parade.
If it makes you feel any better I'm not having any luck either. As it turns out my focexecs don't have "INCLUDES" but they do have drill down and I really don't want to start hardcoding path information inside several focexecs.
I wonder if I could put the requested programs in a "Share Domain" that allows access and then inside the original domain do the include.....
hmm. i think that sounds backwards. I think the fexes should live in the main domain; Edit them once, and then execute from everywhere. so here's what i do; and it works;
In my host domain, i have fexA, drilling down to fexB, which drills down to fexC.
In my guest domain, i have fexA (fexes are identically named) but fexA is just 4 lines long.
...so now when that runs and the user dd's to run fexB, the execute a similar ffex setup, a shell version of fexB that lives in the guest domain, but calls real fexB from the host domain.
...and on and on.
So all the nomenclature is the same, just the fex content is different.
I also tried setting the Edapath specifically in the Guest domain, to include the host domain followed by all the apps directories. i can't remember now what happened, probably an explosion.
say, maybe i could handle my includes the same way..hmm, you've given me an idea. thanks!
There is also another option to share the focexec among different MRE domains (probably not applicable in any case, but in many cases useful).
1. Keep the FOCUS code (*.fex files) not in MRE domains, but within WebFOCUS Server applications.
2. Deploy the report in MRE domains as URL invoking "server-side" focexec (or any html launch page, as needed).
3. According to the requirements you can add another techniques like including HTML form within the focexec (-HTMLFORM), pass parameters from MRE to focexec (
Hope this (somehow) helps
interesting idea Grzegorz. i build in my MRE domain so it might be too difficult, but can you tell me about (2)? "URL invoking "server-side" focexec ".
I have tried invoking from mre the same way i would invoke from a self-serv, and it doesn't work at all (and i can see why).
Can you give us an example of the exact syntax? thanks.
Here's a thought that just might be crazy enough to work (even with 524)... 8^)
1. Put all your FEX's into a single domain, give everyone access to the domain, and uncheck "Show on User's List" for all the files.
2. Put your launch pages into separate domains, and control security accordingly.
This isn't exactly the most secure method out there. Security might actually break down completely if you're using the Business Intelligence Dashboard (don't have much experience with this, so I can't vouch for it). But it should get the job done pretty well if you're just using the MRE.
Come to think of it, there might be security problems with the Library as well, but you might be able to get around them with distribution lists & whatnot. I do remember being able to control who can see what reports even if they're in the same domain in the Library.
Just a thought...
Susannah, I am invoking focexec exactly the same way like a self-service. For instance:
It works well both from MRE console and from BI Dashboard , but it is not working in every configuration.
When the WF Server is SECURITY=OFF it should work with any (?) WF Client configuration.
My WF Client configuration for the SECURITY=ON option is as follows:
With the more sophisticated configuration I do not even want to think about the problems with choosing reporting server and passing credentials (IBIC_server, IBIC_user, IBIC_pass in the URL ???).
One can use WF_AUTOSIGNON setting, but only if the end-users accept this, and with multiple reporting servers the "MRE URL" technique may be absolutely unsuitable.
If "passing credentials, and choosing servers" is not the problem you encountered while invoking self-serv URLs from MRE, also let us know and post.
Thanks mhuber, that's a wild idea. Not at all clean as you say, but tricky. let me explore...
Grzegorz, thanks for your thoughtful response. i'm running with security wcprotected mode[so i can maintain maps to external server drives], but i don't think my initial problem is a security one. I just want nested -includes to work from any access point to one central fex location. And even as admin, with rights to everything, i can't make it work from guest domain to host domain.
|Powered by Social Strata|