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

Replace iwsubmit with a script?

System

I have an application that integrates with TeamSite in a number of ways, one of which is by calling iwsubmit. The call to iwsubmit occurs in vendor-provided code that I would prefer not to edit. This code interprets any non-zero OS return code from iwsubmit as an error condition. There are two cases where I don't want this to happen - when the file being submitted is the same as the version in STAGING and when TeamSite believes the file in STAGING is newer than the version in the WORKAREA (this happens because periodic regeneration and submission of the entire site occurs in a temporary WORKAREA and the other WORKAREAs on the branch cannot be updated with the newly generated versions). I want iwsubmit not to report the first condition and to override conflicts in the second condition, but again I don't want to modify the vendor code to add the overwrite parameter.

I was thinking of renaming the default iwsubmit command with something else and writing a Perl script to wrap iwsubmit with code to handle the cases above, at least if the user invoking iwsubmit is the user running the other application This is a Solaris TeamSite instance so I don't have to worry about the extension on the file name. I realize that I would have to maintain this modification with each patch/service pack/upgrade, and that longer-term I need to work with the vendor or their code to implement this correctly, but I am wondering if I went this replacement route what other issues I might face or if there is some better way for the short term.

it would be nice if in iw.cfg I could have a flag that tells it not to generate the error in the first case and a key that would specify usernames that should always override on iwsubmit - this is probably how I would implement the replacement script. There could be other solutions as well - I am hoping to get as much feedback as possible before making a decision on the approach.

Thanks in advance,

-John

Find more posts tagged with

Comments

Adam Stoller

Well I think it's clear that this approach has never been officially QA'd and thus is not officially supported - but having said that I don't think you should run into any significant issues doing it this way.

I think a more significant issue, or question, is whether the process that is causing the files to be submitted from another workarea in the manner you described can be changed. In general, using overwrite mode for iwsubmit should be done on a case-by-case basis with a clear understanding of what is being overwritten. Automating it is generally not a good idea.

As for the error being thrown when there are no changes for the file that is being submitted - I suggest contacting Support and asking to be added to the list of interested customers for bug # 45434. Essentially this asks for iwsubmit to either (a) accept something a flag that will change this error into a warning and/or disable generating the warning message altogether, or (b) have a distinct exit status code for this situation so that it can be tested for by the calling script, or (c) both of the above.

--fish
Strolling Prime Minister of no fixed address

Migrateduser

One of the problems is that the presentation templates change. Additionally, some presentation templates have logic in them that checks for the existence of files in different places, so even if a DCR doesn't change the output of the presentation template could if files are added elsewhere in the directory structure. These two issues require periodic regeneration of the entire site.

I'm not really responsible for this implementation - I own the other system that integrates with the CMS and is going to have submit conflicts (the CMS will have submit conflicts too but the the business has approved a modification to override in all submittasks). The CMS was developed by a consulting company with Interwoven PSO involved in the design. I don't know if this is a typical practice but there are two workareas on the same branch that are not supposed to contain the same content - one has CMS contributed content and one has content from my application. I probably would have gone with an approach where content from two child branches was copied to one parent integration branch where regeneration, editions and deployments would occur - then I would have workflows use iwupdate to copy the content from child STAGING areas to parent WORKAREA for submit and that could always override conflicts because nobody should work with the content in the parent branch. I would like to rearchitect the solution but at this point in the project it does not seem to be an option - the consultants have hard-coded branch names in numerous places (such as Perl modules used by presentation templates, workflows, etc.) and it's just too significant a change for a production system to go through in the timeline we have, especially with all the other new requirements that we have to meet.

The temporary workarea is used for regeneration because it needs to process only content that has completed approval and is in STAGING. The changes then need to be submitted to STAGING in order to get deployed to the live site by a scheduled process.

I can't use get latest because the persistent workareas are not supposed to have all of the content in STAGING. Even if I could I couldn't use override to avoid the subsequent submit conflicts because then the changes in the WORKAREA would be lost. I have a script that will get latest on only the files that exist in the workarea (like Get Latest but only gets the files that exist in the workarea) but this won't help with the workflow problem.

Adam Stoller

I don't know if this is a typical practice but there are two workareas on the same branch that are not supposed to contain the same content

No - I'd say that is non-typical and generally wrong - and thus I can see how it accounts for the problems you're having. If I were involved, I'd try to set the record straight with regard to the workareas and branches - good luck.

--fish
Strolling Prime Minister of no fixed address