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

Configuring LSCS deployment

Agarwal

Hello,

I have differnet branches in teamsite each of which corresponds to a country. I have a requirement where we need to configure LSCS deployment for a specific branch/country. So what we want is that, whenever there is a deployment triggered from a UK branch LSCS deployment should be triggered because we have LSCS runtime for UK. But for other branches LSCS deployment shouldn't be trgiggered as we don't have any LSCS runtime configured for them.

Any ideas ?

Thanks
Akshat

Find more posts tagged with

Comments

Rick Poulin

Disclaimer: this solution is borderline supported, as is customizing just about anything with this closed-box LiveSite madness..

In your customer-teamsite-resource-config.xml, override the bean id="lscs.serviceadapter" with your own having id="customer.lscs.serviceadapter". Copy the properties as-is from AppContainer/server/default/deploy/iw-cc.war/WEB-INF/conf/livesite/resources/teamsite-resource-config.xml but point it to a custom Java class which you're going to write. That custom class should extend LSCSDeploymentServiceAdapter by overriding the buildDeployments() method. In this method, if you don't want to deploy to LSCS (based on your own conditional logic), return an empty list. Otherwise, return super.buildDeployments().

* Assumes TS7.2; answer is slightly different in 7.3.

Bowker

I'm confused by your question. It's quite possible that rpoulin's answer is 100% correct (although it made my head swim).

Can you give more details on what you are doing? Is it the case that if you deploy from the "xx" branch (non-LCSC) you want to skip the LSCS deployment but do the rest of the PLC (Publish LiveSite Content) workflow? If that's the case can you add filters to the deployment to disallow the non-LSCS servers?

I may be (probably?) totally off base for what you are looking to do.

nipper

I'm confused by your question. It's quite possible that rpoulin's answer is 100% correct (although it made my head swim).

Can you give more details on what you are doing? Is it the case that if you deploy from the "xx" branch (non-LCSC) you want to skip the LSCS deployment but do the rest of the PLC (Publish LiveSite Content) workflow? If that's the case can you add filters to the deployment to disallow the non-LSCS servers?

I may be (probably?) totally off base for what you are looking to do.

A lot depends on the rev of TeamSite. With 7.3.1, the WF reads to see if the lscs_enabled=true. Then it runs the combination LSCS/LSDS deployments (in conf/lscs). Otherwise it runs the LSDS (conf/LiveSite) deployments. That is a system wide setting, so an unsupported change like Rick's is needed.

Agarwal

Hello,

We are on 7.1 version. We want to trigger the LSCS deploment depending on which branch i am in. Rest of the PLC workflow should proceed as is.

Thanks
Akshat

Agarwal

Thanks rpoulin. Much appreciated.

Any views on the below queries :-

1. If we create a new bean, what would be the triggering point of the bean?

2. If bean whose id="lscs.serviceadapter" is picked automatically as part of deployment workflow, then instead of creating a new bean with a different id, why don’t we use this same bean id & this should point to custom class (which extends LSCSDeploymentServiceAdapter) & override the logic of buildDeployment?

Thanks
Akshat

Bowker

Okay - maybe I'm being a little over simplistic.

Why not just modify the deployment to do nothing for the specific branches you want to exclude?

Put in an exclude filter in the LSCS deployments
...\OpenDeployNG\conf\lscs\teamsite-areadiff.xml
...\OpenDeployNG\conf\lscs\commit-deploy.xml
...\OpenDeployNG\conf\lscs\rollback.xml

The deployments will run, but won't do anything.

Building Crosstab using Parameters.docx

Rick Poulin

This is rapidly going to get complicated, so the following answers assume you have a solid handle on Java and the Spring framework.

1. If we create a new bean, what would be the triggering point of the bean?

The PLC uses another bean containing a list of DeploymentDescriptors to figure out what it needs to do in the deployment step of the workflow. This is the (undocumented) way to add your own deployment tasks into that process, typically by merging your custom list with the existing one. However, you're looking to override an existing one. Luckily, because of the product's history, the LSCS deployment descriptor was externalized as its own bean, and the list of deployment descriptors simply refers to it.

2. If bean whose id="lscs.serviceadapter" is picked automatically as part of deployment workflow, then instead of creating a new bean with a different id, why don’t we use this same bean id & this should point to custom class (which extends LSCSDeploymentServiceAdapter) & override the logic of buildDeployment?

One of LiveSite's extensions of the Spring framework is that whenever it sees a bean with ID "customer.*" at application startup, it deletes the one with ID "*" and replaces it with yours. This allows it to explicitly define which beans will take precedence and avoid the guesswork. However, in this case there's a <bean ref="lscs.serviceadapter" /> which may hold on to the original bean. If that's the case, you will have to set the ID of your bean to "lscs.serviceadapter" and rely on the order of the configs to replace the original one (last file loaded wins). The LiveSite app loads the customer-*.xml last, so this is guaranteed to be the case, it's just less "the way Interwoven intended".

All that said, I think Bowker's suggestion is a valid one, especially if you're not so comfortable with Java and/or Spring, or if you don't want to stray too far from what Autonomy will be able to support. My approach is one that I think is more future-proof (for extensibility and conditional complexity) and allows you to manage the logic automatically in your branch/site's configs, however you're doing it (i.e. without manually maintaining an exclusion list somewhere)... but it's also an approach that Autonomy won't help you troubleshoot.

claudiag

I'm confused by your question. It's quite possible that rpoulin's answer is 100% correct (although it made my head swim).

Welcome to my world. Smiley Very Happy

Agarwal

Ya i know i would be inviting lot of trouble for myself by touching this black box.
To be honest i would first like to go with Bowker's suggestion. But the question that comes to my mind is "whether it would be possible to give absolute exclude path in the deployment definiton" ? If i am not wrong it always takes path relative to the filepath.

Thanks
Akshat Agarwal

Agarwal

Hello,

Can anyone help me in this regard.
Bowker - Any suggestions from you ?

Thanks
Akshat

Bowker

I would say you have two very different solutions. Other than what I've already posted I'm out of ideas. I hope you have a test TeamSite/LiveSite environment to verify whatever you do before moving this into production.

I do know that we went back and forth a number of times here how to configure our workflows and if it wasn't for our test environment we would have been out of luck.

GRD

Unfortunately Dan's suggestion won't work with LSCS as the deployment adapter transfers LSCS context folders and not files/branches like "normal" deployments. So you can't really effectively filter them.

I realize Rick's suggestion is far more complicated, but probably the only way at this point.

This was a topic I asked of Autonomy almost two years ago, and was told that documentation was forthcoming. I have not seen anything yet.

-Greg

Computed.jpg