Skip to Content
Author's profile photo Vijayashankar Konam

Zip stream Web Services communication using SOAP Adapter

Usually, in an organization, the service clients and the service providers are located in the same lan and are connected via high speed internal network connection. But sometimes, it could be that, the client applications are far from the service provider and the latency between the service calls could become a bottle neck.

To overcome this situation, in a typical browser and server communication, the web servers usually support zip stream communication, where the client announces to the server that it could accept a zip stream rather than the plain text html. The server then happily sends a zipped/compressed stream of response to the client. The client then locally unzips the stream ans displays it to the user. Both the server and clients are happy 🙂 . Is the same possible for web service? 😕

The same is possible between web service clients and servers since the SOAP protocol is based on HTTP as well. SAP PI provides a built in, ready to use solution for achieving this. There are few magical parameters that could be added to the SOAP communication channels (both sender and receiver) which do this for us out of the box. These parameters are hidden deep in the documentation and could only be found when you are actually looking for them.

They are –

Parameter Values Ussage
XMBWS.XMLEncoding iso-8859-1 etc Add the Content-Type HTTP header to the call.
XMBWS.TransferEncoding base64 Adds Content-Transfer-Encoding header along with encoding the payload.
XMBWS.Encoding gzip Adds Content-Encoding header along with encoding
XMBWS.AcceptEncoding compress, gzip Adds Accept-Encoding header to the call, so that the server knows that it can take zip stream

The above parameters when used in a sender SOAP adapter, makes the SOAP adapter to decompress the content. In sync scenarios, the response is encoded.

In a SOAP receiver adapter, the web service call is zipped and sent to the service provider.

You can use TCPGATEWAY for checking the actual HTTP data that is being exchanged between the client/server to confirm if the data stream is getting compressed for sure.


Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Prateek Raj Srivastava
      Prateek Raj Srivastava

      Hi Vj,

      Thanks for this information. To a large extent, the use of this functionality is limited by the server capability of zipping and unzipping the soap messages. Do you agree?

      Have you actually tried to check the payload size before and after using this parameter? What were the results?


      Prateek Raj Srivastava

      Author's profile photo Vijayashankar Konam
      Vijayashankar Konam
      Blog Post Author

      Yes I do agree. I tried to do this in a module, but that was not possible. had to live with what the adapter has to offer. Otherwise, the only solution is to write our own SOAP adapter.


      Author's profile photo Nageshwar Reddy
      Nageshwar Reddy

      Thanks VJ for sharing. Nice to know that such a feature exists. Are you using this in productive systems? If it is being used, What were the main reasons behind acceptance of this solution?

      Author's profile photo Vijayashankar Konam
      Vijayashankar Konam
      Blog Post Author

      Not yet. Actually, this would be helpful in situations where the PI and the business systems are in different geological regions.