Skip to Content
avatar image
Former Member

Low level TCP/IP connection to external server from PI

Hi Experts,

We've been having trouble connecting to a remote server via PI 7.3. I've seen a few posts regarding this but we only have IP address and port available - no SNC program name/library info as required by the RFC adapter and we also do not have BMP installed so cannot use a Java socket as described in another blog. We have to use PI as other clients must also send info to our side before sending onto this external server, hence sending directly from R3 is out. To complicate things further, all messaging is ASYNC. Even when creating a TCP/IP connection on SM59, it asks for the "acceptor program name" which we do not have.

So we have the following scenario:

  • PR3 sends/receives via PI using proxy - no problem here
  • Other client sends/receives via PI using available adapters - no problem here
  • PI sends and receives to/from external server using low level TCP/IP connection - big problem here

So my question is, is there another way to set up a tcp/ip connection or can we install an additional adapter on the Adapter Framework which only needs IP address and port as input parameters? I know the Seeburger is available but do not know what info is needed and if it will help in this scenario. I've read about the Iway too but seems like it is only supported up to PI 7.0? Which is the best adapter to use for this low-level connection and where do I find it?

Thanks so much for the help. 😊



Add comment
10|10000 characters needed characters exceeded

  • Follow
  • Get RSS Feed

3 Answers

  • Sep 03, 2013 at 12:21 AM

    Hi Anneke,

    Could you please explain the term BMP? You need java sockets for this scenario.

    What is preventing you in creating a java socket.



    Add comment
    10|10000 characters needed characters exceeded

    • Hi Anneke,

      First of all BPM and RFC are not mandatory for creating java sockets.

      This is the scenario you are working with

      SAP(Proxy)------>PI----->External server using TCP\IP.

      You are saying that the communication is asynchronous but the external server is responding back to PI. In there a fixed time gap or response might come at any time? How many response you expect for a specific request from the external server??

      If you are obtaining the response within a fixed time frame then you can proceed with java mapping code described in the blog you indicated. You can insert a waiting time in the code to wait for all the responses from the external server. In case there is a time-out, error message will be sent back to ECC by the code itself.

      Now if you are not sure when response will be sent back or if A is first to request, then entirely different design works here.

      1. Create a server program in java(S): This always runs in PI server and waits(listens) for any request message(or response message) from external server(say A). In case there is a request from A, then S notes it down to a log file. The scenario is asynchronous thus A does not expect a response back immediately. The server code(S) will be based on java socket.

      2. In the SAP side messages (using proxy) will reach PI at regular intervals. In PI there is this java mapping which after receiving message looks into the log file created by S. In case there are response messages they are sent back to ECC. If there are request messages those also are sent back to ECC. The data type for request, response messages are different. Based on input from A java mapping differentiates between whether the log file contains a request or a response message. Now if ECC has sent a response message Java mapping code directly writes it to port of A using java socket.

      Problem areas

      1. You need to do very robust coding and take all measures that the log file is not tampered with. This can be easily taken care if the Operating system is UNIX. Also consult with BASIS team

      2. There might be PI server crash thus you need to ensure that log file is accessed by S and pointer is closed immediately. The file pointer should not remain open during entire time while S runs.

      3. Ensure S runs throughout the day and is never shut down.

      4. In case there are connectivity issues S should write that down in log file so that ECC is informed of the same. In fact from PI you can raise email messages using java mail API to inform users of the same. Thus network team needs to take care of the same.

      Let me know if there are any other concerns to implement this scenario.



  • Sep 03, 2013 at 07:23 AM


    1. could you please briefly explain your scenario like so:

    RFC(your SAP system) --> PI --> SOAP(third party system)

    2. Did I get you correct that you are using PI with your other SAP systems already for communication with third party systems?



    Add comment
    10|10000 characters needed characters exceeded

    • Former Member Former Member

      Hello Anneke,

      have you tried talking to that external company? Surely they must be integrated to other companies as well. This kind of old-fashioned integration might have risen some questions with other clients, too. Can they maybe offer something else to integrate like files, maybe? Maybe this problem is better tackled on organisational level instead of a technical one.



  • avatar image
    Former Member
    Sep 13, 2013 at 10:25 AM

    Thanks everyone for the replies!

    The poblem is that this is a very low-level robot we need to communicate with which understands very little. It cannot accept any Client information on it so we cannot host a listener on our side for the multiple async responses and we cannot install any addional software on it either. It also does not understand XML namespace convention which now must be stripped out before sending the message to the robot. The response is also not the conventional 1 XML per response message but a buffer stream of multiple responses it seems. So those must be split up first, namespace added back into the XML and then only can we send it back to XI via HTTP channel.

    So we've decided to use another integration tool between XI and this robot to deal with those nitty gritties which can handle low-level TCP/IP. Not the ideal solution, but better than nothing.

    To answer Jorg's question, this would be the first integration with PI in the world. They have done it with SAP R3 directly using a Java socket, but in our scenario there are other third parties involved so we must use PI. There will also be more of these robots in future so the routing logic will sit on the Integration side. Another issue is that this robot can only communicate with one party which makes it a bit complicated.

    Thank you guys for all the links - we'll definitely use those for future projects!



    Add comment
    10|10000 characters needed characters exceeded