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 Task startup

fish

I have an External Task that validates and decides my successor.
I'm trying to invoke a CGI task failure screen on one of the successors and would like the screen to show automatically after the external task i.e. not go to the todo list and start task.

How is this possible?

Steve

Find more posts tagged with

Comments

Migrateduser

With an external task, you cannot cause a CGI task to "pop-up" immediately (in the workflow, this is controlled by the immediate="t" directive, by the way).

It is, however, possible after a usertask or cgitask. Although it may result in dirtier code, can you implement the validation within a previous CGI task, so that you basically have neighboring CGI tasks, the second of which is immediate="t"?

Dave

Jeremy

Hi Steve,

I think the only ways that a CGI task will kickoff automatically is if it occurs after a User task where the same user owns the User task and the CGI task and the immediate flag is set to true. I think the other time it starts automatically is if the CGI task is the first task and is also owned by the user who started the workflow.

So I don't think using a CGI task can do what you want to do.

Maybe someone else will chime in with other possible solutions.

Jeremy

Dwayne

There is no practical way, in the current architecture, for TeamSite to "pop up" a window when a CGI task activates. It can "commandeer" the old window used for a usertask (or task initiation screen) that immediately invoked the task, but, otherwise, there isn't enough session information to allow what's being requested. That's one of the limitations of a browser-based UI. All user interaction has to be initiated from the client side. The only way I could see this happening would be for the main TeamSite UI to be "polling" the server on a regular basis, to see if there were any CGI tasks pending, and pop them up if so. But there are already enough complaints about the performance - that would only make it worse. And I think it would confuse users to have these random popup windows appearing.

Also, where should this popup window appear if the user is logged on from multiple workstations?

--

Current project: TS 5.5.2/6.1 W2K

fish

Hi Jeremy,

That is pretty much what I thought (the Supplemental Workflow seems pretty clear on this).

Just hoping someone had come up with a fancy workaround...

Cheers,

Steve

Adam Stoller

What comes prior to your externaltask?
What constraints, if any, are there on who 'owns' the externaltask process?

As was somewhat suggested before - if you have something like:

usertask (owned by "A") -> externaltask (owned by "A") -> cgitask (owned by "A)

You could change it to:

usertask (owned by "A") -> cgitask (immediate="t" owned by "A")

Where the logic you currently use in your externaltask script gets merged into the cgitask script. The CGI portion of the script would not need to actually do anything until/unless the externaltask script portion of it calls a function requiring a window to be initialized and displayed (you *might* see a window pop-up regardless, but I think it would wait until you first print "content-type: text/html\n\n").

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

fish

Yep I agree that I'll have to put my validation External Task functionality in the cgi Task and manage the cgi from the output of the validation. It just would have been made sense to break the two tasks apart in my scenario.

no worries thanks for your input ...

Steve