One of the questions that I’m asked most often about Technical Architecture is what an Enterprise Portal strategy should look like. How many portals do we need? What should we run on each of them? How should they interact?
I’m going to talk about this – particularly taking into account what seems to be the two most common scenarios: Self Service, and BW – but also taking into account other Java environments like SRM, MDM and Solution Manager.
There are several strategies for EP available, and which one(s) you choose will depend on where you are now as an organisation and where you are looking to go. I urge you to spend some time thinking about this before you choose to implement because it is easy to get right and can be difficult to change your strategy once it is in place.
1) Add-in installation
It is possible to install a Java/EP scenario as part of the installation of the software itself. This used to be the most common way to install the BW Java scenario and still is the most common way to install Solution Manager.
However, in many (most?) scenarios, Add-in installations are not optimal. They became unpopular because in 32-bit environments, running ABAP and EP on the same system cause performance and stability issues. This is less true of modern 64-bit environments where even running on Windows, it’s possible to run multiple SAP instances on one piece of physical tin. In addition, it used to be hard to connect BW ABAP and BW Java together and using an Add-in installation simplified this substantially. This is no longer the case.
The major limitations of Add-in installations are that they are tied to the ABAP instance to which they belong. It becomes hard to restart ABAP quickly as you have to wait for EP to restart too which makes troubleshooting tricky. Plus, if your system grows and you want to separate them out, it’s quite a bit of aggravation.
For Solution Manager, it’s still pretty common to use Add-in installations and since the Java elements of Solution Manager are standalone, this is best practice. For all other environments I would highly recommend to avoid using Add-ins – unless you are looking to do a POC style exercise where you need to get something running as fast as possible.
2) Integrated EP and BW Java
BW Java includes usage types EP and EP Core which means it is very easy to add in additional Business Packages – for scenarios like SRM, MDM and ESS/MSS. This is very attractive for organisations that are looking to minimise system proliferation.
The benefits are clear – fewer portals and therefore less cost overhead. Less time spent patching and parameterising the system and less to go wrong – and only having to configure things like Adobe Document Services once! It is also simple to produce an integrated portal environment which contains Self Service, BW and all other content in a single place.
The downside to this scenario is the same as its upside: a more tightly integrated SAP environment. This can mean that there are dependencies when patching the portal, between the Portal and both ABAP systems connected to it – meaning that you may have to patch BW and ERP at the same time.
In organisations with a small, lean and agile Basis team with good integration to the business, this can be a good thing – especially where there are defined periods of downtime during the year when a patch cycle for all systems can take place. In organisations where the converse is true, it can be hard to agree downtime to patch your systems and they can become stagnant as a result. As usual, you need to decide on your strategy, taking this into account.
The other critical consideration for integration is the volume of users and the amount of memory required. Portals run on J2EE technology and have a limited amount of RAM available to them. The default value is 1Gb and the right value as per Note 723909 – Java VM settings for J2EE 6.40/7.0, is 2Gb. If you follow Note 1044330 – Java parameterization for BI systems, then you can push this as far as 2.5Gb. Even given this, in scenarios with a lot of users and complex BW scenarios, there can not be enough memory to also load the ESS business packages reliably, and stability can suffer.
3) Separate EP and BW Java
The case for separating them out is the opposite of the case for integrating them. Stability in large environments is increased and the problems about landscape dependencies more or less goes away, but for considerations around consumer and producer portals in federation scenarios.
Organisations that have set periods of downtime for separate systems and separate business releases run by different teams will appreciate this flexibility, and probably won’t mind the extra cost of maintaining more tin. If you have a virtualization strategy then this will be even less important as you won’t have server proliferation, per se.
Enterprise Portal strategy requires some careful consideration. Spend your time wisely up front and you will find it easier to have the right level of agility, cost and stability for your organisation.
As a rule of thumb, it’s not uncommon to combine into an integrated environment for several hundred named users. I’ve seen sites with thousands of ESS users and around a hundred BW users on an integrated portal, though the BW scenarios were not processing large numbers of data. If your site has thousands of self service users and hundreds of BW users running complex reports, then you should seriously consider implementing two portals – one for Self Service and one for BW.