What is service virtualization
in SAP projects?
Why are projects without service virtualization difficult to test?
Coordinating testing against all non-SAP applications is extremely difficult.
One of the typical worries during the SAP projects is how the project will impact other services, legacy applications, and B2B partners. If only SAP systems are getting change, why do we have to test all other services that are not getting changed? Testing each business process between two (or more) services increase the project budget, extends the timeline, and engages additional resources (external B2B system operators, business users etc.). In reality, testing is a big part of the project budget or is implemented improperly and doesn’t secure a good quality of project deliverables.
How can service virtualization help your SAP project?
In order to speed up your testing decouple SAP systems from non SAP systems.
A remediation for this situation is decoupling SAP testing from testing the other applications which are not getting changed during the project. In order to decouple SAP system from other one which communicate with it, we need to virtualize those external services. This way any kind of SAP system used for the project will be able to test complete business processes without interacting with any 3rd party service. This would give the test team complete freedom in running the isolated tests and will make sure the vital SAP application interfaces will be fully tested.
Why is service virtualization in SAP projects so easy and quick?
Messages exchanged with SAP systems can be easily repeated.
Most of the messages exchanged for the business interface communication in the SAP ecosystem are asynchronous and stored in the database, the only thing we need in order to virtualize the non SAP applications is to re-run them intelligently in a non-invasive way. Creating a test document for virtualization only requires selecting the documents numbers (for e.g., IDOCs) which we want to reprocess.