Hi there,

In the following post we will describe a bug found in the SAP PI Soap Adapter.

This bug is related to the admissible length of User:Pass pair during the basic-authentication in the Soap Adapter.

During the post we will cover the whole process:

– SAP PI Version

– Context of the project

– Initial Configuration

– Errors

– Analysis

– Solution

SAP PI Version

We are running a SAP PI 7.31 SP10 Java Stack (SO: HP-UX)

The SAP_XIAF component is running in the release:

SAP PI Version.PNG

Context


Right now we are developing a project integrating SuccessFactors with SAP ECC.

SuccessFactors is a cloud HR solution, so a cloud integrator called BOOMI, it´s used in order to ease the communication with the HR plattform.


Archi.png

Initial Configuration

Boomi Authentication

   The authentication in Boomi is set up to Basic- Authentication, in this environment:

BoomiManagement.pngAtomOptions.png

   The following user was generated in order to test the flows in Boomi.

Boomi_User_Pass.png

  As you can see the autogenerated pass was really long.

SAP PI Initial Configuration


  We configured the SAP PI Soap Channel the following way:

  ChannelScreenShot.png

Errors


SAP PI Communication Channel Monitor


When we started the tests, we found the following error in the Soap Receiver Channel:

CommChannelMonitor.png

   HTTP 401 Unauthorized

   Which meant that the authentication was not working.

Analysis

   Putty, TCPMon and Xming

   We needed to see what the Soap Adapter was really sending to Boomi

   So we placed a TCPMon between SAP PI and Boomi:

TcpMonArchi.png

   There must be visibility between TCPMon and SAP PI, so we placed the TCPMon inside the SAP PI Machine, which was running on a HP-UX SO.

   The problem, is that there is no visual environment in this SO, so we needed to capture the screen of the TCPMon somewhere else, for this purpose we use XMING (this program must be running in your local computer, before executing the TCPMon, in order to capture the screen).

   Set Up Putty

    We´ll use the putty to start the TCPMon.

    A special configuration must be done in putty in order to pass the TCPMon Screen to the XMING.  (X11 forwarding)

   Start TCPMon

LaunchTCPMOn.PNG

   Screen is captured with XMING (local computer).

Set Up TCPMon

We´ll set up the TCPMon to listen in the port 8899, and pass the received request to:

– XXXXX-stage.sucessfactors.eu: YYYY (SAP PI Channel Host and Port)

Once the TCPMon is listening the following screen is shown:

TCPMON_Listening.PNG

  Set Up SAP PI Comm Channel

  The SAP PI Soap Communication Channel must be reconfigured, pointing to the TCPMon Host and port.

ChannelScreenShotTCPMon.png

   As you can see the SAP PI communication channel is now pointing to the TCPMon.

Capturing the payload

   Everything is ready, so the scenario is executed once again.

   In the TCP Mon we should be able to see the payload and the HTTP headers that are being passed to Boomi:

Payload Captured.PNG

   TCPMon.trc is file attached to the post.

Basic Auth Header:

   Authorization: Basic Qk9PTUlfVEVTVF9VU0VSX1NPQVBQQVNTOjJlMTM1Y2QzLWMxNTMtNDY5OS05YmY5LTYyMjNiYzVi

Decoding the Header

UserPassDecode.png

   When we decode the Basic Auth Header, we can see the real User:Pass pair sent to Boomi.

   As you can see the password is incomplete!

   We have detected that User:Pass Pair can´t longer than 56 Characters, at least for this SAP PI Version.

Headers.png

The Solution


   There are several workarounds for this problem ….

   1.- Use Axis adapter

   2.- Use Http AAE Adapter (create soap:envelope in the mapping)

   3.- I guess that updating/upgrading the system should solve this SOAP Adapter the issue …

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Andrzej Filusz

    Hi,

    I met this bug a few years ago. Fortunately the developer of the external Web Service agreed to make my password shorter.

    Thanks for your post – this bug can be a tricky one for an inexperienced PI consultant cos HTTP error: “401 unauthorized” is in this case a little bit misleading.

    Best regards,

    Andrzej Filusz

    (0) 

Leave a Reply