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

Does TeamSite 6.5 have Delete workflow?

waikong

Hi All,

I have been working on this for about a week. Actually I am configuring a DCR deletion workflow, the requirement is to delete the HTML file that generated by the DCR. (I store the location of the HTML & the location of the DCR in the DCR)

When a author create or delete a DCR, it trigger the author_submit_dcr.wft workflow. But can that workflow be configured to auto delete the HTML file that associate with the DCR? (I mean is there such a capability available?)

I have done a quick study into the author_submit_dcr.wft, and below is the task flow:

In case there is no capability to configure the workflow to delete the HTML file, is there any solution to delete the HTML file (which generated by the DCR) and doesn't require heavy effort to modify on the workflow template? Because the deadline is very close.

I think after the External task, I can call another External task to delete the HTML file (only if I can extract the location of the HTML file from the DCT).

Find more posts tagged with

Comments

Adam Stoller

Hi All,

I have been working on this for about a week. Actually I am configuring a DCR deletion workflow, the requirement is to delete the HTML file that generated by the DCR. (I store the location of the HTML & the location of the DCR in the DCR)

When a author create or delete a DCR, it trigger the author_submit_dcr.wft workflow. But can that workflow be configured to auto delete the HTML file that associate with the DCR? (I mean is there such a capability available?)

I have done a quick study into the author_submit_dcr.wft, and below is the task flow:
...
In case there is no capability to configure the workflow to delete the HTML file, is there any solution to delete the HTML file (which generated by the DCR) and doesn't require heavy effort to modify on the workflow template? Because the deadline is very close.

I think after the External task, I can call another External task to delete the HTML file (only if I can extract the location of the HTML file from the DCT).

If, as you say, you are recording the path / name of the generated file in or on (as an EA) the DCR - then you can add code to the WFT, or to an externaltask script to process the DCR, extract the area-relative path to the generated file(s) and attach them to the workflow. You will also need to explicitly delete the generated file as well.

On the assumption that we're starting the workflow with a deleted DCR - you will probably need to process the copy of the DCR that's in staging in order to find the information about the generated file, add the file to the workflow, and delete the file - from that point on, the rest of the processing of the workflow should work just fine.

Alternatively, you could remove the OOTB Delete option and replace it with a custom option that does this too - and then just deal with submitting the deletions.

However - none of this is completely OOTB - you will have to write some custom code somewhere (custom menu item and/or custom code in wft and/or custom code for externaltask script)

waikong

If, as you say, you are recording the path / name of the generated file in or on (as an EA) the DCR - then you can add code to the WFT, or to an externaltask script to process the DCR, extract the area-relative path to the generated file(s) and attach them to the workflow. You will also need to explicitly delete the generated file as well.

On the assumption that we're starting the workflow with a deleted DCR - you will probably need to process the copy of the DCR that's in staging in order to find the information about the generated file, add the file to the workflow, and delete the file - from that point on, the rest of the processing of the workflow should work just fine.

Alternatively, you could remove the OOTB Delete option and replace it with a custom option that does this too - and then just deal with submitting the deletions.

However - none of this is completely OOTB - you will have to write some custom code somewhere (custom menu item and/or custom code in wft and/or custom code for externaltask script)

Thanks gothi,

let me summarize your point-
write a perl script to do the following things:
1) read the DCR on the staging.
2) get the generated-file.
3) attach the generated-file to the workflow.
4) delete the generated-file.
then create a external task in the workflow to call the script.

do I got it right?

Thanks, I think I got the high level solution, what appear in my mind is how can we read into a DCR, and the staging through the perl script? is there any available TeamSite module that we can use? any document for references? I have did a quick look at the workflow Fundamentals training document, and it doesn't go in detail about how to customize the external task perl script.

Another question appear in my mind is how can we differentciate the submitted DCR is a new created, updated, or deleted DCR?

I have some idea which is compare the staging before the file submit and after the file submit. if case:
1) before submit, the DCR not exist AND after submit the DCR exist in staging - Create Content
2) before submit, the DCR exist AND after submit the DCR still exist in staging - Update Content
3) before submit, the DCR exist AND after submit the DCR not exist in staging - Delete Content

sorry if this question have been answer before.

Adam Stoller

Thanks gothi,

let me summarize your point-
write a perl script to do the following things:
1) read the DCR on the staging.
2) get the generated-file.
3) attach the generated-file to the workflow.
4) delete the generated-file.
then create a external task in the workflow to call the script.

do I got it right?

With the exception of spelling my pseudonym (ghoti) - that's pretty much it. Note though, many customers address this from the other side - which is they start with the generated file and then strive to attach the associated DCR to the workflow - the generated file usually has EAs associated with it that can be used to identify the DCR from whence it was generated - however, if you store the generated file path/name in (or on) the DCR, you should be able to handle either direction.

Thanks, I think I got the high level solution, what appear in my mind is how can we read into a DCR, and the staging through the perl script? is there any available TeamSite module that we can use? any document for references? I have did a quick look at the workflow Fundamentals training document, and it doesn't go in detail about how to customize the external task perl script.

There are no modules for what you want - explicitly. There are a number of different possible modules and just basic calling of CLTs to do what you want - this is what's generally considered the creative part of code development.

Another question appear in my mind is how can we differentciate the submitted DCR is a new created, updated, or deleted DCR?

I have some idea which is compare the staging before the file submit and after the file submit. if case:
1) before submit, the DCR not exist AND after submit the DCR exist in staging - Create Content
2) before submit, the DCR exist AND after submit the DCR still exist in staging - Update Content
3) before submit, the DCR exist AND after submit the DCR not exist in staging - Delete Content

I think you have it - but I'll do a little re-phrasing just in case: Prior to the underlying submit action

Have fun.

waikong

With the exception of spelling my pseudonym (ghoti)

pardon me for spell your pseudonym wrongly.

[QUOTE]I think you have it - but I'll do a little re-phrasing just in case: Prior to the underlying submit action

task.2.) Check the existence of the DCR/Generated File in Staging.3.) Passing DCR to the Perl script to process and upload the data to our custom database. (Note. we don't have data deploy license)Let me try to resolve them one by one and hope you can provide me guidance along the way. Your contribution of knowledge will be highly appreciated.

waikong

update:

I found the WORKFLOW BODY section:

##################################################
# WORKFLOW BODY
##################################################
# A network approach to handling tasks linkages; a seven step process:
# Step 1: Declare the basic properties of the workflow.
# Step 2: Declare all the tasks.
# Step 3: Declare links between tasks.
# Step 4: Identify the 'dormant' tasks and propagate.
# Step 5: Compute activation sets.
# Step 6: Any "special" task handling.
# Step 7: Generate the job spec.

I found that there are some unknown command in the perl script within configurable_author_assignment.wft these are the samples:

declare_workflow

# Step 1: Declare the basic properties of the workflow.
declare_workflow(name          => $job_name,
                 owner         => $iw_user,
                 creator       => $iw_user,
                 description   => $job_description,
                 comment       => "This job was created using $iw_template_file",
                 files         => \@submit_file,
                 file_comments => \@file_comments);

declare_task

# Step 2: Declare all the tasks.
declare_task('add_files',
             name        => $localizer->format('add_files_task.name'),
             description => $localizer->format('add_files_task.description'),
             type        => "usertask",
             start       => TRUE,
             owner       => $iw_user,
             areavpath   => $iw_workarea);

link_tasks

# Step 3: Declare links between tasks.
# NB: When a task has more than one link to successor tasks, the order
# in which the links are declared is significant.  It controls the 
# order of the successorsets, which is very important to an externaltask.
link_tasks('add_files', 'email_author', $done_label);

i believe that is the command use to cronstuct the workflow, workflow task, and linkage.

I would like to ask that whether I will define my external task and linking them to the workflow by using one of these command?

Migrateduser

All the three are functions declared in a Perl Module called TeamSite::WFconstructor...

This is a very useful Module to build workflows instead of using the Workflow builder.

1) Declare_workflow --- Used to give the definition of the workflow.

2) declare_task --- declares a task.

3) link_task --- links two tasks... thus generateing a workflow.

In order to add an external task in between , u need to use declare_task and when u have done that, u need to link the tasks appropriately.

-Dixit

waikong

All the three are functions declared in a Perl Module called TeamSite::WFconstructor...

This is a very useful Module to build workflows instead of using the Workflow builder.

1) Declare_workflow --- Used to give the definition of the workflow.

2) declare_task --- declares a task.

3) link_task --- links two tasks... thus generateing a workflow.

In order to add an external task in between , u need to use declare_task and when u have done that, u need to link the tasks appropriately.

-Dixit

Thanks Dixit, for the clarify.

Please correct me if I make any mistake, so that means I will declare my task using the following code:

declare_task('my_task',
             name        => $localizer->format('deploy_task.name'),
             description => $localizer->format('deploy_task.description'),
             type        => "externaltask",
             owner       => $iw_areaowner,
             areavpath   => $iw_workarea,
             command     => "$iwperl $my_script_ipl @dcr_file_list");

then I link the task to the workflow using these codes:

# In the link_review_tasks function.
sub link_review_tasks
{
  ...

  link_tasks('end_review_cycle', 'my_task', $done_label);
  link_tasks('my_task', 'submit', $done_label);

  ...
}

I realized that in the workflow, every attachment is treat as @submit_file, It doesn't tell whether the file is a DCR or not. Is there any indicator in the DCR that can be use to identify it? or is there any function to get the DCR? or do you have any better solution to get all the DCRs into an array? I need to pass the DCR into my script for further processing.

Adam Stoller

Thanks Dixit, for the clarify.

Please correct me if I make any mistake, so that means I will declare my task using the following code:
declare_task('my_task',
             name        => $localizer->format('deploy_task.name'),
             description => $localizer->format('deploy_task.description'),
             type        => "externaltask",
             owner       => $iw_areaowner,
             areavpath   => $iw_workarea,
             command     => "$iwperl $my_script_ipl @dcr_file_list");
then I link the task to the workflow using these codes:
# In the link_review_tasks function.
sub link_review_tasks
{
  ...

  link_tasks('end_review_cycle', 'my_task', $done_label);
  link_tasks('my_task', 'submit', $done_label);

  ...
}
I realized that in the workflow, every attachment is treat as @submit_file, It doesn't tell whether the file is a DCR or not. Is there any indicator in the DCR that can be use to identify it? or is there any function to get the DCR? or do you have any better solution to get all the DCRs into an array? I need to pass the DCR into my script for further processing.

Unless you know what you're doing with the $localizer->format() stuff - I suggest you avoid using it.

You can figure out which of the attached files are DCRs within the externaltask script itself rather than within the WFT - or you can do it in the WFT if you want.

I'd suggest by starting with the path to the file. If it contains "templatedata" followed by two sub-directories followed by "data" there's a very good chance it's a DCR - if it doesn't contain those elements - it's definitely not a DCR.

Once you've gotten past that - if you want to test further - consider looking up the usage for the CLT iwextattr

Make sure you read the perldoc for TeamSite::WFconstructor carefully - so that you are reasonably sure you understand what changes you need to make to the WFT in order to incorporate your desired changes.

preview_local.pdf

preview_server.pdf

waikong

Unless you know what you're doing with the $localizer->format() stuff - I suggest you avoid using it.

Thanks for the remind.

You can figure out which of the attached files are DCRs within the externaltask script itself rather than within the WFT - or you can do it in the WFT if you want.

I'd suggest by starting with the path to the file. If it contains "templatedata" followed by two sub-directories followed by "data" there's a very good chance it's a DCR - if it doesn't contain those elements - it's definitely not a DCR.

This sounds like a workaround... is that mean TeamSite 6.5 doesn't provide a function to get the DCR? Don't misunderstand me, I am not blaming TeamSite, I just trying to look for a standard/proper way to complete the workflow, because too much workaround is a headache for maintainance.

Let me repeat the approach:
1.) loop through the @submit_file list.
2.) check the file path (in workarea)
3.) if file path not equal to "templatedata/*/*/data/" then it is not a DCR
4.) if file doesn't consist the XML element, then it is not a DCR.
5.) else it is a DCR.

Please correct me if you find it wrong. Thanks

ISCBorisB

if file path not equal to "templatedata/*/*/data/" then it is not a DCR

That's true. The reverse statement is not true however. Eg, the File that does belong to "templatedata/Category/Type/data" directory
may or may not be a DCR. True DCR should also have "TeamSite/Templating/DCR/Type" extended attribute with the correct value.

loop through the @submit_file list...

I'm not sure how you are going to get a file list, so just in case...Please note that there are various mechanisms that allow
qualified user to attach Files to the already instantiated Workflow. To get a full list when you need it use TeamSite::WFtask::GetFiles().

waikong

Unless you know what you're doing with the $localizer->format() stuff - I suggest you avoid using it.

Thanks for the reminder, I have replace the $localizer->format() with some static value.

then I do a simple P.O.C, where I create the task to read the attached file of the workflow, and write the filename to the textfile in

drive, and I got these:

7311
7319
\default\main\crmkb\WORKAREA\p1
htdocs\CRMKB\tm_subject_area\promotions\20070118152046234.aspx
templatedata\tm_subject_area\promotions\data\20070118152046234
# Is the path to DCR is completed?

Then my next P.O.C is to test which of the file is DCR, so I came up with this script:

# get the submit file as parameter and process each of files
foreach $arg (@ARGV) {

# split the path name
 my $filename = $arg;
 my @unit = split(/[\\\/]/, $filename);

# cehck is DCT or not
# --------------------------
# [1] = templatedata?
 print "is the [1] = \"templatedata\"? ";
 if ($unit[0] = "templatedata") {
  print "true\n";
# [3] = data?
  print "is the [3] = \"data\"? ";
  if ($unit[3] = "data") {
   print "true\n";
# is it a XML?
   print "it is in XML format? ";
# QUESTION
# ========
# how do we check whether it is a XML format or not?
# is there a standard/best practice to do it?

# if it is a DCR then write the filename into a text file
   open SUBMIT_FILES, ">>D:/submit_files.txt";
   print SUBMIT_FILES "$filename\n";
   close SUBMIT_FILES;
  }
 }
}

My questions are as mentioned in the script:

Is the path to DCR is completed? do we need to add the Y:\...\templatedata...?
how do we check whether it is a XML format or not?
is there a standard/best practice to do it?

waikong

Hi, I figure out a solution, do you guys think this will work?

# get the submit file as parameter and process each of files
foreach $arg (@ARGV) {

# split the path name
 my $filename = $arg;
 my @unit = split(/[\\\/]/, $filename);

# cehck is DCT or not
# --------------------------
# [1] = templatedata?
 print "is the [1] = \"templatedata\"? ";
 if ($unit[0] = "templatedata") {
  print "true\n";
# [3] = data?
  print "is the [3] = \"data\"? ";
  if ($unit[3] = "data") {
   print "true\n";
# is it a XML?
   print "it is in XML format? ";

# read the 1st line
open DCR, $filename;
$xml_header = <DCR>;
close DCR;

# $xml_header = <?xml version="1.0" encoding="UTF-8"?>
if ($xml_header =~ /^<\?(xml).*\?>$/) {
    print "true\n";

# if it is a DCR then write the filename into a text file
    open  DCR_NAME, ">>D:/dcr.txt";
    print DCR_NAME"$filename\n";
    close DCR_NAME;
   } else {
    print "false\n";
   }
  } else {
   print "false\n";
  }
 } else {
  print "false\n";
 }
}

other then that, I having problem to read the DCR as well, in the parameter list, I found that the DCR value is:
templatedata\tm_subject_area\promotions\data\20070118152046234

I tried to use the code above to open it, it doesn't seems working, thus, I am thinking I will append the workarea in front of the DCR value:

$workareapath = "\default\main\crmkb\WORKAREA\p1";
$dcrvalue="templatedata\tm_subject_area\promotions\data\20070118152046234";
$dcr_location=$workareapath . "\\" . $dcrvalue;

Or should I go and find out the exact path of the DCR? (e.g Y:\default\main\...), but I think that is consider hardcode value, where in the future, I affraid it will cause some maintainance issue (such as migrating environment)

Adam Stoller

Hi, I figure out a solution, do you guys think this will work?
# get the submit file as parameter and process each of files
foreach $arg (@ARGV) {

# split the path name
 my $filename = $arg;
 my @unit = split(/[\\\/]/, $filename);

# cehck is DCT or not
# --------------------------
# [1] = templatedata?
 print "is the [1] = \"templatedata\"? ";
 if ($unit[0] = "templatedata") {
  print "true\n";
# [3] = data?
  print "is the [3] = \"data\"? ";
  if ($unit[3] = "data") {
   print "true\n";
# is it a XML?
   print "it is in XML format? ";

# read the 1st line
open DCR, $filename;
$xml_header = <DCR>;
close DCR;

# $xml_header = <?xml version="1.0" encoding="UTF-8"?>
if ($xml_header =~ /^<\?(xml).*\?>$/) {
    print "true\n";

# if it is a DCR then write the filename into a text file
    open  DCR_NAME, ">>D:/dcr.txt";
    print DCR_NAME"$filename\n";
    close DCR_NAME;
   } else {
    print "false\n";
   }
  } else {
   print "false\n";
  }
 } else {
  print "false\n";
 }
}
other then that, I having problem to read the DCR as well, in the parameter list, I found that the DCR value is:
templatedata\tm_subject_area\promotions\data\20070118152046234

I tried to use the code above to open it, it doesn't seems working, thus, I am thinking I will append the workarea in front of the DCR value:
$workareapath = "\default\main\crmkb\WORKAREA\p1";
$dcrvalue="templatedata\tm_subject_area\promotions\data\20070118152046234";
$dcr_location=$workareapath . "\\" . $dcrvalue;
Or should I go and find out the exact path of the DCR? (e.g Y:\default\main\...), but I think that is consider hardcode value, where in the future, I affraid it will cause some maintainance issue (such as migrating environment)

Below is a modified version of your code, in which I have highlighted the significant (IMO) changes and describe them in a bit more detail beneath the code:

use TeamSite::Config;
use TeamSite::WFtask;

(my $iwhome = TeamSite::Config::iwgethome()) =~ tr|\\|/|;
my $iwmount = TeamSite::Config::iwgetmount();
[color=teal]# Generally a good idea to always set the above two variables

my($jobid, $taskid) = @ARGV;
my $task = TeamSite::WFtask->new($taskid);
die "Invalid task '$taskid'" if (!$task->IsValid());
(my $area = $task->GetArea()) =~ tr|\\|/|;
my @files = $task->GetFiles();
# The above is pretty much "boilerplate" code for any externaltask script
# Use the jobid (perhaps) and taskid passed in to create object(s)
# Validate the object(s)
# Extract the areavpath and file list from the task object
# (the tr|\\|/| stuff is to get all DOS-style paths to look like Unix-paths which
#  work on all platforms and make regex coding for paths much simpler)

# At this point here, you could loop through @files, or you could grep it
# In either case you should compare against a regex rather than splitting the 
# path into 'components'.
# The bigger question is what do you do if there are no DCRs associated with the job?
# (I have ideas - but this is still your code, so I'm only modifying the parts
#  you included)

my @DCRs = grep { tr|\\|/|; m|templatedata/[^/]+/[^/]+/data/| } @files;
# In general, the above should be sufficient, as
# all DCRs must exist within that path structure, and
# any files within that path structure should be DCRs
# If you want to test further, I suggest you look into using TeamSite::XMLnode,
# TeamSite:CRnode, TeamSite::XMLparser, and/or TeamSite:CRparser
# If you want to open the file - use "$iwmount$area/$filename" (or something like that)

if (@DCRs){
    open(OUT, '>:utf8', "d:/dcr.txt") || die " 'd:/dcr.txt' ($!)";
    print OUT join("\n", @DCRs) . "\n";
    close(OUT);
}
# That should give you the results you appeared to be looking for 
# in the code you posted.
# What you do from here is your call - have fun.[/color]

waikong

Below is a modified version of your code, in which I have highlighted the significant (IMO) changes and describe them in a bit more detail beneath the code:

use TeamSite::Config;
use TeamSite::WFtask;

(my $iwhome = TeamSite::Config::iwgethome()) =~ tr|\\|/|;
my $iwmount = TeamSite::Config::iwgetmount();
[color=teal]# Generally a good idea to always set the above two variables

my($jobid, $taskid) = @ARGV;
my $task = TeamSite::WFtask->new($taskid);
die "Invalid task '$taskid'" if (!$task->IsValid());
(my $area = $task->GetArea()) =~ tr|\\|/|;
my @files = $task->GetFiles();
# The above is pretty much "boilerplate" code for any externaltask script
# Use the jobid (perhaps) and taskid passed in to create object(s)
# Validate the object(s)
# Extract the areavpath and file list from the task object
# (the tr|\\|/| stuff is to get all DOS-style paths to look like Unix-paths which
#  work on all platforms and make regex coding for paths much simpler)

# At this point here, you could loop through @files, or you could grep it
# In either case you should compare against a regex rather than splitting the 
# path into 'components'.
# The bigger question is what do you do if there are no DCRs associated with the job?
# (I have ideas - but this is still your code, so I'm only modifying the parts
#  you included)

my @DCRs = grep { tr|\\|/|; m|templatedata/[^/]+/[^/]+/data/| } @files;
# In general, the above should be sufficient, as
# all DCRs must exist within that path structure, and
# any files within that path structure should be DCRs
# If you want to test further, I suggest you look into using TeamSite::XMLnode,
# TeamSite:CRnode, TeamSite::XMLparser, and/or TeamSite:CRparser
# If you want to open the file - use "$iwmount$area/$filename" (or something like that)

if (@DCRs){
    open(OUT, '>:utf8', "d:/dcr.txt") || die " 'd:/dcr.txt' ($!)";
    print OUT join("\n", @DCRs) . "\n";
    close(OUT);
}
# That should give you the results you appeared to be looking for 
# in the code you posted.
# What you do from here is your call - have fun.[/color]

Thank you very much, I like your code, and it is really clean.

The reason I write in that way is because I am still doing a P.O.C, so I didn't really spend time to shorten my code.

But I really appreciate your contribution.

So now i shall move on to detect the action-performed (e.g create DCR, update DCR, and delete DCR).

waikong

Use of uninitialized value in numeric eq (==) at d:\app\tmcrm\Interwoven\TeamSite\iw-perl\vendor\lib/TeamSite/WFtask.pm line 871.
Use of uninitialized value in concatenation (.) or string at d:\app\tmcrm\Interwoven\TeamSite\iw-perl\vendor\lib/TeamSite/WFtask.pm line 886.
Use of uninitialized value in concatenation (.) or string at iw_process_dcr.ipl line 16.
Invalid task '' at iw_process_dcr.ipl line 16.

ops, I got the following error while trying to execute the code, it seems like the top 3 error is generated by the WFtask.pm. and the last error is generated by this line:

die "Invalid task '$taskid'" if (!$task->IsValid());

may I ask that, is it normal practice to write the IF statement after the DIE?

waikong

I think I know why it happen, because I run the script in command line without passing in any taskid...

but when I run the script in the workflow, it doesn't generate the dcr.txt
let me try again.

UPDATE
I got it work already. actually the conflicts come from the way I call the script

my $my_script = "$wft_dir/custom-script/dev/iw_process_dcr.ipl";
no strict "subs";
my @my_files = GetFiles;
#my @my_files = (__ELEM__('iw_file') ? sort __VALUE__('iw_file') : ());
#my $my_log = "D:/execute_log.txt";
declare_task('my_task',
             name        => "my_task",
             description => "My Custom Script POC",
             type        => "externaltask",
             owner       => $iw_user,
             areavpath   => $iw_workarea,
             command     => "$iwperl $my_script @my_files");

now I removed the @my_files, then everythings worked fine, thanks ghoti.

waikong

[QUOTE=ghoti]I think you have it - but I'll do a little re-phrasing just in case: Prior to the underlying submit action

I have tested this logic, and it worked! thanks again, now i will proceed to load the DCR into database using my perl script. (due to the fact that my project don't have the data-deploy license).

waikong

Hi, I found that when I plug my custom script into the workflow, the workflow doesn't function properly.

I run the workflow, it works in this order:

add_files
email_author
author_work
metadata
start_review_cycle

waikong

Issue fixed:

refer to External Task

waikong

edited:

if we delete a file from content center, which workflow will be triggered (by the TeamSite original setting)?

Adam Stoller

edited:

if we delete a file from content center, which workflow will be triggered (by the TeamSite original setting)?

There is no workflow directly associated with deletions, except that you can create one and associate it with the command

tt_deletedcr

- but this (according to the documentation) only works for users of CCStd, not for users of CCPro.

If it's possible you'll use both, or likely that you'll be using CCpro only - then that doesn't help you at all - the act of deleting will not initiate a workflow, a deletion will have to be submitted and then there is no difference (from the workflow instantiation perspective) of whether the submission is new files, modified files, deleted files, deleted DCRs, etc. That distinction (if needed) will have to be made within the WFT and/or through user-training if you have more than one possible submit workflow.

alep

How do I delete a file from the server?I can delete the file in the workarea, but the deployed file is still in the server.

MAK

How do I delete a file from the server?I can delete the file in the workarea, but the deployed file is still in the server.

Hi,

Call OpenDeploy as an external task with doDeletes="yes".
Make sure your deleted file is in the list and be careful using "doDeletes".

Regards,

gridhieght.zip