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 in WFM

bagman

I have read the documentation and multiple threads on here about the "immediate" attribute for cgitasks. I have done it numerous times using WFTs, but having an issue with WFM.

I am using the integrated WFM modeler in TS 7.3 on Linux.

Here is the section of the model:

Here is the applicable code from the validateFilenames.cgi:

my $cgi       = TeamSite::CGI_lite->new();
$cgi->parse_data();
my $submitBtn = $cgi->{form}{continue};
my @badlist     = ();
my $results    = "";
my $cbResult  = qq(Success);
my $cbComment = qq(Files Validated);

# Process attached files
  ...

# Show the bad files to the user if any are found.
if (@badlist) {
  print DEBUG "Found some bad files...\n";
  ...
  $cbResult  = "FixFilenames";
  $cbComment = qq(Found Error in filename(s));
} else {
 print DEBUG "No bad files found...\n";
  ...
}

# If no bad files or user clicked the "Continue"
# button from results screen, callback to the
# workflow. Otherwise, show the results screen.
if ((!$results)||($submitBtn)){
 $cgi->iwcallback("$cbResult", "$cbComment");
} else {
 &print_html_header();
 print $results;
 &print_html_footer();
}

All three tasks are owned by the same user.
The "immediate" attribute is set for both "cgitasks". (The "immediate" works from AuthorWork to ValidateFilenames, but not from ValidateFilename to ScheduleDeployment.)
I am using the correct "iwcallback" from CGI_Lite.pm.

Can anyone see what I am missing? I think I have looked at it far too long.

Thanks,
Mark

Find more posts tagged with

Comments

Adam Stoller

Are these OS users or Non-OS (LDAP / AD) users?

Perl won't do the impersonation of the task owner if the task owner is not an OS-user (i.e. someone with an entry in /etc/passwd)

bagman

Are these OS users or Non-OS (LDAP / AD) users?

Perl won't do the impersonation of the task owner if the task owner is not an OS-user (i.e. someone with an entry in /etc/passwd)

The user is an LDAP user. If that were the case, would the CGI not trigger at all? I thought that was the purpose of the iw_cgi_wrapper.cgi - to handle impersonation. I think I did run into that issue with externaltasks, but not cgitasks because of the wrapper.

The validateFilenames.cgi fires, processes and transitions. It just will not transition straight into the scheduleDeployments.cgi triggering as "immediate". The user has to go into the task and select "Start Input Task".

I just tried to run it as an OS-level user with the same result.

Thanks,
Mark

nipper

Unfortunately I was never able to get that to work with Perl CGI tasks with WFM.

bagman

Unfortunately I was never able to get that to work with Perl CGI tasks with WFM.

Thanks for chiming in. I guess this is a bug I will send to support. It is not a showstopper, but definitely a preferable user experience.

BTW, to clarify... You stipulated "Perl CGI". Does it work using Java? I don't do Java, but this may be a good place to start playing with it.

Thanks,
Mark

Adam Stoller

The iw_cgi_wrapper.cgi only works with OS-users.
The fact that it doesn't work with LDAP users is not a bug - it's a limitation that was documented several years ago when they first introduced the concept of non-OS users.

For "impersonation" with Non-OS users you cannot use Perl.

Java / CSSDK should work - but if you've never coded in Java you can expect a fairly steep learning curve (if done right, the experience is worthwhile IMO)

bagman

The iw_cgi_wrapper.cgi only works with OS-users.
The fact that it doesn't work with LDAP users is not a bug - it's a limitation that was documented several years ago when they first introduced the concept of non-OS users.

For "impersonation" with Non-OS users you cannot use Perl.

Java / CSSDK should work - but if you've never coded in Java you can expect a fairly steep learning curve (if done right, the experience is worthwhile IMO)

I know of the limitation as related to externaltasks, but have not found anything related to cgitasks. Where is that documented?

The individual CGIs work fine with OS and non-OS users, so the wrapper is doing it's job. The problem is with the first CGI closing the window and transitioning to the second CGI. The second CGI is not reopening the window and the user has to click "Start Input Task" instead of seeing the new form immediately.

If this were an OS vs non-OS user issue, you would think the process would work properly for an OS user, but it does not work for either.

Just curious why this would work in Java and not Perl. Is there something fundamentally different in how the Java callback method works vs. the CGI_Lite iwcallback function?

Thanks,
Mark

Adam Stoller

I know of the limitation as related to externaltasks, but have not found anything related to cgitasks.

Hmm, perhaps it doesn't affect CGI tasks - not sure, but I'd be less sure of it doing the right thing (you could have the script log the values of

$<, $>, $(, and $)

to verify that the values are what you expect.

The individual CGIs work fine with OS and non-OS users, so the wrapper is doing it's job. The problem is with the first CGI closing the window and transitioning to the second CGI.

Try changing the first CGI so that it doesn't close the window -- that could be the disconnect there when going from CGI to CGI.

bagman

Hmm, perhaps it doesn't affect CGI tasks - not sure, but I'd be less sure of it doing the right thing (you could have the script log the values of
$<, $>, $(, and $)
to verify that the values are what you expect.

So it turns out the LDAP users are running as "iwui" and OS users are running as themselves. It does not seem to be impacting the functionality.

Try changing the first CGI so that it doesn't close the window -- that could be the disconnect there when going from CGI to CGI.

The window closing is coded in the CGI_Lite iwcallback function.

Think I will report it to support as a bug and see what they come back with. It is either a bug or a documentation error.

Thanks,
Mark

Adam Stoller

The window closing is coded in the CGI_Lite iwcallback function.

Not in the version of TeamSite::CGI_lite I'm looking at - it does a submit of the form (

document.mainform.submit()

) so perhaps there's something in the surrounding HTML code that's causing the window to close, but I don't think it's happening explicitly in the iwcallback code itself.

bagman

Not in the version of TeamSite::CGI_lite I'm looking at - it does a submit of the form (
document.mainform.submit()
) so perhaps there's something in the surrounding HTML code that's causing the window to close, but I don't think it's happening explicitly in the iwcallback code itself.

I think I got that from the "done_page" hidden variable:
[HTML][/HTML]
The close_or_home.html page is where the page is being closed. This is in the form getting submitted by iwcallback. I wonder if I can manipulate this somehow.

Thanks,
Mark