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

Question about transition to nested workflow task

Huan

Hi,
Using TS 6.5 sol. I have two workflow. One is called a.wft and the other is called b.wft. The start task of a.wft is an external task called starttask. a.wft works fine.

In b.wft, I want to reuse a.wft. I tried the following two approaches:

1) in b.wft, I created a nested workflow task calling a.wft.

results: b.wft worked fine untill it transited to the nested workflow. It stoped at a.wft. The start task of a.wft was not executed at all.

2) Instead of using the nested workflow task, I used the starttask of a.wft and changed the external task attributes start from Yes to No. (for testing purpose, I didn't put the whole a.wft into b.wft)

results: b.wft worked very well and didn't stop at the start task of a.wft.

Could anyone point out what is wrong with the first apporach? Why the nested workflow's start task didn't automatically start in the first approach?

I also quote some sentences from TeamSite document:
"Workflow tasks can either be specified with a path to a job specification file or to a workflow template file (.wft). In the case of a job specification file, upon activation of the workflow task, TeamSite compiles and instantiates a new job using the specification file. In the case of a workflow template file, the task owner must manually start the task using the New Job window to input job variables and subsequently initiate the job."

Find more posts tagged with

Comments

Migrateduser

Hi,
In b.wft, I want to reuse a.wft. I tried the following two approaches:

1) in b.wft, I created a nested workflow task calling a.wft.

results: b.wft worked fine untill it transited to the nested workflow. It stoped at a.wft. The start task of a.wft was not executed at all.

You can certainly have start task in the nested workflow a.wft. What do you mean by It stoped at a.wft?
Did you start the nested workflow in TeamSite UI from b.wft workflow instance?
Do you see the nested workflow a.wft in TeamSite Workflow tab?

Hi,
2) Instead of using the nested workflow task, I used the starttask of a.wft and changed the external task attributes start from Yes to No. (for testing purpose, I didn't put the whole a.wft into b.wft)

results: b.wft worked very well and didn't stop at the start task of a.wft.

You can have only one START task in a workflow. You can't copy the full a.wft into b.wft it does not work. You need to use wftask to tie two different workflows.

kaalraa

Hi,
"Workflow tasks can either be specified with a path to a job specification file or to a workflow template file (.wft). In the case of a job specification file, upon activation of the workflow task, TeamSite compiles and instantiates a new job using the specification file. In the case of a workflow template file, the task owner must manually start the task using the New Job window to input job variables and subsequently initiate the job."

You have reached the correct lines of the doc... every workflow needs some parameterised values to inittate the job. In case of nested workflow.. if all the required values are with the workflow.. then it would start immidiately....else it will wait for the user to start manually.

As you have written.. that a.wft is working all well as standalone... please check if the start task has immediate=t or f.

Huan

Thanks for your reply.

[QUOTE=batasari]You can certainly have start task in the nested workflow a.wft. What do you mean by It stoped at a.wft?
It didn't go through the start task of a.wft.

Did you start the nested workflow in TeamSite UI from b.wft workflow instance?
Yes I did. I am using Workflowbuilder and I drew the nested workflow task and filled up the attributes WFfile by applying the full path of a.wft, and drew a transition between one of the task of b.wft to this nested workflow task. You can take a look at the snippet at the bottom.

Do you see the nested workflow a.wft in TeamSite Workflow tab?
Yes, I saw the description of a.wft and nothing else in a.wft happend. It supposed to execute the start task of a.wft, but it didn't.

You can have only one START task in a workflow. You can't copy the full a.wft into b.wft it does not work. You need to use wftask to tie two different workflows.
My workflow (using the nested workflow approach) passed the workflowbuilder validation. The following are the snippet of b.wft:

<wftask name = "Publishing" owner = "__INSERT__($iw_user);" start = "f" description = "Continue on publishing workflow">
<areavpath v = "__INSERT__($iw_workarea);"/>
<successors>
<successorset description = "Go to EndTask">
<succ v = "EndTask"/>
</successorset>
</successors>
<wftfile v = "e:\iw-home\local\config\wft\Publishing.wft"/>
<activation>
<or>
<pred v = "DeploytoProdServer"/>
</or>
</activation>
</wftask>

Just don't know why the first approach didn't work. I didn't see any big difference betweent the first and second approach.

Huan

You have reached the correct lines of the doc... every workflow needs some parameterised values to inittate the job. In case of nested workflow.. if all the required values are with the workflow.. then it would start immidiately....else it will wait for the user to start manually.

As you have written.. that a.wft is working all well as standalone... please check if the start task has immediate=t or f.

I didn't find where to put this attribute in workflowbuilder and I didn't set this attribute in my workflow template either. Are u talking about start="t"? I've set start="t" for the start tasks of a.wft and b.wft both. As in the snippet, I put the full path to reference the nested workflow as well.

Migrateduser

Do you see the nested workflow a.wft in TeamSite Workflow tab?
Yes, I saw the description of a.wft and nothing else in a.wft happend. It supposed to execute the start task of a.wft, but it didn't.

You can have only one START task in a workflow. You can't copy the full a.wft into b.wft it does not work. You need to use wftask to tie two different workflows.
My workflow (using the nested workflow approach) passed the workflowbuilder validation. The following are the snippet of b.wft:

<wftask name = "Publishing" owner = "__INSERT__($iw_user);" start = "f" description = "Continue on publishing workflow">
<areavpath v = "__INSERT__($iw_workarea);"/>
<successors>
<successorset description = "Go to EndTask">
<succ v = "EndTask"/>
</successorset>
</successors>
<wftfile v = "e:\iw-home\local\config\wft\Publishing.wft"/>
<activation>
<or>
<pred v = "DeploytoProdServer"/>
</or>
</activation>
</wftask>

It wftask looks ok to me, try using forward slash insted of backward slash in specifying the wftfile location.

Adam Stoller

You can have only one START task in a workflow. You can't copy the full a.wft into b.wft it does not work. You need to use wftask to tie two different workflows.

Actually, this is not true - A workflow can have multiple start tasks - they would both run concurrently (I believe you'd want to attach the same list of pre-selected files to all start tasks, but you might not have to do so).

That being said, I don't think that's what is desired here.

You have reached the correct lines of the doc... every workflow needs some parameterised values to inittate the job. In case of nested workflow.. if all the required values are with the workflow.. then it would start immidiately....else it will wait for the user to start manually.

As you have written.. that a.wft is working all well as standalone... please check if the start task has immediate=t or f.

Every workflow does not need some parameterized (TAG_Info) values to become instantiated - most do have them though. Start tasks do not have an "immediate" attribute - cgitasks do. If your start task is a cgitask and it's owned by 'iw_user' / the user who instantiated the job - then yes, you want to have immediate="t" set.

wftfile's as of 6.5 SP2 (and perhaps as early as 6.5.0, but I'm pretty sure after 6.1) have an attribute called background that can be set to "t" and will behave (with the same constraints) as a cgitask with immediate="t". This attribute is subtly documented in the manual - in the form of a comment in the DTD. As documented, and this is presumably to what you (kaalraa) were referring:

If background is 't', then TeamSite will attempt to start a job using the wftfile assuming necessary args will be provided in task variables (for details, see documentation for iwwft_compile.pl. If background job creation fails, then the GUI will present the user the option to start a job. Defaults to false (requiring user intervention).

I didn't find where to put this attribute in workflowbuilder and I didn't set this attribute in my workflow template either. Are u talking about start="t"? I've set start="t" for the start tasks of a.wft and b.wft both. As in the snippet, I put the full path to reference the nested workflow as well.

WFB is xxxx (provide your own expletive) and quite likely was never updated to provide for the 'background' (not 'start') attribute for wftfile's - so you'd have to hand-edit the WFT and then continue to do so anytime you tried to modify it using WFB [ugh]. Setting start="t" for the start task in both a.wft and b.wft is required - otherwise there would be no start task in the nested workflow. As per the documentation you need the full system path to the wftfile - so that part's correct.

It wftask looks ok to me, try using forward slash insted of backward slash in specifying the wftfile location.

I agree, it looks correct - except for one very important part:

Using TS 6.5 sol.
[...]
<wftfile v = "e:\iw-home\local\config\wft\Publishing.wft"/>

Those two statements do not jive. If your TS server is Solaris - the path to the WFT should be a UNIX path not a WINDOWS path - so - yes, the slashes should be forward-slashes - but there also should not be an "e:" at the beginning!

Hope some of the above helps.

Huan

Thanks for all of you. Your replies are very helpful. I have made the following changes based on your suggestions:

<wftask name = "Publishing" owner = "__INSERT__($iw_user);" start = "f" background = "t" description = "Continue on publishing workflow">
<areavpath v = "__INSERT__($iw_workarea);"/>
<successors>
<successorset description = "Go to EndTask">
<succ v = "EndTask"/>
</successorset>
</successors>
<wftfile v = "e:\iw-home\local\config\wft\Publishing.wft"/>
<activation>
<or>
<pred v = "DeploytoProdServer"/>
</or>
</activation>
</wftask>

I didn't modify the wftfile path because I am using WINDOWS O.S. The problem is still here. Under TeamSite Workflow tab, I can see that the Task Description is "Continue on publishing workflow", however, it didn't execute any line of the start task of Publishing.wft.

The start external task of Publishing.wft is as follows:
<externaltask lock = "f" name = "AttachFiles" owner = "__INSERT__($iw_user);" retry = "f" start = "t" description = "Attach alternate language files">
<areavpath v = "__INSERT__($iw_workarea);"/>
<successors>
<successorset description = "Go to LockFiles">
<succ v = "LockFiles"/>
</successorset>
</successors>
<command v = "e:\iw-home\iw-perl\bin\iwperl.exe E:\iw-home\local\config\wft\xx\****\bin\attachfiles.ipl"/>
<timeout v = "+000001">
<succ v = "EmailingforFixAttachFiles"/>
</timeout>
__INSERT__($iw_selected_files);
<activation>
<or>
<pred v = "FixAttachFailure"/>
</or>
</activation>
</externaltask>

Adam Stoller

Thanks for all of you. Your replies are very helpful. I have made the following changes based on your suggestions:

<wftask name = "Publishing" owner = "__INSERT__($iw_user);" start = "f" background = "t" description = "Continue on publishing workflow">

<wftfile v = "e:\iw-home\local\config\wft\Publishing.wft"/>

</wftask>

I didn't modify the wftfile path because I am using WINDOWS O.S. The problem is still here. Under TeamSite Workflow tab, I can see that the Task Description is "Continue on publishing workflow", however, it didn't execute any line of the start task of Publishing.wft.

[...]

The background attribute belongs on the wftfile element - not the wftask element.

Is your TS server Windows or Solaris? Your original post indicated Solaris - now you're saying Windows - which is it? (I don't care about your client - just the server)

Huan

Thank you so much ghoti! It solved the problem.

BlueWhale

Hi,

I have got a question using this "background" attribute. How can we implement this in a configurable WFs. I have the wftask as shown below:

declare_task("subWF",
name => $subWF_task_name,
description => $subWF_task_desc,
type => wftask,
owner => $iw_user,
areavpath => $subWF_WA,
wftfile => $iwconfigs/wft/solutions/subWF.wft,
background => "t",
variables => {
"author" => __VALUE__('iw_contributor'),
"editor" => $iw_user,
}
);

I am not sure here how to use the "background" thing to get my nested job to start automatically. Right now with the above set-up, I need to manually start the nested job. By the way, I am calling a .wft file for creating the sub WF.

Can someone please throw some light on this? Thanks in advance.

Environment: TS 6.5 on Windows.

Adam Stoller

Hi,

I have got a question using this "background" attribute. How can we implement this in a configurable WFs. I have the wftask as shown below:

declare_task("subWF",
name => $subWF_task_name,
description => $subWF_task_desc,
type => wftask,
owner => $iw_user,
areavpath => $subWF_WA,
wftfile => $iwconfigs/wft/solutions/subWF.wft,
background => "t",
variables => {
"author" => __VALUE__('iw_contributor'),
"editor" => $iw_user,
}
);

I am not sure here how to use the "background" thing to get my nested job to start automatically. Right now with the above set-up, I need to manually start the nested job. By the way, I am calling a .wft file for creating the sub WF.

Can someone please throw some light on this? Thanks in advance.

Environment: TS 6.5 on Windows.

Unfortunately, it appears that wftask is not a task type that was explicitly covered when TeamSite::WFconstructor was created - so you have several choices (none of them great):

I may have missed an option or two - but I think the above is pretty much complete.

BlueWhale

Thanks Ghoti for your suggestions.

I am wondering whether there's an easy way to achieve this. If anyone has implemented this, sharing your idea will be highly appreciated. Thank you.

DynamicDataSource.rptdesign

ISCBorisB

Thanks Ghoti for your suggestions.

I am wondering whether there's an easy way to achieve this. If anyone has implemented this, sharing your idea will be highly appreciated. Thank you.

It is actually not that hard to *inject* traditional XML Fragment into WFConstructor generated code. Sure enough,
none of that is documented or supported by IWOV.

To do it you may feign any supported task Type (like usertask in the following sample) and then susbstitute WFConstructor-generated XML
with the your desired XML fragment right before you spawn WF Specs. Note that I used the same Task name in both feigned and XML
fragments, keep it this way.

Use standard 'link_tasks' to build links *To* wfttask. In the sample below I've included *From* Links (successors)
into XML itself, with little regex ingenuity you can use 'link_tasks' to do all your linking. Note though that in this case
substitution is more complex, you would have to keep successors and/or activation Tags from the *feigned* XML Fragment


declare_task('Nested_Job',
 name => 'Nested_Job',
 type => 'usertask',
 owner => $iw_user,
 areavpath => "YourArea",
);

my $nestedWFXML = qq(
   <wftask name="Nested_Job"
      owner="$iw_user"
      description="Your Description">
      <areavpath v="YourArea"/>
      <successors>
      ...
     </successors>
     <wftfile v="$iwconfigs/wft/YourPath/YourWFT.wft" background="t"/>
   </wftask>
);

# and then...

# Not sure what you use, print or INSERT. Reagrdless, comment it out
# print get_job_spec();
# __INSERT__(get_job_spec());

# Instead:

my $temp = get_job_spec();
$temp =~ s|<usertask name="Nested_Job".+?</usertask>|$nestedWFXML|is;
__INSERT__($temp);

Comprende?

BlueWhale

Looks like this can be done. Let me try the suggested functionality and will share the result with you.

Thanks soooooo much "ISCBorisB" and "Ghoti".

Adam Stoller

It is actually not that hard to *inject* traditional XML Fragment into WFConstructor generated code. Sure enough,
none of that is documented or supported by IWOV.
[...]
Comprende?

Kewl - I thought there was a way to do this, but hadn't given it that much thought. Good tip!

BlueWhale

That worked excellent!!! Thank You soo much ISCBorisB.

ISCBorisB

That worked excellent!!! Thank You soo much ISCBorisB.

I've tried (just for the sake of it) and had no problem whatever creating 'wftask' completely with the WFConstructor.

It seems that the only (unsupported?) exception is the "background" attribute of <wftfile> Tag. That can be easily
*injected* using regex substitution in the same fashion as before.