How to Test mySAP Components

Until the last two years, when I thought of SAP stress testing I thought solely of R/3. With the advent of mySAP, however, all of that changed. No longer are interfaces to other systems handled through ALE (Application Link Enabling) or EDI (Electronic Data Interchange); instead, more and more systems are linked leveraging the Internet and protocols like HTTP and XML. And SAP’s NetWeaver will push the use of Microsoft’s .NET and Java connectivity/interoperability in general, further underscoring the need to stress test across the “extended enterprise.”

To execute a stress test, you fortunately do not need to be an expert in these protocols and initiatives, nor necessarily in the systems and products that these protocols bring together. Rather, if you “drive” the business process correctly, and the functional testers have done their work to ensure that the business process executes as expected, you can (theoretically) relax and focus on scripting business processes and then monitoring the stress test. This is great news to anyone faced with otherwise learning a slew of interfaces and products.

However, you’re not out of the woods yet. Scripting in different mySAP.com components can be demanding in that each component may need to be addressed differently. And every component includes a database server, which not only needs to be closely monitored but also needs to be warmed and restored prior to each test run. Thus, pure coordination activities rise to the surface as unavoidable and resource-consuming must-haves, lest the stress test results be compromised in terms of integrity and therefore value. This is why SAP’s standard benchmarking kits can prove valuable, as discussed in the next section.

SAP Standard Application Benchmarks

In some cases, it may make sense to execute an “SAP Standard Application Benchmark,” using benchmark kits published by SAP AG and available to SAP technology partners. This approach is valuable in that a particular solution stack can be measured or “benchmarked” against configurations that have been tested and published by SAP’s hardware technology partners. The downside is that such an approach does not leverage your own customer-specific data and business processes, though. I therefore find these types of benchmarks most useful when funded (or at least partially funded) by your hardware partner. For example, I have participated in customer-specific stress tests, where I used the custom SAP hardware sizing performed by the SAP Competency Center to guide me in actually building the architected solution. And then I tested this customer-specific solution for a potential customer, who had other hardware partners doing the same work in their respective hardware labs.

From the customer’s perspective, this works out well—they benefit from seeing a solution in action, and because the same benchmark kit is used by each hardware vendor, the results are very much apples-to-apples; resources and processes used in the execution and monitoring of an SAP benchmark are unswerving and consistent, reflecting dependable benchmark test results. Plus, most of the testing fees are often absorbed by the respective hardware sales organizations looking to close a big sale, making it an inexpensive insurance policy for the customer—they provide oversight to some degree, participate in Test Week, and walk away with great data and a sense of the real value proposition that each vendor brings to the table.

As illustrated in Figure 16.4, SAP AG publishes quite a few standard benchmark kits that can be used in customer-specific benchmarking exercises as I just described. A kit exists for many of SAP’s different mySAP components and technology solutions, such as

• mySAP Supply Chain Management, which covers SAP APO, the ATO functionality, and R/3 MM, PP, SD, and WM functional areas

• mySAP Business Intelligence, which focuses on SAP BW

• mySAP Product Lifecycle Management, specifically PLM

• E-Commerce solutions

• mySAP HR, specifically R/3 Cross-Application Time Sheets (CATS) and HR’s payroll process

• mySAP Financials, focused on SAP R/3’s FI functional area

• mySAP CRM, addressing Internet Sales and the CIC (Customer Interaction Center) functions

• Various industry solutions, like retail, banking utilities, and more

Where eCATT Fits In

Another valuable tool provided by SAP is eCATT, or extended Computer Aided Test Tool, which was discussed in great detail throughout Chapter 15. eCATT is a perfect tool for testing multicomponent mySAP solutions, in that it supports the most common releases of mySAP products on the market or in data centers today, and can leverage its hooks into mySAP to drive complicated back-end processes. But eCATT does not natively support virtual users, relying instead on SAP’s testing partners. So although eCATT is a powerful tool for proving functionality and performing regression-testing, it really takes a third-party SAP-aware tool like CompuWare’s TestPartner (a Web AS-certified virtual product) or other tools to pull off a true stress test.

SE38—One Answer to Cross-Application Stress Testing

Because of the potential complexities associated with testing business processes that span your enterprise, I find it especially useful to leverage transaction SE38 when I can. SE38 can easily be scripted to run a variety of reports and other jobs, both online and in the background (running as batch processes). Selecting jobs that not only represent your typical workload but that also make calls to other mySAP components is one of the most straightforward methods of driving an enterprise stress test.

Problems exist with this “easy” approach, of course. First of all, I doubt that all of your key business processes can be neatly executed in this manner. Second, you need to consider how many transactions you actually have that can be started from SE38 that touch multiple mySAP systems (assuming your goal is a cross-application stress test). My guess is that there won’t be many. Combined, these two challenges tend to make SE38 only a (valuable!) piece of a larger puzzle, then. I like to augment a stress-test load with the heavy load that can come from executing simultaneous batch jobs executed in the foreground, for example. The results may guide you as to when and upon which servers you run your batch jobs, where you place your update work processes, and even help you characterize the degree of parallelism in your custom batch processes. The bulk of the puzzle is then completed by scripting business processes that originate in your other mySAP systems, some of which are discussed next.

Business Information Warehouse and SEM

Scripting BW queries has been a challenge since BW’s inception. Even though a number of stress testing utilities support communications through the SAPGUI or WebGUI (that is, via Internet Explorer), I have not found an easy way for a virtual user to launch a script started in one interface and then pass control of that script to another interface. Specifically, if you start a BW transaction or query through a virtual SAPGUI session, and a Web interface or MS Excel screen is subsequently invoked, you are hard pressed to actually “talk” to this new active window. Conversely, if you script your business process via the Internet Explorer API, you can only “talk” to the initial screen—subsequent screens (used to enter variant data, or to actually view the results of a query) are not accessible via the virtual interface, either. In my experience, I have found five ways around these dilemmas, each of varying application or value:

• First, leverage SAP BW’s inherent capabilities to “trace” its own activity and then to replay it—refer to SAP’s “accelerator” white paper on how to accomplish this task.

• Use a third-party tool from companies like AutoTester or Mercury Interactive, but do NOT leverage virtual client capabilities. Rather, script everything for physical clients. This obviously requires access to the proper number of (adequately configured) clients. Hardware vendors like HP, IBM, and some others maintain a lot of equipment for this kind of use, but such services are almost always fee-based.

• Use a third-party tool’s virtual SAPGUI capabilities, but instead of true business processes, script only simpler “administrative” tasks, like those associated with managing SAP or the database (typical Basis and DBA scripted transactions). This may be all you need, if you achieve the goals set forth in your stress test project plan. For example, if you prove that your hardware platform or solution stack still performs well even after hitting a certain disk queue length, or you achieve metrics in terms of activity or load (like “x” number of logged-in/concurrent users or “x” number of concurrent processes), you don’t necessarily need to script anything else. These tests do nothing to prove that your system can handle the business processes expected to execute on your system, though, and are therefore usually of only limited value.

• Similar to the previous SAPGUI-based solution, script only WebGUI or Web-based activities; the same limitations as just described apply.

• Finally, use transaction RSRT in SAP BW to drive your queries. This transaction can execute any user-based query, but the difference from other queries is that the output—the query results—are kept “inside” the SAPGUI session rather than piped out to Excel or an Internet Explorer session. For stress testing and regression purposes, this is perfect, because you can script your complex BW queries in a virtual and repeatable manner without losing focus between the SAPGUI and the Internet Explorer or Excel interfaces.

Thus, by executing RSRT, you can perform all of your stress testing via the SAPGUI, and still retain the use of virtual client drivers—no need for hordes of physical desktops, or figuring out how to execute and (more to the point) control a combination of SAPGUI and WebGUI scripts at the same time!

Enterprise Portal and SRM/Enterprise Buyer Pro

When it comes to stress testing HTML-based and Java-based mySAP components like Enterprise Portal and Strategic Relationship Management, these products must naturally be driven by Web-based tools. Fortunately, all of the big players in the SAP stress-testing market today have this capability, both in physical and virtual mode. And just as importantly, a host of other testing utilities are available to drive these GUI platforms. The key to making your life simpler is to obtain a product that supports the various controls and other constructs that define a Web browser. Another key is the maker and version of the Web browser upon which you have standardized—not all testing tools support all browsers, for example.

Other mySAP Components and Considerations

Generally, if an SAP component can be accessed via the SAPGUI or WebGUI, you can script a business process using a tool like AutoTester or WinRunner/QuickTest. Of course, exceptions exist, as we just discovered with regard to SAP BW. By and large, though, if the applications supports a standard SAP interface, you’re well positioned to leverage it.

If you are unsure of exactly what to script, and have no access to super users or functional specialists, I recommend obtaining the mySAP component’s completed sizing questionnaire that was shared with each potential hardware vendor. Here, the number of users and transactions, and more importantly, the functional areas and even the types of transactions to be eventually executed will be identified. All of this information can then become a foundation for developing a list of potential stress test transactions and general business processes to execute. For example, if a completed SAP sizing questionnaire tells me that 400 users will execute MM (materials management) functions, and another 50 users will execute in a few other functional areas, it would be safe to assume that MM01, MM02, MM03, MMBE, MD04, ME57, MB1B, and MB1C should be considered first for scripting—these represent typical MM business transactions, and reflect the bulk of activity conducted by many of the future system’s online users.

Another thing that has helped me script business processes touching applications with which I am not deeply experienced involves the SAP benchmarking kits. That is, by their very nature, each benchmark kit provides a sequence of transactions that can be executed in support of the benchmarked business processes. If you take a look at what constitutes the CRM benchmark, for example, you will quickly determine how to log in to a CRM system, which core transactions to run (like CICO), and other details relevant to typical CRM business processes. This impromptu education is invaluable if you are asked to stress test a system before the SAP TSO fully understands all of the business activities that might surround such an effort.