In my previous Implementing the Refrigerator, I began a discussion about NetWeaver landscapes. I talked about the need for long-term planning early on in the landscape design process, mainly because NetWeaver offers so much flexibility. Recently, I had an email discussion with one of our Solution Engineers that offers another example of the flexibility of NetWeaver.
It seems that one of our competitors is fond of pointing out the number of databases necessary with SAP and how their products can all run in a single database instance. Our SE wanted some fodder on how to rebut such a claim. Well, with NetWeaver you can run everything in a single database, too. Or not. It all goes back to this ESA stuff, actually. How compliant with ESA do I want to be? With NetWeaver you have the option to both scale up and scale down.
In a presentation I did at TechEd in San Diego (link to download, session NW105, requires logon) and the recent ASUG Technical Conference (link to download, session 1412, requires logon), I showed some slides with some sample landscape designs with NetWeaver. There is a slide that shows a CRM system and ERP system wrapped by a Portal and SAP XI. Then, there is also a separate internet sales application and a web server in front of that. Looks like a lot of systems, and a lot of databases, too! However, the slide is conceptual, not explicitly technical. For example, the ERP and SCM systems could be SAP, or they could be 3rd party. Same with the Portal and XI (although hopefully, not XI!). The Web AS has a single database and is running a catalog, a java app and the IPC. Many of these components can be combined on a single system (box) or even database (MCOD) if you wish. The point is to understand these options and then design/implement accordingly. Although there are many technical possibilities — like running everything on one box — there are very solid reasons for not running everything in one box. I’m sure the tech types at the competition would admit this as well. NetWeaver offers the possibility of combining may things, and the flexibility to design accordingly (in fact, that is what the slide is trying to point out — separate systems by type of function, then you have the most flexibility to purchase the correct db/os/hardware for the function, build security zones, HA, etc.).
Ok, so, could you run it all in one database? Sure you could. Let’s go a little deeper for the best understanding. Right now, a Web AS (6.40) installation includes both the OLAP and OLTP parts already in the database. More simply, a Web AS installation includes all of the BW tables and code — you can log into the system and go to transaction RSA1 (BW Admin Workbench). What it doesn’t have is BW content. To make it a full-blown BW-functioning system the BW content add-on must be installed. But, once this is done, the WebAS system contains a complete BW system as well. This means that applications built on top of WebAS 6.40 can take advantage of this functionality if they want. And it can be done in any desired manner as well. That means you can run the BW system in the same instance as your mySAP ERP system, run it separately, or some combination thereof. Eventually all NetWeaver components will be like this. It’s like the old R/3 days; just activate what you’re using.
Let’s take the example of running them both in the same system. Right now, the technology we use is MCOS– multiple clients in a single system. The BW and ERP systems are each in their own client within a single database (and a single database schema). From a technical point of view, the systems are logically separate, so the technical part of BW has not changed (i.e. extractions).
(BTW, for us old basis types, this used to be a sin. That is, running OLAP and OLTP in a single database (whether MCOD or MCOS) was just not done, mainly for tuning reasons. With the latest vendor releases of databases, faster operating systems, and so on, this is no longer the case. That is, we have found that the performance degradation of tuning a transaction system to handle reporting to not be as significant as before.)
So, continuing the example above, these two clients are within a single database schema. Now, let’s have a little fun. Within this single database you could then install the J2EE engine. That would install a separate schema in the same database (if you wanted it that way, you could also have this second schema in a stand-alone database if you wanted!). You could also then install other components using MCOD technology (Multiple Components in One Database), too! For example, you could then install another BW system as a MCOD system. This would create a third schema in the single database (and two BW’s!). And all of the NetWeaver components work this way. So, at the end of the day, you have the option to go MCOS, MCOD or just plain multiple instances on one box. The point is, you have the option to design accordingly. Customers are neither tied to a single database nor tied to multiple databases, neither tied to one box nor forced to use multiple boxes. Maximum design flexibility to create the landscape according to what fits best where. A customer needs to determine what they want out of ESA, see how NetWeaver supports it, and then design a landscape that makes sense.
My two cents…I would never run the Portal with anything else. Although it’s probably supported, it’s an excellent idea to keep your web infrastructure separate, no matter the technical combination possibilities. This may be true for many other parts of a landscape as well. Remember, NetWeaver is a technology platform, not just an application offering. We are giving you the flexibility to mold the technology to your needs. Think in business processes and then use NetWeaver to implement the proper flexibility and security.