delayed deployment/submission

jmd

I found some very interesting postings dealing with delayed deployment/submission but I think some points have not been adressed - at least as concern my customer requirements.

Technical environment :
- TS 5.0.2 SP1 NT4
- OD 5.5.1 SP2 Base on NT4 and Receiver on AIX 4.3
- production server : portal infrastructure based on IBM Websphere (not WPS)

Functional environment :
- content = static files (html, wml, pdf, gif...)
- currently 1 branch with 1 workarea
- virtualization : not implemented with Turbo but custom development which provides the same functionality
- publishing : creation of an edition + TS comparison between last and prev editions

The requirements are the following :
a - author has the ability to set a launch date upon a item before submission (not all the items are required to be set a launch date)
b - this launch date could be modified by reviewer during submit workflow
c - reviewer should be able to virtualize the site at a given date (= launch date)
d - at launch date the item must be automatically deployed to production
e - a search for scheduled content should be available through TeamSite GUI (at least 1 criteria = the launch date)

So now where am I ?
a/e - I think of using Metadata Functionality (involving DataDeploy)
b - I think I can handle it with mix of task elements
c - I found nothing about this matter in the previous postings and has no idea
(except I surely need another workarea - can't have 2 versions of a file with the same filename)
d - whatever method I think of (timeout in workflow, OpenDeploy scheduler, OS scheduler..) I come up with the following :
how to be sure that the others items submitted in the Staging since the last publishing (= those which don't have a launch date) are to be deployed at that given date ?
(note that "date" can also mean date(YYYY-MM-DD)+time(HH:MM))

Thanks for your help.

JM

Adam Stoller

slightly reorganized for responding purposes
The requirements are the following :
a - author has the ability to set a launch date upon a item before submission (not all the items are required to be set a launch date)
e - a search for scheduled content should be available through TeamSite GUI (at least 1 criteria = the launch date)
I think of using Metadata Functionality (involving DataDeploy)

DataDeploy's DAS and Metadata Search are not that unreasonable a way to go - unless you really want to roll your own (and/or those solutions don't actually meet your needs - in which case you might consider opening a feature request through Interwoven Support

b - this launch date could be modified by reviewer during submit workflow
I think I can handle it with mix of task elements

I'd think a cgitask would be all you'd need for this, not sure what mix you're thinking of, or why you think you need a mix.

c - reviewer should be able to virtualize the site at a given date (= launch date)
I found nothing about this matter in the previous postings and has no idea (except I surely need another workarea - can't have 2 versions of a file with the same filename)

More refinement / clarification is needed here in order to be able to propose potential solutions:

Are you talking about a date in the past or a date in the future here?

Are you talking about doing this within the context of the workflow, or as a custom menu item, or as a set of instructions that the reviewer could follow in order to do this (probably not too different than a custom menu item, but ...)?

d - at launch date the item must be automatically deployed to production
whatever method I think of (timeout in workflow, OpenDeploy scheduler, OS scheduler..) I come up with the following :
how to be sure that the others items submitted in the Staging since the last publishing (= those which don't have a launch date) are to be deployed at that given date ? (note that "date" can also mean date(YYYY-MM-DD)+time(HH:MM))

There are a couple of issues here:
1) your deployments probably should not be current edition / previous edition, but current edition / last-known-[good]-base-edition

2) the deployment should probably be done as a filelist

3) you still stand the chance of having "old" content overwrite "newer" content on the website due to the delay
Scenario: I modify index.html and delay its deployment until tomorrow. You modify index.html - based on my modifications [no conflict] and deploy it today. When my deployment kicks off - either it doesn't deploy my copy of index.html because it is older than the current version out there, or it overwrites your version of index.html

One thing I've seen done in the past (but have not personally implemented) is a setup where "bucket" workareas or branches are used for the to-be-deployed content and that if there is going to be a delay - the file mods are copied to that "bucket" area. Followup-workflows could be made to verify whether or not a file that is attached to the current workflow is already slated as pending for deployment and "do the right thing" (to be determined) - when it comes time to perform the deployment, the files slated to go (the contents of the "bucket") could be attached to a workflow process that copies them back into the main branch/workarea ("main" as a relative term, not literal) and then submit them and deploy them.

There's probably a lot more detailed information required about the environment and requirements in order to being to truly design the overall process - but I strongly recommend allocating time to design before going head-first into implementation so that you can try to visualize the details that you need to get pinned down and consider what side-effects you may encounter and need to get resolved.

Hope that helps, at least a little...

--fish
(Interwoven Senior Technical Consultant)