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; } } }

Instantiator CGI

wild123

Hi
Can somebody tell me why I am left wtih this window (file attached) after I click on the Run Job button of the Job Instantiation window. The first task (start task) that sends out email is performed but the attached window doesnt close.

Thanks in advance

Find more posts tagged with

Comments

Adam Stoller

Hi
Can somebody tell me why I am left wtih this window (file attached) after I click on the Run Job button of the Job Instantiation window. The first task (start task) that sends out email is performed but the attached window doesnt close.

Thanks in advance

Things that might help:

wild123

[QUOTE=ghoti]Things that might help:

::-All client machines for this workflow , after I added this particular start task for e-mailing.All the workflow features runs perfectly as desired, except for the job instantiation window that changes to a blank as the file attched above. What can be the problem?

Adam Stoller

Hmm - well I don't see anything glaringly wrong.
I do vaguely remember that 6.5 had some issues with a missing HTML file that was specified (built-in) for the done_page URI parameter which I believe caused a problem similar to this - and may in fact be the issue - though I would think that would affect all workflows, not just custom ones.

Can you verify the full URL of the blank page that's sitting there?

wild123

Hmm - well I don't see anything glaringly wrong.
I do vaguely remember that 6.5 had some issues with a missing HTML file that was specified (built-in) for the done_page URI parameter which I believe caused a problem similar to this - and may in fact be the issue - though I would think that would affect all workflows, not just custom ones.

Can you verify the full URL of the blank page that's sitting there?

The full URL is :

[html]http://servername/iw-bin/iw_cgi_wrapper.cgi/iwwft_instantiator.cgi[/html]

That's it!!!

What else can I look at to debug the issue any other logs etc....

This problem doesnot happen in the attched workflow.What can be the reason?

wild123

I tried removing the new code and running the WF bit by bit.The problem arrises when use WF_BanSettings module.What can be the reason?
[html]my $BA_conf = Banks::WF_BanSettings->new($_this_->__VALUE__('iw_workarea'));[/html]

It is this line in the spec that's creating all the problem.I guess. How can I override the problem?

Adam Stoller

I tried removing the new code and running the WF bit by bit.The problem arrises when use WF_BanSettings module.What can be the reason?
[html]my $BA_conf = Banks::WF_BanSettings->new($_this_->__VALUE__('iw_workarea'));[/html]

It is this line in the spec that's creating all the problem.I guess. How can I override the problem?

Without knowing the internals of that module - we can't help you. Sorry.

nipper

my $BA_conf = Banks::WF_BanSettings->new($_this_->__VALUE__('iw_workarea'));

It is this line in the spec that's creating all the problem.I guess. How can I override the problem?

Figure out why that perl module is failing. That is not a standard PM delivered with TS, so it is a local customization.

wild123

Figure out why that perl module is failing. That is not a standard PM delivered with TS, so it is a local customization.

This is a customized PM. I dont see any problem in the PM. Its giving proper output aswell. I have also checked things using use strict and warning, there are no syntax error even.

What has wf's job instantiation window got to do with a PM(which is running without any errors)?

Adam Stoller

This is a customized PM. I dont see any problem in the PM. Its giving proper output aswell. I have also checked things using use strict and warning, there are no syntax error even.

What has wf's job instantiation window got to do with a PM(which is running without any errors)?

The PM could be sending something to STDOUT (perhaps even white-space) which is confusing the instantiator CGI into thinking that the start task is a cgitask (in which case the window used for the instantiator is re-used for the cgitask) - ergo - if the use of the module causes the problem - start debugging the module - look for print, warn, and die statements or anything that's called using back-ticks (`...`) or qx() or open statements that use a pipe -- anything and everything that could be sending unexpected output to STDOUT and/or STDERR.

new_report_1.rptdesign