I'm invoking Maintain from a dashboard page via a javascript MNTCON call and all is rosy save for one little detail -- the &IBIMR_user and &IBIMR_domain variables are not available in edasprof. edasprof runs but the amper variables (I've set them to pass to the Reporting Server) throw an error -- (FOC295) A VALUE IS MISSING FOR: &IBIMR_user.

My WF reports run like a dream, using those variables in the profile (and in a _site_profile that I use to set connections) but for MNTCON calls they seem to disappear.

Any insight on how to correct this problem?

J.

If you indeed use a javascript to call the maintain then you will have to provide all variables to pass to the maintain by means of the javascript. After all, you're building a URL (whether or not it uses a form) with your script and all that the called process needs to know has to be in that url or form.

I have been creating htm files that take passed values and assign them to amper variables to be passed into my Maintain procedure. This technique adds random variables to assure there is no caching.

Mark



<script language="JavaScript">
function launchMaintainProc()
{
var loc = document.location.search;
loc = loc.replace("?",'');
var nameandvalue = loc.split("=");
var XXX = nameandvalue[1];
//document.getElementById('PROGMMR_NAME_Edit').value = nameandvalue[1];
var getRandomNum = Math.random();
var launchURL = "/ibi_apps/WFServlet?IBIS_connect=on&IBIAPP_APP=gartner";
launchURL = launchURL + "&IBIC_server=EDASERVE&IBIC_user=anyone&IBIC_pass=anyone";
launchURL = launchURL + "&IBIF_cmd=MNTCON+APPPATH+gartner;MNTCON+EX+demo;";
launchURL = launchURL + "&MYPROSPECTS_ID_Edit=" + XXX;
launchURL = launchURL + "×tamp=" + getRandomNum;
var cmd = launchURL + "," + "_blank" + "," + "toolbar=no" + "," + "menubar=yes";
document.location.href=cmd;
}

This is for a security setup, so I need &IBIMR_user and &IBIMR_domain to be picked up off of the system internally.

I'm a bit confused -- the variables are available in the Maintain where I also use them, but my DB connection is to be assigned based upon user and domain, so the _site_profile or the edasprof profile needs to be able to see these variables.

The site profile and the profile are running -- I see them throw the error on the system log. It functions properly for reporting and it appears that site.wfs processes since the variables are available in the Maintain code, but they aren't available in the profile or the _site_profile routine prior to Maintain's invocation on the server.

J.

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

Mark, isn't it true that when you use IBIF_cmd, you don't get the variables set. ?

In the past I've used cookies to get variables, as these are availabe at the maintain level, and can be retrieved with IWC.cgiAppParms, assuming this still exists, as I haven't used Maintain for 5 years.

I can get them in the Maintain, but I don't need them in the Maintain. I need them in the edasprof or the _site_profile focexec.

J.

Sorry John, my misunderstanding.

I wonder if you turned on tracing, if you can see the variables being passed around.

Perhaps it may give you a direction to look into.

Passed variables are not pulled in until the reporting server profiles are passed. As a result I don't think that will work.

You can however include a FEX in the _site_profile which sets up a Reporting Server connection. The variables will be populated at that time.

quote:

You can however include a FEX in the _site_profile which sets up a Reporting Server connection. The variables will be populated at that time.

No they won't. That's exactly what I've described above and it's not working.

One more time with feeling and dramatic music:

-- I have a _site_profile focexec. In my _site_profile focexec I have code that looks at the &IBIMR_user and &IBIMR_domain and decides which connection strings to apply for the run.

-- This works perfectly for reporting. Dashboard screens that call for reports apply the connection correctly and all works as expected.

-- It fails for WF Maintain.

-- Specifically, when a call to MNTCON occurs, the _site_profile focexec executes as expected, but it throws an error -- (FOC295) A VALUE IS MISSING FOR: &IBIMR_user. This error appears in the system log. The Maintain screen pukes on startup. The variables should be there -- it works for reporting.

The url being call is running through WFServlet.

 http;//10.1.5.4:8080/ibi_apps/WFServlet?IBIF_cmd=MNTCON RUN madp_app_inf
&IBIS_passthru=on&IBIS_connect=on&IBIAPP_app=mdp&IBIC_server=MDP&App_Key=100&Appl_Key=00000100000&Action=ed_curr&RandomNum=0.01506543335626681
 

Any insight?

J.

Try adding the following to your site.wfs to get the MR userid:

httpsession=_USERID_VAL
<IF> IBIMR_action EQ "MR_SIGNON"
<CALL> CopyWFVarToSessionVar(IBIMR_user,httpsession)
<ELSE>
wfvar=IBIMR_user
<CALL> CopySessionVarToWFVar(httpsession,wfvar)
<ENDIF>
<SET> IBIMR_user (pass)

If that works, try the following for the domain:

httpsession=_domain_val
<IF> IBIMR_domain NE "" AND IBIMR_domain NE null 
<CALL> CopyWFVarToSessionVar(IBIMR_domain,httpsession)
<ELSE>
wfvar=IBIMR_domain
<CALL> CopySessionVarToWFVar(httpsession,wfvar)
<ENDIF>
<SET> IBIMR_domain (pass)

NOTE: The above by default will set a blank value for the variable if for some reason its not populated. This happens whenever you put a

"<SET> VARNAME (pass)".

I tried adding that material to my site.wfs and I see no change.

So I did some serious digging this evening and it appears that the error in the log appears regardless of whether it's a Maintain call or a WF call. Odd that the &IBIMR_user variable can't be seen there.

My _site_profile focexec CAN see the &IBIMR_user variable, and it clearly runs for the WF calls. My guess is that it does not run for the Maintain call. That may be how it's designed.

This is going to sound like an incredibly simple question, but I'd like to hear your answers -- if I'm passing the MR variables via site.wfs, SHOULD they be available in the edasprof? I've been doing this for years and it seems to me the answer has always been yes, but that's not what I'm seeing. Maybe I've just always assumed the profile could see it.

J.

John

_site_profile is NOT called when issuing an IBIF_cmd, only using IBIF_ex.

To get around this create a focexec:

-INCLUDE my_site_profile
MNTCON RUN mymaintain

in the url use

...WFServlet?IBIF_cmd=EX the_above_focexec&...

Also the _site_profile is NOT called when running an EXEC or call from the maintain. If you want to exec:

.
.
.
EXEC my_site_profile KEEP ...
.
.
.
EXEC a_table_request KEEP ...
.
.
.

That's big news right there. Thank you very much for explaining how the system works.

Can anyone speak to the &IBIMR variables not being defined in the edasprof? Is this to be expected?

J.

Unless they've changed the processing, no amper variables are pulled in from a request until after the Reporting Server has processed all its profiles (including edasprof.prf). As a results &IBIMR variables will not be available to the edasprof.prf.

The reason why including something in the _site_profile passed from the WebFOCUS Client is different is because that basically acts like a -INCLUDE in the front of the FEX. By the time the actual FEX is processed, the amper variables HAVE been pulled in, and are available for processing.

This is remarkably bad news. Exceptionally clear and concise and I thank you for providing such a detailed description, but still bad news.

I need to figure out a way to define connection strings for Maintain calls (about 100 different ones) based upon userid and domain. This could be interesting.

J.

John

If you use the process I mentioned above, then all connection strings can be set up in the _site_profile. This, IMHO, is a better place to have dynamic connection strings than EDASPROF, AND the variables you need will be there.

Use EDASPROF for everything fixed, _site_profile for everything dynamic.

I like it, but it means a lot of retrofitting to make it work.

J.