Discussions
Categories
Groups
Community Home
Categories
INTERNAL ENABLEMENT
POPULAR
PUBLIC CLOUD
PRIVATE CLOUD
Quick Links
MY LINKS
HELPFUL TIPS
Back to website
Home
Web CMS (TeamSite)
Create SubWorkflow in CGI Task ipl
dootndo2
I have been banging my head on the wall regarding sub workflows. After doing some research, I have determined that I want to try to create a SubWorkflow through code using:
my $wf_system = TeamSite::WFsystem->new();
my $wf = $wf_system->CreateWorkflow($spec);
(This I pulled out of a TS Manual)
The main problem that I am having is that the SubWorkflow did not start when I used a wftask.
Can anyone tell me if I use the above method (WFsystem::CreateWorkflow($spec)), will it start automatically? Or is there any trick to make that work?
Thanks in advance.
dootndo2
TS6.1 SP3 Windows 2000 Box
Find more posts tagged with
Comments
nipper
Are you using the XML of a Job Spec file or just a WFT ?
It needs to be a job spec, and not a WFT
dootndo2
I am currently set up for a wft. Looking at the manual for Workflows, the job spec looks just like the xml doc generated by a wft. Is this correct?
If that is accurate, could I create a 'here' document and add the necessary variables and then pass it into the CreateWorkflow method?
Thanks again.
dootndo2
nipper
Sounds easy doesn't it ?
& it can be easy, can also get tough depending on what you are doing
Adam Stoller
If you're using a wft - you *might* want to take a look at using iwwft_compile.ipl
I haven't used it myself .. yet .. but it sounds like it might be a bit easier to do than what you're attempting.
--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com
kshitiz
Hi
May be this can help if you are using a wft file:
# Create a wf template with the template file (wft file)
my $wft = TeamSite::WFtemplate->new(template => $template_file);
# Set workflow parameters
$wft->{tag}{"iw_branch"}{value} = $branch;
..
..
# Get the job specification
my $wf_spec = $wft->get_workflow();
my $wf_system = TeamSite::WFsystem->new();
# Create a new Workflow
my $wf = $wf_system->CreateWorkflow( $wf_spec );
# Invoke the job
$wf->Invoke();
Kshitiz Sharma
BT Wholesale | CMS
Mahindra British Telecom
Migrateduser
Personally, I've always preferred doing this via XML spec. This way, your CGI can dynamically build the XML and then invoke the job via
iwjobc
. I have found this to be the most flexible and straight-forward way to create a nested workflow, but it might just be a matter of preference.
Dave
Current Environment(s):
(1) TS 6.5 on W2K3
(2) TS 6.1 SP1 on W2K3
dootndo2
Thanks to all for your replies. I am still unclear on what the difference is. Here is my interpretation.
The wft file is an XML doc that contains PERL script and TAG code to generate an XML file read by the workflow engine.
The job spec is an XML doc that does not contain PERL script and TAG code that is read by the workflow engine.
So for example, a valid job spec file could look like this:
<workflow>
<external task>
<successor>
<files>
</external task>
<group task>
<shared by>
<activation>
<successor>
</group task>
<end task>
</end task>
</workflow>
Is this assumption correct? The manual that I have has a DTD for a job spec and I cannot tell any difference. If I can pass this XML as a job script as a variable, would there be significant benefits to compile this through a command line tool and then run it from another command line tool? On pages 156-157 it shows what a job spec DTD looks like. I have attached that sample.
Still learning. Thanks for all your insights.
dootndo2
Migrateduser
A wft file is not an XML doc, though. The parsed result, however, is. The wft file can include Perl code and modules, etc., that control how the workflow spec is built. In this, you can put both Perl variables and TeamSite workflow variables. If you were to run a basic workflow in debug mode, you would see the source wft file and the resulting XML spec.
The XML spec is really just that. The reason I like it so much is that it's very straight-forward and if I'm already using a CGI, I can build it very easily from that. That is, Perl's extensibility is already built in to the CGI. Going this route, the CGI outputs the XML spec to a file, likely a temporary file or a file that will be deleted by some means later on. After the job spec file is created, you'll be able to run the iwjobc command on the file to instantiate your new job.
Dave
Current Environment(s):
(1) TS 6.5 on W2K3
(2) TS 6.1 SP1 on W2K3
james1
> The wft file is an XML doc that contains PERL script and TAG
> code to generate an XML file read by the workflow engine.
A WFT is no necessarily a valid XML document. But you are right about the rest -- it contains Perl code and TAG directives, and it generates an XML file ... a job specification, to be precise.
> The job spec is an XML doc that does not contain PERL
> script and TAG code that is read by the workflow engine.
I think you have the right idea here. A job spec has neither Perl code nor TAG directives. It is a fully specified workflow, with no parameters to be substituted at instantiation time.
Your example job specification is structurally on the right track, though, obviously, it is missing a lot of required data.
> If I can pass this XML as a job script as a variable, would
> there be significant benefits to compile this through a
> command line tool and then run it from another command
> line tool?
I'm not sure what command line tool you are thinking of running it through here. If you run the "iwjobc" CLT on a job spec document, then you are done compiling the *job spec* (you are not "compiling" a WFT) -- there is nothing more to do.
Hope this helps.
-- James
--
James H Koh
Interwoven Engineering
dootndo2
I am able to run the following code:
$workarea = $task->GetArea();
$workarea =~ s/\\/\//g;
my $wf_system = TeamSite::WFsystem->new();
#getSpec() returns a 'here' document that has the job spec as shown below.
my $spec = getSpec();
my $wf = $wf_system->CreateWorkflow($spec);
if ((!defined $wf) || !$wf->IsValid() || $wf->GetError())
{
$errorcode .= $wf->GetError();
print logfile $errorcode;
}
$errorcode .= $wf->GetError();
print logfile $spec;
print logfile $errorcode;
close(logfile);
There is no errors reported, but a workflow is never created. This code is executed after the postback from the CGITask CGI page. Using a Callback or not does not create a workflow. Here is the job spec:
<?xml version='1.0' standalone='no' ?>
<!DOCTYPE workflow SYSTEM 'iwwf.dtd'>
<workflow name = 'subworkflow' owner = 'me' creator = 'me'>
<externaltask lock = 'f' name = 'EMAIL' owner = 'me' retry = 'f' start = 't' retainowner = 'f'>
<areavpath v = '/default/project/'/>
<successors>
<successorset description = 'Go to GROUP'>
<succ v = 'GROUP'/>
</successorset>
</successors>
<command v='D:/iw-home/iw-perl/bin/iwperl
/iw-home/bin/iwsend_servlet_mail.ipl GROUP "me"'/>
</externaltask>
<grouptask lock = 'f' name = 'GROUP' start = 'f' readonly = 't' description = 'description' retainowner = 'f'>
<areavpath v = '/default/project/'/>
<successors>
<successorset description = 'Go to EndTask'>
<succ v = 'EndTask'/>
</successorset>
</successors>
<sharedby><user v = 'me' /></sharedby>
<activation>
<or>
<pred v = 'EMAIL'/>
</or>
</activation>
</grouptask>
<endtask name = 'EndTask'>
<activation>
<or>
<pred v = 'GROUP'/>
</or>
</activation>
</endtask>
</workflow>
Are we required to use iwjobc from CLT? Or can we use this method?
Thanks again.
dootndo2
james1
I'm sure your workflow is created. Check the id of "$wf" (i.e., "$wf->GetId()") and run "iwgetwfobj [id]".
After you create the workflow, you need to invoke your workflow to start it running. Try "$wf->Invoke()".
-- James
--
James H Koh
Interwoven Engineering
dootndo2
That worked beautifully. Thanks to all that participated.
dootndo2