External Customer Portal – BSP vs Web Dynpro – Odd outcome

Background

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.

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

help.sap.com 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

Outcome

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.

9 Comments

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.

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)

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.

Sounds like you need a reverse proxy then http://en.wikipedia.org/wiki/Reverse_proxyRefer to the Security through Obscurity item in there.http://en.wikipedia.org/wiki/Security_through_obscurityIt’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.

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.

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.

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 http://www.mycompany.com, while the internal translation could point separately to portal.mycompany.net and erp.mycompany.net. 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…