Why should we test interfaces ?

During the development phase there is a major riskof an error caused by the newly implemented changeto the already functioning configuration.

Possible consequences of such error:

• Stopping production or distribution – veryserious and expensive issue which might leadto decrease of IT’s reputation

• Posting incorrect documents on the productionsystem

• The deliveries could be processed on wrong datesor 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 impossibleto revert the changes due to lack of the sourceof data

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

To prevent this from happening a proper processfor interface regression testing should be introduced.

However if this process is manual following concernsappear:

• 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 softwarefor automated testing but most of it is dedicatedto single systems. There are only few tools designedspecifically for interface testing and one of themis INT4’s IFTT. IFTT’s uniqueness baseson special concepts that could have beenimplemented only because the tool is tailoredexclusively for SAP.

IFTT Interface Testing Tool is an int4 software productfor automatic SAP interface testing. It is providedas an ABAP add-on installed on a backend system.

The Add-on has been officialy certifiedfor integration with SAP NetWeaver 7.40 viathe SAP integration scenario ABAPAdd-On Deployment for SAP NetWeaver. It has beenalso certified for integration with SAP S/4HANAon-premise editions: 1511 and 1610 via the SAPintegration scenario ABAP Add-On Deploymentfor SAP S/4HANA.

It’s main purpose is to fully test SAP interfacedevelopment after any source code / configurationchanges.

1

2

3

IFTT Scope

IFTT covers not only the middleware platform(in this case SAP PI/PO, but the architectureis open and other middlewares could besupported) but also ECC landscape Inbound,outbound and synchronous interface scenariosare supported. IFTT can provide the regressiontesting of the whole business proces. The wayin which the 3rd party system communicateswith the ECC is not relevant and all PI/POadapters are supported.

If the source message has not changed IFTT canstill test the full scope without the needfor the 3rd party partner to send the newmessages. The testing proces is independendof external resources.

The test cases can be orchestrated and runin sequences. Some steps in the interfaceprocesses can be manual and they are supportedin the IFTT through integration with eCATT– a standard SAP tool for recording and playbackof user actions. Thanks to the eCATT integration,all scenarios that require manual user actionsare still fully automated.

4

IFTT Scope

The integration and the application interfacesare built on many levels. It is combinationof technical connectivity and functional logicto process data from one documen to another.IFTT tests all the layers.

IFTT tests following technical requirements:

• 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 thatthe final business document was created properly on the ECC side.

7

Test Case Execution – inbound interface

IFTT provides fully automatic test caseexecution.

When the test case is created, the further testingof the SAP part is not dependent on the3rd party software. IFTT mocks the 3rd partysoftware and sends the message in its name.The message is previously enriched to createthe final document with a new businessdocument number. SAP PO receives the messageand starts to process it in a regular way.

When the processing is finished and the finalbusiness document is created in the backendsystem IFTT generates the report of comparisionbetween the reference business document keptin the snapshot and the final business documentcreated during the test case execution.

8

The Assertions

Using IFTT does not require assertion creationfor every test case.

Assertions are defined for each businessdocument separately, and once only duringthe tool configuration. IFTT validatesthe whole document providing a reportof all unacceptable differences.

The Assertion results

Assertions for inbound interfaces in IFTTare based on comparison of final businessdocuments i.e. sales orders.The assertion screen displays the Test CaseStatus: failed or passed. If the test case failesIFTT presents the detailed resultsof documents comparison.

In the sample screenshot both document headerand items are visible:

• lighter rows -> original reference document• darker rows -> newly created document

In this example something has failedwith the material determination. The material IDvalues are different in two compared documents– they are marked red, to indicate the error.The yellow color is used to mark inconsitencieswhich are acceptable from the businessperspective. They are treated as a warning only,and do not cause the executed test case failure.

9

Test Case Execution – outbound interface

In terms of testing the outbound scenarios IFTTstill checks e2e the SAP layer. Duringthe test, the creation of the messagein the backend should also be covered.

Test cases can be created in two ways:

1. The inbound test case generatesthe response by itself ( i.e. EDI sales ordercreation generates EDI sales orderconfirmation )

2. The interface is triggered due to manualaction. ( action recorded & replicatedby an eCATT script )

The second part of the test caseis an output message that will be receivedby 3rd party. This XML message is foundby IFTT on the middleware thanks to theinterface name and namespace storedin the business obj. definition. Once foundit is fetched and compared with the referencesnapshot.

IFTT is able to delete messages after theircreation to prevent sending test casesto the real 3rd party software.

10

XML comparator tool - assertions

In outbound and synchronous interfacescenarios XML messages are compared:

• the reference message• the new xml message created as a result

of a test case execution

IFTTs XML comparator tool automaticallycompares all fields of the two XML messages,By default, if the value of the compared fielddiffers it marks it with not equal sign indicatingan error.

Exceptions can be set as a part of configurationi.e. differences between values of selected fieldscan be marked as a warning.

11

Support for business processes

IFTT is able to group single test cases into process chains and perform the testing on the whole business process level.Thanks to the variable concept (part of business objects) the relations between documents are passed between themduring the test case execution. IFTT also supports 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 sendPurchase Order XML. It then produces an IDOCwhich triggers Sales Order creation on the ECCsite, with IFTT add-on installed on.

Using IFTT test cases can be created, to test thisparticular interface in the future. There is noneed to involve third party resourcesto create test cases. It is enough to use existingdocuments created by this particular interface.The documents for test case creation must bevalidated from business perspectiveso the potential approach is to take the resultdocuments from the User Acceptance Tests.

In order to create inbound test cases in IFTTit is enought to provide the numbers of thedocuments with descriptions, and the interfacetype.

13

Interface Change Implementation

Customer C, which contains some localrequirements, has to be incorporated to use thesame interface. The interface has to be testedafter implemented changes in orderto determin if it works as before the changefor the other customers.

After running the created cases IFTT willgenerate the results of comparison between twodocuments: the original, reference message andthe new message created

as a result of the test case execution.If the business documents sent by customersA and B are created incorrectly IFTT will indicatewhich fields contain errors.

14

Non-SAP System Virtualization

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

IFTT solves this issue as it allows to emulate 3rdparty systems on SAP instances without beingconnected to them. Documents (messages)created by 3rd party systems, can be storedand run on other enviroments.

15

Where can we benefit from using IFTT?

PI & ECC upgrade,

• Test case creation• upgrade of PI or ECC (any ABAP Backend),• Test case execution - checking if interface

related processes behave as before

Rollout project

Automating regression testing of interfacesboosts rollout projects. Typically core interfacesdeveloped during template are extendedand used by many other sites with new localrequirements. IFTT allows to test if all sitesalready in production can continue to use theirapplication interfaces unaffectedly.

Regular development process

During green field SAP implementaions IFTTallows to speedup development. Developeror functional expert can proces same messagescontinously without engaging 3rd party partners.It reduces cost of 3rd party external expertsas they don’t have to be availableall the time. The testing is also quicker thanksto the 3rd party non-SAP virtualization concept.

Regular system maintenance

The live-cycle of the IFTT is as long as the SAPsystem itself. Nowadays the business processesare very dynamic and they are changed oftendue to business needs (new clients, vendors,mergers and aquistions, legislation requirementsand business improvement projects)so the enterprise integration architectureis also adjusted and changed very often.The IFTT guarantees system stabilization in thisarea and makes business more confidentthat no matter what new functionalities they willrequest, still all interface processes will workon production as desinged. Usually testing usingthe IFTT becomes a part of monthly transportwindow process. All interface changes that areimported to production systems are at firsttested and confirmed by IFTT.

16

17

18

19

Key features

1) IFTT allows for quick test case creation and execution.

• Multiple test cases can be executed within one click.

2) It has got a flexible configuration – that has to be one only once for each interface.

• There is no need for defining the assertions for each test case created. Done only once per each interface.

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