Focal Point Banner


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.

Join the TIBCO Community
TIBCO Community is a collaborative space for users to share knowledge and support one another in making the best use of TIBCO products and services. There are several TIBCO WebFOCUS resources in the community.

  • From the Home page, select Predict: WebFOCUS to view articles, questions, and trending articles.
  • Select Products from the top navigation bar, scroll, and then select the TIBCO WebFOCUS product page to view product overview, articles, and discussions.
  • Request access to the private WebFOCUS User Group (login required) to network with fellow members.

Former myibi community members should have received an email on 8/3/22 to activate their user accounts to join the community. Check your Spam folder for the email. Please get in touch with us at community@tibco.com for further assistance. Reference the community FAQ to learn more about the community.


Focal Point    Focal Point Forums  Hop To Forum Categories  WebFOCUS/FOCUS Forum on Focal Point     [SHARED][CLOSED] DrillMenuItem URL length management.

Read-Only Read-Only Topic
Go
Search
Notify
Tools
[SHARED][CLOSED] DrillMenuItem URL length management.
 Login/Join
 
WF8Developer
Member
posted
We use DrillMenuItem to many levels and have become aware of the limitations of the URL in a drill.

We build our drill logic dynamically (in part).

FOCEXEC=DX (
&LNK_LOC
<15 MORE ITEMS>
)$
WHERE:
&LNK_LOC = USER_SEL_LOC='&USER_SEL_LOC' \
&USER_SEL_LOC = 13 OR 9 OR 14

***The drills work great***

However our URL character limit is reached prematurely. Upon inspection of the URL we see (again in part):

&USER_SEL_LOC=12%20%20
or
&USER_SEL_LOC=12&%09=%09=&USER_SEL_XXX

I've tightend up the &LNK_LOC and &USER_SEL_LOC by removing spaces (%20 hex), = signs, & signs and tabs (%09 hex).

The translation of a space to %20 in a properly formed statement is a 1:3 loss of character. The multiple spurious %20 and %09 and the occasional \\= is stealing too many characters.

Please, I welcome advice, suggestions and techiques from those who may have dealt with this situation already.

Thanks

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


Production: WebFOCUS 7.703 & 8.104,
All output formats.
Win7-64,MS Office 2013.
Sandbox 8009
 
Posts: 27 | Registered: April 11, 2012Report This Post
dhagen
Virtuoso
posted Hide Post
If you search on this there are a couple of examples where an JS file is used to consolidate the values at run time to ensure that the drill menu items are small enough so that the menu appears, and the report submission is done using a POST. The examples I posted are quite old, so I suspect that you will have to make some changes for it to work. The POST removes any concern about query sting size.

here


"There is no limit to what you can achieve ... if you don’t care who gets the credit." Roger Abbott
 
Posts: 1102 | Location: Toronto, Ontario | Registered: May 26, 2004Report This Post
dhagen
Virtuoso
posted Hide Post
One last thing. A couple of weeks ago I ran into the same problem with another customer, and I am a little tired of using JS to solve all of my problems. So, I made the following assumptions:

- In all of my multi-drills, there are some constant variables that apply to every drill. Typically these are associated with a HTML launch page. All drill downs are associated with that. I decided that it was foolish to keep added the constant variables to every drill down (not to mention it was a lot of work).

So, on the first report from the launch page I added code like this:

APP FILEDEF VARS DISK foccache/vars.fex
-RUN
-WRITE VARS -SET &|VAR1='&VAR1';
-WRITE VARS -SET &|VAR2='&VAR2';
...
-WRITE VARS -SET &|VARx='&VARx';

Now, in the drill down reports I then included the vars.fex and there was no need to keep repeating the same variable settings in the drill down requests. If the reports are MRE based, then you include using:
-MRNOEDIT -INCLUDE VARS

This method proved to be very easy and useful, and saved a lot of time on the down stream drill reports.


"There is no limit to what you can achieve ... if you don’t care who gets the credit." Roger Abbott
 
Posts: 1102 | Location: Toronto, Ontario | Registered: May 26, 2004Report This Post
Wep5622
Virtuoso
posted Hide Post
Even worse, passing those variable names and values on between the server and the client all the time is absolutely pointless if the user can is not supposed to not change them. It's just wasted bandwidth.

The usual solution for such data is to put them in the session on the server. What's the equivalent for that in WebFOCUS? Global variables?


WebFOCUS 8.1.03, Windows 7-64/2008-64, IBM DB2/400, Oracle 11g & RDB, MS SQL-Server 2005, SAP, PostgreSQL 11, Output: HTML, PDF, Excel 2010
: Member of User Group Benelux :
 
Posts: 1669 | Location: Enschede, Netherlands | Registered: August 12, 2010Report This Post
ReddyP
Gold member
posted Hide Post
Another way to avoid passing the same variables would be to do do a hold file by applying the filters from the html file and do a foccache on the hold file. Your drillmenu items would go against the hold file instead of the actual table that need to process all the parameters again.
Example:
-IF &RPT_DD EQ 'Y' THEN GO TO DRILLTBL;
TABLE FILE CAR
PRINT COUNTRY
WHERE COUNTRY EQ '&COUNTRY' --params from html file
ON TABLE HOLD AS HFOCCACHE/HRPTOUT
END
-RUN

-DRILLTBL
TABLE FILE HFOCCACHE/HRPTOUT
PRINT *
ON TABLE SET STYLE *
--Drillmenu items style commands
ENDSTYLE
END


7.7.01,windows2008 R2
 
Posts: 65 | Registered: July 28, 2011Report This Post
  Powered by Social Strata  

Read-Only Read-Only Topic

Focal Point    Focal Point Forums  Hop To Forum Categories  WebFOCUS/FOCUS Forum on Focal Point     [SHARED][CLOSED] DrillMenuItem URL length management.

Copyright © 1996-2020 Information Builders