custom deployment with Deploy Task

Hi Techies,

I have created a workflow with Deploy Task...It is deploying properly from teamsite to runtime.

Now my requirement is like if selected source file is locked then it should not be deployed to runtime.

what and where i needs to configure ? please reply.

Thanks,
Rajesh

Find more posts tagged with

Comments

sheikh1

Now my requirement is like if selected source file is locked then it should not be deployed to runtime.

You can do it by using an external task before your deploy task. Use either perl or java whichever is comfortable for you.
If java implement CSURLExternalTask and overwrite execute method to check if attached files are locked.
You can also do this using preprocessor and postprocessors. More in the workflow documentation about it

ISCBorisB

...requirement is like if selected source file is locked then it should not be deployed to runtime

If you have this luxury, you may want to reconsider your design. You obviously deploy to Production from WAs.
In my opinion, that should be avoided. It is far safer to Deploy from Staging. It is (again IMO) even better
to deploy to Production sites from dedicated Editions.

There are numerous benefits to it. Your contributors may work on the new content version (locks, approvals and all)
without dependencies on current version Deployments. You will automatically have roll-backs (previous Editions), you
are sure that Files will not change or disappear during Deployments and so on.

Anyway, all that aside... Assuming that you have your reasons to deploy from WAs, you may do the following
to satisfy the requirement:

1. The most flexible way is perhaps to code External/URL Task and do desired pre-deploy validation there.
Depending on the results you may then either transition to the Deployment Task or bypass it.

2. Alternatively, you may want to use Lock Task. If it succeeds, you'll transition to Deployment. If it fails,
(it will if some Files are already locked outside of WF) you bypass it, transitioning for example to generate some
form of warning and then terminate job.

The problem with this approach is that you'll have to unlock deployed Files somewhere.

3. Finally, you may want to set Lock flag and Timeout transition on the Deployment task itself.

Beware! It's a dirty trick that may not work. The task will try to acquire TS Locks on all the Files.
If will fail to do so if some Files are locked outside of WF and try again (and again...). Finally,
it *may* timeout to whatever successor you model.

Once again, even if this works you'll have to unlock deployed Files upon success.

LineChartWithYSeriesGrouping.rptdesign

Adam Stoller

FWIW - in my previous project, I created a custom java class / JSP used as a CGI Task in a PLC-variant workflow which ran after the Attach Dependencies task; it processes all the files attached to the task looking for any files that are locked - and then presents those files in a UI that allows the user to select (locked) files to detach from the job (and thus prevent them from getting deployed). All other files are unlocked and processed accordingly with the rest of the workflow.

With regard to Boris' comments on preferring to deploy to production runtime environments from the staging area or edition, the PLC workflow's LSCS (or perhaps LSDS?) deployments have the unfortunate side-effect of modifying EA's on the files that get deployed, which means that [using OOTB processing] you have to deploy those files from the workarea rather than the more preferable staging or edition.