Is Your Integration Project Costing More Than It Should?

Over the years I’ve been directly involved in a great number of IT software development projects at Prolifics. And without exception these have all involved integration of a number of software components – whether it is integrating back-end systems such as SAP, plugging in external services from business partners, or the more relatively straightforward integration of new business systems or processes to in-house business services.

And something I’ve seen all of these projects having to deal with is the fact that software integration introduces some very real dependencies in development and test plans and environments – all of which require a fair amount of attention and a non-trivial amount of coordination and resources which could impact the time and budget estimates.

But what if there was a way to reduce the cost and planning impact of these dependencies?

Monica Luke and I tackle this topic in a new IBM whitepaper that discusses the usage of business service virtualization and testing techniques and tools to remove bottlenecks and reduce costs in building today’s modern, interconnected applications.

Many of our IBM customers will be interested in the discussion on example service architecture as well as mobile and portal domains. We briefly contextualize the value for customers using products such as WebSphere Application Server, WebSphere Enterprise Service Bus, IBM Integration Bus (previously WebSphere Message Broker) and MQ, WebSphere DataPower, IBM Business Process Manager, WebSphere Portal Server and IBM Worklight.

Read our whitepaper here:

Use Service Virtualization to Remove Testing Bottlenecks






How do I get started?
This is a great time to highlight Prolifics' very own IV&V (Independent Verification and Validation) practice. IV&V is an important aspect of our global delivery model, providing customers with end-to-end testing solutions that help to improve productivity and quality while reducing overall cost of all software development activities.

Our team has extensive experience in testing large, interconnected, critical business applications, and is ready to help you reinvent the way you approach your testing – backed by a service framework and testing accelerators that have been field tested and refined for over a decade.

Interested in taking a deeper dive? Connect with me!
Twitter - @greg_hodgkinson
Email - ghodgkinson@prolifics.com
LinkedIn - Greg Hodgkinson

To learn more about Prolifics, visit www.prolifics.com.

Gregory Hodgkinson is the Lifecycle Tools and Methodology Practice Director at Prolifics and an IBM Champion for Rational. Previous to that he was a Founder, Director, and the SOA Lead at 7irene, a visionary software solutions company in the United Kingdom. He has 16 years of experience in software architecture , initially specializing in the field of component-based development (CBD), then moving seamlessly into service-oriented architecture (SOA). His extended area of expertise is the Software Development Lifecycle (SDLC), and he assists Prolifics and IBM customers in adopting agile development processes and SOA methods. He is still very much a practitioner, and has been responsible for service architectures for a number of FTSE 100 companies. He presents on agile SOA process and methods at both IBM (Rational and WebSphere) and other events, has also co-authored a Redbook on SOA solutions, and contributes to DeveloperWorks.

Application Performance Testing Best Practices

Application Scalability:

1. Define Application Scalability in two ways:    a. Vertical         b. Horizontal
2. Vertical scalability is defined as the scalability of an application as additional CPUs are added to the same server
3. Horizontal scalability is defined as the scalability of an application as additional servers are added to the environment
4. Scalability of an application is important for large enterprise Portal deployments where an individual server cannot support the anticipated load. In such cases, the Portal provides the capability to cluster multiple instances of the application. This can be achieved by either installing multiple instances of the Portal on a single server with a large number of CPUs or having each instance run in a separate Java Virtual Machine (JVM), a combination of both
5. Performance improvements are depends an operating system, application server and JVM handle the scheduling of threads across a larger number of CPUs. This is also subject to change as subsequent versions of JVMs are released to market. In addition, careful tuning of the application server is required to ensure that the load on a single instance can be most effectively supported (e.g., Web Sphere Web Container Thread Pool parameters)
6. For horizontal scalability, the only limitation on the scalability of the Portal will most likely be from the network or database perspective (the database is a shared resource between all instances of the Portal in a particular cluster). Any other system component that is shared by all Portal instances (e.g., LDAP Directory server) can potentially create a bottleneck and prevent further scaling of the application.
7. Portal instances running in a clustered environment it is required Portal network throughput is below 70% of the maximum network bandwidth available at peak periods (i.e. maximum of 8 MB/sec on a 100 Mb/sec network). Network throughput levels above this will impact the average response times for end users during these periods.
8. Database CPU utilization of above 75% at peak periods can greatly impact the Portal performance depending on the types of queries being executed at that time

Web Server:

1. If a web server (e.g., Apache, Sun ONE, IIS) is using proxy to accept request from the application server in a production environment, it is recommended to host the web server on a separate physical server. Such a configuration may be encountered in an Internet deployment with a DMZ (Demilitarized Zone)
2. The net effect of this is that more resources, in the form of memory and CPU, will be available to the application server to process requests. This will have a small impact on the response times due to an additional network hop but will increase the overall throughput of the application due to the additional CPU resources that will be available

Application Server:
Tuning parameters for Web Sphere & Apache Tomcat application servers
WebSphere:

1. The optimal number for the Web Container Thread Pool Maximum Size is 75 (default is 50). Both lower and higher values result in slightly lower throughput.
2. Increasing Thread Pool Minimum Size has adverse effect on performance.
3. Similarly, increasing Thread Inactivity Timeout has a slightly negative effect on performance.
4. Running Performance Monitoring Service introduces about 30% overhead

Apache Tomcat:
The development time issues relate to how the Java code for the Web application was designed and implemented. Again, there is a whole set of implementation best practices surrounding this area, such as:

1. Do not create sessions for JSPs if they are not required
2. Do not store large objects in your session.
3. Time out sessions quickly, and invalidate your sessions when you are done with them.
4. Use the right scope for objects.
5. Use connection pooling for improving performance.
6. Cache static data.
7. Use transfer objects to minimize calls to remote services.
8. Minimize logging from Web applications, or use simple logging formats

Database Server:
For large enterprise deployments of the Portal, it is recommended that a dedicated database server be used to host the Portal schema. In addition, certain database subsystems (e.g., MetaStore, Users) can be further distributed across several database servers. Deploying the Portal schema in this manner will help to ensure that the database will not become a bottleneck as the Portal is scaled to support a continually growing user base
Oracle 11g:
To assist in the rollout, build a list of tasks that increase the chance of optimal performance in production and enable rapid debugging of the application. Do the following:

1. When you create the control file for the production database, allow for growth by setting MAXINSTANCES, MAXDATAFILES, MAXLOGFILES, MAXLOGMEMBERS, and MAXLOGHISTORY to values higher than what you anticipate for the rollout. This technique results in more disk space usage and larger control files, but saves time later should these need extension in an emergency
2. Set block size to the value used to develop the application. Export the schema statistics from the development or test environment to the production database if the testing was done on representative data volumes and the current SQL execution plans are correct
3. Set the minimal number of initialization parameters. Ideally, most other parameters should be left at default. If there is more tuning to perform, then this appears when the system is under load
4. Be prepared to manage block contention by setting storage options of database objects. Tables and indexes that experience high INSERT/UPDATE/DELETE rates should be created with automatic segment space management. To avoid contention of rollback segments, use automatic undo management
5. All SQL statements should be verified to be optimal and their resource usage understood
6. Validate that middleware and programs that connect to the database are efficient in their connection management and do not logon or logoff repeatedly
7. Validate that the SQL statements use cursors efficiently. The database should parse each SQL statement once and then execute it multiple times. The most common reason this does not happen is because bind variables are not used properly and WHERE clause predicates are sent as string literals. If you use precompiles to develop the application, then make sure to reset the parameters MAXOPENCURSORS, HOLD_CURSOR, and RELEASE_CURSOR from the default values before precompiling the application
8. Validate that all schema objects have been correctly migrated from the development environment to the production database. This includes tables, indexes, sequences, triggers, packages, procedures, functions, Java objects, synonyms, grants, and views. Ensure that any modifications made in testing are made to the production system
9. As soon as the system is rolled out, establish a baseline set of statistics from the database and operating system. This first set of statistics validates or corrects any assumptions made in the design and rollout process 

Showcasing Effecta at SAPPHIRE NOW - Prolifics Tool for Test Automation & Data Validation

Prolifics kicks off SAPPHIRE NOW & ASUG Annual Conference this week in Orlando. At the conference, we will be showcasing our SAP testing solutions and share recent success stories with customers like McKesson and Pacific Coast. At booth #2715, we will also showcase a demo of our Test Automation and Data Validation tool - Effecta.

Get a sneak peek of Effecta by viewing the demo below.

Learn more about our SAP testing solutions for our customers here:
McKesson Transforms Business with Script-less Test Automation
Pacific Coast Builds SAP Test Automation Strategy with Effecta

Effecta Demo


To learn more about Prolifics' week at SAPPHIRE NOW, visit: http://www.prolifics.com/sapphirenow-2013.htm

Test Automation for SAP Packaged Applications

SAP Packaged Applications allow you to rapidly configure and customize business processes as your environment changes. To ensure the quality, performance and reliability of these applications, you need a sophisticated testing solution that can be configured and customized as quickly as your SAP landscape. In this article, we will show you how you can use your IBM® Rational® Functional Tester (RFT) toolset along with tools from IBM Ready-for-Rational partner, Arsin.

In this blog entry, I will discuss:

• A structured approach to SAP testing


• SAP current test automation paradigm and its challenges


• The need for a new solution for SAP test automation


• How Arsin Packaged Test Automation for SAP integrated with IBM Rational Functional Tester helps address these challenges

We will examine the functionality of Effecta Validation Engine, in conjunction with RFT, to collect the test requirements, define and build the test cases, build the test procedures, and execute and analyze the reports. Use of RFT and Arsin's tools enables you to greatly expand your test scope, significantly compress your test schedule, and reduce testing costs.


A Structured Approach to SAP Testing
SAP implementations pose some of the most intriguing and difficult challenges in the QA universe. The thickly netted system is extremely integrated and is typically linked to every business process in the enterprise. To tackle such an immense system, QA engineers must approach SAP applications with care.
With more than a decade of experience in testing SAP systems for a large client base in myriad industry verticals, we have developed a test maturity model assessment and improvement framework to bring about an organized and a structured approach to SAP testing. This framework has a three pronged approach, which offers process improvement, knowledge management, and test automation, as follows:

1. Process improvement. Process improvement deals with the assessment of the current Test Maturity Model and developing a plan to improve the Test Maturity Model to the next level and then implement it. A mature test process that has standardized templates, well-defined processes, clear protocols, and no bottlenecks provides for a complete and comprehensively tested SAP system. By comparing the current test maturity model with industry standards and identifying the gaps and focusing on them, test maturity can be improved.

2. Knowledge management. Knowledge management deals with institutionalizing QA knowledge collected over time. Traditional testing for SAP systems relies on the functional and technical consultants of the SAP system for subject matter expertise to deal with various instances. In this phase, test artifact libraries are built for critical business process for regression. The following test artifacts are documented:

• Test Requirements


• Test Cases


• Test Procedures

3. Test automation. After test artifacts have been documented in the regression library during the knowledge management phase, they are ready to be automated. However, before they are automated, these test artifacts are analyzed for feasibility of automation, the effort required for automation, the frequency of use of the business process, and the longevity of the business. With automation, execution components are developed using RFT, and Validation Components are configured using Arsin's Effecta Validation Engine to execute them automatically.

The remainder of this discussion focuses on the test automation aspect of the Structured SAP Testing Approach. Our belief is that RFT, in conjunction with Arsin's Effecta Validation Engine, makes SAP testing thorough, comprehensive, easy, and cost effective.


Importance of Test Automation in SAP Implementations
The SAP landscape is continuously changing, as a result of changes to SAP modules from SAP, business process changes within the client’s company, changes to the system environment, changes to applications interfacing with SAP, and a multitude of regulatory compliance mandates.

In order to keep up with these changes, SAP systems must be thoroughly tested. With every change, there is a regression library of test cases that needs to be executed to ensure stability. Each test requires time and effort when executed manually; by comparison, automated test take a very small fraction of the time and effort to execute. Automation also helps makes most of the test assets reusable.


Current SAP Testing Solutions and their Limitations
The existing SAP testing model on the market today makes a very rudimentary use of automation, in terms of:

Validation: In most cases, user interface (UI) tools that are available are used to automate test execution, which is only about 25% of the total testing effort. Validation represents more than 75% of this effort, and scrubbing the data using UI test automation tools is difficult. A certain level of validation is possible through UI based test automation tools, however it takes a long time to script this validation and any change requires a lot of coding following the first implementation.

Data management: Traditionally, data used for testing is captured and maintained in spreadsheets. Searching and sorting through this data is difficult, as is maintaining the consistency of data across users and locations. This difficulty is compounded by ever increasing volumes of test data to be maintained. In addition, there is no intelligent association between SAP metadata and its corresponding test data.

Managing change: Changes to SAP implementations occur during reconfiguration or the addition of custom-built components (programs). In these situations, the scripts for automated test execution need to be changed regularly, which is difficult. Moreover, when using UI tools for automation, 75% of the effort needs to be constantly re-worked to keep up with the changes to the SAP system.


Addressing these Limitations
The limitations above described call for a new solution that can address these issues. We offer a complete and scalable testing solution that combines Arsin Effecta Validation Engine with IBM Rational Functional Tester.

By automating the validation of data, business processes, custom development and integrations across SAP applications, you can increase the quality of implementation, support multiple changes in their environment and mitigate business risks. Also, by eliminating manual testing you can avoid greater difficulties in production that ultimately impact the quality and performance of the business. Arsin’s Effecta Test Suite provides the benefits of a complete testing solution by automating impact analyses of changes, test data maintenance, test execution and validation.

Figure 1: Arsin Effecta Solution Architecture for testing SAP applications

Test Data Manager
Stores test data along with criteria in the Effecta database. Before executing an automated test, validity of test data is checked on the target system and system is automatically updated. If the test data no longer exists in the target system or cannot be reused, the data set update feature will help to refresh with new valid data.

Script Manager
Automatically enhances recorded scripts and eliminates need for customization. Script manager enables script less automation of IBM Rational Functional Tester.

Change Impact Manager
When changes occur in a system, Change Impact Manager automatically extracts affected objects and identifies test cases to be executed for regression testing. It also identifies objects being changed that don’t have test cases in the library.

Report Manager
Report Manager provides out-of-the-box reports for tracking test artifacts, development and test execution. Detailed test results pinpoint failed events in test case.

Test Manager
Effecta promotes reusability and repeatability with the following features:
- Ability to create Test Requirements and link them to Test Cases and development objects
- Ability to create Test Cases and link them to Test Requirements for coverage analysis
- Ability to create separate Test execution steps in the form of Test Procedures and link them to Test cases
- Defect management
- Dashboard for reporting and metrics

Validation Manager for Middleware
Simulates inbound messages at various data interchange points and validates outbound messages.
Automatically validates translations and mappings

Validation Manager for Transactional Systems
Validation Manager for Transactional Systems is a completely configurable, customizable and readily deployable validation library of components for various business processes. It significantly accelerates validation by automatically extracting the actual data created by transactions and comparing it with expected results. The Validation Manager is specifically designed to support SAP systems.

Validation Manager for BI
Tests Business Intelligence systems during initial implementation and during maintenance and support pack deployments. It also automates the validation of data loaded from multiple ERP and other systems. Provides sophisticated reporting including detailed results.

Conclusion
The benefits of using automation in SAP testing are abundant. Test automation, deployed with minimal effort, enables increased test coverage, which in turn reduces cycle time and enables efficient bug detection early in the development cycle. Since test automation is designed for reusability, routine tasks are eliminated and total cost of ownership is reduced. Test automation is far more precise and consistent, and features standardized reporting, enabling clear test analysis across the QA environment.

Sarat Addanki is the Vice President, ERP Practice. He has 18 years of experience in the ERP arena including design, development and testing of ERP implementations. He was part of a SAP Quality professionals team contributing to the design of SAP Test Accelerator TAO. He founded the ERP Division at Arsin, which focuses on developing frameworks and accelerators to ensure delivery excellence, reduce the overall cost of ownership and increase productivity in ERP implementations. The Test Accelerators he designed significantly improve the testing process, knowledge management and test automation. His division focuses on providing quality services for SAP, Oracle, PeopleSoft, Sterling, Retek and Middleware applications. His domain expertise ranges from Pharmaceutical Distribution, Hi-Tech, Manufacturing to Retail industries. He is a PMI (Project Management Institute) certified Project Management Professional (PMP). Sarat holds a bachelor's degree in Computer Science and Engineering from Osmania University, Hyderabad, India.