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

Template to Workflow - Locking Conflicts

Tob

I would like to generate 1 file and update 2 files(Indexes of links) using 3 different templates from 1 DCR. I plan on doing this by initiating a Workflow when a user saves a DCR. The job will end up in an approvers task list for approval.

My question is this. What if more than one person saves a DCR creating multiple jobs before the approver can approve pending jobs? Won't this cause a conflict with the two files I am updating since my Workflow tasks will modify the same file possibly from different Workareas?

Thanks!

Find more posts tagged with

Comments

Adam Stoller

If you have two people editing the same DCR in two different workareas - the second person to initiate the edit will get a warning (just like any other file being edited at the same time in two different workareas) - if this second person chooses to continue editing the DCR despite the warning, then yes - there will be a merge issue when they go to submit it *after* the initial person who edited it finished there submission.

The merge will take place at the raw XML level (i.e. not within the TeamSite Templating UI.

Will this have an effect within Workflow? Depends. If you have any tasks with lock="t" in the attributes, chances are they will seemingly hang waiting to get the lock on the file if it is already locked. Similarly if you use a locktask, you will probably end up travelling through the failure-mode transition (locktask's are definitely preferable to lock="t" in the attributes)

If you get past all that and, somehow, the second user's edits get approved before the first user's edits - and thus an attempt is made to submit the file to staging without having acquired a lock - you will end up with a Resolve Conflicts task (which, unless you look at your To Do List, you will probably not notice [bugs filed])

In this case, the Resolve Conflicts window may be a bit confusing because it will say that there are no conflicts - but if you look at the individual file comments within that window you will see something that says "failed to acquire submit lock".

At this point you basically need to wait until the user with the lock finished their submission, and then try "Continue" to try and gain the lock and get into the *real* Conflict Resolution mode where you have to merge your changes with the first person's changes at the raw XML level.

Whew.

TeamSite Templating will not allow two people to edit the same dcr within the same workarea (you won't get the choice to continue despite the lock)

--fish
(Interwoven Senior Technical Consultant)

Renata

one more thing to consider is that if a dcr is attached to a job, whoever else edits this dcr will not be able to attach this dcr to a new wf, i.e. if you're planningon using tt_data, your changes to dcr may be saved but the workflow will not start as this dcr is already part of another job.

Tob

Do you see any implications with the following scenerio.

I allow users to create DCR's and their cooresponding htm file from the template.

Then, at a certain time, I run a scheduled task which rebuilds the navigation pages based on extended attributes which exist in staging only. Example, If a new htm file is submitted to staging the index page is rebuilt using iwregen and then automatically submitted to staging with iwsubmit.

Adam Stoller

extended attributes which exist in staging only

What does this mean? EA's will exist on the files in the workarea from which they were submitted, in the staging area, and in any workareas that were updated from staging after the submit from the original workarea took place.

If you mean, on submit a script will be kicked off to perform this processing - you could do this with a trigger (see documenation on iwat) or as part of an externaltask within a workflow. The former adds overhead to the server as it will kick off for each and every file that gets submitted, the latter does not add overhead but depends on all the relevant workflows using the same process and nobody using Submit Direct.

A possible adaptation of the above with your original idea would be to use either a trigger or workflow to build up a list of files submitted since the last time you ran your process, and then use that list (stored in a file somewhere on the local disk probably) to determine what index page(s) need to be regenerated.

--fish
(Interwoven Senior Technical Consultant)

Tob

What if I ran a nightly batch job which would read newly created files that have been submitted to staging throughout the day? I could use the iwextaatr to get the name of the dcr.

This would eliminate the overhead of using iwat and capture any Submit Directs.

Adam Stoller

How would you get the list of submitted files?
If you cut an edition before running this process (and keep track of the last edition created using this process) you could use the iwcmp utility to quickly compare both editions and get a list of changed/new/deleted files and then use that to generate the list of files you would need to examine with iwextattr.

--fish
(Interwoven Senior Technical Consultant)

Tob

One of my business rules states that a link on the index page may exist only until the date on one of my extended attributes has passed. Therefore I am not entirely concerned about what new files have been submitted. Only if files in directory X in staging have a dcr with an valid extended attribute date.

So I'm constantly rebuilding my index page from scratch each night. I should have stated this fact earlier.

Thanks!

Adam Stoller

I'd suggest thinking about using DataDeploy / DAS to push metadata such as this to a DB, so your re-indexing script can do a simple query to a DB to retrieve a list of all files that have a given extended attribute of a given value (or range, or whatever).

The overhead of adding a DB to your process should be more than compensated for by the lack of overhead for accessing this information from a DB versus parsing each and every file in your system using iwextattr (if that's what you were doing).

If you don't have a DB / DBA handy at your site - you might look into using Perl: Smiley Very Happy

BI for creating DB-files - but a real DB would probably be better (not my area of expertise, but I've dabbled in it from time to time)

--fish
(Interwoven Senior Technical Consultant)

Tob

I thought about this as well. Then my question is why use Templating at all when I can do the same thing with a form/database soulution?

Adam Stoller

The strenghts of templating are the separation of content creation and presentation, and the power of the presentation engine beyond that separation.

The strenghts of workflow are that you can automate processes to occur based on certain events or in relationship to other parts of a process.

You specifically set up a scenario in which you started with concepts that fit within the realm of templating and then deviated further and further away from it as you responded to the suggestions offered.

Templating is not a panacea - it addresses specific needs and offers a fair amount of flexibility to allow it to be adapted to customer-specific requirements.

You seem to have a process which states that you regenerate the index pages once per day (or on a scheduled basis several times a day) and not directly upon submission.

The use of a database is simply one way to extend / adapt the functionality of Templating to provide data for use in other, perhaps orthagonal, processes.

--fish
(Interwoven Senior Technical Consultant)

sma

how do I use tt_data to avoid a second user to kick off a second workflow. Thanks

Adam Stoller

In IWHOME/local/config/wft/available_templates.cfg - you create an entry for a workflow template(s) that you want to be available for use when someone closes a modified DCR - these use <command value="tt_data"/>

If the DCR that was modified is closed and is *not* part of another workflow - you will be prompted to start a workflow for it.

If the DCR that was modified is closed and *is* part of another workflow - you will not be prompted at all (I believe there's a feature request for better UI on this, but I'm not sure)

Does that answer your question?

--fish
(Interwoven Senior Technical Consultant)

sma

so, if I take out <command value"tt_data" /> from available_templates.cfg, does it mean a second user is not allow to kick off another workflow with the same modified DCR. This is what I really want to to.
Right now, my DCR does not get attach to the workflow, only the output HTML does.

Adam Stoller

No - I think I understand what you're trying to do (from other threads you've posted) - and I don't think you can solve it through this mechanism.

tt_data is a command (the closing of a modified TeamSite Templating Data Content Record) which can be used to trigger the initiation of a workflow. It currently is focused entirely on the DCR - not on any of its potentially generated files.

To do what you want to do - I think you'll have to make use of the iwgetfilejobs CLT and do something within either the WFT or an externaltask or cgitask script associated with the workflow - to verify that none of the files associated with *this* workflow are associated with any *other* workflow.

Check with Support - there may be an already open feature request or bug report on this issue - and if not - you can ask them to open one for you.

--fish
(Interwoven Senior Technical Consultant)

sma

Thanks. Support is looking into it.