Why testing your SAP PI/PO system is important and how you do make a business case for it. Check out https://figaf.com/IRT

1. Why you should test
SAP PI/CPI
© Figaf 2019

2. • 15+ years as integration
developer with SAP
• SAP Mentor
• Father
Daniel Graversen

3. Why testing

4. What is the impact of failures in your business
● It is not just the support for PI developers
● One failed message can
○ You did not meet production delivery planning
○ Could not deliver order for customer
○ Break SLA with customer
○ Lose of customer
● Connection to critical interfaces could shutdown production
● Extra work for business and developers to fix problem
Integration is critical to your business

5. Types of testing

6. Upgrade and patches
Ensure that a patch installation will not affect your system
Potential changes can affect
● Message mappings
● Adapter modules
● B2B capabilities
● Adapter processing

7. From the SAP roadmap there is a limited functionality being added that
could affect the PI.
Small features are planned
You will still have to upgrade to get the newest option to run CPI on
your PO. Here new innovation will happen more often, and if want to
use the function it is a requirement to upgrade often to simplify your
development
March roadmap https://www.sap.com/denmark/products/roadmaps.html#pdf-asset=8ce1a128-c37c-0010-
82c7-eda71af511fa
Will we see as many updates in future

8. When a developer have made a change to an interface you need
regression testing to ensure it does not affect other areas
Make sure it does not break something that was not planned
Testing affected interfaces where function is used
Test after each change

9. Normally you cannot make a change to a User Defined function Library
because you do not have an idea on its affect on other parts of the
application.
Try to modify an UDF?

10. SAPs new Testing tools

11. Collect data from production system
This will give you an input and expected output
Send the input in to development system
Fetch the new test data output
Run comparison with expected output
Testing idea

12. Comes free with your SAP PO 7.5 sp14
Easy to install just a patch and a config wizard
Just add some roles to your users to create test cases
No extra development
Will be developed future as pr SAPs roadmap
Fetch data from dual stack
Good

13. The first test
Lot of manual steps
Only simple patterns supported
No module testing -> so no EDI comparison
You can only run one interface at the time
Easy to see if small changes have been made like one item. If
something with the structure it becomes difficult.
Challenges

14. ● You may need to implement OSS Note 2650265 which is an upgrade
to MESSAGING SYSTEM SERVICE released with the testing tool. This
can apply on many 7.31+ sp levels
● If it is a long time since you have upgraded you will need to patch
your systems and all the depended patches
● You cannot test this with the SAP tool. You will have to do manual
testing.
● Then you can collect test data on your 7.5 SP14 system and run
tests on it. That way you cannot do a before and after of the
upgrade.
First test challenge

15. Demo of the SAP testing tool

16. Want to test your first upgrade
Easier to use
● Collect test data and setup test cases faster
● Cover more patterns, modules, bridges and comparison
● Run multiple test cases at the same time
● Can use data from your first upgrade
● Generate reports of changes
Integrates with a development lifecycle tool so you can run test based
on what is changed
One tool for both PI and CPI
Why you need a better tool

17. Demo of the Figaf testing tool

18. Reason and benefits of tools

19. Your developers leaves, how do you know how the interface should
work.
There maybe some documentation, but is it updated and how do you
really test the function.
Keep knowledge

20. Be able to perform you upgrade faster
Faster deployment of changes to production
Short term benefits

21. Less errors with your integration
Better documentation of changes
Be able to fix your interfaces even when developers leave
More stabile enviorment
Long term benefits

22. Business case

23. © Figaf 2019
Hourly cost 80
Number of ico 200
Changes pr year 300
Number of support packs pr year 2
Assumptions
https://figaf.com/how-to-build-a-business-case/

24. © Figaf 2019
Time
required pr
instance
Number of
ICOs Hours Price Pr year Cost pr year
Normal PI testing
Test an interface when changing
mapping 120 1 2 160 300 48.000
Support packs installations testing 60 200 200 16000 2 32.000
Total 80.000
Testing price

25. © Figaf 2019
Time
pr instance
Number of
ICOs Hours Price Pr year Cost pr year
Normal PI testing
Test an interface when changing
mapping 120 1 2 160 300 48.000
Support packs installations testing 60 200 200 16000 2 32.000
Total 80.000
Testing with IRT
IRT server 15.000
IRT installation and configuration 5.000
IRT create test cases 10 200 33 2667 1 2.667
Test an interface when changing
mapping 5 1 0 7 300 2.000
Support packs installations testing 10 800 2 1.600
Total with IRT 24.667
IRT testing

26. If we do not test
• Could be a bomb
• Failure in your business
• Impact relationship with
partners
• Legal
• Cost money
• Support
• Fix problem again
• Change management
• Lost time with business
© Figaf 2019

27. © Figaf 2019
Cost of not testing
Price Pr year Cost pr. year
Support cases 320 30 9.600
Rollback and start over 20.000 0,3 6.000
Lost business because
of errors
20.000 1 20.000
System down 100.000 0,5 50.000
Total for errors 85.600

28. © Figaf 2019
Documentation
Time required
pr instance
Price Pr year Cost pr. year
Normal
Documentation
90 120 300 36.000
IRT DevOps
additional
10.000
IRT
Documentation
15 20 300 6.000
Total with IRT
documentation
16.000

29. https://figaf.com/IRT
Try Figaf IRT on your own
Free trial