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

overright staging with conflicts

guru1

Dear All,
Can anyone tell me how to overwrite a file in the staging area using a workflow?

Find more posts tagged with

Comments

Adam Stoller

Create a modified version of the file in a workarea (or explicitly delete the file in the workarea) and then use a submittask with override='t' set.

You cannot modify files in staging without doing so through a 'submit' operation.

--fish
(Interwoven, Curriculum Development)

akshathp

One (*sort of dangerous*) method could be to use an external task. In the IPL script for this external task you could use TeamSite CLT iwsubmit with -w (override conflicts) option to force write on STAGING.

Remeber, this could be a way for a file that is known as otherwise this could be a very *dangerous* option. Please use iwsubmit with overwrite only if you are sure of the content to be overwritten by new one.

Hope this helps.

Akshat Pramod Sharma
Interwoven Inc.

Migrateduser

So what's the difference in doing what fish suggested and using the CLT instead? Don't they ultimately do the same thing with the override flag set? Why would one be any more dangerous than the other, unless you're referring to a possible "rm *" type of programming error being a possibility because it's a human doing the programming in the external script?

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

james1

They are equally dangerous. The submittask has nice properites, e.g. if the submit fails due to locks, then the task stalls, whereas an external task invoking iwsubmit would have to deal with that scenario explicitly.

-- James

Migrateduser

That's certainly more annoying maybe, but I wouldn't classify it as dangerous. You have the control of skipping or not skipping locks with the CLT as well. I still don't see one being any more dangerous as the other. I would think a submittask simply ends up calling iwsubmit at some point anyway.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

james1

A submittask causes a submit operation to be performed inside of iwserver. It does *not* invoke iwsubmit, or any other CLT!

iwsubmit is a CLT that communicates over RPC with iwserver, requesting iwserver to perform a submit operation.

-- James

Migrateduser

OK, so what does that mean in layman's terms?

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

PageOut.png

result.png

james1

A submittask has the same end result as an invocation of the iwsubmit CLT, but that does not mean that a submittask causes the iwsubmit CLT to be invoked.

Hope that clears things up!

-- James

PageOut.png

akshathp

Well, incase of the iwsubmit CLT if the -w option is hardcoded, it will do force submit on the file with which it is used. So, I wanted user to first decide whether it will suit the requirements.
Ofcourse with proper validation and bit more of a perl porgramming, the script could first evaluate the conflicts and then prompt for user to confirm the force submit or not.
And for this CGI task would be best as it will allow user interaction in browser. But if the idea is to just submit one odd file forcefully to overwrite the STAGING then straightaway this CLT coul dbe used in the IPL script.

Hope this helps.

Akshat Pramod Sharma
Interwoven Inc.

Migrateduser

Yes, that one I understood. Thank you.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

Migrateduser

That makes sense. I just was curious why you implied that using the CLT was that much more dangerous. It appears we all could shoot ourselves in the foot either way if we tried hard enough. Thanks for the response.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

Migrateduser

It should also be noted that a submittask is nicer on system resources since it does not have to exec another process. If you are going to be submitting a lot of files, or running many workflows, and you do not need to perform pre-processing on the files to be submitted (i.e. only submit files with an extension of .txt) use the submittask.

An external task calling iwsubmit has to exec a perl process to start the external task and then exec iwsubmit. This can get expensive.

Adam Stoller

Just in case it isn't clear what the "danger" is - (the performance issues and comparisons between using the CLT and the submittask already having been explained)....

The danger in using overwrite/override mode is that you could potentially overwrite a newer version of an asset with a version that was based on an older version.

I.e. if staging contains foo/4 and the workarea contains foo/3+ and you forcibly submit that file into staging - you will *not* be prompted to merge and subsequently will lose changes that were made earlier between versions '3' and '4' of that file (recoverable via reverting from the history list and re-submitting without the overwrite mode on - but a pain to have to go through) - of course if you're dealing with a binary file - overwrite mode is the only way to go if you know you want to submit an older version of the asset, because you cannot merge binary files.

Hope that clarified rather than confused the issue

--fish
(Interwoven, Curriculum Development)