3.3. Stress Testing Other SAP Enterprise–Enabling Solutions and Products
It's not just an organization's mySAP solutions and components that rate stress testing; other SAP products that play a role in either connecting different systems or enabling access to them can be responsible for performance problems. Failure of products that interconnect multiple SAP systems can easily lead to unscheduled downtime of your core applications, too. Think about it—even though your R/3 system may be “up,” if key business processes cannot complete or end users cannot access systems that front-end R/3, then for all intents and purposes, R/3 is down! And, because the downtime clock starts running as soon as your SAP system becomes unavailable to its user community, the expense of not testing and tuning complex mySAP environments can add up fast. The downtime clock continues ticking away as the problem or issue is noted by a systems management tool or administrator and researched; end users potentially sit idle as the problem eventually escalates and is finally resolved or a work-around is established. Even then, only once the SAP administrator validates that the restored system is truly in shape to be opened up for use by its end users again does the downtime clock stop ticking.
Given the preceding timeline, it's not hard to imagine how one 4-hour downtime event easily exceeds the costs of even the most elaborate of enterprise stress tests, countless exercises I've planned, conducted, and managed for my own customers—and you're probably no different. So, in the interest of being comprehensive in my approach to stress testing, and helping to bring everything together under the banner of SAP NetWeaver, let's next take a look at challenges and reasons why load testing SAP's XI, ITS, xApps, and SAP systems that take advantage of MCOD is not only indispensable from a technology perspective, but makes good business sense as well.
3.3.1. SAP XI
The SAP XI brings both SAP and select non-SAP enterprise products together, enabling integration unlike anything we've seen in the past from products out of SAP AG. This evolving integration technology can be used today, or in conjunction with the latest and all future mySAP solutions and components. In a nutshell, XI provides an Integration Repository (to manage interfaces and mappings to each product being integrated into XI), an Integration Directory (to manage routing rules and mappings across your mySAP system landscape), and the necessary enabling proxy and integration engine components. Thus, business processes that must span multiple systems—like sales-order processes, which might originate in CRM and then proceed to R/3 and APO—can now be easily managed through XI. And, with the use of synchronous and asynchronous messaging, XI supports deploying business processes across heterogeneous enterprise system landscapes, such as those I see every day in the real world. SAP solutions surrounded by third-party enterprise applications, including commonplace solutions from the likes of Baan, Broadvision, JDE World Software, Oracle, PeopleSoft, Siebel, and more, as depicted in Figure 3-5. Note the use of industry-standard file adapters JDBC (Java Database Connectivity) and JMS (Java Message Service, an asynchronous messaging standard that allows J2EE application components to create, send, receive, and read messages), making it easy to link XI with the rest of the non-SAP world.
Figure 3-5. Because the SAP XI Integration Server can tie so many diverse applications and products together, it may represent a key stress-testing objective for your unique environment.
With this wonderful business flexibility and technology freedom comes a requisite level of end-to-end stress testing. That is, what XI does for the business in terms of capabilities can create an equally dramatic performance nightmare over time, one that is both difficult to pinpoint and hard to characterize. With so many systems and underpinning network and other shared hardware resources, each representing a unique solution stack, the need for stress testing throughout XI's lifecycle should be unquestioned. Fortunately, once an organization's business processes are linked into XI, a certain amount of the burden related to testing can be reduced if you take into consideration the following factors:
The XI Integration Server is the embodiment of XI—it does the actual work of messaging. Thus, it's important that the number and size of the messages that your XI Inte-gration Server needs to process are understood, and that a performance baseline is established. Not surprisingly, only messages from servers and systems that actually touch XI need to be considered. Through stress testing, you will also be in a position to establish a high-water mark, so that you understand your growth and peak processing limitations well before you unknowingly run into them.
Given that the average size of a message is only about 31 kilobytes (the size of an iDoc with four line items), and all messages are held in a compressed format for only a day (and subsequently archived or deleted), you really do not need to concern yourself with database or disk subsystem–specific testing. Note, however, that data held in Unicode format consumes up to twice the amount of disk space as that maintained in a non-Unicode format.
Network testing, on the other hand, should be a staple of XI stress testing. A number of back-end network segments will certainly be involved, as might a few public segments. Thus, characterizing the load during normal and peak periods will help you stay on top of the bandwidth curve, giving you the information you need to establish a network infrastructure capable of meeting current requirements, and later growing as your messaging needs dictate.
Finally, like most of SAP's products, when it comes to average CPU utilization the general goal is not to exceed 65% under reasonable load; stress testing will make it clear what the message-to-CPU utilization ratio looks like in your own distinctive enterprise system landscape.
3.3.2. SAP ITS
Even though one day soon it will be completely replaced by Web AS, SAP's ITS is as viable a platform today as ever, and makes itself useful in thousands of installations across the globe. Stress testing ITS is a simple matter of ensuring that the number of connected users per instance does not exceed the capabilities of the underpinning hardware. At a high level, ITS works by converting HTML to SAP RFC, and back again. In this way, Web clients appear like any other SAPGUI-connected user as far as the back-end R/3 or other SAP system is concerned. The performance question that needs to be answered is not solely the HTML-to-RFC conversion process but also the network bandwidth challenges behind it, connecting ITS to the back-end SAP systems, especially if a secure (and inherently more bandwidth-intensive) network protocol is employed. In addition, with the ability to install multiple SAP ITS instances on a single physical server and disk subsystem comes the challenges of ensuring that each instance meets its individual SLA levels and other performance metrics.
3.3.3. SAP xApps
Given their custom nature and an inherent level of technical complexity because all four layers of the SAP NetWeaver stack are involved, the need to stress test SAP's xApps throughout each system's lifecycle is a no-brainer. SAP xApps are developed by SAP AG and a growing number of their select partners, combining people, information, and processes into a set of cohesive, collaborative, content-driven business processes that seamlessly span multiple systems. But it's not as though all of the risk inherent to such a seamless but still potentially complex solution ever disappears. Indeed, a custom solution, however much “canned,” screams for regular and repeatable stress testing both before and after Go-Live.
3.3.4. SAP MCOD
Although more of an approach rather than a solution per se, SAP AG's MCOD initiative absolutely demands a certain amount of at least initial stress testing (as does any IT consolidation approach, a number of which were discussed earlier in this chapter). MCOD allows multiple R/3 and mySAP databases to be collapsed into one or fewer physical databases, as seen in Figure 3-6, thereby simplifying the SAP system landscape and database management/backup administration in particular. Even more compelling, MCOD allows for a reduction in database licenses and reduction in the amount of physical disk space and tape resources necessary; combined with the benefits surrounding simplification, MCOD has the potential to significantly reduce the TCO of a select set of SAP AG's installed base.
Figure 3-6. Minimize the risk of deploying and maintaining systems that leverage SAP's MCOD ability to share a common disk subsystem and database (DB) through the use of both upfront and regular stress testing/tuning.
Unsurprisingly, however, with all of these benefits come several tradeoffs, many of which represent a challenge handily addressed by load testing, as follows:
As SAP AG touts, separate mySAP installations and even functional upgrades leveraging a single database are indeed achievable. However, from an infrastructure perspective, sizing and then verifying that the underlying disk subsystem performs well for all components, during peak times (which may overlap, depending on your business needs), demand solid baselining and repeatable, regular stress testing.
For production systems, high-availability solutions and the processes undertaken to perform a “failover” will impact more than one SAP component; how the disk subsystem performs during and after the failover needs to be characterized from a performance perspective.
Backup and restoration of the database become more challenging, as the physical disks on which all of these data lie are still only capable of moving “X” MB per second (a throughput and overall sizing consideration), and the window of time to perform all SAP component database and other backups to tape may be limited as well (an execution window consideration).
To actually host an SAP database, MCOD may leverage single or multiple servers running one or more operating systems. If the former approach is taken, and multiple components are collapsed at the server layer as well, a whole other reason for stress testing exists.
When MCOD was first introduced, it was made clear that OLTP (online transaction processing) and OLAP systems should be housed on different databases; combining R/3 and BW, for example, was a no-no. Today, this restriction has been lifted. However, just because SAP supports lots of mySAP and other SAP products sharing the same physical database does not mean that your hardware solution is optimized for this use. Consider the fact that many disk subsystems operate best when certain parameters are set based on the nature of the I/O being supported. Even more fundamentally, consider that to achieve optimal throughput at a high level, disk subsystems are regularly tuned for high-read performance in the case of OLAP systems, or tweaked for maximum write performance in the case of OLTP systems, and you'll begin to understand the need for load testing your particular MCOD implementation.
In regard to this last point, note that SAP classifies only BW and SEM as OLAP solutions. All other SAP components—R/3, CRM, APO, SRM/EBP, Workplace, and so on—are looked on as transactional systems as far as MCOD is concerned.