Below are some of the key, high level, points I wish I would have been told about before my first E-Commerce project. The list is not exhaustive and the descriptions are not detailed. However, hopefully you take away some ideas (even if you don’t agree with my suggestions) from this post if you are about to start / in the middle of an E-Commerce project.
07/07/2010 Update: Please read comments posted by Philipp Koock in response to this blog as they highlight some good, differing points of view. One of the very good points he raised related to this blog is that the content is based on my personal experience and the scenarios I have encountered are where E-Commerce is used as a Framework rather than a product. This means that the customers have by choice wanted the shop to be modified and extended beyond what it is able to do out of the box. If you plan to use E-Commerce as a product without major modifications, you can probably ignore some parts of the content below (and also keep a bigger part of supportability 🙂 .
14/01/2011 Update: You can now download instructions and code to port your E-Commerce development to open source by following the blog E-Commerce on open source to make up your own mind about which way you prefer to do your development.
My E-Commerce background
Thought I would share some of my experiences with SAP E-Commerce (Formerly known as Internet Sales). As a bit of background. I have been involved with Internet Sales projects since version 3.x and up until CRM 2007 so maybe you would call it E-Commerce 2007? Both on ERP and CRM and B2B as well as B2C scenarios. I’ll mostly use the term E-Commerce in this post when I am talking about the J2EE web application as provide by SAP, regardless of version (as ECC and CRM versions are called differently and it was up-until 4.0 called ISA).
What is E-Commerce (technically)
SAP E-Commerce is a J2EE 1.4 compatible (mostly) Web Application built on top of the Struts classic framework and a number of other Java Web frameworks.
Apart from the Java web application there are a number of E-Commerce specific RFC enable functions in the CRM or ERP system to expose convenient interfaces for interaction between the web application and the backend.
The functions expose all the product and customer information as well as searching and pricing (from E-Commerce 5.x versions onwards the pricing is accessed through RFC interfaces, which interface with the Java Pricing application (formerly known as IPC) running in the VMC, but won’t go into the pricing elements any further in this post). The catalog indexing and searches happen through TREX in some configurations, but the data is loaded to TREX through RFC function interfaces as well.
12 things I wish I would have known
Over the years I have come to the following conclusions that hopefully will help some of you who are about to start working with this platform or who are struggling with the development for one reason or another:
1. You need Java web application (and preferably some Struts) expertise and experience to be a good E-Commerce developer.
– I have seen a number of cases where the development team has been put together with the idea that all team members must have some SAP experience. This is simply not a requirement for the E-Commerce development. Sure you need someone in the team with CRM/ERP expertise both functionally and technically, but pure Java development skills are irreplaceable and no, you won’t learn sufficiently during the project if you are not already experienced, no matter how much ABAP you have written before, without any guidance from more experienced Java devs.
2. Drop Netweaver for local development and use Tomcat or Jetty
– This statement is a bit unfair to some…we spent probably a total of 400 – 500 hours to actually port E-Commerce to Jetty (different versions over a few projects), but it was worth every hour tenfold! You change a page (JSP) or write some new Java logic and the most it will take you before you can see the results in your environment is a couple of seconds (most of the time it happens immediately). Also, again, Java developers know how to work with Jetty or Tomcat, Eclipse integration is dead easy, stack tracing tools, etc. are readily available, etc. So all in all, this will make you extremely productive in no time whatsoever.
3. Go standard Eclipse for development…
– Again, no need to go through hoops to not have the ability to use the latest and best versions of plug-ins and Eclipse environments and no need to learn any SAP specific NWDE components, just stay standard…it is all you need and most of your team will be yet again used to these tools anyway.
4. SVN or CVS for version control
– This is a point where I must admit it has been a couple of years since I’ve even considered any alternative. Every self respecting developer is familiar with SVN (or CVS) as a robust and generic version control system. It integrates again with all other tools and just works. You can also get it securely hosted on external sites that give you some extras along the way (for example I can thoroughly recommend http://www.codesion.com/ as a robust service and no, I have no commercial interest in Codesion).
5. You need integrated issue management
– For example TRAC is not the most complete solution around, but it is free and open source, it integrates fully with SVN, has ticket and feature tracking in place, comes with Wiki, etc. again a proven solution that works perfectly with E-Commerce development. Obviously many alternatives exist instead of TRAC, but just brought it up as from experience I have seen it used many times over with great success.
6. E-Commerce is not for everyone
– Reality check here if you have not yet started your project. SAP E-Commerce is good for most customers who don’t expose large catalogs or have significant site traffic, but are willing to invest in custom development after the investment into E-Commerce.
You can use E-Commerce for 1 million+ hits a day sites, but only after some relatively heavy tweaking.
E-Commerce does not work for sites that expose large catalogs (for example I’ve seen a catalog with 900 000 items and there were a lot of challenges of which some had to be resolved with non-SAP solutions). I won’t go into detail about what technically stops you from using it with large catalogs, but there are some fundamental architectural choices that have been made along the way that restricts the catalog size to maybe somewhere in the region of 100K items unless you want to invest heavliy into hardware and custom development.
7. E-Commerce is mostly a framework, not a product
– Related to the previous point, but worth mentioning separately. None of the projects I have been involved in or even heard of in detail have used E-Commerce as it is delivered from SAP without extensive custom development. Each customer has specific requirements and the Struts, etc. frameworks are very flexible, but the default E-Commerce implementation is not what most customers would consider as production ready (security, usability, etc.). Obviously this will quickly impact your support arrangements as the boundary between custom and standard codebase starts blurring over time…
8. Do a security audit
– This was a bit of a surprise to us during one of the projects. The customer involved before go-live an internet security company to perform an audit on the E-Commerce site and they found a number of issues that allowed amongst other things cross-site scripting to be performed. I am not saying that they found anything critically wrong with the solution, just that it is worth getting an external audit in place as E-Commerce sites often get exposed to the world.
9. Pricing is very, very complex (and potentially very slow)
– Pricing development, though done in Java in CRM (can be done in Java in ECC now as well I think) is significantly more complex than you would think and with very poor existing documentation or templates as soon as you step out of the simple scenarios.
I have worked in total a couple of years in this pricing space and I still find it quite hard a times as you need to understand quite a bit to get the implementation right. So don’t get fooled by the straightforward E-Commerce development, it does not quite apply to the pricing. On top of this performance can be an issue (on many levels), but won’t go into detail here about it…
– Invest in hardware for your search or replace TREX with some external search engine. This is not to say that it does not work, but more than one customer have had some challenges to get it to perform to the required standard.
11. Servlet filters
– Just find out what they are and how they work. You’ll need them…a lot 🙂
12.You need the source code
– You will be dead in the water if you don’t get your hands on the Java sources for all the standard E-Commerce classes. This is extremely valuable when debugging due to bugs or further development. You just need to have these tools available to you. Of course you should not change standard classes, but you already knew that 😉
Hopefully some of the points have at the very least given you some food for thought. Be critical of everything you read (including the text above) and just use it to help your own thought process…
If anyone has interest I could write some possibly informative stuff about VMC based pricing development. Especially point out some of the non-documented tricks that might get you out of trouble one day 🙂