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

Issue in AddMultipleFiles method

Kannan1

Hi
We tried
$task->AddMultipleFiles(@fileList,"submit");
method to attach multiple to workflow.
Here @fileList ==> list of files to attach(Vpath list).
We also tried
$task->AddMultipleFiles(\@fileList,"submit");
option , But it is not working for me....
Please help on this......

Find more posts tagged with

Comments

Adam Stoller

Hi
We tried
$task->AddMultipleFiles(@fileList,"submit");
method to attach multiple to workflow.
Here @fileList ==> list of files to attach(Vpath list).
We also tried
$task->AddMultipleFiles(\@fileList,"submit");
option , But it is not working for me....
Please help on this......

The second thing you tried, using a reference to the array, is the correct usage of the method - but not knowing how you created the list and what the contents of the list look like it is difficult to know what exactly is wrong.

My gut guess is that the paths in @fileList are not correctly specified as workarea-relative paths, or that you have empty elements or typos within the list such that they reference nonexistent files.

The AddMultipleFiles method was added with good intentions, but it doesn't really handle errors gracefully - you're better off, at least when trying to debug it, to replace it with a loop using AddFile where you can log diagnostic information if any one of the files fail - e.g.:

foreach my $file (@fileList) {
    if (! $task->AddFile($file, $comment)) {
        warn("Unable to add '$file' to task");
    }
}

(I'd recommend a better diagnostic routine than 'warn', but I leave that to you)

Kannan1

The second thing you tried, using a reference to the array, is the correct usage of the method - but not knowing how you created the list and what the contents of the list look like it is difficult to know what exactly is wrong.

My gut guess is that the paths in @fileList are not correctly specified as workarea-relative paths, or that you have empty elements or typos within the list such that they reference nonexistent files.

The AddMultipleFiles method was added with good intentions, but it doesn't really handle errors gracefully - you're better off, at least when trying to debug it, to replace it with a loop using AddFile where you can log diagnostic information if any one of the files fail - e.g.:
foreach my $file (@fileList) {
    if (! $task->AddFile($file, $comment)) {
        warn("Unable to add '$file' to task");
    }
}
(I'd recommend a better diagnostic routine than 'warn', but I leave that to you)

Thanks Ghoti for reply.
$task->AddFile($file, $comment) was worked for me if number of files is less than 900.In my scenario value of $file is taking from an xml file. If it is up to 2000 then it gives internal server error. I tried after increasing time out but it is not working for more than 1100 files. There for I tried with AddMultipleFiles method, here @fileList is list of vpath(file name after work area name) I also tried with “iwaddtaskfile” CLT but it also gives same result. Is there any way to attach bulk amount of files to work flow.

Adam Stoller

Thanks Ghoti for reply.
$task->AddFile($file, $comment) was worked for me if number of files is less than 900.In my scenario value of $file is taking from an xml file. If it is up to 2000 then it gives internal server error. I tried after increasing time out but it is not working for more than 1100 files. There for I tried with AddMultipleFiles method, here @fileList is list of vpath(file name after work area name) I also tried with “iwaddtaskfile” CLT but it also gives same result. Is there any way to attach bulk amount of files to work flow.

Are you doing this in the Task Details screen, an External Task or a CGI Task?

It sounds like you're running into an HTTP timeout issue (this has been posted about before - if I recall, you would need to tweak something in the iwwebd.conf.template to increase he timeout threshold - search and hopefully ye shall find).

Alternatively, again if I recall correctly, if you're using a CGI Task you could try adding a print statement inside the loop to keep the connection alive - something like:

foreach my $file (@fileList) {
    if (! $task->AddFile($file, $comment)) {
        warn("Unable to add '$file' to task");
    }
    print qq(<span style="display:none">.</span>\n);
}

ISCBorisB

...it is not working for more than 1100 files...

In iw.cfg, section [workflow], what is your external_task_add_filelist Settings?

Kannan1

In iw.cfg, section [workflow], what is your external_task_add_filelist Settings?

ISCBorisB,
We are not giving any value to to external_task_add_filelist in iw.cfg. So by default it is true

Kannan1

Are you doing this in the Task Details screen, an External Task or a CGI Task?

It sounds like you're running into an HTTP timeout issue (this has been posted about before - if I recall, you would need to tweak something in the iwwebd.conf.template to increase he timeout threshold - search and hopefully ye shall find).

Alternatively, again if I recall correctly, if you're using a CGI Task you could try adding a print statement inside the loop to keep the connection alive - something like:
foreach my $file (@fileList) {
    if (! $task->AddFile($file, $comment)) {
        warn("Unable to add '$file' to task");
    }
    print qq(<span style="display:none">.</span>\n);
}

Thanks Ghoti for reply.
I am using cgi task , I modified iwwebd.conf.template to set time out. I also tried by using print statement inside loop .But it is not working for me.

ISCBorisB

We are not giving any value to to external_task_add_filelist in iw.cfg. So by default it is true

This is definitely one of your problems.
With so many attached files you have to use external_task_add_filelist=false.

The reason is that with "Add Filelist" set to true WF Engine passes attached Files as External Task Command
Line Arguments. There are therefore two limitations, both Platform/OS dependent: "Too many Arguments" and
"Maximum Command length exceeded".

Note that 'external_task_add_filelist' setting is global. If you change it, all existing workflows may be affected.
You'd have to make sure that CSTask.getFiles() / TeamSite::WFtask::GetFiles methods are used to obtain Attached Files
List wherever needed (eg, you will no longer be able to get attached Files as command arguments)

Kannan1

This is definitely one of your problems.
With so many attached files you have to use external_task_add_filelist=false.

The reason is that with "Add Filelist" set to true WF Engine passes attached Files as External Task Command
Line Arguments. There are therefore two limitations, both Platform/OS dependent: "Too many Arguments" and
"Maximum Command length exceeded".

Note that 'external_task_add_filelist' setting is global. If you change it, all existing workflows may be affected.
You'd have to make sure that CSTask.getFiles() / TeamSite::WFtask::GetFiles methods are used to obtain Attached Files
List wherever needed (eg, you will no longer be able to get attached Files as command arguments)

Thank you ISCBorisB for reply.
I modified iw.cfg with
external_task_add_filelist=false
option but still I have the same issue

ISCBorisB

Thank you ISCBorisB for reply.
I modified iw.cfg with
external_task_add_filelist=false
option but still I have the same issue

I told you you it is "...one of your problems...", not all of them Smiley Happy

Anyway, if I were you I would remove this processing completely from the CGI. Use CGI to collect
required input from the user and then transition to the external Task. Use CGI input there to
make all required attachments.

This way you take Web Daemon out of the picture, do not have to worry about CGI timeouts, do not have
to bother that you print something that will break CGI and so on. Use single file Attachment and log out
liberally to see if it breaks and if it does, what are Error messages etc..

Dynamic Crosstab.rptdesign

Adam Stoller

This is definitely one of your problems.
With so many attached files you have to use external_task_add_filelist=false.

The reason is that with "Add Filelist" set to true WF Engine passes attached Files as External Task Command
Line Arguments. There are therefore two limitations, both Platform/OS dependent: "Too many Arguments" and
"Maximum Command length exceeded".

Note that 'external_task_add_filelist' setting is global. If you change it, all existing workflows may be affected.
You'd have to make sure that CSTask.getFiles() / TeamSite::WFtask::GetFiles methods are used to obtain Attached Files
List wherever needed (eg, you will no longer be able to get attached Files as command arguments)

All of the above is true, mostly accurate (in the phrase "all existing workflows may be affected", it should say "... will be affected"), and best practice - however it only applies to External Tasks and not to CGI Tasks - which is the issue at hand.

However, while I was composing this, I see Boris already responded with some additional good advice, so I'll leave it at that.

Let us know what happens.

ISCBorisB

All of the above is true, mostly accurate (in the phrase "all existing workflows may be affected", it should say "... will be affected"), and best practice - however it only applies to External Tasks and not to CGI Tasks - which is the issue at hand.

However, while I was composing this, I see Boris already responded with some additional good advice, so I'll leave it at that.

Let us know what happens.

We do not actually know that the issue is indeed in CGI. In all this long thread the actual problem manifestation is casually
mentioned once as "it [...] gives internal server error". *Looks" like CGI, but still... That may be a problem with subsequent
external Task with too many arguments.

Further, CGI presumably attaches all these Files to get processed somewhere else. Sure, this "somewhere else" may or may not
have external tasks. If it does though - with this number of Files passed as arguments it will fail for sure. Further still, assuming
reasonably shallow relative path, a number in low one thousand+ range is a very typical tell-tale sign of "external_task_add_filelist"
Problem. Kannan mention ~1100 and that was what promptede my reply.