Remark about cgi-params in wft-cgi's

Hi all,

see below my remarks on the cgi-parameters that are passed by Teamsite to a cgi-script in a workflow cgi-task:

1. the cgi-params are nowhere documented. The only way to find out what/how is passed is to write a cgi-script with some code that will list all params & their values. See sample_cgi_task.ipl for sample code.

2. since they are not documented there is the risk that Iwov will change these params and their values in future version (don't think they would never do so, they have done so in the 55 to 60 release for 'normal' cgi-scripts) and thus breaking your scripts.

3. cgi-params (name & value) are depend on how the cgi-script is started (immediate vs. by clicking the button in the task-screen). Both the name of the param as well as the value differ.

4. some params (f.i. task_id) are passed more then once under different names. With regards to 2, there is no way how to find out which name one should use.

I'm writing this to share with all AND to let Iwov know that this, to me, is kind of unacceptable in a product that they charge so much $$$ for. :-)

Cheers, Ronald

TS65 Sp1
Win2k Sp4
OD602

Find more posts tagged with

Comments

Adam Stoller

I don't disagree with you about the lack of proper documentation for these items - in fact in 5.5.2 there used to be *some* documentation - under the headings: Custom Menu Items / Creating Custom CGI Scripts - most of which appears to be lost in the 6.5 manuals (there's some vague references in the UICG but nothing that could really be considered qualified documentation.

However, even from before the 5.5.2 days - the rule-of-thumb (which should have been documented) was to use the CGI program show_env.cgi wherever you wanted to use a custom CGI - in order to get a complete list of the form variables accessible to the CGI program in the context in which it was going to be used.

True, these form variables changed significantly with 6.x - but that was relatively quickly "fixed" by the inclusion of the CGI wrapper wdpro_menu.ipl (Early on in the 6.x days - I posted recommendations for creating two custom menu items for showing the environment / form variables - one with, and one without the use of wdpro_menu.ipl - to help developers revise code for working in 6.x)

With respect to your item #3 - I'm unaware of any CGI form variables that change explicitly based on whether the cgitask (I assume you meant a cgitask) was declared with immediate="t" or not - can you elaborate a bit more on this?

With respect to your item #4 - task_id and its variants have been around since 4.x and possibly 3.x (or earlier) days - and there is some documentation regarding that in the workflow manual (but I believe covered better in the Workflow Tutorial Supplement which I wrote many years ago, and which is available on DevNet if you search for it). I do, however, agree that they should have unified on one such variable and killed off the other ones over the course of releases (with ample documentation regarding such) - I always felt that iw_taskid was the best named variant...

All of this should be captured in a bug report, filed with Interwoven Support - once you have a bug id # - you can post it here and other organizations can add their names to it to give it some priority (it's not the "best" system - but it is the prevailing system for handling this kind of thing - either that or utilizing a significantly big customer who has lots of $$'s to throw its weight around)

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

RonaldV

Ok, here we go.

This is a listing (TS65Sp1, Win2k) of all param that are passed to a cgi-task that starts immediately (i've hidden some security related values):

Form Data
area_path \default\main\wwwnl\Master\RELEASE_01\WORKAREA\Ronald
done_page /iw-cc/base/util/refresh_done_target_and_close_window.jsp?done%5ftarget=fs%5fget%5flist%5fframe%28%29
iw_areaowner owner
iw_branch /default/main/wwwnl/Master/RELEASE_01
iw_desc
iw_home d:\iw-home
iw_jobid 230549
iw_overwrite
iw_role admin
iw_session the-session-key
iw_taskid 230550
iw_template_file workflows/www/www_dcr_submit.wft
iw_template_name New DCR Submit
iw_use_default
iw_user domain\myid
iw_workarea /default/main/wwwnl/Master/RELEASE_01/WORKAREA/Ronald
session the-session-key
taskID 230550
task_id 230550
taskid 230550
user_name domain\myid
user_role admin

And now the same task, same cgi, same flow, same everything, now started from "Start Input Task"-button the cgi-task-overview (so I closed the first cgi-window without calling-back and then opened the cgi-task and clicked the "Start Input Task" button):

Form Data
area_path //myserver/default/main/wwwnl/Master/RELEASE_01/WORKAREA/Ronald
cgi_transition true
done_page /iw-cc/ccpro/workflow/transition_handler.jsp?customer.done_page=/iw-cc/base/util/close_or_home.html&customer.full_redirect=true&taskid=230577
full_redirect true
iw_locale en
iw_role admin
iw_taskid 230577
iw_user domain\myid
session the-session-key
session_string the-session-key
taskID 230577
task_id 230577
taskid 230577
custom_errorTask Error
custom_nextTask Approval

As you can see, area_path is now forward-slashed and starts with the servername. Further many iw_* params are missing, session_string is new, user_name & user_role are gone, task-varaibles are now exposed. (I'm now ignoring the internal-looking params like cgi-transition & full_redirect)

Cheers, Ronald

TS65 Sp1
Win2k Sp4
OD602

DashBIRT-1.0-20100210.zip

requiredlibs.txt

DashBIRT_deployed.jpg

Adam Stoller

So - according to your post - the data below represents a cgitask fired off immediately, then the CGI window closed without transitioning and re-started manually via Start Input Task - right?

I'm a bit curious about a few things here:

Which UI is being used? (CCPro?, CCStd?)
Have you tried with the other UI to see if the results are the same?
Items number 13, 21, 22, and 23 seem to have different values between the first and second invokation - if you did what you said you did, they shouldn't have different values - so that's a bit confusing
The second run seems to have two custom form variables - were these created during the first run, and showing up in the second run somehow?
In addition to the above - why were they not [apparently] displayed in sorted order as all the rest of the form variables were?

Clearly there are a lot of differences here - and to some degree I'd say it looks like the immediately-executed CGI script were run as-if through the wdpro_menu.ipl wrapper, and the manually-executed CGI script was not. However, there are also enough strange differences here to make me wonder about the manner in which the data was collected. (I don't have a good situation right now to try this out myself, if I find time I might do so though...)

All of this is good information to provide to Support when opening a bug report.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

RonaldV

Hi Fish,

thanks for your nicely layout-ed overview. :-)

Here some more details:
- Which UI is being used? (CCPro?, CCStd?) => CCPro
- Have you tried with the other UI to see if the results are the same? => Yes, funnily enough the CCStd ALWAYS shows the params as if "started-manually" in CCPro. So it looks like CCPro, immediate is the exception.
- Items number 13, 21, 22, and 23 seem to have different values between the first and second invokation - if you did what you said you did, they shouldn't have different values - so that's a bit confusing? => well that's just because I had to start a new job because the previously had already done a callback. The rest is 100% equal.
The second run seems to have two custom form variables - were these created during the first run, and showing up in the second run somehow? => NO, they simply miss out when started 'immediately'. They task-vars were present right from the beginning.
In addition to the above - why were they not [apparently] displayed in sorted order as all the rest of the form variables were? => you are sharp, man. That because I renamed the vars to make them more standardized.

TS65 Sp1
Win2k Sp4
OD602

Adam Stoller

Interesting - I still think you should file a bug with IWOV Support on this (have you?)

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

RonaldV

Sorry, but I can be bothered by support.

You always have to convince them 5 times and remind them 3 times before they start to believe that this could actully be a bug and not something by design.

I think Iwov should use these forums pro-actively and scan it for issues, bugs, tips, remarks, etc that could help make the product better.

Anyway, this way the community at least knows about this bug. :-)

Ronald

TS65 Sp1
Win2k Sp4
OD602

Adam Stoller

That's a wonderfully defeatest attitude. It's like not voting and complaining about who got elected.

I ran a test on my solaris 6.7 beta server and got what appears to be similar results - so I collected them along with the wft I used and have sent it into Support.

I don't expect too much action before January - but at least the ball should be rolling then.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Doc1.doc

RonaldV

Did you ask them to fix the bug (and maybe break my script ;-) or to fix the documentation? The latter would prove more usefull, I think.

TS65 Sp1
Win2k Sp4
OD602

Adam Stoller

Did you ask them to fix the bug (and maybe break my script ;-) or to fix the documentation? The latter would prove more usefull, I think.

I told them to make whatever changes would make your life more difficult because you were too lazy to bother trying to file the information yourself.

Actually, I asked for both documentation and engineering bugs to be filed. The documentation bug is generic (this information needs to be documented). The engineering bug(s) are prioritized based on how easy or difficult it is to work-around the difference and/or whether or not the difference seemed to be important (I might have gotten some of that wrong?). In summary fashion:SECKEYIMMEDIATEMANUALPRICOMMENTENVCONTENT_TYPE<empty>application/x-www-form-urlencodedLA little strange perhaps, but I dont think it's importantENVREQUEST_URL/iw-bin/iw_cgi_wrapper.cgi/show_env.cgi?iw_jobid=556&.../iw-bin/iw_cgi_wrapper.cgi/show_env.cgi?Perhaps the [near] source of the discrepencies?Form Dataarea_path/default/main/devnet/WORKAREA/work//ts-sun/default/main/devnet/WORKAREA/workMAnnoying difference, but if you code to account for it, not that bad:my $area = $cgi->{form}{area_path};
$area =~ tr|\\|/|;
$area =~ s|^//[^/]+||;Form Databanner.flag<empty>FALSELSignificance unclear, but I don't think anyone is coding with it.Form Datacgi.transition<empty>TRUELSignificance unclear, but I don't think anyone is coding with it.Form Datadone_page/iw-cc/base/util/refresh_done_target_and_close_window.jsp?done.../iw-cc/ccpro/workflow/transition_handler.jsp?customer.done_page=...MPotentially significant as it may affect post-script behavior.Form Datafull_redirect<empty>TRUELSignificance unclear, but I don't think anyone is coding with it.Form Dataiw_areaowneruserid<empty>MHPotentially significant - workaround requires calling CLT [ugh]:my $area = ...(see above)...;
my $owner = qx($iwhome/bin/iwattrib $area owner);
chomp($owner);Form Dataiw_branch/default/main/devnet<empty>LSimple to work around if value really needed:my $area = ...(see above)...;
(my $branch = $area) =~ s|/WORKAREA/.*$||;Form Dataiw_home/export1/iw-home<empty>LI never count on this coming from a form variable:use TeamSite::Config;
my $iwhome = TeamSite::Config::iwgethome();
$iwhome =~ tr|\\|/|;Form Dataiw_jobidjobid<empty>LEasily worked around:my $taskid = $cgi->{form}{iw_taskid};
$taskid = shift(@$taskid) if (ref($taskid) eq "ARRAY");
my $task = TeamSite::WFtask->new($taskid);
my $jobid = $task->GetWorkflowId();Form Dataiw_locale<empty>enLSignificance unclear, but I don't think anyone is coding with it.Form Dataiw_session<iw-auth-string><empty>LEasily worked around:my $session = $cgi->{form}{session};Form Dataiw_template_filedevnet/cgitest.wft<empty>MHPotentially significant if the same cgi script is used in multiple wfts and behaves somewhat differently depending on the wft from which it was called. I'm now thinking this is a low proirity (see below) unless the path to the workflow template file is important.Form Dataiw_template_namecgitest<empty>MHPotentially significant (see above) but not too difficult to work around:my $jobid = ...(see above)...;
my $job = TeamSite::WFworkflow->new($jobid);
my $wftname = $job->GetName();Form Dataiw_workarea/default/main/devnet/WORKAREA/work<empty>LEasily worked around.my $area = ...(see above)...;Form Datasession_string<empty><iw-auth-string>LEasily worked around:my $session = $cgi->{form}{session};Form Datauser_nameuserid<empty>LEasily worked around:my $user = $cgi->{form}{iw_user};Form Datauser_rolemaster<empty>LIn the data I submitted I listed this as medium-high(mh), but I now realize it's really trivial to work around:my $role = $cgi->{form}{iw_role}

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Frederik

Ghoti, did you ever hear back from support on this? Or can you post the bug numbers?

(TS 6.5 sp2 patch 1767 on Solaris)

I just noticed that the same difference exists for Workflow with CGI-task (start=true, immediate=true), when Workflow is started as a SUBMIT or TT_DATA command (terms used as in available_templates.cfg).

I came to this because the out-of-the-box default_submit.wft is posting error messages in the $IWLOGS/iwui/error_log about a bad call to iw-home/bin/iwgettaskbyname. The error is in the (equally out-of-the-box) iwconflictcheck.cgi, which assumes that

$jobid = $cgi->{form}{iw_jobid}

, but iw_jobid is missing in a TT_DATA situation, while present in a normal SUBMIT situation.

Cute... out-of-the-box default_submit workflow broken.

I hope the table below survives these Boards' I-like-to-break-HTML parser.



  cgi->{form}
  SUBMIT
  TT_DATA


  area_path
  /default/main/prjx/WORKAREA/userWA
//myserver/default/main/prjx/WORKAREA/userWA


  banner.flag
<n/a>
  false


  cgi_transition
<n/a>
  true


  done_page
  /iw-cc/base/util/refresh_done_target_and_close_window.jsp 
 ?done%5ftarget=fs%5fget%5flist%5fframe%28%29
  /iw-cc/base/util/refresh_done_target_and_close_window.jsp 
 ?done_target=getFileListFrame%28%29


  done_target
<n/a>
  fs_list


  full_redirect
<n/a>
  true


  iw_areaowner
  prjx000t
<n/a>


  iw_branch
  /default/main/prjx
<n/a>


  iw_desc
<blank>
<n/a>


  iw_home
  /extra/app/TeamSite/iw-home
<n/a>


  iw_jobid
  17517
<n/a>


  iw_locale
<n/a>
  nl_BE


  iw_overwrite
<blank>
<n/a>


  iw_role
  editor
  editor


  iw_session
  52616e6 ... fed72989177829ba629be36
<n/a>


  iw_taskid
  17521
  17556


  iw_template_file
  default/default_submit.wft
<n/a>


  iw_template_name
  Submit to Staging
<n/a>


  iw_use_default
<blank>
<n/a>


  iw_user
  fred
  fred


  iw_workarea
  /default/main/prjx/WORKAREA/userWA
<n/a>


  session
  52616e6 ... fed72989177829ba629be36
  52616e6 ... fed72989177829ba629be36


  session_string
<n/a>
  52616e6 ... fed72989177829ba629be36


  submittask_name
<n/a>
  Submit changes


  taskID
  17521
  17556


  task_id
  17521
  17556


  taskid
  17521
  17556


  user_name
  fred
<n/a>


  user_role
  editor
<n/a>

Adam Stoller

Ghoti, did you ever hear back from support on this? Or can you post the bug numbers?[...]

My post was from 2.5 years ago - I no longer remember if I had any follow-up regarding it. Sorry.