Hi,

I'm using the autoprompt screen to let the user select several values.
We have almost for every report multiselect boxes. One of them is "Department" which contains sometimes more then 50 departments. (At this moment we are using WF 7.1.3 dev studio and MRE.) Now when we use the option "no selection" in the multiselect boxes or select just a few deparments we can drill down without any problem. However when we select all of the possible departments or a lot of departments then the drill down doesn't work anymore. In PDF for eg, when you hover over the department column you get the url for the drill down without 'http://'. In HTML the url seem to be complete but won't work.

I suspect that I'm reaching the max length of the url and therefore cannot drill down. Making my own html page that passes the department_id instead of the name would solve my problem but this is not an option here for different reasons. So I'm stuck with the autopromt screen. Is there a way to display the name of the department and pass the id? If this is not possible I need to find a way to prompt for the department name but pass the all the id of the selected departments to the drill down report.
Any ideas?

Dirk,

I'm not at all sure I fully understand your situation, so much (or all) of what I propose may be ridiculous. I will say there is definitely a limit to the length of the url string passed on a drill down. That limit is actually smaller if you're drilling from a compound PDF report.

You don't have to pass the value on which you are drilling. If you print department_id with the NOPRINT option, for example, you can pass that value in the drill. Just reference the field.

Ar you creating your program with the GUI. I don't do that much, so I don't know how it handles drills. If you are, just look at the underlying code for the field being passed in the drill statement (in stylesheet) and replace the name.

I understand the maximum URL length is about 2k for Internet Explorer.

Again I am not a GUI'ised person, so perhaps someone with GUI expertise can help here. What I do know is that if you submit a form, rather than a URL directly, then the maximum amount of data passed increases dramatically when using POST (not GET). (I thought I'd try a quick test and got 2,700 full zip codes into a database via a multi-select on a form.)

Trying to alter what is passed via the GUI on the URL might be a solution, but I suspect that a lot of that is black-boxed with the IB code.

Is it not possible to activate a POST form submission on a drill down instead of using the direct URL?

This message has been edited. Last edited by: Alan B,

What makes the difference is which method for the FORM is being used. A method of GET puts all the values on the URL. A method of POST does not put all the values on the URL. POST uses another method to pass the FORM values to the web server. POST permits a greater amount of data to be passed to the web server.

Now the issue is that I have never been able to get a drill-down to use a POST method. I'm not sure if this is possible.

The following text is copied from the MSDN Library web site for the FORM object.

"METHOD Attribute | method Property

--------------------------------------------------------------------------------

Sets or retrieves how to send the form data to the server.

Syntax

HTML

Scripting [ sMethod = ] FORM.method

Possible Values

sMethod String that specifies or receives one of the following values.get Append the arguments to the action URL and open it as if it were an anchor.
post Send the data through an HTTP post transaction.


The property is read/write. The property has no default value.

Expressions can be used in place of the preceding value(s), as of Microsoft® Internet Explorer 5. For more information, see About Dynamic Properties.

Remarks

When using the post method, there is no theoretical limit to the amount of data that can be sent to the HTTP server. The amount of data may be constrained by the physical limits of the client computer.

When using the get method to send data to an HTTP server, the amount of data that can be sent is limited by the maximum length of a URL. In this case the URL cannot be longer than 2048 bytes."

Thanks!

Mickey

FOCUS/WebFOCUS 1990 - 2011

While I think about this problem, I thought I'd mention that in the case of drilldowns, there is no HTML FORM, so the limitation is not GET/POST/FORM related.

The drilldowns are HTML ANCHOR tags, or <A HREF="">.

E.G. <A HREF="/cgi-bin/ibi_cgi/ibiweb.exe?IBIF_webapp=/ibi_apps&IBIC_server=EDASERVE&IBIF_ex=EQREP003&CLICKED_ON=&DD_FEXNAME=BRPR022">Net New Reservations Report</A>

Run the report as HTML, view source and take a look at the HREF's - are they complete?

This fex creates a column that's 4000 characters and is passed in a drilldown. It works on my humble 5.3.2 server.

DEFINE FILE CAR
DUMMY1/A50 = '123456789A123456789B123456789 123456789D123456789E';
DUMMY2/A4000 = 
DUMMY1 || DUMMY1 || DUMMY1 || DUMMY1 || DUMMY1 ||
DUMMY1 || DUMMY1 || DUMMY1 || DUMMY1 || DUMMY1 ||
DUMMY1 || DUMMY1 || DUMMY1 || DUMMY1 || DUMMY1 ||
DUMMY1 || DUMMY1 || DUMMY1 || DUMMY1 || DUMMY1 ||
DUMMY1 || DUMMY1 || DUMMY1 || DUMMY1 || DUMMY1 ||
DUMMY1 || DUMMY1 || DUMMY1 || DUMMY1 || DUMMY1 ||
DUMMY1 || DUMMY1 || DUMMY1 || DUMMY1 || DUMMY1 ||
DUMMY1 || DUMMY1 || DUMMY1 || DUMMY1 || DUMMY1 ||
DUMMY1 || DUMMY1 || DUMMY1 || DUMMY1 || DUMMY1 ||
DUMMY1 || DUMMY1 || DUMMY1 || DUMMY1 || DUMMY1 ||
DUMMY1 || DUMMY1 || DUMMY1 || DUMMY1 || DUMMY1 ||
DUMMY1 || DUMMY1 || DUMMY1 || DUMMY1 || DUMMY1 ||
DUMMY1 || DUMMY1 || DUMMY1 || DUMMY1 || DUMMY1 ||
DUMMY1 || DUMMY1 || DUMMY1 || DUMMY1 || DUMMY1 ||
DUMMY1 || DUMMY1 || DUMMY1 || DUMMY1 || DUMMY1 ||
DUMMY1 || DUMMY1 || DUMMY1 || DUMMY1 || DUMMY1
END

TABLE FILE CAR
SUM
SALES
DUMMY2 NOPRINT
BY COUNTRY

HEADING
"WEBFOCUS REPORT"
ON TABLE SET STYLE *
TYPE=DATA, COLUMN=COUNTRY, 
FOCEXEC=TEST1 ( \
COUNTRY=COUNTRY \
DUMMY2=DUMMY2 ), $
ENDSTYLE
END

Is your drilldown hyperlink being built differently?

If Dirk cannot get a URL to work when long, but does work when short, then I assume that there is an issue somewhere. Could be the url length, inbuilt javascript or whatever.

But with a URL or a GET, there is a microsoft declared limit of 2083 characters - see microsft knowledge base for full details. If you try to enter a longer URL in the address bar, IE will truncate it.

Other browsers have a different maximum lengths, Firefox for example can be over 64k. Servers also have a maximum length they will accept, depending on which server, e.g. IIS or Apache, is used. However general recommendation is not to even approach the maximum length.

Whilst a drill down on a FOCUS report is normally a URL, there is the option of calling a javascript function. I did wonder if there was another way to make life easier, as I said not being greatly knowledgeable on the GUI tools.

What I tend to do is run a report with a drill down of a javascript function, output the report to HTMTABLE, and then build the user screen within -HTMLFORM, including any other data entry or select items within a FORM which has a method of POST and appropriate action, WFServlet or whatever. Add my javascript, which is normally a simple submit of the form, but can also add/remove/change parameters on the form. And finally add the FOCUS report in the right place.

This method I know will handle large amounts of data, but it is not easy to do the first time.

Hi everybody,

First of all I'm not a GUI user myself . Infact this problem has nothing to do with the GUI at all.
I'm forced to use the WF autoprompt screen which generates a html screen by itself if WF finds unresolved &vars in the fex. This means I cannot change the method form "GET" to "POST". If I was allowed to write my own HTML page I would not have this problem. So I'm stuck with the autoprompt screen.
I try to describe the problem more clearly:

First I run a summary report that prompt me first for some variables (like entity, department, category etc. Once the values selected from the different list and multiselect boxes I run the report. The report looks a bit like this:

Entity Department Category ..... colom n

Now I want to drill down on the entity for more detail. Along with the Entity I need to pass all the departments that has been selected from the multiselect box and some other variables to the drilldown report.

something like this:
TYPE=DATA
COLUMN=N1
FOCEXEC=DRILLFEX (ENTITY=N1 DEPARTMENT=&DEP.QUOTEDSTRING CATEGORY='FOC_NONE' ......) , $

Now if I have selected a few departments or the "no selection" in the autoprompt sreen this works fine, but... If I select for example 20 departments or more (depending on the length of the department names) the drill down doesn't work anymore. You can still click the entity column but there is no respons. In PDF, if you hovering over the entity column of the summary report the url for the drilldown is displayed in a tooltiptext automaticly. It is in that tooltiptext that I can see that the "http://" part is missing or not. If it is missing then the drilldown won't work.
If the summary report is in HTML then the drilldown url in the status bar seems to be ok but you'll get no respons by clicking the entity column if the to much departments have been selected.

So I believe that I'm going over the 2083 charater limit for a url in the MS IE. Therefore I would like to pass the department_id, which is only 5 chars long, to the drilldown instead of the departments name. This way the url would be shorter. But how can I do this? In the autoprompt screen the displayed value and the passed value are the same. Or can that be changed from within a fex???

I'll hope my problem is more clear now.
Thanks

Hi Dirk

We are probably moving away from the real issue here.

I think in reality that the issue is within the IB product. Yes POST will move more data, but if a GET has too much data, then IE will try to issue the url, but then will come up with an error.

You are not actually getting an error, if I read what you are saying properly.

Therefore I think that the IB javascript that lies behind your page is failing to actually produce a valid url at all. The JS should be grabbing the page values and putting the url together. And without an ability to debug the code it can be very difficult to know where a break is occurring.

I would raise a case for this.

As for changing the name to id, again you would have to interrupt the IB JS. Again not something I would relish doing, but doable if your JS skills are good.

I think the lack of positive repsonse is a reflection of the difficulty in trying to get workable solution for you.

Dirk..
(btw, please edit your profile to tell us your version,platform, etc)
It is a best practice to make your &var names as short as possible, for many reasons which we'll be talking about at summit, and you've highlighted one very good one. DEPARTMENT could be DPT, ENTITY could be ENT; Remember,when you have a multiselect, DEPARTMENT becomes DEPARTMENT0, DEPARTMENT1 , DEPARTMENT2, DEPARTMENT3, etc.. which can eat up a lot of your 2k-character passthru. I suspect that's whats happening, as you say it works for a few selects, but not alot of them.
Similarly, FOC_NONE is a neat feature but can be expensive to use, and in your example, it is. Passing character strings is the most expensive..for that reason, we'll be suggesting that only codes are passed, and their lengthy text translations are then looked up in a decode table by your receiving fex.

You can use only the DEPT_ID in your fex, and have your fex lookup the dept full name in a lookup table for reporting purposes. But I suspect that your problem lies in your Autoprompt page...you feel that your user has to see the DEPT FULL NAME, not just the DEPT_ ID in order to know what to pick.
hmmm.
the best excuse for making your own launch page... where you would have a select box

<select multiple name="DPTID"..>
<option value="AAAAA">department a full name</option>
<option value="BBBBB">deparment B full name</option>
..etc

So...how about NOT using the Autoprompt screen, but rather something very much like it...but cuter....
right click on your fexname in MRE, and click the PUBLISH option...pick a nice name for your fex...takes a minute or two ... and it makes a launch page that is a notch up from your Autoprompt... then right click on the same fexname, click properties, and UNCHECK show on user's list. Now you have a launch page sitting in exactly the same place as your original fex...so the user's won't be confused....and you can edit that launch page to make your dept list a nice long list of selectables, where you pass only the id, but display the full name to the user.
I think i remember that you said you don't have permission to make your own launch pages..but this is kind of inbetween...its a 'launch page' that can be called 'a fancier autoprompt screen'...and you might get away with it.

BTW,If you're using servlet (which i'm assuming you are), it is POST by default, (which has its pros and cons)

AlanB..would you be kind enough to write up an example of your techniques as an article for Focus On Developers?

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

Hi Susannah, Alan,

Many thanks for your replies. I updated my profile to reflect the wf version, server, webserver, etc...I'm using ,althoug I already mentioned the WF version I'm using by the opening of this discusion!
My &var names are short. In the example I gave, I simply made the &var-names longer to make it clear I'm using departments.
Susannah, you stated that with an multiselect &var becomes &var0,&var1,...,&varn. That's true if you writting your own html forms, but according to my experience with the autoprompt screen it just returns a string in the &var like this: '''value1'' or ''value2'' or ....''valuen''' . That's also the reason why I'm using the QUOTEDSTRING option in the drilldown code. I'll try out the publish option and see if this is a workable alternative for us.
Alan you're so right this is a difficult problem to solve. But if it was easy, were is the challenge . It would be a nice feature though if you could mark in your code what field value should be passed and what field value should be displayed. Don't you think . As Alan suggested I'll open a case for this to speed things up.

Many thanks for your help.

Ah well. A lot for nothing.

The method used within Auto Prompt is POST. So URL length has nothing to do with it, therefore the error must reside within the js and or xsl file that puts everything together before submitting the form.

Hi Alan,

Your "a lot for nothing" remark I don't understand. My ony goal here is to try and fix this problem as soon as possible. So I followed your suggestion and opend a case. I don't want to waste peoples time! Therefore I made some screen shots of this problem, where you can clearly see that the url is truncated. With your permission, I would like it to sent you this 2 page word document.

Kind regards,

Sorry Dirk, I meant that I had really been looking at the url being shortened by the browser, when it had not even reached the browser, and because the autoprompt uses POST, which would not cut off a url anyway, then I was looking at it all wrong.

By all means send me the docs in a private message.

Dirk, i've never seen an autoprompt screen that gave you multiselect ability. in my experience, only a launch page of some sort can specify the 'multiple' needed on a select... and the fex must be written to handle multi's.

Thought I had better give this a try. Had never used Auto Prompt before.

Managed to get a string of 1500 items (about 14k url) to work before the server crashed ('nother story).

So the auto prompt is fine, it's just the drill down that is the issue.

So what I tried is:

DEFINE FILE ALL_VZIP
VTOWN/A4000=&VALID_TOWN.QUOTEDSTRING;
END
TABLE FILE ALL_VZIP
PRINT VALID_ZIP
      VTOWN NOPRINT
BY    SYSTEM_CODE
BY    VALID_TOWN
ON TABLE SUBHEAD
"&VALID-TOWN"
WHERE VALID_TOWN EQ &VALID_TOWN.(OR(FIND VALID_TOWN IN ALL_VZIP)).Town.
WHERE SYSTEM_CODE EQ &SYSTEM_CODE.(OR(UK01,AU01).System
ON TABLE SET STYLE *
.
.
TYPE=DATA
COLUMN=N1
FOCEXEC=TEST10(VALID_TOWN=VTOWN)
$
.
.
ENDSTYLE
END

With this I managed to get right up to the url limit, which in this case was 56 towns.

Note. The url in the drill down was perfectly formed, the drill down worked when over the url limit, except that IE came back with the expected error because the url was too large.

Is this any help.

This message has been edited. Last edited by: Alan B,

Susannah,

This code generates a mulitselect drop down if auto prompt is on:
WHERE DEPARTMENT EQ &Dept.(OR(FIND DEPARTMENT IN VW_REPORT_PARAM_PROMPT)).Departement. ;

It's very easy as you can see but, it would be nice if you could tell WF what the value is to displayed and what value should be passed to the fex. Maybe this could be a new NFR.

Regards,

Hi Alan,

Tried your suggestion. Safed a pdf with a well formed url for the drill down and one with a mal formed url. I opend both in a text editor (Textpad in my case) and looked ad the /URI tag and it seems to be correct in both cases. It starts with '/ibi_apps/' as it should be.

/URI (/ibi_apps/WFServlet?IBIF_webapp=/ibi_apps&IBIC_server=EDASERVE&IBIWF_msgviewer=OFF&IBIAPP_app=standardreportsfr&&IBIMR_drill=X,devstasf/devstasf.htm&IBIF_ex=app/gt015d%2Efex&CLICKED_ON=&Entity=XXXXXX%20S%2EA%2E&Departement=%27%27Accounting%20-%20Controlling%27%27%20OR%20%27%27Antibody%20%20Production%20-%20Services%27%27&Category=FOC_NONE&TELLER=FOC_NONE&BeginDate=01012006&EndDate=31122006&DateRef=01012007&WFFMT=PDF&Multi_Ent=no&Multi_Dep=yes&Multi_Cat=yes) >> >> endobj

I changed the name of the Entity to XXXXXX for obvious reasons. On Monday I'll to take a client trace. Hope this will help me to find the problem.

Many thanks for your help. Any other suggestions are welcome.