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

LiveSite vs WebSphere Commerce

work4u

We are using TeamSite and SitePublisher to create content and pages for an commerce site. This site has over a millions SKUs and over 2000 hits per second. We are using WebSphere commerce for the Catalog and price management. Also WCS will be use for any transactional pages for add to cart, check etc, functionality. We also have LiveSite.

Q1. Given the amount of traffic can LiveSite handle the load with a user accepted response time.

Q2. Should we just deploy generated jsp pages or .page which is XML and LiveSite needs interaction with the content store if there are DCR referenced.

Q2. Should we use WCS as the fronting application and use the LiveSite library tags to include Livesite content. Is there even any benefit to it. Can we still use Targeting with this model.

Q3. Is there any benefit of using LiveSite at all?

Please if you could provide your point of view and comments. I would really appreciate your help.

Find more posts tagged with

Comments

thatfish

We're been asking very similar questions with our Ecomm site (ATG).

These sound like high level architectural questions which IWOV professional services are best placed to ask. We're treading carefully; going Proof of Concepts small steps with ATG+IWOV planned involvement.

Q1 - set up POC and load test it. Probably a licensing issue and need to increase the LS licenses to required load - assuming you've global server farms watch careful as the LS licensing costs can go through the roof.

Q2 - Depends on your design solution. Assuming you need to keep WS as the primary controller and off load the relevant requests to LS (OOTB both assume they are the main controller - Ecomm platform is the natural choice of primary controller and treat LS/TS as a separate content repository and offload the presentation logic to LS as required).

Q3 - see above - targeting can be maintained. If not then what's the point other than a fancy UI for content contributers.

Q4 - Marketing folks like the UI and I guess Targetting is the big sell, particularly for Ecomm platform. Sounds like IWOV have sold it to your client.

Looks like you need a plan to get to where the client needs to be. I suggest look at where you are now and where you need to be and work out the steps in the middle to get there. We've gone through that recently here and the LiveSite roadmap looks like a 3 year plan.

Hope some of this helps

AlexC

We are using TeamSite and SitePublisher to create content and pages for an commerce site. This site has over a millions SKUs and over 2000 hits per second. We are using WebSphere commerce for the Catalog and price management. Also WCS will be use for any transactional pages for add to cart, check etc, functionality. We also have LiveSite.

Q1. Given the amount of traffic can LiveSite handle the load with a user accepted response time.

Q2a. Should we just deploy generated jsp pages or .page which is XML and LiveSite needs interaction with the content store if there are DCR referenced.

Q2b. Should we use WCS as the fronting application and use the LiveSite library tags to include Livesite content. Is there even any benefit to it. Can we still use Targeting with this model.

Q3. Is there any benefit of using LiveSite at all?

Please if you could provide your point of view and comments. I would really appreciate your help.

Q1. This is hard to answer without concrete requirements. LiveSite scales horizontally which makes it easy to increase capacity once you have more than 1 instance set up (which would imply load balancing in place). If you can determine your requests per second number (RPS) you can then build a configuration which works. The response times are often controlled by the content of the page (if anyone tells you they can get, say, sub 3 second response on all load without knowing the exact content of your page is misleading you). The response time depends on how much dynamic content is on the page, LiveSite has multi-level caching and multi-path rendering which can be fine tuned to a specific requirement.

Q2a. Are you trying to generate the content (with script)? The .page XML is not exposed and subject to change anytime. SitePublisher is meant to be used for creating .page files and associating them with DCRs, etc. You can easily code the pages with controllers and externals to interact with the store as needed.

Q2b. I would recommend avoiding tags unless required by customer, some of LiveSite functionality is limited by the allowed API of the tags. However we have many successful deployments within such an environment. Targeting has also been done within tags.

Q3. There are a lot of benefits over hand-coding pages. Without going into a long list of features, are there specific problems you are trying to solve?

work4u

Thank you so much for the feedback and the comments are very valid. The decision we are trying to make is whether to use LiveSite as the rendering application or WCS. As you mentioned that we will be limiting the capability of LiveSite by using Tags and so should use LiveSite as the main application and use multiple instance to load balance the response time based on our requirement.
In this scenario would LiveSite be also be responsible for the transactional pages? Do we need to build components for “shopping cart” , “check out” etc. using the WCS capability and include the WCS container within LiveSite? What would be the best approach for this? There is also personalization with WCS.
I know there are multiple ways to implement this solution and I am collecting this valuable opinion before deciding on a solution. Once decided I will also share the approach I will taking.

AlexC

You would have to build the components for shopping cart and checkout (and such) that interface with their database and utilize the transactional capability of the database. It is a safer choice to let the database do the transactions rather than rely on a page (and ultimately the page will be doing it through the database but that is yet another level of indirection).

You may even consider an API set for doing commerce that already incorporates transactions, CC processing, shipping, etc and simply create wrapper components around that.

The design is up to you.

work4u

I agree with your response about the components and the use of the DB. But to achieve this functionality it’s more than the use of just the DB. It’s the WCS framework that needs to be integrated with the LiveSite application.
Have you done integration like this or have an opinion as to how complex, stable and scalable such an application would be.
Do appreciate your reply and feedback.

vpatel

I agree with your response about the components and the use of the DB. But to achieve this functionality it’s more than the use of just the DB. It’s the WCS framework that needs to be integrated with the LiveSite application.
Have you done integration like this or have an opinion as to how complex, stable and scalable such an application would be.
Do appreciate your reply and feedback.

Your question is fairly complex to answer on a forum thread. IMHO, you'll probably need a LS Architect to review your requirements and recommend a solution.