nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

CGI to CGI revisited (again & again)

bagman

Ok... I know this has been covered time and time again on here. I have brought this up already in relation to WFM, but now I'm working with a WFT. I know have I done this in the past, but it's been many years.

I believe I am following all of the rules for CGI to CGI transition. Here is a section of the specification file and the iwcallback call from my CGI. I believe everything is in order, but the %#@$ thing doesn't work.

I have tried this with OS users and LDAP users. Same result with each.

Would someone mind giving it a fresh set of eyes and advising if I am missing something?

EDIT: Attached document with code since the XML doesn't appear to be showing... Smiley Sad


======= Snippet from workflow specification =======



















































======= Snippet from validateFilenames.cgi =======
sub determineCB(){
 #print DEBUG "Inside determineCB()\n";
 my $cbResult  = qq(Success);
 my $cbComment = qq(Files Validated);
 my $flag = scalar keys %badlist;
 #print DEBUG "\t\$flag -> $flag\n";
 if ($flag == 0){
  print DEBUG "\t\$cbResult  -> $cbResult\n";
  print DEBUG "\t\$cbComment -> $cbComment\n";
  #displayNoBadFiles();
  $cgi->iwcallback("$cbResult","$cbComment");
  #$cgi->iwcallback(); #Have also tried this...
 } else {
  &print_html_header();
  displayBadFiles();
  print $results;
  &print_html_footer();
 }
}

Find more posts tagged with

Comments

nipper

Ok... I know this has been covered time and time again on here. I have brought this up already in relation to WFM, but now I'm working with a WFT. I know have I done this in the past, but it's been many years.

I believe I am following all of the rules for CGI to CGI transition. Here is a section of the specification file and the iwcallback call from my CGI. I believe everything is in order, but the %#@$ thing doesn't work.

I have tried this with OS users and LDAP users. Same result with each.

Would someone mind giving it a fresh set of eyes and advising if I am missing something?

EDIT: Attached document with code since the XML doesn't appear to be showing...

[php]
======= Snippet from workflow specification =======

======= Snippet from validateFilenames.cgi =======
sub determineCB(){
#print DEBUG "Inside determineCB()\n";
my $cbResult = qq(Success);
my $cbComment = qq(Files Validated);
my $flag = scalar keys %badlist;
#print DEBUG "\t\$flag -> $flag\n";
if ($flag == 0){
print DEBUG "\t\$cbResult -> $cbResult\n";
print DEBUG "\t\$cbComment -> $cbComment\n";
#displayNoBadFiles();
$cgi->iwcallback("$cbResult","$cbComment");
#$cgi->iwcallback(); #Have also tried this...
} else {
&print_html_header();
displayBadFiles();
print $results;
&print_html_footer();
}
}
[/php]

Fixing post

That should work, use the immediate flag and keep the user the same.

bagman

Fixing post

That should work, use the immediate flag and keep the user the same.

Thanks nipper. I forgot to mention this is on 7.3.2 on Linux. I have not tried it on our 6.7.1 instance yet.

Anyone else have issues on 7.3.2 with this?

Thanks,
Mark

birt2.PNG

Adam Stoller

Can you provide a bit more details about what doesn't work?

I.e.:

Snap 2016-05-19 at 09.16.14.png

Snap 2016-05-19 at 09.18.46.png

Snap 2016-05-19 at 09.21.10.png

CrossTab6.zip

bagman

[QUOTE=ghoti]Can you provide a bit more details about what doesn't work?

I.e.:

MKRAU5 master TaskGoActive Wally Test Dev to Prod 0xc4fc ChooseECN 0xc502 /default/main/wally_test/WORKAREA/mhk_site Thanks,Mark

Adam Stoller

Ghoti,

The validateFilenames.cgi runs completely and does perform the transition. The window closes and the next task becomes active. The choose_dev_dest_common.cgi runs only after clicking on the Start Input Task.[...]

Thanks,
Mark

This sounds like there's code within validateFilenames.cgi that explicitly closes the CGI window - that could be the source of the problem (as everything else seems to look correct) - try making sure that you do not close the window in validateFilenames.cgi and see if that fixes the problems with choose_dev_dest_common.cgi not running immediately after.

bagman

This sounds like there's code within validateFilenames.cgi that explicitly closes the CGI window - that could be the source of the problem (as everything else seems to look correct) - try making sure that you do not close the window in validateFilenames.cgi and see if that fixes the problems with choose_dev_dest_common.cgi not running immediately after.

Ghoti,

validateFilenames doesn't close the window. There was code in there, but I took it out. In fact, the HTML headers aren't even created before the callback is attempt. I did try adding printing the headers just to see what happened. As a result, dual headers ended up getting created and the form did not submit or transition. But that did get me the iwcallback form.

[HTML]

<script language="javascript">
function handleOnLoad()
{
document.mainform.submit();
}
</script>

[/HTML]

So, I noticed the form action is iwcallback.cgi. I tried going directly to the iwcallback.cgi to see what it did and got the following help...

TeamSite : Workflow Custom CGI Callback
Error: Error in iwcallback usage: %s
  required parameters: session                    - the session string
                       task_id                    - the task id of the task to callback to
                       one of:
                           callback               - the callback to the transition to the next task
                           special_callback       - one of:
                               delete_workflow    - permanently ends the current workflow
                               retry_workflow     - sends a retry to the current submit or update task
  optional parameters: callback_comment           - comment to associate with the callback in the task history
                       return_page                - specify which screen to return to in main TeamSite UI
                           values:  tasks_list    - go back to the tasks todo list
                                    job_history   - go back to the job history list

So, it appears the form is telling it to go back to the task list. There are also a number of other form fields that I do not know how they are being processed - specifically curious about "done_page", "full_redirect" and "cgi_transition".

I don't know if there is another process that iwcallback.cgi is forwarding these values to or something.

Adam Stoller

Ghoti,

validateFilenames doesn't close the window. There was code in there, but I took it out. In fact, the HTML headers aren't even created before the callback is attempt. I did try adding printing the headers just to see what happened. As a result, dual headers ended up getting created and the form did not submit or transition. But that did get me the iwcallback form.

[HTML]

<script language="javascript">
function handleOnLoad()
{
document.mainform.submit();
}
</script>

[...][/HTML]

You might want to take a closer look at 'close_or_home.html'
Or better yet, handle the iwcallback yourself in your own code rather than calling some other piece of code that you don't fully understand - yes, it's a bit of wheel-recreation, but it's either that or spending a lot more time to understand the code that already exists (which wouldn't necessarily be a bad thing to do - but if you do it - document it, since apparently nobody else did)

So, I noticed the form action is iwcallback.cgi. I tried going directly to the iwcallback.cgi to see what it did and got the following help...
[...]
So, it appears the form is telling it to go back to the task list. There are also a number of other form fields that I do not know how they are being processed - specifically curious about "done_page", "full_redirect" and "cgi_transition".

I don't know if there is another process that iwcallback.cgi is forwarding these values to or something.

As I said, all the more reason to just handle the callback in your own code rather than calling out to another program that probably does a lot more than you need or want (like closing the window).