Why should we test integraton and application interfaces ?

During the development phase there is a major risk of an error caused by the newly implemented change to the already functioning configuration. Possible consequences of such error: • Stopping production or distribution – very

serious and expensive issue which might lead to decrease of IT’s reputation

• Posting incorrect documents on the production system

• The deliveries could be processed on wrong dates or with incorrect quantities

• It could take very long time to trace the mistake

• Thousands of incorrect documents could be created by that time

• A lot of manual effort would have to be put in reverting changes and fixing documents. After some time it might even be impossible to revert the changes due to lack of the source of data

• Legal or reporting issues – wrong taxes or wrong information reported to the shareholder

To prevent this from happening a proper process for interface regression testing should be introduced. However if this process is manual following concerns appear: • It is time-consuming

• it is expensive • it is not repeatable • it is not error free • we are limited to small number of cases that

can be tested How can manual regression testing be automated? On the market there is a lof of software for automated testing but most of it is dedicated to single systems. There are only few tools designed specifically for interface testing and one of them is int4 IFTT. Int4 IFTT’s uniqueness bases on special concepts that could have been implemented only because the tool is tailored exclusively for SAP. Int4 IFTT Interface Testing Tool is an int4 software product for automatic SAP interface testing. It is provided as an ABAP add-on installed on a backend system. The Add-on has been certified for integration with SAP NetWeaver 7.40 via the SAP integration scenario ABAP Add-On Deployment for SAP NetWeaver. It has been also certified for integration with SAP S/4HANA on-premise editions: 1511 and 1610 via the SAP integration scenario ABAP Add-On Deployment for SAP S/4HANA. It’s main purpose is to fully test SAP interface development after any source code / configuration changes.

1

2

3

Int4 IFTT Scope IFTT covers not only the middleware platform (in this case SAP PI/PO, but the architecture is open and other middlewares could be supported) but also ECC landscape Inbound, outbound and synchronous interface scenarios are supported. IFTT can provide the regression testing of the whole business proceses. The way in which the 3rd party system communicates with the ECC is not relevant and all PI/PO adapters are supported. If the source message has not changed IFTT can still test the full scope without the need for the 3rd party partner to send the new messages. The testing proces is independend

of external system and their resources. The test cases can be orchestrated and run in sequences. Some steps in the interface processes can be manual and they are supported in the IFTT through integration with SAP eCATT. SAP eCATT is a standard tool for recording and playback of user actions. Thanks to the eCATT integration, all scenarios that require manual user actions could be still fully automated.

4

Int4 IFTT Scope The integration and the application interfaces are built on many levels. It is combination of technical connectivity and functional logic to process data from one documen to another. IFTT tests all the layers. IFTT tests following technical requirements: • Adapter modules (B2B Add-on

conversions) • middleware interface determinatioon • message mappings • lookups

• BPMs • backend interface logic i.e. ALE or ABAP

user exits

IFTT tests following functional requirements: • AIF – Advanced Interface Framework • system customizing -> both for the

interface and module settings • output configuration and others

5

6

SYNCHRONOUS interface: the test case is a mixture of inbound and outbound. To test a synchronous interface it is necessary to make sure that the final business document was created properly on the ECC side.

7

Test Case Execution – inbound interface IFTT provides fully automatic test case execution. When the test case is created, the further testing of the SAP part is not dependent on

the 3rd party software. IFTT mocks the 3rd party software and sends the message in its name. The message is previously enriched to create the final document with a new business document number. SAP PO receives the

message and starts to process it in a regular way. When the processing is finished and the final business document is created in the backend system IFTT generates the report of comparision between the reference business document kept in the snapshot and the final business document created during the test case execution.

8

The Validations Using IFTT does not require assertion/ validation rules creation for every test case. Assertions rules are defined for each tested interface only once during the tool configuration and are reused for all the test cases of particularly tested interface. The validations of testing inbound interfaces are based on comparison of final business documents created by the interface i.e. sales orders. This guarantee that all different interface layers are working properly and documents are created as designed from their functional perspectve. The report displays the Test Case Status: failed or passed. If the test case is failed then the field by field documents comparison is presented. In the sample screenshot both sales order header and items are visible where:

• lighter rows -> shows values from the

reference document • darker rows -> shows values from newly

created document In this example something has failed with the plant determination. The reference and newly created document have different values so they are marked as red, to indicate the error. The yellow color is used to mark inconsitencies which are acceptable from the business perspective. They are treated as a warnings, and do not cause the executed test case failure.

9

Test Case Execution – outbound interface In terms of testing the outbound scenarios IFTT still checks e2e the SAP layer. During the test, the creation of the message in the backend should also be covered. Test cases can be created in two ways: 1. The inbound test case generates

the response by itself ( i.e. EDI sales order creation generates EDI sales order confirmation )

2. The interface is triggered due to manual action. ( action recorded & replicated

by an eCATT script ) The second part of the test case is an output message that will be received by 3rd party. This XML message is found by IFTT on the middleware thanks to the interface name and namespace stored in the business obj. definition. Once found it is fetched and compared with the reference snapshot. IFTT is able to delete messages after their creation to prevent sending test cases to the real 3rd party software.

10

XML comparator tool - assertions In outbound and synchronous interface scenarios the last processing step is sending a message to the receiver system. Int4 IFTT fetchs those messages and compares the reference message with the newly created message as a result of the test case execution Exceptions can be setup as a part of configuration i.e. If the interface logic populate current date we cannot expect to be the same on reference and the newly created message.

In the same way flat files are compared

11

Support for business processes Int4 IFTT is able to group single test cases into process chains and perform the testing on of the full business process. Thanks to the variable concept (part of interface configuration objects) the relations between documents are exchanged between each other during the test case execution. Int4 IFTT supports also automatization of manual actions between execution of interfaces (integration with SAP eCATT)

12

Sample use case: common interface In this sample scenario two customers: A and B, use a Common Interface to send Purchase Order XML. It then produces an IDOC which triggers Sales Order creation on the ECC site, with IFTT add-on installed on. Using int4 IFTT test cases can be created, to test this particular interface in the future. There is no need to involve third party resources to create test cases. It is enough to use existing documents created by this particular interface. The documents for test case creation must be validated from business perspective so the potential approach is to take the result documents from the User

Acceptance Tests. In order to create inbound test cases in int4 IFTT it is enought to provide the numbers of the documents with descriptions, and the interface type.

13

Interface Change Implementation Customer C, which contains some local requirements, has to be incorporated to use the same interface. The interface has to be tested after implemented changes in order to determin if it works as before the change for the other customers. After running the created cases int4 IFTT will generate the results of comparison between two documents: the reference message and the new message created as a result of the

test case execution. If the business documents sent by customers A and B are created incorrectly int4 IFTT will indicate what is wrong.

14

Non-SAP System Virtualization Usally there are more instances of SAP than the 3rd party systems (project-dev, test, maintenace-dev, QA, consolidation, integration, production). Only one of the SAP test or development enviroment is connected to internal or external 3rd party software to run processes e2e by application interfaces. This leads to delays in development interface changes and makes testing more difficult.

Int4 IFTT solves this issue as it allows to emulate 3rd party systems on SAP instances without being connected to them. Documents (messages) created by 3rd party systems, can be stored and run on other enviroments.

15

16

Benefits of int4 IFTT appliance: SAP PI/PO & ECC upgrade Steps: • Test case creation from existing

documents in the system • upgrade of PI or ECC (or any ABAP Backend

system) • Execute all test cases and validate if

interface related processes behave as before

Rollout project Automating regression testing of interfaces boosts rollout projects. Typically core interfaces developed during the template are extended and used by many other sites with new local requirements. IFTT allows to test if all sites already in production can continue to use their application interfaces unaffectedly. Regular development process During developng SAP interfaces int4 IFTT allows to speed-up development (idea of continues development).

Developer or functional expert can process same messages continously without engaging 3rd party system. It reduces cost of 3rd party external experts as they don’t have to be available all the time. Regular system maintenance The livecycle of the int4 IFTT is as long as the SAP system itself. Nowadays the business processes are very dynamic and they are changed often due to business needs (new clients, vendors, mergers and aquistions, legislation requirements and business improvement projects) so the enterprise integration architecture is also adjusted and changed very often. The int4 IFTT guarantees system stabilization in this area and makes business more confident that no matter what new functionalities they will request, still all interface processes will work on production as designed. Usually testing using the int4 IFTT becomes a part of monthly transport window process. All interface changes that are imported to production systems are at first tested and confirmed by int4 IFTT.

17

18

19

Key features

1) IFTT allows for quick test case creation and execution. • Multiple test cases can be created and executed within one click. 2) Flexible configuration – that has to be setup only once for each interface. • There is no need for defining the validation rules for each test case created.

3) IFTT saves time – both during the development and the further maintenance. • No need for engaging 3rd party resources in order to perform the testing. 4) IFTT testing scope covers the full landscape – both functional and technical side.

20

21