Skip to Content
Author's profile photo Matt Harding

External Customer Portal – BSP vs Web Dynpro – Odd outcome


I’m in the process of building a custom customer Portal for a client.  The overall solution is based on an Enterprise Portal (NW 7.01) fronting ERP (NW 7.01). As part of the confirm phase, one task was to evaluate and choose the appropriate technology available within ABAP to deliver the web application and transactional functionality.

Note – One key aspect for this portal is that the number of potential concurrent users will be quite small; and is by no means anything like an anonymous external facing portal.

Common  Benefits

  • Fully integrated with the SAP Enterprise Portal
  • Both are strategically positioned within SAP – Web Dynpro for ABAP – SAP standard UI technology – Business Server Pages – Underlying technology behind CRM
  • Built in developer tools within se80
  • Significant help available online
  • Reasonable skills availability (and expanding)
  • Flash objects can be leveraged to provide a more Web 2.0 experience

BSP Benefits

  • Fast and lean
  • ABAP’s version of ASP/JSP which has been available since 4.7 (more proven in Internet scenarios than Web Dynpro)
  • Extension framework available to significantly enhance core functionality with reusable components.
  • Any html/JavaScript can be embedded delivering nearly endless possibilities
  • Built for developing any type of web application (including mobile)
  • Possibility to support nearly every browser (including mobile browsers)

Web Dynpro Benefits

  • Mainly model driven (less code, but complex code where required driven by wizards when used by new developers)
  • Skilled developers will increase dramatically over next few years due to standardisation by SAP
  • Based on Model View Controller pattern by default known as a best practice for UI development
  • New visual elements will be continually made available
  • Protected against attack by default
  • Allows integration with Adobe Interactive Forms (if required in the future)
  • Mobile client in development but not currently available (?)
  • Out-of-the-box support for Flash
  • Web Dynpro AJAX features provided out-of-the-box and will be added to continually by SAP (eg. Drag and Drop)

BSP Negatives

  • Out-of-the-box BSP tags are quite basic and limited (BSP is usually customised to meet the visual requirements so this is not really an issue)
  • Application is more open to attack the more customised the solution is (default solution is protected and is more a risk than an issue)
  • Flash supported via open source code and not currently SAP supported code
  • Programming model is not very prescriptive and hence requires good design (MVC is possible)

Web Dynpro Negatives

  • Quite difficult to pick-up for new developers (to do properly)
  • Uses significant bandwidth compared to BSP though Flash layer being built by SAP which may be possible to leverage by customers(?)
  • Very little use of caching on the client, and hence quite a significant delay in starting on some customer’s browsers
  • Significantly more restrictive in UI possibilities

Biggest Decision Factor – Stateless or Stateful talks about stateless and stateful to understand the implications of this decision.  In short, if this was a fully external internet web site; then I’d be pushing for static Portal functionality over BSP, or if needed; BSP stateless functionality only.  Stateful is just not an option.

In this scenario however, all scenarios are for logged in users; and the majority of content viewed is display only data; with just a few transactional style applications.

So what’s nice about Stateful is it’s just so easy to code transactions.  You get locking, you get object persistence without serialisation, and you get the choice to use Web Dynpro.

What’s nice about Stateless is you may slow the system down if you are inundated with users; but at least you’re unlikely to bring the system down due to out-of-memory errors.  The best thing is: if you consider a standard customer; then they are just as likely to be browsing the Portal during tv ads and while their favourite sitcom is running, there is no load on your SAP servers and timeouts can be extended with minimal capacity requirements so they don’t receive a time-out next ad.

I Want to Have and Eat My Cake

So I like stateless for practical reasons and I like programming transactions in a stateful way so I thought, why do I have to settle on just one approach. So the options I put up were:

  • Stateless BSP for all functionality
  • Stateless BSP for display only functionality, and stateful BSP for create/modify functionality
  • Stateless BSP for display only functionality, and stateful Web Dynpro for create/modify functionality
  • Stateful Web Dynpro for all functionality


So my recommendation was that fully Stateful is not an option hence BSP stateless is mandatory.  That said, since customer updates to data are quite infrequent; stateful is recommended for these scenarios.  

Note – By combining Stateful and Stateless in this way, the underlying object model layer can be reused across both applications.  If we were to go a fully stateless approach, models would need to be changed to support serialisation, and/or include various approaches to how Customers change data.

So the only remaining choice is how to implement the stateful transactions… 

A few thoughts helped me here:

  • Based on hacking Internet sites; having a default SAP portal implementation and leveraging SAP Logon Tickets helps substantially, but I can’t help think that BSP exposes you to more risk than a Web Dynpro application.
  • Web Dynpro needs to become a standard part of every developers toolkit hence, as transactional applications are usually more complex, it’s best to have your future support staff confident in developing enhancements.  I believe BSP can be picked up easier by a Web Dynpro skilled programmer than a BSP skilled programmer picking up Web Dynpro.
  • Although Web Dynpro is potentially much slower; transactions can be typically slower than the other reporting style areas of the portal.

So although I thought the portal was heading towards a fully stateless BSP solution; I found myself recommending a hybrid.  Good idea, bad idea.  Obviously every customer is different, but at least if you find yourself recommending this approach in the future; you’ll have a blog you can reference to back you up….Wish I had that now.

One Final Note

So after getting everyone on board with this approach; the visual design’s are just about to arrive, so if visual designers get really creative, it’s quite likely that BSP may be the only possible solution.  Anyway, we’ll cross that bridge when we come to it.

Thanks for reading…

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      Thanks for sharing your decision making thoughts.. They are extremely helpful. At my company, we are currently evaluating eCommerce for CRM. You mentioned CRM in your blog and also talked about custom application.

      Are you exposing any standard CRM e-commerce to the Internet?  If yes, I am assuming a lot of it is Java based WebDynpro (correct me if I am wrong). I am sure there's BSP too here, but not sure.

      Thanks again,

      Author's profile photo Matt Harding
      Matt Harding
      Blog Post Author
      Sorry Kiran.  Nearly all content will be custom due to the nature of Customer Portals being highly optimised for specific customers.  Maybe a future requirement, but to be honest, unless it works out of the box from SAP, I'd be pushing to stay away from Web Dynpro for JAVA in this scenario as I only see this as a fit in large organisations who can afford the associated costs of setting this up (NWDI, cross skilled Developers, etc)


      Author's profile photo Steve Oldner
      Steve Oldner
      Thank you for the nicely done article.  Brief with much supporting information.   
      Author's profile photo Former Member
      Former Member
      HI Matt,
      I have internal BSP application integrated with Portal now we want to expose to internet, so that external vendor will have access, we are using 2 factor authenation and also https communication inside and outside, while testing the application though internet, I used https watch to trace the request and respnse url but in trace we can see all SAP server details and version infromation is exposed, We want to hide this information so it should not exposed otside world and also want to make short url.I will appricate your qucik resonse.


      Author's profile photo Matt Harding
      Matt Harding
      Blog Post Author
      Sounds like you need a reverse proxy then
      Refer to the Security through Obscurity item in there.
      It's fiddly to set up with Apache but possible.  There are good hardware solutions out there I'm sure (which could also offload image files and similar to reduce load on precious server resources).  No quick fix for you as this needs to be part of your overall architecture but isn't hard to add.

      Recommendation - Get someone who's set it up properly(!) before. eg. In a locked down fashion.

      Author's profile photo Former Member
      Former Member
      Hi Matt,

      We are using SAP NetWeaver Portal and SRM SUS,Instead of using Apache, Can we use SAP Netwevaer Portal itself to setup reverse proxy? I think that will solve the issue? Please suggest.


      Author's profile photo Matt Harding
      Matt Harding
      Blog Post Author
      Technically you could use a Portal, but typically the Reverse Proxy sits as a separate server in the DMZ.  Deploying a full Portal though just as a WAS for Reverse Proxy is massively overkill though.  Potentially you may be able to deploy a open-source JAVA reverse proxy on the Portal and redirect back to itself; though:
      a) I don't know what exists that I would run production on;
      b) I wouldn't recommend this.

      Really, best bet is to install a proper Reverse Proxy.  Note - If you are not sure how to protect your servers by hiding these internal host names; I'd recommend getting an expert in.

      I'd recommend posting on the Forums if you want to see how other people have solved this. I'm just going with the most appropriate solution for your problem.


      Author's profile photo Former Member
      Former Member
      In Http trace I found out

      10:11:59 948 0.000 1606 GET 302 25 text/html; charset=utf-8

      The information in the URL should not be generated in the first place.So encrypting will not help ,it must be readable by the browser,
      and if it is it is also readable for a hacker.So we need to find some way to short the URL and also remove the version details.

      It's possible to short the URL in some way?

      Author's profile photo Matt Harding
      Matt Harding
      Blog Post Author
      Hi Vivek,

      I'm not sure exactly what you are trying to do or are concerned with, but it appears by viewing the http that happens when you embed a BSP in the Portal it is quite descriptive and easy to be played with.

      Firstly, SSL will still encrypt the content of the URL (including get parameters) so that's safe from hackers.

      In terms of protecting underlying URL's when the hacker gets a hold of the information and starts playing with it.  They'll need to be logged in to try this (unless your BSP is not locked down properly).

      In terms of your question about removing URL's (or at least changing them) a proxy is definitely a requirement for making this external facing. eg. Apache is fairly straightforward (and free) and will allow you to configure a single external URL and translate it to the internal URL so that the user sees a nice domain name like, while the internal translation could point separately to and Plus anything outside of what you want users to access can be blocked at this point.

      Security like this is definitely something you want to be sure of; especially when exposing BSP to the world.  Thanks for asking...