In this article you will learn:<\/h2>\n\n- How systems virtualization for SAP projects works in Int4 IFTT?<\/li>\n
- How can you decouple SAP environment from legacy\/external environments\/EDI for testing purposes?<\/li>\n
- What can you gain from Int4 IFTT virtualization?
\n<\/div><\/li>\n<\/ul>\n
\nReading time: 5 minutes<\/span><\/strong><\/p>\n<\/p>\n<\/div><\/span><\/strong><\/p>\nIntroduction<\/h3>\n
Testing of interfaces can be a challenging task, especially in complex environments. Very often the ambition is to test interfaces end-to-end, which is understandable but can bring more risks and delays to a project or even a single change request. An alternative to this approach, can be to focus on testing of the interface in the environment where the changes are implemented. This can speed up things significantly but requires tools to do this properly.<\/p>\n
<\/p>\n
Manual vs automatic testing<\/h3>\n
When we are discussing the testing strategy with companies, we often hear that they perform their testing manually. Sometimes they have tools for test automation, but the integration area is rarely covered there. The reason for this is the complexity of the topic. If the ambition is to test interfaces always end-to-end then the usual choices are:<\/p>\n
\n- Test manually, involving legacy\/external systems and teams<\/li>\n
- Test automatically using test automation tool<\/a>
\n<\/div><\/li>\n<\/ul>\n
\nManual testing can be a tedious and prone for error process. On the other hand, to be able to test automatically end-to-end, you need to invest (time and money) in a tool and its setup.<\/p>\n
But maybe the real question is if we should always strive for testing end-to-end? My suggestion is to do this only when really needed, for example during UAT phase of a project. But on many occasions, testing of only the environment affected by change, for example whole SAP landscape, should be enough. That though, can be secured if you are equipped with the right tool, for example Int4 IFTT.<\/p>\n
<\/p>\n
Decoupling SAP environment<\/h3>\n
Implementing SAP solution tends to be a big step for companies. SAP environments can be quite complexed, and they also need to be integrated with the remaining parts of the company (legacy) and with the external world. It is usually the case that these parts remain the same or are changed\/replaced only partially.<\/p>\n
If the main changes, as a result of a project, are happening inside of SAP environment, then you should put most of your focus and resources on testing that part. This applies also to testing interfaces. Yes, you still need to test end-to-end at some point, but for most of the project, testing SAP should be enough.
\nInstead of spending time on executing the necessary steps in legacy environment, where no changes were implemented, you can focus on the part that really needs to be tested.<\/p>\n
Using Int4 IFTT you can secure that your new or changed SAP environment will work properly for messages arriving from outside (legacy or external) and will produce correct messages when sending them outside.<\/p>\n
<\/p>\n
Int4 IFTT Virtualization<\/h3>\n
With Int4 IFTT you can virtualize<\/a> all the systems which are integrated with your SAP environment. For your interface scenarios this means the following:<\/p>\n\n- For inbound interfaces you virtualize the sender, and can simulate messages sent by that sender into your environment<\/li>\n
- For outbound interfaces, you can secure that you send the right messages from your environment to the outside systems
\n<\/div><\/li>\n<\/ul>\n
\nYou can either do the virtualization of all systems (legacy applications, EDI providers, etc.) on the SAP middleware level (what you can see on the Figure below on the left hand side) or even virtualize the SAP middleware itself (along with all of the systems connected to it) in case you’d like to run very isolated testing – see the right hand side of the Figure below.<\/p>\n
![\"Int4](\"https:\/\/int4.com\/wp-content\/uploads\/2020\/11\/Figure-1-Int4-IFTT-virtualization-and-test-automation.jpg\")
<\/a><\/p>\nFigure 1 – Int4 IFTT virtualization and test automation<\/em><\/p>\nIn both scenarios, you can perform mass testing as well. That gives you the ability to verify various alternatives and ensure that you covered all of them. For example, for inbound interfaces you can use messages that you pulled from your productive landscape and store them as test cases in Int4 IFTT. Then you can run them, which will send the messages, virtualizing the sender, into your development or test environment. Finally, Int4 IFTT can automatically verify the outcome of those messages. The automatic verification can be done for both the middleware platform (e.g. SAP PO<\/a>, SAP CPI<\/a>, Dell Boomi<\/a>) and the application system (e.g. SAP S\/4<\/a>).<\/p>\n <\/p>\n
Summary<\/h2>\n
There are many benefits of using Int4 IFTT and the service virtualization that it provides. You can benefit from decoupling of your SAP environment from legacy and external systems and test it independently. You can put more focus on the changes implemented in SAP, and still make sure that your changes will not affect the other systems. By using the real messages exchanged with the “rest of the world” you can secure that your solution can process the incoming messages properly and produce correct messages that are sent outside. Thanks to the mass testing ability you gain confidence by verifying hundreds or thousands of possible alternatives, instead of only testing a few as it would be the case in end-to-end testing.<\/p>\n
You can check out the rest of the Int4 Blogs<\/a> in order to read about Int4 IFTT and other interesting SAP-related topics. If you want to find out more about the Int4 IFTT<\/a> features, just book a session with the product demo or\u00a0contact us<\/a>.<\/p>\n <\/p>\n
Read also:<\/h3>\n
- \n
- How systems virtualization for SAP projects works in Int4 IFTT?<\/li>\n
- How can you decouple SAP environment from legacy\/external environments\/EDI for testing purposes?<\/li>\n
- What can you gain from Int4 IFTT virtualization?
\n<\/div><\/li>\n<\/ul>\n
\nReading time: 5 minutes<\/span><\/strong><\/p>\n
<\/p>\n<\/div><\/span><\/strong><\/p>\n
Introduction<\/h3>\n
Testing of interfaces can be a challenging task, especially in complex environments. Very often the ambition is to test interfaces end-to-end, which is understandable but can bring more risks and delays to a project or even a single change request. An alternative to this approach, can be to focus on testing of the interface in the environment where the changes are implemented. This can speed up things significantly but requires tools to do this properly.<\/p>\n
<\/p>\n
Manual vs automatic testing<\/h3>\n
When we are discussing the testing strategy with companies, we often hear that they perform their testing manually. Sometimes they have tools for test automation, but the integration area is rarely covered there. The reason for this is the complexity of the topic. If the ambition is to test interfaces always end-to-end then the usual choices are:<\/p>\n
- \n
- Test manually, involving legacy\/external systems and teams<\/li>\n
- Test automatically using test automation tool<\/a>
\n<\/div><\/li>\n<\/ul>\n
\nManual testing can be a tedious and prone for error process. On the other hand, to be able to test automatically end-to-end, you need to invest (time and money) in a tool and its setup.<\/p>\n
But maybe the real question is if we should always strive for testing end-to-end? My suggestion is to do this only when really needed, for example during UAT phase of a project. But on many occasions, testing of only the environment affected by change, for example whole SAP landscape, should be enough. That though, can be secured if you are equipped with the right tool, for example Int4 IFTT.<\/p>\n
<\/p>\n
Decoupling SAP environment<\/h3>\n
Implementing SAP solution tends to be a big step for companies. SAP environments can be quite complexed, and they also need to be integrated with the remaining parts of the company (legacy) and with the external world. It is usually the case that these parts remain the same or are changed\/replaced only partially.<\/p>\n
If the main changes, as a result of a project, are happening inside of SAP environment, then you should put most of your focus and resources on testing that part. This applies also to testing interfaces. Yes, you still need to test end-to-end at some point, but for most of the project, testing SAP should be enough.
\nInstead of spending time on executing the necessary steps in legacy environment, where no changes were implemented, you can focus on the part that really needs to be tested.<\/p>\nUsing Int4 IFTT you can secure that your new or changed SAP environment will work properly for messages arriving from outside (legacy or external) and will produce correct messages when sending them outside.<\/p>\n
<\/p>\n
Int4 IFTT Virtualization<\/h3>\n
With Int4 IFTT you can virtualize<\/a> all the systems which are integrated with your SAP environment. For your interface scenarios this means the following:<\/p>\n
- \n
- For inbound interfaces you virtualize the sender, and can simulate messages sent by that sender into your environment<\/li>\n
- For outbound interfaces, you can secure that you send the right messages from your environment to the outside systems
\n<\/div><\/li>\n<\/ul>\n
\nYou can either do the virtualization of all systems (legacy applications, EDI providers, etc.) on the SAP middleware level (what you can see on the Figure below on the left hand side) or even virtualize the SAP middleware itself (along with all of the systems connected to it) in case you’d like to run very isolated testing – see the right hand side of the Figure below.<\/p>\n
<\/a><\/p>\nFigure 1 – Int4 IFTT virtualization and test automation<\/em><\/p>\n
In both scenarios, you can perform mass testing as well. That gives you the ability to verify various alternatives and ensure that you covered all of them. For example, for inbound interfaces you can use messages that you pulled from your productive landscape and store them as test cases in Int4 IFTT. Then you can run them, which will send the messages, virtualizing the sender, into your development or test environment. Finally, Int4 IFTT can automatically verify the outcome of those messages. The automatic verification can be done for both the middleware platform (e.g. SAP PO<\/a>, SAP CPI<\/a>, Dell Boomi<\/a>) and the application system (e.g. SAP S\/4<\/a>).<\/p>\n
<\/p>\n
Summary<\/h2>\n
There are many benefits of using Int4 IFTT and the service virtualization that it provides. You can benefit from decoupling of your SAP environment from legacy and external systems and test it independently. You can put more focus on the changes implemented in SAP, and still make sure that your changes will not affect the other systems. By using the real messages exchanged with the “rest of the world” you can secure that your solution can process the incoming messages properly and produce correct messages that are sent outside. Thanks to the mass testing ability you gain confidence by verifying hundreds or thousands of possible alternatives, instead of only testing a few as it would be the case in end-to-end testing.<\/p>\n
You can check out the rest of the Int4 Blogs<\/a> in order to read about Int4 IFTT and other interesting SAP-related topics. If you want to find out more about the Int4 IFTT<\/a> features, just book a session with the product demo or\u00a0contact us<\/a>.<\/p>\n
<\/p>\n
Read also:<\/h3>\n