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

Automating PLC

Adam Stoller

Environment[indent]TS 7.3.1 (not-yet-patched) on W2K8 64-bit[/indent]Scenario[indent]We have a situation where we're pulling in content from, essentially, a news feed - and constructing the SitePublisher files programmatically (it's a bit more involved, but that's the general picture).
These Page files then need to be published to the target servers (Staging + Production).
The desired workflow process has no user-interaction (unless an error occurs in one of the automated scripts, and then there's an error-handling grouptask for that) - including no instantiation interaction (the job would be kicked off with iwmodelc)[/indent]Problem[indent]If I try to just perform the "Publish - Staging" step (URL External Task) without having gone through Attach Dependencies or Attach Deployment Target - the workflow fails (ignore the stupid forum-supplied white-space in the middle of the lines):

Error during task execution: Publish - Staging, message: java.lang.NullPointerException
*** START STACK TRACE ***
com.interwoven.livesite.json.JsonUtils.fromJson(JsonUtils.java:395)
com.interwoven.livesite.json.JsonUtils.fromJson(JsonUtils.java:352)
com.interwoven.livesite.opendeploy.impl.OpenDeploymentServiceAdapter.getDeploymentFileListMap(OpenDeploymentServiceAdapter.java:307)
com.interwoven.livesite.opendeploy.impl.OpenDeploymentServiceAdapter.buildDeployments(OpenDeploymentServiceAdapter.java:243)
com.interwoven.livesite.lscs.impl.LSCSDeploymentServiceAdapter.buildDeployment(LSCSDeploymentServiceAdapter.java:220)
com.interwoven.livesite.lscs.impl.LSCSDeploymentServiceAdapter.buildDeployments(LSCSDeploymentServiceAdapter.java:133)
com.interwoven.livesite.deployment.impl.BaseDeploymentService.buildDeploymentList(BaseDeploymentService.java:178)
com.interwoven.livesite.deployment.impl.BaseDeploymentService.deployFiles(BaseDeploymentService.java:326)
com.interwoven.livesite.workflow.task.DeploymentTask.deployFiles(DeploymentTask.java:100)
com.interwoven.livesite.workflow.task.DeploymentTask.handleExecution(DeploymentTask.java:49)
*** END STACK TRACE ***

If I put back the Attach Deployment Target task (CGI Task - I don't want) - it still fails:

Error during task execution: Publish, message: 0
*** START STACK TRACE ***
com.interwoven.livesite.lscs.processor.BaseAttributeProcessor.preProcessAttributes(BaseAttributeProcessor.java:211)
com.interwoven.livesite.lscs.impl.LSCSDeploymentServiceAdapter.buildDeployment(LSCSDeploymentServiceAdapter.java:269)
com.interwoven.livesite.lscs.impl.LSCSDeploymentServiceAdapter.buildDeployments(LSCSDeploymentServiceAdapter.java:133)
com.interwoven.livesite.deployment.impl.BaseDeploymentService.buildDeploymentList(BaseDeploymentService.java:178)
com.interwoven.livesite.deployment.impl.BaseDeploymentService.deployFiles(BaseDeploymentService.java:326)
com.interwoven.livesite.workflow.task.DeploymentTask.deployFiles(DeploymentTask.java:100)
com.interwoven.livesite.workflow.task.DeploymentTask.handleExecution(DeploymentTask.java:49)
com.interwoven.livesite.workflow.task.AbstractUrlExternalTask.execute(AbstractUrlExternalTask.java:79)
com.interwoven.livesite.spring.workflow.task.DelegatingUrlExternalTaskProxy.handleExecution(DelegatingUrlExternalTaskProxy.java:124)
com.interwoven.livesite.workflow.task.AbstractUrlExternalTask.execute(AbstractUrlExternalTask.java:79)
*** END STACK TRACE ***

(For those of you who notice such things, yes - that task name changed from "Publish - Staging" to just "Publish")[indent]SIGH: They just installed Patch 1 for 7.3.1 and now WFM doesn't work, so I cannot look at the actual WFM to find the details[/indent][/indent]What I'm looking for[indent]Has anyone managed to create a fully-automated (no CGI Task) PLC workflow?
If so, can you share [at least some of] the details?

I will shortly be opening a ticket with Support because I truly despise this "black box" type "solution" from them that prevents folks, like me, from doing what I need to do.

If they want to provide alternative "black box" [URL] External Tasks for this - fine (not great, but okay) - but otherwise I need to know the details of what all those CGI Tasks are doing - at least with respect to the dependencies that the publish (deployment) task requires to function correctly.

[indent]Note: We are *not* doing anything with Optimost for these pages, so we don't need any of those tasks - we just want to push these Page files out without requiring user-interaction[/indent][/indent]

Find more posts tagged with

Comments

Rick Poulin

What I'm looking for[indent]Has anyone managed to create a fully-automated (no CGI Task) PLC workflow?

Closest I've got was to have a few CGI tasks at the beginning to 'prime' all those black box inner variables, and then had the actual deployment part run in the background (urlexternaltask).

You need the Attach Deployment Target task in there. The one you're missing (per the second stack trace) is the Attach Required Metadata task.

The former computes a map of LiveSite deployment target (customer-teamsite-resource-config.xml) to List<CSFile>. This is to support multiple sites in a workarea, that might each deploy to different targets. Whether this is your case or not, the PLC's deployment task doesn't care. It always looks for the computed map, not what's attached to the task. This is why you get stack trace #1.

The latter assigns 'required' metadata to all attached files. This is not really required if you're only doing LSDS, but IS required if you're doing LSCS. The main thing is that it's putting that TeamSite/LiveSite/Id attribute on all files, which is required by the LSCS deployment and is what's causing your ArrayIndexOutOfBounds:0 in the preProcessAttributes (it assumes it's there when looking up CSSimpleFile.getExtendedAttribute()).

Yes, you could build urlexternaltask versions of these, and they'd be as "supported" as any other custom workflow task, but support probably won't ever help you troubleshoot any PLC deployments after that.

Adam Stoller

Yes, you could build urlexternaltask versions of these, and they'd be as "supported" as any other custom workflow task, but support probably won't ever help you troubleshoot any PLC deployments after that.

Well, we'll see what happens with my support case. However, this is where I got with my limited testing thus far:

TASKS	COMMENTS
Attach Dependencies	We don't need this for ourparticular workflow, but I know it can be implemented via CSSDKif / when it becomes required for our process
Check Migration Status	Not sure what this is / does - butI do not believe we need it
Check Untranslated Assets	We don't need this for ourparticular workflow as we are not doing anything with locale /language / tanslation for the content to be processed.
Attach Deployment Target	This appears tobe *the* required piece in order to get Publish -Staging (or Publish - Production) to succeed. We either need anon-CGI "black-box" solution or we need the details of what thisactually does so we can implement our own non-CGI solution.
OptimostExperiments	We don't need this for our particularworkflow as we are not doing anything with Optimost for thecontent being processed.
Validate Files	Not sure what this is / does - but itdoesn't look like we need it to successfully publish content.
Add Required Tags	We don't seem to need this to publishsuccessfully, though as per rpoulin, this may change if we findwe need for the content being published to utilized LSCS.
Transform Taxonomy Files	We don't need this for ourparticular workflow as we are not doing anything with taxonomiesfor the content being processed.
Publish TeamSite Auth	Not sure what this does, but we donot seem to need this in order to successfully publish content.
Publish - Staging	Obiously we need this (and/or it'sProduction counter-part) - but this is a URL ExternalTask andthus is not an issue for us to use in a fully-automated,non-interactive workflow

Garth McMillan

We've not created a fully automated workflow, but regarding the attach deployment target task, it creates a job variable called "deployable.files" (which you could create anyway you want) that includes the runtime to deploy to and the files that go to that runtime in a JSON format.

For example:

Variable name: deployable.files
Variable value: {"LiveSiteRuntime":["images/path/to/image.jpg","templatedata/path/to/dcr.xml","sites/path/to/page.page"]}

As far as your second error, are you running LiveSite ContentServices (LSCS) on your target system?

We had an error (unfortunately, I can't remember if it resembled yours) because we weren't running LSCS on the target server. We had to change the property "lscs.enabled" to "false" in \TeamSite\local\config\lib\content_center\livesite_customer_src\etc\conf\livesite_customer\content.properties (then run build.bat). Then the workflow ran.

Of the tasks you specified, we removed the following (they seem mostly based for LSCS sites - which we aren't using): Check Migration Status, Check Untranslated Assets, OptimostExperiments, Transform Taxonomy Files, Publish TeamSite Auth.

Rick Poulin

FYI..

Validate Files : Last I checked, this makes sure that there are no broken file references attached to the workflow or in that deployable.files map immediately prior to the deployment. The PLC deployment doesn't behave nicely (at least in 7.2.1) if someone deletes+submits a file that was attached to your task, leaving a broken ref in your task.

Publish to TeamSite Auth : The default config does nothing for LSDS, and publishes the content to LSCSAuth if you have it installed and enabled in the wf. With bean configs, you can change the behaviour of this task to push to a 'preview' environment outside of TS if you want. The only difference between this and the final deploy is that this is the CGI version of it. If you had the final deploy task set with TargetNodes=development, then you'd be doing the same thing but system-side.

Adam Stoller

Thanks for the info (Zaarin & rpoulin) - I've got a feature request filed with Support (TS-16162) for non-CGI alternatives for all these tasks.
Hope to have a call with Engineering sometime next week to discuss further...

nipper

Not all information *has* to go through the PLC.

Have you tried a standard WF ? At times when I have a SP project when I needed to do a site refresh I just did standard deployments. If you are looking at straight .page files, it works fine. I would also bounce the web server because of caching, but you can also build up the invalidate cache file for all files you send.

Frederik

(...) because I truly despise this "black box" type "solution" from them that prevents folks, like me, from doing what I need to do.

+1
When it doesn't work, they tell you these are just sample workflows... but try to build your own, and you find that so much of the stuff is not documented :-(
I wish you good luck on the support case. I hope your years of commitment to their product has some weight!

we also looked at this stuff at one time in some detail (ts 7.2.1). Not to make it run automated, but because we were trying to figure out why some tasks execute opendeploy (to LSCS) using the workflow owner, and other tasks run the same deployments using the "LSCS deployment user" that was set at install time. This forces every contributor to be also an od-user with permissions on the LSCS deployments. The PLC black-boxiness was driving us crazy. IIRC, it turned out to depend on whether there was a review task, or not. If there is no review task, then the whole deployment (to development {LSCSAuth, database}, and to runtime {lsds,lscs,db}) happens in a single CGI task, but if there's a review task, then the CGI task only deploys to the backend, and after review an URLExternal deploys to the runtime. Sorry, to go so far off-topic Smiley Wink

Thanks for the useful info sprinkled around in this thread! Smiley Happy

GRD

Ghoti, et al, I share your frustration with the PLC deployments. Once LiveSite came along, it seems the engineering direction was toward using closed Java classes to perform what would otherwise traditionally be done with OD descriptors and human-readable CGI tasks. The closed-source nature of the PLC makes it difficult to extend or alter deployments, or the PLC in general.

LSCS deployments are far more challenging even, but there you at least have a command line tool, startdeploy.sh, which can perform the task. (Ping me if you want to know how to create a file list to pass to startdeploy.sh, to avoid the default comparison-only deployment. It's not well documented, but possible.)

In addition to the required variables mentioned earlier, the other problem is that most of the tasks inherit from a WebTask that requires user input. Thus the workflow gets stuck waiting on input.

In your original post you seem to indicate that LSCS was not involved? If not, then my suggestion would be to create an OD descriptor and new workflow to just publish the .page files directly. The challenge, though, is the cache expiration file. For that, the suggestion would be to create a custom script on the receiver side using the OD Perl library. The script would create the cache expiration file to tell LSDS to expire the page cache.

-Greg