As of December 1, 2020, Focal Point is retired and repurposed as a reference repository. We value the wealth of knowledge that's been shared here over the years. You'll continue to have access to this treasure trove of knowledge, for search purposes only. Moving forward, myibi is our community platform to learn, share, and collaborate. We have the same Focal Point forum categories in myibi, so you can continue to have all new conversations there. If you need access to myibi, contact us at email@example.com and provide your corporate email address, company, and name.
If you are looking to rationalise the number of environments within which you hold your fexes, then why not go the whole hog and have all your fexes in your apps folders and call them via tailored HTML launch pages? Then the drilldowns will always expect the drilldown fex to be located in your apps folders (via the path).
You are not going to escape from the need to have the originating prog file (fex or HTML) held within the Domain folder, purely because there has to be some sort of reference that can be displayed within the "domain tree". By taking the route of having unique launch pages within the MRE domains, it doesn't matter where in your apps folders the fexes are, you just have to ensure that your HTML points there instead of the MRE folders -
<INPUT type=hidden name="IBIF_ex" value="fexfilename.fex">
<INPUT type=hidden name="IBIAPP_app" value="baseapp" id="IBIAPP_app">
<!-- the following line turns off autoprompting -->
<INPUT type=hidden name="IBIF_wfdescribe" value="OFF" id="IBIF_wfdescribe">
<!-- The following lines are used to point at MRE fexes -->
<INPUT type=hidden name="IBIMR_action" value="MR_RUN_FEX">
<INPUT type=hidden name="IBIMR_sub_action" value="MR_STD_REPORT">
<INPUT type=hidden name="IBIMR_domain" value="defaultx/defaultx.htm">
<INPUT type=hidden name="IBIMR_folder" value="#defaultfoldr">
<INPUT type=hidden name="IBIMR_fex" value="app/fexfilename.fex">
If you utilise amper autopromting, then I have a pair of HTML files that give a similar layout using framesets if you are interested?
In FOCUS since 1986
WebFOCUS Server 8.2.01M, thru 8.2.07 on Windows Svr 2008 R2
WebFOCUS App Studio 8.2.06 standalone on Windows 10
Posts: 5694 | Location: United Kingdom | Registered: April 08, 2004
I think I have seen a consultant that has used your technique to 'spoof' amper autoprompt and it looks very nice
Adapting your solution to amperautoprompt, it seems that I should be able to have a 'stub' focexec that contains the amper variables to be prompted for in MRE and then I need to switch context by calling a URL that points to the application.
-DEFAULTS &TITLE = 'R1152 Navy Partnering'
-*SET &ECHO = ALL;
-SET &DUMMY = &RPT_TYPE.(<Naval Summary with Drilldown,1>,<Hierarchy with Drilldown,2>).Report Type. ;
-*-SET &DUMMY = &FINPERIOD_TYPE.(GL Postings,Date Worked).Chosen Period Applies to. ;
-SET &DUMMY = &FINYEAR.(2008,2007,2006,2005).Enter Financial Year. ;
-SET &DUMMY = &FINPERIOD.(01,02,03,04,05,06,07,08,09,10,11,12).Enter Financial Period. ;
-SET &DUMMY = &GL_TYPE.(Single,Cumulative).For GL only Single Financial Period or Cumulative. ;
-SET &DUMMY = &WFFMT.(<HTML,HTML>,<Excel,EXL2K>,<PDF,PDF>).Select display output. ;
CALL URL=http://chaos/ibi_apps/WFServlet? (IBIF_webapp=/ibi_apps IBIC_server=EDASERVE IBIWF_msgviewer='ON' IBIAPP_app='reports' IBIF_ex='R1152D2' TOD='&TOD' WFFMT='&WFFMT' YEAR='&FINYEAR' PERIOD &OPERATOR2 '&FINPERIOD' REPTYPE='NAVY' CATEGORY=BKG_NAVY_CATEG ORG_CODE=BKG_NAVY_ORG_CODE PRODUCTIVITY=NEW_ACTIVITY_PROD_FULL SUB_PROJECT_ID='ADMIN' CLASS=BKG_NAVY_ACTIVITY_CLASS) , $
Unfortunately I can call a URL within a drilldown but there does not seem to be the syntax to call a URL unconditionally from a .fex.
Unless of course someone out there knows...
Server: WF 7.6.2 ( BID/Rcaster) Platform: W2003Server/IIS6/Tomcat/SQL Server repository Adapters: SQL Server 2000/Oracle 9.2 Desktop: Dev Studio 765/XP/Office 2003 Applications: IFS/Jobscope/Maximo
Posts: 888 | Location: Airstrip One | Registered: October 06, 2006
In mid 2005 I wrote a WebFOCUS Newsletter Article 'Drilling Down from a Managed Reporting Procedure to a WebFOCUS Server Procedure' that provides information of how to drill-down to a WF Server procedure from a MR report. The information is integrated into core documentation: Technical Memo 4580: Drilling Down From a Managed Reporting Procedure to a Procedure Located on the WebFOCUS Reporting Server 5.3 and in then into Rel 71 and 76 MR Developer Guide (see Rel 76 Chapter 2 topic 'Drilling Down from a Managed Reporting Procedure to a WebFOCUS Server Procedure'. Syntax explanation and code examples are included in the documentation.
The WF Environmental variable FOCEXURL controls where the WF Client will look for the drill down. When running reports from MR the default is to look within MR. The parameter on the URL to the WF Servlet that tells the WF client the report resides in MR is IBIMR_drill. So you need to SET FOCEXURL in your FEX to override the default setting within MR.
Here is the example code from our MR Developer Chapter 2 topic Drilling Down From a Managed Reporting Procedure to a Procedure on the WebFOCUS Reporting Server Example: The following illustrates how to drill down from a Managed Reporting procedure to a procedure located on the WebFOCUS Reporting Server. Main report (main.fex, located in the Standard Reports folder of a domain): -SET &FOCEXURL='/ibi_apps/WFServlet?' | '&'; -SET &FOCEXURL=&FOCEXURL | 'IBIAPP_app=ibinccen' | '&' SET FOCEXURL=&FOCEXURL TABLE FILE CENTHR PRINT START_DATE PAYSCALE POSITION BY FULLNAME ON TABLE SET PAGE-NUM OFF ON TABLE SET STYLE * GRID=OFF, $ TYPE=DATA, COLUMN=N4, FOCEXEC=drilldow (DESC=POSITION) , $ ENDSTYLE END Drill-down report (drilldow.fex, located on the WebFOCUS Reporting Server): TABLE FILE CENTHR SUM POSITION_DESC WHERE POSITION = '&DESC'; ON TABLE SET PAGE-NUM OFF ON TABLE SET STYLE * GRID=OFF, $ END
Note the values the above example in FOCEXURL are relative (don't include protocol, host and port) because the values within the user's browser context (connected to WF application environment) will be used. If you use ReportCaster to distribute reports to users via email and ftp the value specified for FOCEXURL must be absolute (include protocol, host and port) and the user must have intranet/internet access from their machine to the WF Client to run the drill down request.
the connection information So in your code you need to set teh FOCEXURL environmental variable On the URL submitted to the WF Client The parameter on the URL to the WF Servlet that specifies to look in MR for the drill down Here is a code example showing how to code FOCEXURL for both FEX is FOCEXURL. trick is to tell the WF Client that the drill down FEX does not reside in MR. This is done by setting FOCEXURL to not include the parameter IBIMR_drill. The IBIMR_drill parameter tells the WF Client what domain or user area (where a My Reports are stored) the
Here's something you might try. It's an idea I used on another thred but something I have incorporated into my environment to solve this problem.
As mentioned, one way to drill down to a server fex from an MRE fex was to manually create the drilldown URL. Then you get all sorts of issues with managing URL length, use of FOC_NONE, etc.
What seems to work very well for me is to create a simple "shell" fex inside of MRE that contains -MRNOEDIT -INCLUDE fexname
I supposed you could even use &fexname.EVAL and then if you passed the server proc name as a parm you would have a single fex that allows you to run any server based fex from within MRE. This could reside in a "common" domain which you would specify in your drill procedure (common/app/shell.fex).
All of the parameters would get populated as in normal processing (including any using FOC_NONE) and you only need to maintain your code in a single location.
In FOCUS since 1991 WF Server: 7.7.04 on Linux and Z/OS, ReportCaster, Self-Service, MRE, Java, Flex Data: DB2/UDB, Adabas, SQL Server Output: HTML,PDF,EXL2K/07, PS, AHTML, Flex WF Client: 77 on Linux w/Tomcat
Posts: 2298 | Location: Salt Lake City, Utah | Registered: February 02, 2007