Skip to Content

12 things about E-Commerce (I wish someone would have told me)

Hello all,
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 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…

10. TREX

– 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 🙂






You must be Logged on to comment or reply to a post.
  • Hi Kalle,
    Thanks for sharing your experiences. I have not implemented an E-commerce project but always wanted to know the details of a 'real world' implementation. Reading though you blog made me realize that reading SAP documentation definitely does not give you a complete picture (and discourage me a little bit from venturing into it!!)

    I also look forward to your blogs on VMC based pricing development. Hope you share your experience on that topic as well. 

    • Hello,
      We'll have a look into releasing information regarding the port to Jetty. We would have to release quite a lot of information for this, but are looking into it to see how feasible it would be to create full instructions and also ask SAP if they approve us to release this information on their SDN (I can't see it being an issue, but better ask first).
  • Hi Kalle Pokkinen,

    Thanks for taking time and writing this blog. This will help every to understand how e-commerce works and what are skill set requirement.
    I am looking for some help on end to end guide on how to customize e-commerce JAVA code, incorporate custom BAPI's etc using NWDI.
    Please help me if you can.


  • Although I do agree with the author on some of the points I have object to any recommendations using Non-SAP tools for E-Commerce development. I've been doing SAP E-Commerce consulting/development exclusively for the past 5 years in more than 15 customer projects. The one thing that has greatly improved the ways of working in E-Commerce development was the introduction of the NWDI. Using CVS/SVN and plain Eclipse is just outdated since version 5.0

    There is no officially supported way of getting the sources without an NWDI any more. Plus you will get into lots of trouble with SP upgrade and product upgrades without the NWDI. The product itself, the NWDI, has been greatly improved during the past 5 years and can be setup and configured in no more than 2 days including a developer workstation with its own NW-Java Stack and the Developer Studio from SAP.

    With a little performance tweaking and moderatly up-to-date hardware, system performance will not be an issue any more. Just make sure you've got 2 gigs of RAM or more.

    There's tools available for on-the-fly syncronization of changes from the SAP Developer Studio to the SAP NW-Java Stack which will sync JSP/CSS changes instantly and Java/XML changes with the delay of an application restart (15-30sec)

    TREX as catalog index engine and IPC as pricing engine were also never such a big problem as hinted in this post. When using the IPC, take extensive care of the VMC-parameters and patching of the VMC. The TREX also requires some decent hardware but with todays system performance I haven't seen TREX performance to be an issue for years.

    • Hello Philipp,
      Nice to hear some differing opinions on this topic. Misleading is pretty strong and provocative, but it does show that you are comfortable with your position on this 🙂

      So, I shall respond a bit strong and possibly provocatively as well 🙂

      Before I get into any other point: Have you ever compared the NWDI to these outdated tools like Eclipse and SVN that you mentioned? If you have, please let us know what technologies you used (we use the awesome Jetty server and latest Eclipse builds).

      Note: We are only talking about local dev environments the normal NW servers are in place for centralized dev builds, test and prod of course.

      You must've worked on some very different projects than I have (and everyone who have contacted me directly and expressed their equally similar issues on these points :)). Could also be that you have more in-depth expertise in these areas and issues I have encountered over the last 8 years in this space are due to lack of understanding and expertise.

      I do not quite understand what is meant by "official way of getting the sources"? Could you elaborate on this statement, just so that I understand the context as all the sources are packaged with the class files (open the jars).

      2 Days to get a the NWDI up and running? We get the local environment up and running in less than an hour by a new developer and restarts of the whole server take less than 5 seconds. Actually we can pull it all out from SVN and hit start 🙂

      Saying that using Eclipse (Helios at the moment) and/or SVN is outdated when you talk about Java development on anyones platform is quite strong. What does NWDI offer that makes it so good?

      Stating that TREX and IPC were never such big problems makes me think that you have missed some aspects of E-Commerce in your projects either in catalog size or pricing complexity. Be careful before you make a statement saying that they were never big problems without knowing details of the scenarios where they were problematic.

      One of our customers had to replace TREX completely as it simply did not perform on a catalog with 1 million items and 4000+ categories and SAP could never help them to get it right. If all the IPC performance issues that have been had by the customers are due to lack of knowledge then that knowledge must be very well hidden even from SAP 🙂 (you could sell it to them for good $$ and I could even take you on a project to resolve these issues).

      I might run a comparison set-up of the latest NWDI and our Jetty, Eclipse, SVN set-up if I get the time and try to report it in such detail that we can then jointly compare results (to make sure that I have not missed something useful on the NWDI).

      Last thing on upgrades. Done 3.2 --> 4.0 --> 5.0 ---> 2007 --> 70 upgrades. Please, enlighten me where I get into more trouble with SP's and Upgrades compared to NWDI? Why on earth would I have any more issues with this set-up than NWDI? And how do you know if you don't know how we apply SP's or do upgrades to our local environment or how we have configured this all? Siimilar to the TREX and IPC statements...that you haven't had them doesn't mean that they don't exist.

      Meanwhile, thank you for raising your concerns about the content of this blog. Always nice that people bother to read and make well thought comments on something one produces, even if we don't agree on all points 🙂

      And honestly, I mean it, if you truly hold the key to IPC performance I am more than happy to talk to you more about some available work if you can prove your expertise in this 🙂



      • Hi Kalle,

        I didn't intent to be this provocative. And since you've used up all the sarcasm, I'll try to keep my reply dry and clear.

        First off, I was never talking about SVN/Eclipse as a development environment in general. They outperform SAPs tools in every possible aspect. But SAP did not release the NWDI to compete with them. The NWDI was released to put an end to the development environment chaos that was present when the build tool was still around. Each customer came up with an own collection of tools and this situation is very difficult for consultants and support. This is why NWDI is the only fully supported way of developing SAP E-Commerce since version 5.0

        Same thing for the source code. Sure, you can extract it from the SCA files but that's again not supported. That's just a technical possibility. You can also de-compile the standard source and modify them - technically possible but not supported by SAP.

        I've used the word support so many times now. That's because support is one of the most valuable aspects of standard software. My experience has taught me that most customers would like to stay as close to the standard as possible to receive maximum support from SAP.

        If a customer decides for your completly selfmade development environment, who will support this after you left ? As a consultant, how would you like getting used to a different development environment at every customer ? No one except for the people who set up this particular environment will be able to apply support packages and quickly do further developments. And the fact that it is quickly setup is a result of a huge investment into this environment beforehand.

        Next thing is TREX and IPC. Those two components have worked fine for me and all my customers so far - that's all I'm saying. Never meant to say there's no way to push there components to their limits. Performance of the IPC price calculation has never ever been an issue in any of my projects. And I've had some pretty complex pricing, too. If you want to complain about getting the pricing right - I'll agree on that. This can really be a pain ! But performance - never. Even with a current customer who uses the IPC for extreme product configuration performance is not an issue. Again - I never meant to say performance can't be an issue but you make it sound like no customer runs with IPC although the vast majority does !

        Keep in mind that the IPC is not only the pricing engine of the Web Shop but might also be used in CRM pricing which might increase the load significantly.

        Next thing is the TREX. One component I never had a single issue with except for the fact that it's not failsafe. This has changed with CRM 2007 and the introduction of catalog staging. Not even in large B2C projects have I seen the TREX performance to be an issue.

        Having a million products in the TREX will definitly impact on its behaviour. But that's a very extreme case - and doesn't concern 99% of all E-Commerce customers.

        That's generally my impression on some of your recommendations. You did face some extreme use cases of the web shop and developed extreme solutions. That's cool - I really respect that. But selling it as general advice for all E-Commerce customers is something I have to object to. There is already too much uncertainty and suspiciousness in the market about these E-Commerce components TREX, IPC and NWDI. It doesn't help feeding them with advice gained from 1-million-products-shops.

        Let's try to be honest. I do agree with you on some of the points. Mainly 1, 5, 6, 7, 8
        But keep in mind that there are a lot of customers that do not plan on using E-Commerce as a framework but as a web shop. Colors changed, couple of additional buttons and it's done. And after the consultant left, they want the solution to be well supported by SAP and easily upgradeable. This can only be guaranteed when using SAP tools and keeping the modifications simple.

        Replacing the IPC/TREX is far from simple and requires in depth knowledge of the application. Not even mentioning the maintenance effort over the years. So I'm not saying it should never be done. But it's something one in ever 100 E-Commerce customers might do.

        Maybe you should give the NWDI/Developer Studio another try ? As I mentioned, it's been GREATLY improved since CRM 5.0 was released. You can easily use Developer Studio 7.1 with NWDI 7.0.

        And 64-bit Hardware with plenty of RAM is essential for Netweaver Java-stack and IPC in the VMC. Then you shouldn't run into performance problems any more.

        Best regards,

        • Thanks Philipp, I am very excited to find well structured debate on SDN 🙂

          I must admit that in my reply to you I was partially venting my frustration with SAP in this space...unfortunately just ran into the wrong end of the stick so many times. I shall update the blog to point to your comments as they deserve a proper read by others. Perhaps you could write a blog entry yourself on these points you raised?

          Last point is obviously that I can only speak from experience with my 12 points, and perhaps all the cases I have encountered have required more than a lot of customers request or perhaps we have allowed customers to do things they would not have otherwise wanted to do.



          • Hi Kalle,

            I'm very glad we did come much closer than in our first, emotional replys. Thanks alot for considering to take some of my points into your blog post !

            In the end there will never be the one right way of doing things in E-Commerce and all other SAP products. And it's easy for me to preach because I did work for SAP for most of my E-Commerce time and had perfect access to developers and experienced co-workers. One of the major flaws of SAP E-Commerce from my point of view has always been the lack of a central place where SAP offers all the documentation and tools available for the solution. There's so many brilliant PDFs and notes around - shattered over a dozen locations.

            But you're right. It's about time to create my own blog and substantiate some of my points with good documentation.

          • Hi Philipp,
            just to let you know. You can now download the how to guide to port E-Commerce to open source by looking at the link at the beginning of the article.

            We have now had the opportunity to compare the performance against NWDI (7.0) and apart from lack of functionality in NWDI we concluded that the development overhead was over 3 times larger on NWDI so perhaps still a way to go before NWDI catches up.



          • This is great discussion on the e-commerce for clients planning CRM 7.0 for B2B or B2C.

            I have a questions here. with the new CRM 7.0 ecommerce env being implemented why would some one still need to have ISA in environment?

            With CRM being used as pricing engine, do we still need IPC? if so, why and how that would help enhance the speed of pricing customer specific pricing while customer browsing making configurable product selection scenario.

            I am a functional solution architect, and answer to these questions help me in providing value to my client in deciding the landscape and needed tools. Thank you.

    • I'm also going to re-evaluate NWDI / Dev studio in the next month, I hope that it as improved as much as you are saying, because frankly last time I tried it (when it came out) it was not very usable.

      I also do agree with you that there ARE some good documentation about most things, but it is completely fragmented and on top of that the search feature on SAP help portal does a poor job at finding them (search on SDN is quite a bit better).

  • I arrived to the same conclusions as well ~ 4/5 years ago ... after fighting for 6 months with NWDI.

    1. You need Java web application (and preferably some Struts) expertise and experience to be a good E-Commerce developer.
    - Yeah, and you also need to be able to figure out SAP's custom made UI stuff ..... and better be ready for some very heavy logic-ladden JSP's
    - Not sure why SAP can't adopt some of the better Opensource technologies instead of reinventing the wheel as they did (not too well) in NWDI.

    2. Drop Netweaver for local development and use Tomcat or Jetty
    On top of your great points, I would say WEBAS is not a very good J2EE server for development, it's quite slow(heavyweight), lacks features like JSP debugging support(a must here) and tends to die after too many debug stop/start cycles, on top of that no "standard" IDE integration (other than with SAP developer worspace which is not lightweight either).

    While we still use WEBAS I did write some custom scripts to allow for quick deployment (using the telnet API's), because the stop/deploy/start cycle is just way too slow.

    3. Go standard Eclipse for development...
    Exactly .. actually I would even prefer it not to be tied to any IDE in particular(ant scripts) .... but the fact they used Eclipse in the dev studio is a plus, however why an old version with no external plugins allowed ??

    We used eclipse for the longest time, but for the last 3 years have been using Netbeans, I find the out of the box Java/JSP support to be even better.
    Our productivity using this is way up from using "standard" java tools.

    4. SVN or CVS for version control
    I like my code to be stored somewhere reliable, heavily used, and documented, thank you ... buggy, slow CTS out !
    First thing I did was put this in SVN (also using mercurial a bit)
    and since the build tool(CBS) is crap also very slow and mostly undocumented(never worked for me anyhow) ... we put all that in Hudson as well with (ant build scripts), which is our very nice , simple, no maintenance needed, centralized build server.

    5. You need integrated issue management
    NWDI should have that baked in.
    Here I got Mantis(easy to use) setup and it has been used increasingly for e-commerce and more since.
    Also we setup a wiki, which along others has the links to the myriad of servers, config links etc....

    6. E-Commerce is not for everyone
    Well it can do a lot, but out of the box it's pretty useless, as a ramp up customer I found all kind of very problematic issues:
    - Some of settings allow very low numbers of concurrent users at a time (why setup such a huge system to allow only 5 customers in parallel ??)
    -Some pretty ugly bugs, check that one out:
    - many many undocumented and poorly configured settings ... and, sorry to say,  some just plain bad code (not the majority but some).

    7. E-Commerce is mostly a framework, not a product
    That's my main pet-peeve with ISA.
    I wish SAP would acknowledge that because they seem to truly believe users are going to use it almost "as is", sorry but the default implementation is not very good, definitely dated and quite ugly (besides web UI stuff changes too fast for SAP to keep up).
    So just MAKE it a framework and as such remove ugly things like heavy logics in the JSP's !
    Here, we use Sitemesh(clean templating library) as our front-end, in fact overriding the standard JSP's, so we ARE using ISA as a framework.

    8. Do a security audit
    You would hope it's made for you already ... but we have found some issues there as well.

    9. Pricing is very, very complex (and potentially very slow)
    My current project is called "complex pricing", so I guess it was still not complex enough for our company !
    But yes, it's very, very complex and the implementation choices make it much more complex to use/debug (IPC running on standalone JavaVM's inside the CRM box) ... this is just very impractical. Once again documentation is very poor here as well.

    10. TREX
    - While we got TREX to perform ... replication is still horribly slow for a large catalog(hour+) even though the data gotta be<100MB.
    - Yet another product with poor documentation ... it's possible to make it work wekk ... but some heavy configuration was required.

    11. Servlet filters
    We have been using those quite a lot as well, both for monitoring features and other plug-in features (Ex: sitemesh)

    12.You need the source code
    It is very very useful for debugging at least, and proving SAP when there is a bug !
    It's also very often the only functional "documentation" available.

    • Hello Thibaut,

      First of all thank you for your interesting point of view.

      You point out that : "- Some of settings allow very low numbers of concurrent users at a time (why setup such a huge system to allow only 5 customers in parallel ??)"

      Can you please tell me if and where can I set the number of concurrent users and where can I find more information about this topic.

      Thanks for you help.


  • Hi Kalle,
    Can you share your two cents on the amount of scriptlets (java code) in the JSPs of ISA?  I am just making the switch from a non SAP java world into SAP and feel like I'm going back in time.  Moving forward I'd love to start to push the scriptlets out and use JSTL to clean up our jsps (mostly customized).  But am reading conflicting posts on whether JSTL (even 1.0) is properly supported on Netweaver AS (we are on 7.01SP7) - I saw a post from you a while back commenting that most tags worked for you - can you elaborate at all or is it really just going to be trial and error?
    • That post is from a few years (and SAP versions) ago 🙂

      To be on the safe side I'd say trial & error, but we used a fairly recent version of JSTL recently (sorry don't have access to version info at the moment) in a project without any issues...but did not use all aspects of it so can't be 100% sure.

      You will quickly learn a lot of quirky things about the SAP e-commerce stack...I call them quirky to be polite 😉

  • Kalle - How do you do SP upgrade then? NWDI takes care of SP upgrade very well. I am wondering how you would do it in your setup.

    Earlier versions of NWDI was horrible but I feel it has got stabilized now.

  • Hi Kalle,

    When i try to buy a product based on reward point i am getting follwing Error.

    'Enter numeric value between minimum and maximum value specified'

    How to solve this issue ?