Scheduled deployment with PLC workflow

Hendrik2

Hi Experts,

 

Env: Teamsite 7.4.1 Unix

 

Has anyone worked with customizing the PLC workflow for scheduled deployment??

 

The requirement is for users to select a deploy date and time via CGI task. We will have a user task (with timeout link) before the 'Production Deployment' task. Through the workflow API (task->setTimeout), we will dynamically set the timeout of this timeout link.

 

The problem here is the deployment could be scheduled few days in advance, and during this delay period, the files can be modified by any users in the Workarea. Thus, when the deployment tasks activate, the 'modified' files are the ones picked up for deployment.

 

Has anyone worked on similar requirement before??

 

Thanks.

Adam Stoller

I have not tried to modify the PLC workflow in the manner you are talking about, however, I believe there is more than the one problem you noted (which is a general problem for any workflow).

 

There are, if memory serves correctly, three different deployment operations within the PLC workflow, and at least one of them happens within the chain of CGI tasks at the beginning of the process flow.  If you insert a timeout task before that CGI, the CGI will not fire automatically and someone would have to go into the Task Details screen to "Start Input Task" for it.

 

Presumably though, you'd only really want to place the timeout before the Production Deployment task - which would probably work, but then you run into the problem you noted, which is that the files associated with the job could be modified sometime between when they were deployed for preview and when they get deployed for production.

 

The usual solution for that problem is to ensure that all files associated with the workflow are locked when the job begins and do not get unlocked until the job ends - thus users would have to make a conscious decision to unlock the files (assuming they have the ability to do so) in order to change them while the job is in progress... unless they're working through the file system interface (as opposed to the GUI) in which case they probably would never know that the files were locked and the system wouldn't be able to stop them from modifying them.  Also, you would need to make sure that there was a graceful way to abort the job such that doing so would first transition the job to a task to unlock the files before ending.