WSO2Con2024 - GitOps in Action: Navigating Application Deployment in the Plat...
Int4 and IFTT @ SAP SIT Berlin 2017
1. The challenges in E2E SAP application
interface testing
int4 presentation for SIT Berlin
Date: 2 September 2017
@sitBER 2017
Who: Frank van der Plas
Michal Kowalczewski
Contact: iftt@int4.com
2. Agenda
• Introduction
• The challenges in E2E SAP application interface testing
• The int4 vision to address this challenges
• Demonstration of automated interface testing
3. Company profile
• Founded in Poznan, Poland in 2010.
• int4 consultants have both SAP middleware (SAP PO/PRO/EDI), SAP
development (ABAP, IDOC, ALE, SAP AIF, HANA) and SAP module
certification and experience which not only allows them to design and
develop an interface but also to test it correctly.
• One face for One interface
• Michal Krawczyk is an SAP Mentor since 2007
4. Q: How confident is your ALM
team with a deployment to
production of an application
interface change ?
5. Cost of late detection of application interface
issues in ALM cycle
Preliminary estimates of relative cost factors of correcting errors as a function of where errors are
introduced and found . (X) relative cost unit
Where errors are
introduced
Where errors are found
Blueprint Configure, code
unit test
Functional
integration test
UAT
Pre-production
Post go-live
Blueprint 1X 5X 10X 15X 30X
Configure/code/unit
test
1X 10X 20X 30X
Functional/
integration test
1X 10X 20X
Source: The economic impact of inadequate infrastructure for software testing
National institute of standards and technology . May 202
6. The integration domains and interface points
On-Premise
Business
Partner
B2B
Cloud
OnPremise2Cloud
Real World
Objects
User2OP
User2Cloud
Non-SAP
Clouds
Business
Suite
OP2OP
Non
SAP
Thing2OP
Thing2CloudNon SAP
Cloud Apps
Clouds…
Cloud2Cloud
User-Centric
Applications
ISA-M Template Version 3.1
7. Interface testing in different integration styles
User-Centric
Consumption
How to integrate user-
centric applications with
business applications
Odata interface
Data
Movement
How to synchronize
data between business
applications?
Masterdata interface
Process
Invocation
How to chain business
processes across
business applications?
Transactional interface
Thing
Integration
How to integrate real
world things with
business applications?
Event interface
ISA-M Template Version 3.1
8. Manual E2E application interface testing
Prepare test data Execute test Validate
select input
file
Edi, xml, csv
Find unique
doc number
Edit file
BGM+220+DOCED6
0+9'
Connection
Details
password, userid,
connection tools
Ready to
execute test
Make
connection
Upload file
Run
Is the
business
document
created ?
If not check
monitors
Inspect new
business
document
Compare with previous
successful posting for
regression test
9. Cycling between functional and regression
testing
Implement
change
Functional
test
Validate
Regression
tests
After validation of test add to
regressiontest library
Execute existing and new
regression test
10. ABAP vs Application Interface Development
ABAP Application Interface Development
- Custom coding
- One technology & Enviroment
- Unit testing: Regular input / output
- Functional testing: Various final
interaction channels
- Custom coding
- Multiple Technologies & Enviroments: SAP PI-
PO/CPI/Backend
- Unit Testing: Different protocols & tools
- Functional testing: Similar final results - Documents or
Req./Resp.
But EAI helps to standarized it
Possibility of common validation rules ?
11. Our concept for an automated interface testing
solution
Goals
Concepts
Operations
Fast creation of interface test cases from existing messages
End to End Results in SAP enviroment
Provide a solution for continue application interface regressiontesting
Separate validation rulesets from test case
Compare documents based on database content
Automated E2E execution in SAP landscape and 3rd party system virtualization
Do not involve 3rd party experts in testing
Not only for integration developers but also for functional experts
http://www.springer.com/us/book/9783319593357
14. The application interface as part of a process
EDI SALES
ORDER
REQUEST
SALES ORDER
DELIVERY
&
WAREHOUSE
PICKING
EDI ADVANCED
SHIPPING
NOTIFICATION
Billing & invoice
document
EDI Invoice
15. Demo
Within int4 IFTT we support different SAP application interface testing strategies.
In this demo we will focus on the regression testcase and use a successful
functional test as input for the regression testcase.
DemoDemo
16. SAP test automation landscape
E2E SAP application interfaces testingE2E SAP UI and Module testing
DevOps : Automated Regression Testing is the Key to Success
SAP eCATT
How the testing of such scope is achieved ?
Going back to IFTT concepts, let me explain the first one – the quick creation of test cases.
What a Test Case is according to the IFTT definition?
When I was explaining the concepts I said that test cases can be created with one click by providing the GUID of the message.
In case of an INBOUND interface the test case is a combination of an inbound xml message from the middleware platform and the final business document
created on its basis on the backend side by the interface. This combination gives us what we call a snapshot:
Those snapshots are used as a reference for further execution
In case of an OUTBOUND interface the test case is a combination of an action (either manual or automatic to trigger the message) plus an output XML Message.
Let me highlight that this is a great advantage of IFTT: The test case creation is very fast and efficient.
When using a full business document as a snaphost you don’t need to define assertion rules for every single test case independently. The matching is done automatically and the only user role during test case creation is to provide the GUID number of the XML message (or an idoc number if this is an idoc interface).
-----
Tthis final document can be any document….Invoice, Sales Order,
Thanks to that we have reached the 3rd concept of IFTT. In fact you don’t need to prepare the assertions for every test case.
Thanks to IFTTs business object concept assertions are defined for each business document separately during the tool configuration.
You don’t need to focus on particular business feature of the document like for example:
taxes
GL account determination
delivery date
because IFTT can vailidate the whole document for you, providing you with a report of all unacceptable differences.
The definition of the documents is setup only once during the tool configuration so you don’t need to spend time on defining the assertions
when you create your test cases.
For this purpose we reflect in IFTT configuration the data model how SAP stores business documents internally. This configuration is done only once during tool customizing.
After execution of test cases IFTT can automatically compare reference documents (ligther rows) with newly created ones (darker rows) and automatically classify if the test has passed or not.
During the presentation we will highlight 3 principles that we had during the design
