Human potential unlocked through automation.

Yes, Int4 IFTT has been successfully certified by SAP for integration with SAP S/4HANA on-premise edition 1511 via the SAP integration scenario ABAP Add-On Deployment for SAP S/4HANA (certification number 8681) and certified for integration with SAP NetWeaver 7.40 via the SAP integration scenario ABAP Add-On Deployment for SAP NetWeaver (certification number 8670).

• In 2019 Int4 IFTT 2.0 has been SAP certified again. Int4 has completed the second Int4 IFTT SAP solution certification and once again we’re the only native SAP Test Solution for testing integration flows (SAP PO/SAP CPI/SAP AIF including S/4HANA conversions) certified as Powered by SAP NetWeaver and Certified for Integration with SAP S/4HANA.

The process of a test case creation is very efficient because the existing documents, previously created by the interfaces, may be reused. In a typical scenario, the tester picks up interface messages for documents created during the user acceptance test and bulk uploads them. Additionally, assertions are defined per document groups (e.g. sales order, outbound delivery, financial posting, etc.). There is no need to define them each time when a test case is created. Moreover, based on the Int4 IFTT configuration, the assertions will be applied to test cases automatically.

We can distinguish a few Int4 IFTT user groups. They are for example: 

• Managers (for example Integration Team Managers/Integration Architecture Managers/Test Team Managers, Project Managers, etc.) – Int4 IFTT provides this group with the support of the SAP integration area, increasing confidence in the system and changes, increasing testing speed, automation in SAP integration and much more.
• Test engineers/developers – Int4 IFTT makes testing faster and more effective, test cases number is not limited, migration process is automated. Their job is done easily and smoothly because of high automation coverage of testing scope.
• Integration developers/architects – Our tool gives them the opportunity to learn something new and introduce complex changes faster. They also get more development requests thanks to business assurance that there is a way to test them.
• Functional experts –  Int4 IFTT makes it possible to test technical areas and solve incidents or implement a change request in the functional module. Thanks to our tool technical integrations might be tested by Functional people, together with business processes.
• CIO/CTO – Int4 IFTT helps complete tasks on time and saves budget (for example cheaper maintenance). Thanks to our tool this group is always up-to-date with innovations and can react faster on business requests.

There are two models of Int4 IFTT licensing: a free trial period license and a full license.

• The free trial license doesn’t allow customers to make any modifications to the source code.
• The full license allows such modifications but the original code’s ownership remains with Int4.

From a technical point of view, Int4 IFTT is a regular ABAP add-on to the SAP system and modifications of functionalities or extensions can be done by customers on their own or with implementation partners, just like with any other custom code in the customer’s system. Int4 doesn’t recommend own modifications and is always happy to help with implementations of new client-specific functionalities.

We are the authors of an openSAP course “Virtualize and Automate Your SAP Testing Using Int4 IFTT” (over 5000 enrollments). In this online training, you will learn more about our solution. We’ve created special Int4 IFTT Learning Paths to help you get the answers you’re looking for fast and successfully. Watch the lessons that we recommend and learn more about Int4 IFTT.

Int4 IFTT is a tool which was designed to be used to test SAP middleware (SAP PO, SAP CPI, SAP AIF, IDOC, proxies, also for S/4HANA conversions, etc.) where it can be fully scriptless (no need to create any test data as we use existing messages or backend documents posted on the SAP backend systems). It can be used in all sorts of migrations/patching/service pack upgrades/rollouts where it’s not possible to create test cases manually as with other testing software. On the other hand, Int4 IFTT can be called via API from any Test tool like HP/Microfocus ALM, Test Suite, etc. for test result analytics and this kind of integration we do in all of our projects as integration testing is a good way to start the testing journey but the journey needs to be continued with other types of testing too. With Int4 IFTT we also test different phases of the projects (more the Unit Testing and Integration Testing and less for UAT). From the functional perspective, Int4 IFTT can also virtualize external systems (legacy, B2B). So to conclude, Int4 IFTT is a more detailed engine for running the Test Suite if your company heavily relies on integration with other systems. Int4 IFTT is an SAP certified add-on installed on Solman (just like SAP Test Suite).

In our openSAP course ” Week 3 Unit 6 (last one)” we’re describing:

• The API for Int4 IFTT when you want to initiate Int4 IFTT runs/executions from other tools like Microfocus ALM: https://www.int4.com/int4-iftt-integration-with-alm/
• In the same lesson, you can find more about how to connect Int4 IFTT with defect management tools (like when run/execution fails Int4 IFTT connects to CHARM (or any other software) to create/update a defect.

Seeing that in DevOps a small team is recommended for efficiency we’ve designed Int4 IFTT in a way it’s easy to be used by 3 types of people:

• Developers (easy access SAP GUI, automated wizards for SAP PO)
•  Functional consultants (SAP GUI access, no SAP PO/SAP CPI/IDOC knowledge required to test integration flows )
• Testers (SAP GUI access, no SAP PO/SAP CPI knowledge required to test integration flows, Int4 IFTT runs can be executed from HP ALM)

Int4 IFTT and CBTA serve two different purposes:

• Int4 IFTT – for test automation of integration scenarios (SAP PO, SAP CPI, SAP AIF, IDOCs, Proxies, ABAP code) CBTA is a UI screen recorder (similar to ecatt) for testing User Interfaces

However – in case Int4 IFTT needs to simulate a complete SAP End to End process for integration flow where a certain activity needs to be done manually in SAP like:

• EDI sales order
• Manual step to create a delivery
• EDI delivery
• EDI invoice

Int4 IFTT can use (as one of the steps) ecatt or any other screen recorder (CBTA) and the same applies – any test in ecatt/CBTA can call Int4 IFTT to do an integration scenario test (via Int4 IFTT API).

Int4 IFTT can be and is very often used without SAP PO/CPI as shown in the S/4HANA conversion and ABAP backend lessons as it has IDOC, Proxy, AIF adapters. So you don’t need any middleware but still can test all SAP integration scenarios based on IDOCs, Proxies and SAP AIF. This is also a standard way how we test S/4HANA conversions as the demo system for conversion does not need to be connected to any middleware but still, we may want to test some scenarios.So the answer to this questions is: yes, we work like this quite often without SAP PO/CPI as Int4 IFTT is testing both parts of an interface middleware + backend implementation (they can be tested together or separately).

The functionality which handles that in Int4 IFTT is called Landscape configuration where you configure all systems with their respective names (as in SLD) so the changes are happening on the fly during test case execution. It’s described in our openSAP course – Lesson 1 of Week 3 in more detail.

Int4 IFTT is an SAP certified ABAP addon so you can deploy it on any ABAP based system (like ECC, S/4HANA). We, however, recommend to deploy it on SAP Solution Manager as a central instance connected to all existing systems.

Yes, there are alternatives to include UI testing in Int4 IFTT (as for this eCATT is used). In week 3 of the openSAP course, you will see Int4 IFTT API that allows for calling test cases from other testing tools like CBTA, Microfocus UFT, Tricentis Tosca. In such a case, the record & playback function will be delivered by them, and the application interface test cases will be executed and validated by Int4 IFTT. The difference is that test case orchestration will be maintained in the external software.

Int4 IFTT is used mainly for test automation of integration flow scenarios (virtualization of sender systems like B2B, legacy, etc. and then comparing the final result: either message after mapping or the final business document created in the backend system). At the same time, Int4 IFTT supports ecatt for UI flows (for example, when you build a process like order to cash in Int4 IFTT’s EDI order, EDI ASN, EDI invoice but one of the steps like ASN creation needs to be done manually and not with the interface, Int4 IFTT uses ecatt for doing that). Those kinds of processes will be shown in Week 2 and Week 3 during lessons with ABAP backend support. So to conclude Int4 IFTT is doing integration flow testing and not UI scripting (ecatt), about cbta (we will probably add its utilization in Int4 IFTT) but due to the scriptless nature of Int4 IFTT (tests are created from real messages and don’t need to be done manually), it’s not a priority right now.

SAP E2E means we only test all SAP applications (SAP middleware: SAP PO, SAP CPI + SAP business systems, ABAP code, customizing, SAP AIF, business documents). So all non SAP systems are completely virtualized hance not required for the test. This means since SAP is in most cases the most “changed” system, we want to make sure we at least have it tested (so bank, EDI system, other legacy applications are not required to run the test at all: as those are virtualized by Int4 IFTT). This kind of approach is very important for us as we want to enable earlier stages of testing. Many companies don’t have any automated testing but they want to start with full E2E flows which in most cases fails due to the complexity and maintenance later one. We believe it’s easier to start with testing just SAP system and only do something more once you have this mastered.

SAP PIT was designed for a single purpose only: to help developers do the SAP PO migration. Int4 IFTT, on the other hand, was designed to help to implement continuous testing across all SAP middleware technologies, so SAP PO migrations are just one of the many different use cases.

•  Int4 IFTT supports testing of the complete SAP integration (SAP middleware but including ABAP backend postings as mentioned in Units 2.4 and 3.5 of our openSAP course).
•  Int4 IFTT supports SAP CPI (and SAP PO to SAP CPI migrations from Units 2.3 and 3.4) of the course.
• As Int4 IFTT supports ABAP backend implementations also SAP AIF and all users exist/ABAP enhancements are thoroughly tested.
• For the continuous testing Int4 IFTT was also designed to support daily runs and rollouts performed in SAP GUI by testing teams/functional teams (and not only by developers as with PIT where you need to use Netweaver Developer Studio to work with that).
•  Int4 IFTT also supports building E2E flows if required (tight ecatt, CBTA integration)
• Another main difference is out of the box support for external tools integration like (Microfocus ALM, SAP CHARM).
• There are many other low-level differences even in Int4 IFTT even for SAP PO testing (like adapter module support: B2B, flat files compare, SAP PO multi mappings) and more of them are described here: https://www.int4.com/sap-test-tool-pit-sap-po-7-5-sp14/.

As for the Solman version: Int4 IFTT can work with any available version of Solman.

There are many use case scenarios supported by Int4 IFTT:

• SAP middleware only: (SAP PO/SAP CPI, migrations.) where we only test messages (with routing, adapters, etc.) so in those cases, masterdata is not required at all ? so you can easily take the messages from production landscape and run those on any other landscape (dev, test, etc.)
•  ABAP backend, S/4HANA, SAP AIF, End to End scenarios: in those cases, you need to have correct master data but in those cases we mostly create scripts for each landscape (and not run them across landscapes). Unless we do S/4HANA conversion then in most cases the sandbox where you test the conversion is a copy of the production system so you can use production master data to check if the S/4HANA conversion did not change anything in your integration scenarios.

The only Personal Data that we need to process are limited to name, surname and email address of the given Customer representative. For more please have a look at our Personal Data Protection Notice