Automated testing tool for PI interfaces?

[Former Member]

Hi,

Is there a best practice for automated testing of PI interfaces?

The focus will be on simple unit test. However, sometimes would be beneficial to test that data are updated in the receiving SAP system based on the message.

Regards

Dagfinn Parnas

[MichalKrawczyk · Accepted solution]

Hi Dagfinn,

I'm preparing such a best practices document for GSIG for PI (global support interest group for PI)

and we will be discussing about it soon (1-2.10.2012) during the GSIG meeting,

there are tools on the market which allow automation of testing with end to end (also with SAP data creation and checking that automatically) so please stay tuned

Regards,

Michal Krawczyk

[Former Member · Accepted solution]

Hi,

Will be interesting to follow your best-practice document.

In my case, the PI interface are quite light and do not contain any major orchestration/transformation.

Therefore, in order for the automated test to provide value, we should:

• For incoming messages also validate that the proxy in SAP receives the data and the following handling returns the expected result
• For outgoing messages, start the test from the program that directly or indirectly triggers the PI interface (and check the outgoing message from PI towards expected result)

I have gotten a few tips that soapUI might be suitable as it has functionality for generating test cases as well as integration with build engines such as Hudson/Jenkins.

However, it will not be able integrate with SAP in a deep way and I believe therefore it is not suitable for my requirements.

I'm currently looking a bit closer at the Test Automation Framework in Solution Manager 7.1. Could be that it is the best starting point for implementing automated tests where interfaces are involved.

http://scn.sap.com/community/it-management/alm/solution-manager/blog/2012/04/05/test-automation-fram...

Regards

Dagfinn

[MichalKrawczyk · Accepted solution]

Hi

>>>>For incoming messages also validate that the proxy in SAP receives the data and the following handling returns the expected result

end to end testing tools don't care about the middleware to be honest - it will

check the final result in a transaction in SAP - so it's even better then just doing any sort of validation as this might be different each time you use a different protocol

>>>>For outgoing messages, start the test from the program that directly or indirectly triggers the PI interface (and check the outgoing message from PI towards expected result)

that's a standard case I guess

>>>>I have gotten a few tips that soapUI might be suitable as it has functionality for generating test

this tool does not work with async interfaces so it's not able to do any of the mentioned points I believe automatically

>>>>I'm currently looking a bit closer at the Test Automation Framework in Solution Manager 7.1.

check it out but as it works only with SAP software it might be difficult to do an automated end to end test with it unless you have SAP on both ends,

Regards,

Michal Krawczyk

[Former Member · Accepted solution]

Thanks again for the feedback,

A full end-to-end testing would of course be preferable, but to be realistic I believe my scenario will focus the testing the SAP landscape (PI + ABAP backend).

Right now my thoughts are:

1. Define an eCatt script for each of the interface we have

2. Run the eCatt scripts as part of the new test automation framework in SolMan 7.1

3. Use SolMan eCatt scripts for creating complex business objects that can be used as test data.

(already have some of the scripts running on a daily basis)

4. Simple static test data (such as SOAP messages) can be defined through test data attached to the test script in SolMan

5. Create an eCatt script for each interface you want to test. This test script will call a custom built transaction and provide input values for interface id and test data.

6. The custom built transaction will identify the suitable ABAP test class (which uses the ABAP unit framework for utilities) and pass the parameters to it.

7. The ABAP test class will contain the implementation of the test.

Based on the interface it can perform different actions:

• Perform SOAP request
• Call Proxy class in ABAP (proxies defined in SPROXY) for outgoing interfaces
• Call business logic for updating the test data

8. The ABAP test class will also be responsible for evaluating if the results match the expect ones. Based on the interfaces it will perform different validations:

• Check return status on SOAP request
• Asynchronously check SXMB_MONI in PI for expect messages and contents
• Verify that test data has been updated as expected

9. A summary of the test will be provided back to the transaction that initiated the ABAP test class. It is good enough to know if one or more test failed. This will then be picked up by the eCatt script and reported as an error to the Test Automation framework.

Overall the work for setting up such a concept is quite low and the benefits should quickly outweigh the cost.

Regards

Dagfinn