Low level TCP/IP connection to external server from PI

[Former Member]

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.

Regards,

Anneke

[Former Member]

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!

Regards,

Anneke

[JaySchwendemann]

Hi,

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?

Cheers

Jens

[Former Member]

Hi Jens,

We use PI for all our integration to external companies but this external server is different in the way that it only communicates on a very low-level and not on application layer at all. Hence we could not implement an HTTP communication. We also cannot install anything on this external server, we only have IP and port available. We also cannot use the RFC adapter as it changes normal XML to RFC-XML which the low-level server cannot understand.

Our scenario currently is:

• initial request:

(SAP) -> proxy -> (PI) -> tcp/ip connection -> (third party) in async mode

where this tcp/ip connection is the problem

• multiple responses back:

(SAP) <- proxy <- (PI) <- tcp/ip connection <- (third party)

The initial request can also be established by the third party, then SAP would send back the response message.

Thanks for the help guys.

[JaySchwendemann]

Hi Anneke,

I'm certainly no expert on this matter but my gut feeling would be that you need to delve into adapter development? I would suppose so because if you are situated on layer 3 or layer 4 you would need to have some "itelligence" that encapsules the meaning of all the bits that you are transferring (with HTTP or RFC being on layer 7 for example).

Please let me know if I missunderstood your requirements.

Cheers

Jens

[Former Member]

Hi Jens,

Thanks for the reply.

We were hoping to find an adapter that was already developed and tested as we have very tight deadlines on this project. Do you know of anything already out there?

[holger_stumm2]

Hi,

I doubt that an adapter would help. It will probably not allow you access to the socket layer.

What we did once in a similiar situation was to use the SAP WAS Java to write a servlet (POJO Plain Java Only) and the PI was talkin http to that service.

It was like this: ABAP Stack --> PI --> http Adapter --> Servlet (on same server) --> TCP socket communication --> Target Server

You can write the servlet based on plain Tomcat specifications.

HTH

Holger

[anupam_ghosh2]

Hi Holger,

                 First of all thank you for your kind response to this thread. There is this small doubt cropping up in my mind.

In case the external server sends first request to PI , will the servlet be able to take care of that? I am not sure. Certainly the request from external server will not come as an http request I guess. 

Regards

Anupam

[holger_stumm2]

Hi Anupam,

the native server needs to talk to the servlet first, that's sure in when the server initiates the communicatiobn. Even if it is not http-communication, you can use the java library to act on a socket level. You only need one server that is running which needs to handle the requests.

I have not the intention, that this is a perfect solution - I throw this idea in a ring to offer options, like everybody else here.

We used this to communicate to specific security devices with specific requests. It was quite some elaborating, but it worked at the end. 

Regards

Holger

[Former Member]

Thanks for all the feedback guys. I'm wondering, if I create a Java adapter myself, how do I go about it?

[JaySchwendemann]

If I understood Holger and Anupam correctly, they suggest not opting for the java adapter but either writing a standalone java app (Apunam) or a servlet (Holger).

If you want to try java adapter development anyway ( mentioned here that this would be feasible), you can start by looking at the help files here:

http://help.sap.com/saphelp_nw73/helpdata/en/69/e1e6667710415a9c331ec2e0715561/content.htm

Sorry to be not of more help currently

Cheers

Jens

[holger_stumm2]

Hi,

I think that the post from Jens is right on the spot:

Stefan Grube's blogs are really the best way to get your way into adapter development.

(or depending on the location ask Stefan directly, I did some of this kind of work with him together  😉

But regardless of the way you are going, (either Apunam's way or mine), I would take an (rather wild than)  educated guess and say, that you need two weeks either way for an beginner java programmer to get this done. A pro in front of a working NWDS installation will take a week.

This is no offer, rather an idea of what kind of magnitude of development we are talking about. .

HTH

Holger

[anupam_ghosh2]

Hi Anneke,

                    In this case you need to listen to asynchronous  TCP/IP request from external server. I do not think creating an adapter will be able to handle this request. Secondly you also need to write to the external server, then two kinds of adapter are required. Creating an adapter is not a easy task and if I were you I would have looked for alternative solution. The reason being after creating these adapters there is question of maintaining the same , doing troubleshoots etc. The project would require to hire highly skilled professional who can handle such troubleshoots. I was thinking on this for quite some time now and here I suggest a little different design than what was suggested earlier.

case 1:

----------

The External server is initiating/sending the request to PI.

Solution:

-------------

1. You need a server code(S) which runs in PI server and listens to a specific port.

This code may be written in java or c or c++. As soon as any request arrives to S it writes the request down in a file.

2. In PI design a simple File to idoc scenario. The sender file adapter will pick up the file written by S and  send it to ECC. You need to be careful that PI does not pick up the file before S completes writing to it. (Please refer to this thread.)  

3. Ecc receives request message from PI and ABAP code in background creates appropriate response.

external server---request-->S----->writes file----->read by PI ------idoc---->SAP R/3

Case2.

-----------

1. ECC initiates the communication (or sends a response) suing RFC/Proxy  to PI server.

2. In PI java mapping code (similar to the one in blog mentioned by you) communicates the response/request to the external server. 

3. The mapping code also sends back status to ECC on whether writing to external server was successful or not.

ECC--->RFC------->PI------>ext server

                                |

ECC<---RFC<------Status

I think developing this scenario will much easier than writing new adapter code.

I am sure this design can be realized without any confusion. In case you face any issues please share the same

with the forum.

Regards

Anupam

[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.

Regards,

Jörg

[anupam_ghosh2]

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.

Regards

Anupam

[Former Member]

Hi Anupam,

Sorry I meant to say BPM (Business Process Management). What I understand about this blog:

http://scn.sap.com/people/saravanakumar.kuppusamy2/blog/2005/12/15/socket-integration-with-xi

is that you need a synchronous RFC connection which we cannot create as we need async communication and we also do not have enough information of the external system to create the RFC communication. Our system will also send one message to this external server and get multiple response messages back asynchronously so how do you receive back those response messages if the socket is initiated on the Java side? Then where does the socket listener sit?

That's why an adapter would work better if available.

Thanks

[anupam_ghosh2]

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.

Regards

Anupam