Forum OpenACS Q&A: Who has Ecommerce 4.6.1 working? On what platform?

I need *proven* paths of least resistance to get an openacs 4.6.3 ecommerce site live.

What OS is it on?

Any tweeking to it, special software versions installed etc?

I've been fighting the openacs learning curve for a while... I think I've reached a second wind, and now my boss (idealist at heart, pragmatic supporter in business for 2 years) is preparing to drop openacs ecommerce by declaring it Vaporware, as this[1] is yet another unexpected hurdle to cross --justified or not in the deduction.

Your suggestions much appreciated,

Torben

1. https://openacs.org/forums/message-view?message_id=158383

Collapse
Posted by Janine Ohmer on
Furfly has several ecommerce sites running successfully, but they are based on ACS 4.2 Classic, using the original ecommerce port.  This probably doesn't help you much as OpenACS and ecommerce have both changed considerably since then, this is about as much encouragement as I can provide.

Berklee Music is also using it;  we did that work sometime in 2002, so I'm not sure what version that was, but it was working ok at that time.

Collapse
Posted by Brad Duell on
I've been involved with a few instances of Ecommerce 4.6.3 via Authrorize.net, which are up and running.

The OS has been Linux, but varies between RedHat and Debian (as well as nsopenssl and squid).

Special tweaking has always been involved (but not necessary to the site running - just business rules of the stores).

That's been the great thing about the toolkit's Ecommerce package - you can tweak it as much as you want.

Collapse
Posted by Bart Teeuwisse on
Torben,

I too, have setup several ecommerce sites. Most of them on OpenACS 4.6. but I don't think that ecommerce is incompatible with OpenACS 5.0. Yes, there are a number of noquote issues in the user interface but the code under the hood should work well.

Maybe you can provide us with some more information about your setup. OS version, DB version, OpenACS version, AOLserver version, openssl version and nsopenssl version.

I do know that AOLserver 4.x requires nsopenssl 3.x which does NOT support outgoing HTTPS connections. That is ns_httpsget and ns_httpspost are not supported at the moment in nsopenssl 3.x.

For ecommerce w/ the authorize-gateway that means that you'll have to use AOLserver 3.x + nsopenssl 2.1.

/Bart

Hi Torben,

Can you elaborate on the reasons why your company is prepared to drop the ecommerce module? Was it mainly due this error message or some other reasons?

I was looking at your site (kingsolar) and I find it pretty impressive.
Thanks.

Collapse
Posted by Tom Jackson on

Torben, I haven't used the current ecommerce setup either, but have hacked much on the original port. What are the issues you are having a problem with? Are there features missing which your boss expects? Or does it just not install?

Ecommerce itself is a very broad area. This module is good for a retail shop, but the backend is more important than the sucky front end, as you can easily create a new frontend. You should also note that every retailer has an infinite desire to customize their site with features, so you constantly have to hack in these features. So even if the package (OpenACS Ecommerce or other) you choose does everything you want when you install it, soon you will discover it's weaknesses.

Torben,

I have had ecommerce fully working with the verisign authorisation test server. Worked pretty much out of the box.

The site was running on RedHat 8.0 with nsopenssl and aolserver ad33.13.

If there was an underlying problem with ssl I would expect the Verisign gateway to be affected also (as I understand it the verisign.so module makes calls to verisign supplied c libraries to make the secure connection and returns the results). I am not aware of the gateway code changing appreciably since 4.5.1 (though Bart and Janine would know much better than I).

I have been looking into authorisations with a UK bank recently and they support XML requests sent via https POST.
Maybe that is an option for you with the payment gateway.

Regards
Richard

Collapse
Posted by Torben Brosten on
Can you elaborate on the reasons why your company is prepared to drop the ecommerce module? Was it mainly due this error message or some other reasons?

Nagita Karunaratne, the boss' concern was mainly due to a series of errors, incomplete features, and undocumented steps, which pushed the project significantly passed the original deadline we set and others' expectations (that we had built up). We should have set up a working test site beforehand, but didn't think it was necessary since others were successfully using it. My mistake.

Hi, Tom. Gladly the backend issues have since been resolved.

For the record, the issues consisted of:

1. issues recorded in the bug tracker. Most are now fixed thanks to help from Bart and a growing number from the community.

2. poor documentation with a different payment gateway that seemed to claim compatibility to authorize.net. Turned out it was *not* compatible for direct access. We've created an ezic.com gateway thanks to help from Bart and EZIC. However, the site uses the authorize.net gateway. note: Ecommerce is limited to using one gateway.

Advantages of each? Authorize.net is the mature, sophisticated choice. EZIC gateway is a simpler, recent implementation. EZIC offers a feature to change the billing message that appears on customer statements, which is useful when setting up vendors with multiple domains. (The refund function has not been tested yet).

You should also note that every retailer has an infinite desire to customize their site with features, so you constantly have to hack in these features.

Customize? Actually, we just wanted to start with a generic running setup and modify later. The generic features are reason enough to choose openacs' ecommerce package. However, it became clear to us that not all ecommerce features ported from aD have been used. Or, if they were, bug fixes did not make it back to openacs.org.

Weaknesses? There's one feature needed before officially announcing the implementation. We're working on a single checkout form that integrates with the existing multipage ordering checkout format, so that the one page form is used for first timers, and the multipage format is used when more than one address already exists for the user. This should reduce end-user usability issues we've encountered. The code will be worked in to 5.x.