Skip to Content

E-Commerce on open source

Hello all!

January 2011, Happy New Year!

Weather here in New Zealand has been a bit of a mixed bag, but when you living in a country like this even rainy days are awesome! (that’s my NZ promotion done for the year).

We’ve been involved with the E-Commerce stack from SAP for quite a few years now (since 2003) and thought we would finally share how we have been able to become very fast at both development, maintenance and troubleshooting of the various flavors of E-Commerce. Let’s call this our New Year 2011 present to the community (and for those of you who do not find the New Year anything special, this is for your next birthday).

Some reasonable pointers to be aware of (sorry, list is quite long):

What we describe below is of course outside the SAP supported way of using NWDS and NWDI and unless you are willing to throw bundles of some good currency our way we will also only support it on an ad-hoc basis because we are nice guys 😉

Saying that, this is solid stuff…used for years at various customer sites and improved many times over (I think we counted about 500 man days spent on building it), if you know your Java development (outside of SAP especially) and understand E-Commerce you should really have this up and running in a day or two at most (don’t feel bad if it takes you longer, just means that you haven’t used some of this stuff before).

We are also very conscious that we don’t thread on SAP’s ownership of the code or copyrights, etc. Please respect them as you would hope others to respect your copyrights. We have gone to reasonable lengths to only provide how-to instructions and you have to insert all the SAP specific parts in there. Of course we could have technically been able to give you a pre-built environment, but we just can’t + this way you actually get a much better understanding of the steps and why they happen.

Don’t use this for Test or Prod environments. Really, this is just for real developers as an alternative local dev. environment to (rocket) boost your productivity tenfolds. Refer back to earlier “not supported” statements…if you ask SAP support a single question about this then you deserve the response you will most likely get 🙂

We, as in “The Sisu Team from NZ” designed and built this environment…we are asking nothing else in return except that you do not present this as your own solution to anyone, don’t try to sell this to anyone, charge a customer for using this or do something else that is not considered good manners…bad karma will follow from such actions…

And last very important point: We are not responsible of what you might or might not break while using this…really…we can’t quite think what you could break using this, but where there is a will there is a way so take care and be responsible for your actions.

Right, now to the business end of this blog…an explanation of what we have done, then the question and hopefully later the details:

Why did we do this?

1. Flexibility:

  • Allows us to use any recent version of Eclipse for development with any plug-ins of our choice as well as any J2EE engine we like (well, at least Tomcat or Jetty).

2. Performance:

  • JSP changes reflected on page as soon as you save the JSP change. 
  • Hot Code replacement meaning that in many cases when you modify Java source code you don’t have to re-deploy)
  • Server restart time in seconds or perhaps a few tens of them (depending on your hardware spec.)

3. Ease of adaptation by non-SAP Java devs.

  • Using standard dev tools and processes (Eclipse, SVN, Jetty, Tomcat) significantly decreases the time it takes for a new resource to become productive + there are tons of documentation and forum support for each used technology and process.

4. Ease of dev tasks and maintenance

  • JSP Debugging available (and local)
  • General source debugging locally (fast)
  • SVN source control easy to integrate with ticketing systems like TRAC giving a very powerful combination

So generally we are just talking about something that is a way lighter, more flexible, easier to learn and faster (we are talking about a big multiplier in performance) environment to do your development in compared to NWDS / NWDI solution.

The beauty of the statements above is that you don’t have to believe us at all, but actually do side by side comparison with whatever you are doing right now and make up your own mind. We would LOVE for someone to show us how to achieve most of these using NWDS or NWDI.

Right, so that was why and partially what we use as well. To keep this blog entry concise we have decided to provide the detailed instructions on our site with the links to the actual files you need (20 page PDF and 17 MB download). 

http://www.sisusoftware.com/ecommerce

Enjoy!

4 Comments
You must be Logged on to comment or reply to a post.
  • I’m doing eCommerce customization regularly and especially the JSP development is a pain in the ***. I really wish there was a new (>1.4.2) less complex and easier maintainable eCommerce coming our way – but for now, I will try your examples.
  • Hi Kalle,

    I’m very pleased to see such information “released” free of charge to anyone in SDN. I hope people really try it out, as per my experience I’ve worked twice using this environment and it really boosts up development.

    Keep it up the good work!

  • Hi Kalle,
    I recently went through your doc and got up and running on Jetty in about 3 days (I only worked on it in my ‘spare’ time and documented screen shots for my team while doing it.) It took less than another day to get our heavily modified version of ISA running.  I’ve also found a site out there mentioning an instance running on Tomcat – have you had any experience using tomcat?  Any reason(s) you chose Jetty?  In our current env we use NWDS+NWDI(linked to Dev only) and then transport via CTS+ from NWDI beyond dev… have you integrated CTS+ with SVN/CVS?  If we plan on staying with NW for the App server in our centralized Dev, QA, and beyond could you recommend how to make that scenario work without NWDI/CTS+ based on your passed experience?  Also since this is not a SAP ‘supported’ way of doing things have you seen any problems there?  (Also anyone else reading this comment beyond Kalle please throw in your two cents if you have used Jetty/Tomcat on your local and NW for Dev and beyond).  My only concerns are that the time savings we get by using the modern tooling and lightweight local env may be counter acted by having to ‘re-do’ our changes in our supported NWDS/NWDI env.  (I doubt this is the case though as it takes about 5-10 min to build, another 6-10 to deploy and then another 15-20 should a restart be needed in NWDS, whereas Jetty is under 1min!!! for rebuild/redeploy/restart)

    Cheers!!

    Mike Altieri

    • Hi Mike,
      quite a few questions there 🙂
      Regarding Jetty / Tomcat:
      We chose Jetty because it is even more stripped down for local dev than Tomcat and is very flexible for configuration if needed.
      Saying that we don’t see any reason why not run it on Tomcat. Thibaut Colar took our instructions and ported it all to Tomcat for their use without any great hickups http://wiki.colar.net/sap_isa_on_tomcat

      We did a comparison for a customer between using this approach vs the SAP standard NWDI based one…numbers weren’t pretty.

      We haven’t integrated this any further with NWDI components, however you could do this probably without great trouble if you planned it a bit.
      It is not difficult to port this back to NWDI at any stage or even to update the NWDI repositories in parallel if desired.

      In our experience SAPs support for E-Commerce and related topics has not suffered because of the environment we use as long as you know your non-standard environments as of course SAP won’t support that. Mainly support is necessary only with what you have deployed in which case how you have deployed it should be irrelevant anyway.

      We always have centralized Netweaver Dev, QA and Prod servers of course. When you have done your local dev you commit to SVN after which we have an ant bulid script that builds a deployment package that can then be when wished deployed to the Netweaver servers.

      Hope this helps a bit…happy to discuss further (with a bit of delay due to workload at the moment).