Design Choices for OpenCms and KonaKart

[lucky]

Hello..

I deployed konaKart and OpenCms(full) on the Tomcat server that came along with KonaKart.exe. And then I deployed the Konakart module in OpenCms and I could see the integration working.

I read the documentation and understood that the integration design based on the assumption that Konakart and OpenCms live seperately.

We are actually planning to come up with a brand new website which is going to use both of these technologies. Design choices we have are as follows.

1) Manage content and shopping cart seperately( Using the integration module)
2) To deploy Konakart front end (JSPs) in OpenCms and tighly integrate with OpenCms

Since this is brand new development, we want to make things simple and planning to avoid SOAP calls as far as possible as both OpenCms and Konakart are going to reside in same company network and probably on the same JVM.

Assuming OpenCms supports Struts framework, ideally we can host all the JSPs that are developed by KonaKart as a module in OpenCms. If we have Action classes in the same Tomcat somewhere in classpath visible to JSPs, they can invoke the KonaKart engine directly.

I just want put this idea in the forum and get the feedback from Gurus at KonaKart and other members using OpenCms integration module.

Any Comments, Suggestions ??.


Thanks

[pete]

Hi Lucky,

Regarding design choice 2, I'd verify the following:

1) Does OpenCms support the Struts framework ?
2) Are there any clashes of jar versions etc. when KonaKart and OpenCms are deployed in the same webapp.

Design choice 2 doesn't give you as much deployment flexibility and may present problems when upgrading either OpenCms or KonaKart, but there is no doubt that it will perform better. A third option that you could consider is to deploy them in seperate webapps and use RMI to communicate to the KonaKart engine.

Good luck,

Pete

[lucky]

Thought I have not proved it, I saw a few articles talking about OpenCms and Stuts integration.

Regarding RMI, I will look in to it and get back to you. Are there any examples to see KonaKart RMI interfaces?

Thanks

[pete]

Regarding RMI, I will look in to it and get back to you. Are there any examples to see KonaKart RMI interfaces?

No, we haven't used RMI yet. So far we've concentrated on SOAP or direct engine calls . I was thinking that you could always implement a wrapper around our engine to provide RMI if you wanted to go down that route.

[lucky]

Thats what I am thinking too.


Thanks for your inputs, i will update you once I complete the Wrapper.

[BoJo]

We would like to achieve a slight variation on this architecture. I agree with Design Choice #1. The twist is regarding Design Choice #2, we would simply like to deploy the KonaKart front end (JSP) or 168 portlet as is (without porting it to OpenCms or equivalent WCM system). The benefits are; 1) we do not have to reproduce the UI funtionality, 2) we would be using a UI supported by the KonaKart community, 3) we get the best-of-breed  e-commerce functionality from KonaKart and WCM functionality from OenCms (or the like).

The problem is that we need the OPPOSITE functionality of the existing OpenCms/KonaKart integration. Specifically, we need "intercept hooks" in KonaKart to call the WCM system for:
1) product lookup and display
2) order data

Further details are listed below.

Questions:

(Q1) Are there any existing efforts to use the KonaKart UI and a WCM component for "product data"?
(Q2) Is there a "intercept hook" for pushing order data to 3rd party components?

Any help is greatly appreciated.

Regards,

Bob


Here are details from a post to magnolia-dev I posted today on this topic (in repsonse to an old thread with Paolo Sidoli:  http://www.mail-archive.com/[email]dev-list@magnolia.info[/email]/msg09229.html):
-----------------------------------------------------------------------------------------------
Paolo,


Sorry I did not see this message some time ago! I have reviewed the documentation, JavaDoc, WSDL, ... I like your approach and implementation. However, I have the OPPOSITE problem. I want to use the KonaKart UI or new 168 portlet functionality for my customers e- commerce site. The proposition is to store the "product pages" and associated metadata in Magnolia/CRX. This gives them the WCM capabilities of Magnolia combined with all the e-commerce features of KonaKart. We would not have to reproduce these UI features in our Magnolia implementation. The question becomes how do we "intercept" KonaKart request for "product pages" and redirect them to Magnolia/CRX?

It has been suggested that we implement replication functionality on Magnolia/CRX to push any "product page" changes to the location expected/used by KonaKart. I consider this a backup approach as I prefer not to have to keep two sources of data synchronized.

We have similar requirement to "intercept" KonaKart operations for persisting order data. We want to also push this data to a 3rd party application.

Any insight/efforts on your part are greatly appreciated.

Regards,

Bob
-----------------------------------------------------------------------------------------------

[paolo]

Hi,

I'm not sure that I completely understand your approach, but here goes :

(Q1) Are there any existing efforts to use the KonaKart UI and a WCM component for "product data"?

The KonaKart JSPs call struts actions which in turn make API calls to the KonaKart engines. You have the source code of the struts actions and so could do your intercepting there.

(Q2) Is there a "intercept hook" for pushing order data to 3rd party components?

The saving of an order is normally initiated from a Struts action so you could use the same approach as above. However we also have callbacks for when an order is saved or changes state. Take a look at http://www.konakart.com/configurationfaq.php#how_can_i_make_something_happen_when_an

Hope this helps,

Paolo

[BoJo]

Thanks Paolo. This has been quite helpful. The basic premise is that we want to use as much out-of-the-box KonaKart functionality as possible. After reviewing the Struts configuration and action classes, we now believe that the best approach is to simply use the KonaKart Admin Web Service (KKWSAdmin.wsdl) to push product information from the CMS (e.g. OpenCms) to KonaKart. This  differs from Design Choice #2 (above) in that we are using the entire KonaKart stack for our e-commerce solution. The CMS environment (e.g. OpenCMS) is only used for authoring product information (images, description, price, ...).

Regards,

Bob