Authoring LSCS and Production LSCS DataBases

The Publish LiveSite Content workflow will publish content to both LSDS and LSCS via OD deployment configs.

There is a separate workflow that only publishes to LSCS called the Publish LiveSite CS Workflow.

Thanks for the reply.

My question is little different. I am talking about LSCS DataBase.

TeamSite uses Authoring version of LSCS DB and production portal/server/site uses Production LSCS DB.

As I know, LSCS will be present both on TeamSite and Production.

LSCS is an entity that is composed of multiple parts. I don't think anyone would agree to people looking at the internal LSCS schema that it uses. What are you trying to do?

Anyways, the LSCS entity as a whole is populated by the OD adapter. Including all internal parts.

LSCS is an entity that is composed of multiple parts. I don't think anyone would agree to people looking at the internal LSCS schema that it uses. What are you trying to do?

Anyways, the LSCS entity as a whole is populated by the OD adapter. Including all internal parts.

Thanks. I am inline with you. What does the adapter do internally and how does it deploy to DB, this is what I am trying to understand.

In that respect, whether the deployment mechanism is same in both Authoring and PROD or it varies.

Even I do not personally know the inner details. We consider it as a black box. I know it uses an OD Java Adaptor.

Even I do not personally know the inner details. We consider it as a black box. I know it uses an OD Java Adaptor.

Thank You. I was wondering what mechanism Autonomy follows for deploying content.

Now my question is,

Can we have structure like TeamSite->Preview->Staging->Production.

Both TeamSite and Preview being Authoring environments sharing one LSCS instance.

Staging being a separate entity with a separate LSCS.

And also Production being separate entity with a separate LSCS.

When Previewed it should get deployed to Authoring with Page preview say custom preview.

And with an workflow deployment first to Staging and then to Production. Staging will just act as a mimic of production for the entire site to visulize.

Any obstacles in doing this?

Hi iwstore,

I think it is Iwovs responsibility to properly document the workflows and deploys around lscs. It is a big shame to release it like this. Maybe Alex can comment on this?

Having said this:

the obstacle is that the lscs deploy can NOT be configured to add more deploy targets then the default dev & prod. This is hard-coded in the java-code. :-(((((

It feels, however, that it is possible to configure the 'production' target to deploy to more then 1 lscs-instance, at the same time. This would make sure they would be in sync. So if you want to have your staging & prod to be in sync, this should be possible.

Hi iwstore,

I think it is Iwovs responsibility to properly document the workflows and deploys around lscs. It is a big shame to release it like this. Maybe Alex can comment on this?

Having said this:

the obstacle is that the lscs deploy can NOT be configured to add more deploy targets then the default dev & prod. This is hard-coded in the java-code. :-(((((

HARD CODED?? Where exactly, any information on class name or place where this has been done ? Is it possible to customize?

It feels, however, that it is possible to configure the 'production' target to deploy to more then 1 lscs-instance, at the same time. This would make sure they would be in sync. So if you want to have your staging & prod to be in sync, this should be possible.

No, we don't want to just sync up. We are looking for independent STAGING environment.

Then, whats the significance of below materials ?

1. ts_72_spdev_en_rev1.pdf page numbers 338 to 343

2. https://customers.autonomy.com/support/secure/index.jsp#{"state":{"version":2,"Text":"livesite%20database%20state"},"datasource":"FAQ","operation":"zoom","vstate":{"MatchReference":["/automater/automater_files/docs/FAQ/Interwoven/60255.html"],"oldState":{"state":{"version":2,"Text":"livesite%20database%20state"},"datasource":"allTab","operation":"zoom"},"resultSetIndex":3,"resultSetSize":1152,"links":"LIVESIT,DATABAS,STATE","text":["livesite%20database%20state"]}}

HARD CODED?? Where exactly, any information on class name or place where this has been done ? Is it possible to customize?

com.interwoven.livesite.lscs.impl.LSCSServiceImpl.startDeployment().

Decompilation required.

Then, whats the significance of below materials ?

1. ts_72_spdev_en_rev1.pdf page numbers 338 to 343

I am not sure but given that this relates to database and NOT lscs I feel that this refers to the old-style database storage and NOT to the new-style lscs/idol-storage.

2. https://customers.autonomy.com/support/secure/index.jsp#{"state":{"version":2,"Text":"livesite%20database%20state"},"datasource":"FAQ","operation":"zoom","vstate":{"MatchReference":["/automater/automater_files/docs/FAQ/Interwoven/60255.html"],"oldState":{"state":{"version":2,"Text":"livesite%20database%20state"},"datasource":"allTab","operation":"zoom"},"resultSetIndex":3,"resultSetSize":1152,"links":"LIVESIT,DATABAS,STATE","text":["livesite%20database%20state"]}}

I can read this url. To what document does it refer?

AGAIN, i feel we are left in a hopeless mess by Autonomy regarding lscs-deployments. They are responsible and should step in here!!!

Also, the xml-structure of lscs-authoring (under lsauth-home/authoring\etc\deployment\config) does not look like we can add target-nodes here.

Maybe we are able to set target-nodes PER branch. Some minor/global instruction are included in the lscs-auth reference but a detailed reference on this is missing.

The link which I have given is a Support Article, which talks about adding a new node.

Also, the xml-structure of lscs-authoring (under lsauth-home/authoring\etc\deployment\config) does not look like we can add target-nodes here.

Maybe we are able to set target-nodes PER branch. Some minor/global instruction are included in the lscs-auth reference but a detailed reference on this is missing.

I totally agree with you! Lots of information is missing from document perspective.

Any thoughts or approches or ideas writing own custom startDeployment() method by removing hard code of dev and prod environments and by extending other part of whole process?

Well you could write a wrapper around LiveSiteCSAuth\authoring\bin\startdeploy.bat or com.interwoven.wcm.iwrr.deployment.StartDeployment (rtserver.jar) but this has the same limitations :-) [from the clt-help]:

[PHP]-StartDeploy_DeploymentMode Deployment mode.
production|preview[/PHP]

So you would have to start by re-writing this StartDeployment-class. Which basicly reads the configs and then calls the od-services via soap. Not easy but not impossible either. Whether this is a wise thing to do is another question. ;-)

Thanks Much. Makes Sense :-))

The code has been refactored to allow for multiple LSCS targets, either with 7.2.1 or 7.2.2.

That would be very good news for me.

Is this (properly) documented?

The code has been refactored to allow for multiple LSCS targets, either with 7.2.1 or 7.2.2.

Do you have 7.2.1 or 7.2.2 with you? If yes, could you please verify command LiveSiteCSAuth\authoring\bin\startdeploy.bat -help ?

When I look at document ts_72_spdev_en_rev1.pdf page numbers 338 to 343, I get sense of allowing multiple LSCS targets.

lshi

We start to support multiple LSCS targets in LSCS7.2.2.

In the new lscs-authoring.xml, we are no longer using "preview" and "production" elements for global and branch specific node definition. Instead, we are using generic "runtime" element for runtime node definition and use mode attribute to distinguish the different deployment modes.
For example:
old preview node is defined as:
<preview lscsContext="" lscsRuntimeHostname="" lscsRuntimePort="" destinationArea="" destinationNode=""/>
new preview node is defined as:
<runtime mode="preview" lscsContext="" lscsRuntimeHostname="" lscsRuntimePort="" destinationArea="" destinationNode=""/>

Besides "preview" and "production" modes, user can specify any deployment mode. For example, "demo", "sample" ......
<runtime mode="demo" lscsContext="" lscsRuntimeHostname="" lscsRuntimePort="" destinationArea="" destinationNode=""/>

We start to support multiple LSCS targets in LSCS7.2.2.

In the new lscs-authoring.xml, we are no longer using "preview" and "production" elements for global and branch specific node definition. Instead, we are using generic "runtime" element for runtime node definition and use mode attribute to distinguish the different deployment modes.
For example:
old preview node is defined as:

new preview node is defined as:

Besides "preview" and "production" modes, user can specify any deployment mode. For example, "demo", "sample" ......

Thanks Much. This is a great News.