PLC Workflow "Deploy Files"

Environment[indent]TS 7.2.1 on Linux (CentOS 5.5)[/indent]
As near as I can tell, the "Deploy Files" task in the PLC workflow is a CGI Task that uses the command WebTask.do - which I'm assuming is some sort of wonderfully un-documented generic wrapper - that utilizes the following task variables (these settings are what I see at the customer site):

Find more posts tagged with

Comments

nipper

Is TargetNodes really a list of nodes, or a replicationFarm name?TargetNode can be a rep farm. Why not transition immediately - I realize this is a CGI Task, but (having never actually run the workflow myself) what does it do from a UI perspective?It sits there, waiting and provides feedback if it failed.How is the name of the deployment configuration file determined? (hard coded, task-name dependent, ???)It runs the OOTB LiveSite Deployments, reading the variables out of the Java Beans. What other parameters are actually passed along to the deployment (key-value pairs, -inst [does the value matter?], etc.)?See above. -inst is NOT passed. These are sequential, so if you run 5 at the same time, you will see the CGI say waiting. If you kill it, you have hung jobs.

One more point, the deployment bean is called Production (which is also in custom_instantiation.cfg). If you change it to something else (or add a new bean/target called Ghoti), the WF will give an NPE. There is a pain in the **** patch to allow multiple deployment targets.

HTH

Andy

Crsb

I haven't used the OOTB PLC in a while, but if i recall correctly:
The first deploy task in the workflow is a CGI task. i prefer to call this type of tasks a web task to distinguish it from the actual cgi task that uses cgi code and because it uses the webtask.do. this task makes it possible for lscs dependent functionality to work in sitepublisher by running lscs deployment to the embedded preview content services (LSCSAuth-Store). this task is just like every other web task in the PLC workflow, it has a jsp and a java class (bean), the jsp uses ajax to call the java code which in turn invokes StartDeployment.trigger(). this method is documented in one of the lscs/ls/sp docs and it is very similar to the famous startDeploy.sh, parameters such as StartDeploy_DeploymentMode StartDeploy_TsAreaDiffArea..., preview mode is hardcoded to use the lscs deployment configs (all OOTB files under OpenDeployNG/conf/lscs) and it doesn't do a webroot deployment. so for deployment to LS instance, you should be looking at the second deploy task in the workflow.

The second deploy task is a URLExternal task which has a class behind it. this class was developed specifically for the PLC workflow, it invokes lscs deployment, database deployment and webroot deployment. the references to what OD configs to use are in the java code. this task uses the OOTB deployment configs under OpenDeployNG/conf/lscs|LiveSite. it depends on what version of SP you have, the OOTB class/task doesn't do farm deployment, doesn't recognize targets other than the target defined by the installation (production and development), and it doesn't queue deployment in 7.1.x. Making it run farm deployment is as simple as using the targetnode parameter as farm name in the deployment config files, updating odnodes.xml with farm details, and updating LiveSiteCSAuth/.../lscs-authoring.xml production node to use 'localhost' as lscs runtime hostname. queued deployment issues is resolved in 7.2.x. Making the deploy task recognize new targets is long process that is not documented and it requires livesite build. To make livesite deployment work the way i wanted it to work, I ended up decompiling the OOTB class and changing the code to take some extra parameters. To add new target, you won't need custom code, these steps should be enough to add new target to livesite deployment: (assuming you have target in odnodes named "new-target")

1- Add this line to livesite_customer_src/etc/conf/livesite_customer/opendeploy.properties: opendeploy.newTargetRuntimeHome=/lshome/LiveSiteDisplayServices/runtime/web

2- Copy the key="production" entry from /iwhome/TeamSite/httpd/webapps/content_center/WEB-INF/conf/livesite/resources/teamsite-resource-config.xml to livesite_customer_src/etc/conf/livesite_customer/resources/customer-teamsite-resource-config.xml, replace the word "production" with your target name key="new-target"

3- Update the value of the property named "targetDirectory" in customer-teamsite-resource-config.xml with "{opendeploy.newTargetRuntimeHome}"

4- Disabled the livesite database deployment by setting in livesite_customer_src/etc/conf/livesite_customer/database.properties. this deployment is not needed and this change will save you from having to make more configurations.

4-1 Update iwhome/LiveSiteCSAuth/.../lscs-authoring.xml production node to use 'localhost' as lscsRuntimeHostname

5- Run ls build

6- Create a simple workflow with one deploy task similar the production deploy task in PLC, change the target node name to "new-target" and test the deployment to livesite instance.

Keep in mind:

1- these steps worked for me in 7.1 and they should work in 7.2.x. If this doesn't work, you should still be able to figure out what is missing to make it work.

2- the node named "new-target" can be just localhost if you are doing this in your vm and you have LSDS installed on the same machine as TS.

3- if your livesite implementation doesn't use LSCS, then you can just run normal static deployment to lsds webroot.

4- LSDS database deployment is not needed unless you write code to query for data from the lsds tables. this is the deployment that uses the production.database and development.database entries in livesite-database.xml file

5- I apologize for typos, misspelling and editorial errors, this is a long topic and i would need a lot of time to accurately write about it.

Adam Stoller

I haven't used the OOTB PLC in a while, but if i recall correctly:
The first deploy task in the workflow is a CGI task. [...] it doesn't do a webroot deployment. so for deployment to LS instance, you should be looking at the second deploy task in the workflow.

The second deploy task is a URLExternal task which has a class behind it. [...] these steps should be enough to add new target to livesite deployment: (assuming you have target in odnodes named "new-target")

A wealth of information (thanks!) however, most of it stopped being relevant to me once we got past the first paragraph - and I apologize for that because I don't think I fully explained the rationale behind my questions when I originally posted.

The posting stemmed from my coming into a project in which the customer is going from 6.7.1 to 7.2.1 and another team is doing the actual development work. They filed a case with Support about not being able to have the CGI Task deployment process run by the task owner, which is/was an issue for them because they didn't want to have to register every single TS user as an OD user and have to continue to maintain that relationship as people come and go. So they changed the task owner to be a generic account which was registered with OD - but the deployments continued to be run as the job owner rather than the task owner, and most of their users who were authorized to run the job were not authorized to run deployments, and so it kept failing there.

I - naively - came in and started with talking about disabling the OD authentication checking via deploy.cfg - then we found out that the CGI Task's deployment process was using web services which doesn't care about the setting in deploy.cfg.

I then - still naive since I haven't done anything with PLC before - suggested that they change from the CGI Task using these mysterious classes and beans to a simple Deploy Task - or a Deploy Task with a custom class that extends the DeployURLExternalTask class, thinking that it wouldn't be too difficult to transfer the task variable information from the CGI Task to the Deploy Task. I was wrong :-)

It became apparent when looking at the limited list of information associated with the task variables on the CGI Task and comparing that to the parameters expected by the deployment configuration files, and then extracting out the actual values used from a bunch of deployment log files .... that there was a lot more going on than I had originally thought, and the idea of reverse-engineering it all in order to implement a custom solution that didn't use the web services seemed like a bad idea (most of this was realized after I made the posting)

Ultimately we decided to create a script to parse the tsusers.xml file and make sure that every entry in there had a corresponding registration with OpenDeploy (using iwodauthorize) so that we can go back to using the original WFM and concentrate on some other issues.

It would be nicer though if Autonomy just handled it via either a standard DeployTask or an enhanced DeployTask (which doesn't use web services) rather than creating a CGI Task that seems questionable (does it really provide any significant UI experience for the user?).

I'll leave the thread open in case anyone wants to comment on the above - or (more likely) wants to follow up on the wealth of information that you (Crsb) posted.

Thanks again.

nipper

I assume they are using LSCS, from my experience this only happens on LSCS deployments and not LSDS deployments. I never saw this until I turned on LSCS and got it a bunch.

Crsb

I don't think it is a big deal to maintain deployment access as you add and remove TS users since this is done from the user configuration UI in TS. they have to click on many things to add a user, they might as well click on one more radio button, especially that they don't seem to care about deploy access and they just want anyone to be able to run deployment using a generic user.

I can't see how deployment would run as job owner rather than the task owner unless the task owner is still $IW_USER. The only other explanation i can think of is TS somehow updates the cgi task owner on the fly with whoever clicks on the button (start input) or is actually running the task rather than who is the owner of the task in the job specs. I thought about doing this before too and i run the deploy task as iwui, but i don't like how it causes all deployed files to have iwui as the last modified by, this would cause a lot of confusion to the users. I have a case open with Autonomy support to help me stop lscs deployment from updating the useless DeploymentAudit EA. you can still try doing this by converting that cgi task to URLExternal task (copy production deploy task) and change the target node to development, the task will run as whoever is configured to be the task owner.

In 7.1.x, I run into 2 permission related issues when users run the OOTB PLC deploy tasks. I resolved one by giving every user "access to all deployments", this is configured from the admin UI when a user is added. Users with master role had to be added manually as od-admins because a master isn't automatically added as od-admin/user (in 7.1.x). The other issue was related to updating the useless DeploymentAudit EA, the user had to have permission to modify files or at least set EAs in the workarea they are running the deployment from.

Adam Stoller

I don't think it is a big deal to maintain deployment access as you add and remove TS users since this is done from the user configuration UI in TS. they have to click on many things to add a user, they might as well click on one more radio button, especially that they don't seem to care about deploy access and they just want anyone to be able to run deployment using a generic user.

No, but they were using their own script interface to add users, both to the OS (for now, until we get the LDAP thing figured out), and to TS - I've since given them a script to put the lists in sync between TS and OD, and they'll probably just add a call to iwodauthroize within their existing script for adding users. I agree, it's not a big deal; they were just trying to avoid the extra step.

I can't see how deployment would run as job owner rather than the task owner unless the task owner is still $IW_USER. The only other explanation i can think of is TS somehow updates the cgi task owner on the fly with whoever clicks on the button (start input) or is actually running the task rather than who is the owner of the task in the job specs.

I cannot really comment on this in detail as I was not involved in their diagnosis of the situation - I'm simply acting on the information I was provided.

I thought about doing this before too and i run the deploy task as iwui, but i don't like how it causes all deployed files to have iwui as the last modified by, this would cause a lot of confusion to the users. I have a case open with Autonomy support to help me stop lscs deployment from updating the useless DeploymentAudit EA. you can still try doing this by converting that cgi task to URLExternal task (copy production deploy task) and change the target node to development, the task will run as whoever is configured to be the task owner.

I started looking into this, but there appeared to be a lot of variables (in general terms and specifically in terms of OD key/value pair parameters) that I simply did not have quick-and-easy answers for figuring out how to translate into code that would work for a vanilla DeployTask or for a custom extension of the DeployURLExternalTask class. Authorizing all the users to be able to run the deployments seemed the most expedient and lowest risk alternative.

In 7.1.x, I run into 2 permission related issues when users run the OOTB PLC deploy tasks. [...] The other issue was related to updating the useless DeploymentAudit EA, the user had to have permission to modify files or at least set EAs in the workarea they are running the deployment from.

Hmm - don't know anything about that. It wasn't brought up as an issue from the customer. However, I'm assuming that isn't an issue since having all the users be able to run deployments seems to be working (no errors about being unable to modify EAs). It's interesting though - I may have to check into that.

Thanks again for the wealth of information. One of these days I might actually "learn" SP/LS (and it's associated PLC workflow) ... ;-)

itsamb

Hi,

I getting an issue of data deployment. Scenario is something like when I create new DCR and deploy using PLC workflow all goes well and workflow inserts data in respective tables. No if I again deploy the same DCR with/without update using the PLC it is deleting entries from one table and in other tables it is performing well. And workflow also completes without any error. The deletion of rows is directly impacting to our application. Please let me if you have any solution/suggestion for such issue.

Thanking you.
Amit

CAM00265.jpg

CAM00264.jpg