X
CASE STUDIES

Financial Organization Virtualizes SAP & Seamlessly Migrates Legacy System

Reading Time: 3 minutes

DOWNLOAD PDF »

Financial Organization Virtualizes SAP & Seamlessly Migrates Legacy System

THE CHALLENGE

A financial organization was embarking on a technology upgrade, involving SAP as its core replacement technology partner to migrate off its legacy backend systems. Wanting to leverage the existing Middleware platform to seamlessly switch from old to new without impeding the customer experience, the organization sought a solution that could provide them with confidence in the changes being made within its Middleware system.

THE APPROACH

One of the key technical risks was ensuring that the mapping and transformation logic in the middleware system was correct once migrated. After reviewing options, it was determined that the most cost effective and reliable approach was to remove the dependency between the middleware and backend systems by virtualizing SAP. This would provide a means of building the switching logic within its Middleware component before the SAP interfaces were available, as well as being able to repeat tests without the overhead of data setup and teardown.

The organization’s next challenge was to justify the investment to change from a manual testing approach (at the service layer), to an automated approach without end-to-end functionality. The ROI was a simple metric that stakeholders could understand and relate to – defect cost avoidance. If they could find 3 defects per operation during the development phase, this would avoid a greater cost of resolving defects during the system integration phase. At the completion of the development phase, they had exceeded the ROI by 68%.

Before the upgrade project, the team’s existing manual testing process was able to keep pace with the rate of application updates. However, once the project was fully scoped, it became clear that the existing manual process would not be sufficient, considering the time required to set up data in SAP, waiting for SAP to be made available, as well as the number of software iterations expected.

THE RESULTS

Virtualizing

The most obvious benefit of having service virtualization was that the team could begin developing and testing against the new backend systems’ anticipated behavior before those systems were actually deployed.

Additional benefits included:

  • They no longer had to wait to get the test data needed for each test or to have the test data reconfigured to the desired state (for example, reopening an account that a test closes so that it is ready for the next automated test run).
  • They could easily mimic a broad set of backend system response conditions (data variations, failure conditions, performance variations), which helped them catch complex issues prior to deployment.
  • Since the virtualized responses were validated and consistent, the team knew that any detected problems with the response messages actually stemmed from an issue with the Application Under Test — not a backend system update, reconfiguration, or failure.
  • The team started building automated tests for each SAP operation as the associated middleware code was being modified. Tests were defined with Parasoft SOAtest, which works alongside Parasoft Virtualize in the Parasoft Continuous Testing Platform.
  • Backends that the application under test communicated to, but were not part of the testing scope, were virtualized to always give a successful response. This made tests more reliable (as these backends were sometimes unavailable or had authentication issues with our data) and able to focus on testing what the test’s purpose was.
  • Since virtualization required the team to replicate the behavior of the back end, this forced them to dig deeper into how the back end worked.
  • In one of the more complex systems, they worked with the Middleware developer and the SAP developers to work out how the mapping would take place and were able to simulate a response from the SAP developers in Virtualize to help the developer to build the Middleware code correctly.

White Box Testing

From a development perspective, it was not sufficient to simply validate the requests and responses were returned as expected, but the internal orchestrations, workflow and downstream output were correct. The team integrated Parasoft’s event monitoring with the middleware system to inspect each message flow and assert that the results were as expected.

Outcome

At the completion of the delivery, the team amassed an automated test suite that could be run after each new build of middleware. The number of backends virtualized amounted to 8.

TAKE THE NEXT STEP

Find out how to choose the right service virtualization solution for your organization. Download the whitepaper.

Related Case Studies

Try Parasoft