How to sniff SAP CPI and SAP PO requests

r_herrmann · ‎04-10-2020

As no one can resist a cute puppy and you are already here, let us use your attention to learn something new today!

Today's blog post is about how HTTP(S) requests from SAP PO and SAP CPI can be recorded aka "sniffed" and the analyzed. But before we dive into the practical implementation, let's take a little look at the "why". Why should you be interested in recording the requests and when does such a feature benefit you?

So in the following minutes we will discover and answer the following topics.

When and why to sniff HTTP(S) requests

If I have to address a new API in a SAP CPI or SAP PO interface, I usually test this API in advance via Postman or SoapUI and familiarize myself with it. If I have found out in the above mentioned tools how the call (which content? which url parameters? which header? which HTTP verb?) works, I rebuild it in the SAP interface.

Most times things go well, but sometimes the apparently completely identical call in SAP CPI/SAP PO does not work. In this case, it's hard to find out what's wrong, because theoretically the call should be identical to the one in the working Postman/SoapUI example. When sniffing the results done in Postman/SoapUI and SAP CPI/SAP PO with a neutral tool and then comparing the results, you can find out the differences and trace down the issue.

In addition to such situations, it can be helpful to record the requests to answer questions such as the following:

Does the used SAP PO adapter add some additional header?

Does SAP PO/SAP CPI use the headers I set up in the interface before?

From which IP address does my request reach the recipient? (This may help to find out the routing and your public IP in case you are using a proxy server or a complex network infrastucture.)

What exact requests are done, when using OAuth credentials in CPI or the OAuth handler(s) of SAP PO adapters and how does their content/headers look? (Real-world example)

Now that the purpose of sniffing is clear, let's see how this works in practice.

If the request targets the internet

In case your target API/service is hosted and reachable via internet, we can trace the requests by online sniffing tools. The one I prefer (mainly because its ease of use) is called requestcatcher.com.

To sniff any request go to requestcatcher.com and choose a unique name for your session. (Be careful when setting this, because everyone knowing the session name can see your requests too. Thus it's a good idea to use anonymized data for your tests and use a random session name. You could generate one e.g. with random.org tools.)

When you have entered a session name, you will be redirected to the requestcatcher-userinterface as shown in the screenshot above. Copy the interface url (1) and set it as target url in you SAP PO or SAP CPI receiver adapter or SAP CPI credential pair (or anywhere else where a webservice url can be configured.

Then run your interface/resend a message on or trigger your receiver adapter the way you like. As soon as SAP PO/SAP CPI do their requests, they will appear on requestcatcher's interface as shown below.

Note: If you ran your interface and no requests shows up, you have a clue that something with your network settings/firewall/proxy might be wrong.

That's it. Now you can trace down, what your SAP CPI/SAP PO interface is really sending. With this knowledge you hopefully can identify problems way faster, when setting up the next web service.

If the request targets the local network

The example above made use of the internet service "requestcatcher.com". But what, if you target service is placed in your local network. Testing the requests with an internet-based sniffer wouldn't be a good idea, since when directing your SAP PO to the internet, the request may go a total different way through your network, probably hopping over multiple proxies which could change your request. So when it comes to sniffing a locally targeted request, I suggest to use a local sniffing tool.

Again there are a lot of tools, but I personally had very good experiences with Fiddler Everywhere and therefore I will only go into this in the following.

Download Fiddler Everywhere (It's available on Windows, Mac OSX and Linux)

Run the setup

Launch Fiddler

Fiddler acts as a proxy server which sniffs for you the traffic. The advantage? You configure Fiddler as proxy into your SAP PO channels, but keep the original target. That way you can test and at the same time inspect your complete traffic flow.

After launching Fiddler for the first time, you have to setup Fiddler for use as SAP PO proxy. Therefore go to the settings page, write down Fiddler's port and activate "Allow remote computers to connect".

Then head over to your SAP PI channel and configure Fiddler as a proxy. The proxy ip address is the ip address of your computer/the computer Fiddler runs on. (Open CMD/terminal and type ipconfig /all on Windows or ifconfig on Linux/OS X to find our your computer's ip address.) The proxy's port is the one you wrote down from the Fiddler settings page.

Then (re-)run your interface. If you have correctly setup everything, the request of your SAP Po should occur in Fiddler's request view on the left side. (See screenshot below.)

Clicking on a request, sniffed with Fiddler, brings up request and response details on the right-hand pane of the application. That's it!

Conclusion and Advices

Both presented tools have helped me in the past to solve tricky situations. But you should always keep the following things in mind.

Always choose the sniffing tool according to the location of the web service you want to address. If the service is located on the Internet, choose a sniffing tool on the Internet, if the service is on-premise, host a local sniffing tool. This is the only way to ensure that the routing/network conditions can be realistically analyzed.

The main purpose of such tests is to see if headers are set correctly or if the payload is encoded correctly. The actual content of the payload is often irrelevant. So whenever possible, remember to anonymize the payload with pseudo data to avoid sending sensitive data to sniffer tools. (In theory, these tools adhere to data protection guidelines, but in practice something that didn't get there in the first place cannot be leaked. Data economy is a key term here).

Finally, I would like to know if and if so, which tools you use to analyze SAP CPI/SAP PO requests.

Note: I was pointed in the comments by Eng Swee that there's another great article series on HTTP sniffing. If you are still interested in the topic of HTTP tracing, you should put Ariel's series on HTTP tracing as next item on your "what to read"-list.

(Cover picture licensed under CC BY 2.0 by Steve Jurvetson)