Discussions
Categories
Groups
Community Home
Categories
INTERNAL ENABLEMENT
POPULAR
THRUST SERVICES & TOOLS
CLOUD EDITIONS
Quick Links
MY LINKS
HELPFUL TIPS
Back to website
Home
Web CMS (TeamSite)
iwaddtaskfile path attribute
gsumers22texas
Can anybody offer a little richer description of the "path" attribute of iwaddtaskfile CLT? the 5.0.1 CLT pdf doesn't really describe its' purpose, and the example doesn't show it used-
Is it just used to be able to set a path to a file you're adding to a task that exists from the workarea root? or are there other effects of using it that should be considered?
application / use / problem: reason I ask is that we're using it to try and add a file to our job (within an external task, downstream from an iwgen action creating a new htm file), but instead it's adding the entire directory set in the path attribute of iwaddtaskfile- A downstream submittask is submitting the entire contents of this directory instead of just the files we want (DCR originally selected to begin workflow and generated htm file produced by iwgen)
thanks for any responses
Find more posts tagged with
Comments
Adam Stoller
The path is an area-relative path.
For instance - say there's a file:
/iwmnt/default/main/www/WORKAREA/myworkarea/subdir1/subdir2/foo.html
The task that you want to add the file to - must have an areavpath - in the case of the above, the areavpath would be:
/default/main/www/WORKAREA/myworkarea.
The path for the file you want to add to the task (and thus the job the task belongs to) is relative to the areavpath of the task - and thus would be:
subdir1/subdir2/foo.html
Now - the tricky part here only because I don't remember off the top of my head and am not trying it out right at this moment is whether the area-relative path needs to start with a '/' or not. I *think* it will take
subdir1/subdir2/foo.html
/subdir1/subdir2/foo.html
./subdir1/subdir2/foo.html
and treat them all equivalently - but you can easily find out while testing...
If you're using an externaltask - you should be creating a TeamSite::WFtask object ($task) within the script - and then you can use $task->AddFile() rather than calling iwaddtaskfile directly [minor point].
Regardless - the question is: What are you providing as the path argument for iwaddtaskfile? If you supplying just the "path" without the filename - then that might be why it is adding the entire contents of the directory (I never would have even thought of this as working) - the "path" is the area-relative path-to-the-(and-including-the)-file
subdir1/subdir2/foo.html
*not*
subdir1/subdir2
Does that answer your question?
--fish
(Interwoven, Curriculum Development)
gsumers22texas
based on the CLT pdf descriptions, I was thinking that path and filename were seperate flags to the CLT, but actually "path" is both- it does require a leading "/"
what is the advantage to using $task->AddFile() over just running the iwaddtaskfile CLT directly within the script? since the only real documentation on the subroutines of the WF modules is in the module code itself (and is not very detailed), it's hard to know why this is the way to go?
thanks for help as always Ghoti
Migrateduser
If you are going to be calling the CLT from within a Perl script, then you may find the modules WFtask and WFworkflow to be more convenient as they provide Perl interfaces. If your code is written correctly, there shouldn't be any functional difference.
Brinko Kobrin
Interwoven Staff Engineer
Adam Stoller
I guess there was a mis-reading of the help information (I can see where it might be possible) - I'll file a bug report on it 34261).
The value in using the TeamSite::WFtask module's AddFile() method over calling iwaddtaskfile yourself is - at this point in time - minimal - mostly a convenience factor.
At this time, the method calls the CLT for you. At some point in the future, it is possible that the method call might be able to make "lower level" calls (perhaps OpenAPI) - if you use the method in your code, you gain the advantages automatically upon upgrade. If you hardcode the call to the CLT, you will always be using the CLT.
Other than that, it's the convenience of not having to arrange your own system call to invoke the CLT with the correct arguments in the correct order (jobid, taskid, etc.) and keep your code looking just that tiny-bit more cleaner for not having to have done so.
--fish
(Interwoven, Curriculum Development)
Renata
it seems like you have already implemented the functionality we're working on - namely, generating HTML from DCR's attached to a wf. Do you mind sharing with us how you have achieved this functionality?
thanks a bunch -- R.
gsumers22texas
it's a perl script that basically builds the two CLT commands iwgen and then iwaddtaskfile (to add the generated file to the workflow)
from the wft (CGI section):
my %externalcmd = (unlock => "$iwhome/local/bin/unlock.ipl",
ourgen => "$iwhome/local/bin/our_gen.ipl");
from the wft (externaltask):
<command v='__INSERT__($externalcmd{"ourgen"});'/>
in the our_gen.ipl:
my $dcrpath =
@files[0]
;
($templateroot, $datacategory, $datatype, $subdir, $dcrname) = split(/\//, $dcrpath);
my $gentpl = "-t $area/$templateroot/$datacategory/$datatype/presentation/$dcrname.tpl";
my $gendcr = "-r $area/$dcrpath";
my $genfile = "$area/DCFS/$dcrname.htm";
my $cmdx = "$iwgen $gentpl $gendcr $genfile";
($nulldir, $defaultdir, $maindir, $branch1, $branch2, $genWA, $WAName, $DCFSdir, $iwaddfilename) = split(/\//, $genfile);
my $iwaddservername = "-s teamsite.domain.com";
my $iwaddtaskid = $taskid;
my $iwaddcomments = "NOTE: $iwaddfilename generated by our_gen.ipl";
my $cmdy = "$iwaddtaskfile $iwaddservername $iwaddtaskid $iwaddpath/$iwaddfilename $iwaddcomments";
system($cmdy);
make sure permissions on your our_gen.ipl script allow for execution by task owners
hope this helps, lots of blood sweat and tears went into it
Migrateduser
As ghoti indicated in the thread "using iwgen", "There isn't an OOTB script for this because the parameters you need to pass (and how you want to pass them) tend to vary greatly - not only from site-to-site, but even within a site from branch-to-branch and even from instance of workflow to instance of workflow."
The code provided by gsumers22texas is one possible solution. It may or may not be appropriate for you needs.
Some of the questions you need to answer are:
1. Which presentation template(s) should be used?
2. Where do you want the generated files to go?
3. How do you want the generated file to be named?
4. What should happen if a generated file already exists?
5. Do you need to set any EAs on the generated files?
Brinko Kobrin
Interwoven Staff Engineer
gsumers22texas
I'll definitely second Brinko's comments-
our workflow and scripts have only been unit tested so far -
so far, we're making the assumption that our very non-technical users would sacrifice a little flexibililty for not having to know filenames/locations/etc - right now this is working / performing the right actions at the right time in the workflow in Unit Testing, but needs to be more thoroughly tested to understand all ramifications of doing this way
brinko, do you have an alternate method of doing this that would also avoid additional usertasks and/or cgitasks requiring "decisions" on the user's part?
Renata
Guys - this is very helpful. We are implementing very basic form of it for now, and have (or at least tried to) addressed the above issues.
Thank you as always -- Renata