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

Nested Workflow task does not seem to start

blacke

Hi,

I'm using TS 6.1.0 on Solaris 9. I'm trying to create a workflow with other generic nested workflows that may or may not have input forms. On the first one that I'm try to get working, I get the input form, then a nested Job Id and it's taskid after submitting the form, but it doesn't seem like the perl script that accompanies the wft is run since there is no debug file output. If I run the perl file from the command line I get a debug file. At this point I can debug the nested wf perl script, but I'm not sure how to debug the startup of that nested wf job. Any ideas?

The external task FTP works fine and uses the same ftp.ipl file as the wf task. Basically, I want the user to input the data for a FTP session, but if they type in the wrong password or something, and it fails, I just want to re-present the same form(almost) and have them try again.

Thanks,
Eric

Find more posts tagged with

Comments

jbonifaci

It sounds like things would be much simpler for your workflow if you just did the entire ftp process in a cgitask. Otherwise you're going to have to have a cgi-task that transitions to an external task and then if there is an error in the external task, transition to the same cgitask or a new one. At which point the user would need to refresh their task list and start the cgitask, as you can't have a cgitask with after an external task with immediate=true.

~Jeff

brandon1

To clarify you are having the issue with the nested wf correct? You attached what seems like the main wft. Can you attach the nested one ftp.wft. As well as the script in question. That would definitely make it easier for the community to help you track down the problem.

Current Project: TS 6.1
Environment: Windows

blacke

Here's ftp.wft.

blacke

Here's the ipl

jbonifaci

As I said before, you're probably better off doing this completely within a cgitask, otherwise the user will need to refresh his task list in order to complete the form again. If you insist on doing it through an external task and nested workflow, you will need to either add a cgitask that is similar to your tag_info section and transition to this task if there is a problem with the ipl or have the parent workflow kick off the nested workflow again. But, here are the three options I've given in order of best to worst:

1. Get rid of the nested workflow and just add a cgitask to your main workflow that does both the UI and the ftp.

2. Keep your nested workflow, but remove the tag_info section of it and make the start task a cgitask with a similar input form. It would then transition to the external task and the external task would transition to end if successful, or back to the cgitask if there were a problem. It could set a workflow variable that the cgitask could check for and display a message to the user if this variable is set.

3. Leave your nested workflow unchanged, but have the parent workflow kick off the nested workflow again if the nested workflow encountered any problems.

~Jeff

brandon1

An alternative is to validate the username and password on the job kick off screen, before the job is instantiated.

Current Project: TS 6.1
Environment: Windows

jbonifaci

True, that's probably his best immediate solution. Although, I would think a cgitask would be the best option long term, unless they are ftping huge documents. I would slot that solution as #2 on my list and bump my 2 and 3 down. Unless they are ftping large amounts of data, then it would be #1.

~Jeff

brandon1

I do have a question regarding the use of ftp. Why are you not using open deploy?

Current Project: TS 6.1
Environment: Windows

jbonifaci

I was thinking the same thing, but didn't want to open that can worms. But since you already did...

I would highly recommend using OpenDeploy for transfer of files. It is an obvious best practice for TeamSite implementations. Unless you have some reason OpenDeploy won't work for you? It would also significantly simplify your workflow and potentially completely remove the need for this nested workflow.

~Jeff

blacke

Third party vendor's server. No access other than ftp.

blacke

Is there really a way of validating whether the username/password is valid without trying a login? I'm concerned that in a long workflow, that a simple typo will require the user to start a new job after failing at the FTP part.

brandon1

No you would still need to login, but you're wft kick off screen could validate before the job is created. Please see this post about calling a PERL sub to validate TAG_info data.

http://devnet.interwoven.com/forums/cgi-bin/showthreaded.pl?Cat=&Board=DOWNLOADS_WORKFLOWS&Number=69196&page=&view=&sb=&o=&vc=1#Post69196

Current Project: TS 6.1
Environment: Windows

blacke

I'm new at creating workflows and it sounds like your suggestions make sense. I wanted to keep the FTP as a simple workflow so other workflows I develop can use it sort of like a lib module. If I create the cgitask it wouldn't be as portable(at least it sounds like that). I also want to keep the workflow as automated as possible since it will run for hours on GB of data, so I want to gather all the info up front and keep the user out of it unless there is a failure, and hopefully never make the user restart from the beginning. What I've decided to do until I work out some of the kinks to my logic, is create an initial form that allows th user to select the starting point, so if there are any failures, the user can restart whereever they want.

I would still like to know why the wftask is not working because I'm sure I'll come across this again even if I don't use it this time. It just seems like the task gets started and just waits before starting the internal ftp exernal task(ipl), and I don't know how o trouble shoot that problem.

Thanks,
Eric

jbonifaci

The cgitask would be portable, as a cgitask instead of a wftask, which is better IMO. But it's your call, so whatever you're comfortable with.

~Jeff

brandon1

The nested wft's start task was calling this

my $command = "$iwperl $wft_dir/$this_dir/$wft_base_name.ipl";

Is the above mentioned script then calling ftp.ipl?

Current Project: TS 6.1
Environment: Windows

blacke

The command was the problem. When called from it's own ftp workflow directly, the path was relative. When called from the ftp workflow as a wftask, the path was absolute and the $this_dir variable was doubling the $wft_dir path.

Now that I have the nested workflow thing working, I can see what you mean about the refreshing of the workflow, change jobs to get the internal details of the nested workflow, etc,, so I think I'll attempt to change it to a cgitask so I can compare the two.

Thanks for all your help.

Eric