Welcome back to the BSP Developer's Journal. In this part we will take a look at the process we went through to get our system environment setup.
Budget BluesWell we had our development group convinced that we wanted to give BSP development a try, now all we had to do is convince management to give us some money to go forward. If your corporation is anything like ours, you know that this can be quite a chore. No one wants to give you money until you can prove the business benefits. However it is difficult to research and demonstrate these benefits without first spending some money on at least a sandbox environment. Our approach was to build a sandbox but not tell anyone about it. We found a small server that was well past the end of its useful life. We affectionately referred to this server as The Heater. On a cold day you could warm your hands by the heat coming off this old workhorse. We secretly installed WebAS 610 not even telling our Basis group about the new system. We began the process of learning about BSP by building several simple applications. It didn't take too long to convince us that this was the approach that we wanted to take; however going to management and asking them to spend money to just provide us with a better development tool wasn't going to get us anywhere. We needed something that would really catch the business's attention. Our company is a global operation with facilities in North America, Asia, and Europe. Our R/3 system is a MDMP system (a technology that allows you to operate a SAP system in multiple code pages without Unicode). We were beginning to face the challenge of creating web applications that operate as well in multiple languages as R/3 does. We decided that this was the business angle that we were going to use.
Multi-language is the keyWe configured our WebAS as MDMP and installed Spanish, Thai, and Polish into it. We prepared several sample applications that ran in multiple languages. We demonstrated how we could pull descriptions from R/3. We also showed how easy it was to translate the user interface using the tools we were already familiar with from R/3. We also demonstrated the use of multiple language versions of Mimes and the use of OTR tags. We didn't even realize that this was just the beginning of the functionality the WebAS offered for multiple languages. Part VII of this weblog will dive into this subject in greater detail. Management was impressed and we finally received our official go-ahead. Choosing a PlatformNow we faced the challenge of moving forward with the project and choosing a platform. Our R/3 system was 4.6C. Even if R/3 Enterprise, with its built in 620 WebAS, had been available at the time, we wouldn't have been considering an upgrade. We wanted to complete our R/3 rollout to all of our facilities before we did any upgrades to R/3. Our only option was to build a separate landscape for stand alone WebAS. I don't know how many people realize that you can run just the technology layer of SAP, otherwise know as the WebAS. This allowed us to advance our SAP Technology while remaining on the same release of R/3. We would still execute all our application logic in R/3. We would just access it from the WebAS via RFC. Unfortunately people within our company didn't fully realize the difference between a R/3 system and a Standalone WebAS. Their first impression was that we would run our WebAS on the same platform as our R/3 - HP-UX and Oracle. The original spec had us running on a huge system with 32gigs of memory and a 1/2 a terabyte of disk space. Although most tech folks would love to have a system that powerful for their web server, it just isn't necessary for the standalone WebAS. The first thing to understand is that although the WebAS still has a database, it just isn't as large nor does it grow like a R/3 system. Because your application data is still over in R/3, the WebAS database really just has to store your Object Repository. Initially our Production WebAS's database was just a little over 6Gig. After more than a year and a half in production, it has only grown to 9Gig.
Now I'm not wanting to start a argument on who's operating system is best (although Operating System Holy Wars can be interesting to observer), but we did end up choosing windows/MSSQL for our platform. Given the standards within our company and the experience we had in house for support, this platform provided the best price/performance point for us. The only other database we considered was SAP's own database, SAPDB or as it is now known MaxDB. We could have saved money on licensing with this option, but we just didn't feel like we had the experience in house to properly support the platform.
We ended up with dual 2.8GHz CPU servers with 4 Gigs of memory. With nearly 1000 named users and 50 or so simultaneous connections at any time, the Production server hardly ever breaks a sweat. We have been able to scale the servers a bit by adding more work processes as more and more applications are rolled out. We still have plenty of overhead within our 4 Gigs of memory to add more as we grow. We have certainly seen that the number of users has a direct correlation to the amount of memory needed and we have been able to plan for our growth accordingly.
TransportsWe decided to setup our WebAS Transport structure separately from our R/3 one. Originally we made this decision to keep the landscape setup as simple as possible. We also didn't want to do anything to disrupt our running R/3 environment. If there is some code that needs to exist in both landscapes, we simply copy the Transport file from our Unix R/3 transport directory to our Windows WebAS Transport directory. The other thing that this allows us to do is let the developers do their own transports (even to Production). In R/3, for control and separation of duties, the developers of course can not do their own transports. However because the WebAS doesn't contain the application logic, we have less restrictive standards. We even setup TMS workflow to make the process very simple and fast. We did make one mistake in the original system setup. Unlike our R/3 landscape where we have a Sandbox, Development, Quality, Training, and Production instances, we only created a Development and Production WebAS. In the beginning this appeared to make sense in order to save money. However as we became a victim of our own success, it became increasingly difficult to do development while testing was going on in the same system. We also began to be hurt by the fact that we didn't have any place to test patches and system maintenance before trying them in Development. About 9 months after our Production system went live we did end up adding both a Small Sandbox and a Quality system that exactly matches our Production Hardware. This also provides us a poor man's high availability. Because of the identical hardware we could simply swap the drives between the two servers in the case of a hardware failure.
ReunificationTo make reintegration of R/3 and the WebAS a possibility someday, we have tried to plan ahead. We setup any new development class in both landscapes. We use a separate naming convention for any object in the WebAS that doesn't exist in R/3 as well. That way we hope to avoid any future conflicts. Someday we plan to upgrade R/3 and migrate some of the WebAS applications back over there. On the other hand, I don't necessarily see the stand alone WebAS going away. It is nice to have the separation of the two systems. We have much more freedom to upgrade and patch our WebAS without disturbing the business and causing retesting of all the R/3 business transactions. Looking AheadNext week's weblog will detail the impact of implementing BSP had on our Development Team (We would never be the same again 🙂 ). In case these weblogs have been a little too lacking in code samples, you should look forward to Part IV. In this part we will hit the code for the first time as we discuss RFCs and the BAPI Browser.
