Multiple clients for a RFC sender to SOAP scenario

[Former Member]

All,

We have a RFC to SOAP scenario in our Development server and is working.

The problem we are having is - we only have one XI server available. But there are different clients in Dev that want to use this scenario now. Though we create the new BS for each of these clients, the issue i see is in the RFC sender communication channel. it needs to have the program id.

Right now we are creating a new program id for each of the clients(which translates to different RFC destination names on the ABAP side)... but that is causing a problem on the ABAP side - since the calling function is the same and they need some logic to change the RFC destination based on the client..

Are we missing something or is there a simpler way to this?

Thanks.

[Former Member · Accepted solution]

You dont have to create new program ID for each client. As a matter of fact, you dont have to change anything in ECC. All you have to do is just create a new Business Systems in XI SLD for each client and create new communication channel, sender agreement, receiver deter, etc. The new communication channel should have the new client from which you would want to test.

[Former Member · Accepted solution]

we created the exact same way you told... just add another business system. complete the receiver determination, interface determination and sender agreement.

It works every other time. When we checked the communcation channel monitoring - it will go to the client 210 once, and it would work. when we call the next time - it will error with a short dump in ABAP - but the error will appear on the communication channel for 250 (though we are calling from 210).

Error in processing caused by: com.sap.aii.af.rfc.afcommunication.RfcAFWException: alternativeServiceIdentifier: party/service from channel configuration are not equal to party/service from lookup of alternativeServiceIdentifier (CPA party/service/channel ''/'UD1CLNT250'/'RFC_UD1CLNT250', lookup of alternativeServiceIdentifier for party '', schema 'TechnicalSystem' with 'UD1#210' returned party/service of ''/'UD1CLNT210')

Any thoughts?

[Former Member · Accepted solution]

The error looks like the sender agreement has not been configured right. You would have to create two communication channels and two sender agreements for this to work. We do the same thing in our company and it works fine. Also check the adapter specific identifier for the Business systems and check if it is pointing to the correct client.

Hope this helps and award points if helpful.

[Former Member · Accepted solution]

Praveen

Our settings are exactly as you described.. we also checked the "adapter specific identifiers" and they have the values correct.

Can you please confirm in your case -

1. Are you using the same program id in both the communication channels?

2. If different, is the ABAP program calling the function with different RFC targets based on client number.

Thanks,

[Former Member · Accepted solution]

I am using the same Program ID in both my communication channels.

[Former Member · Accepted solution]

Hello

will it be possible for you to send me the screenshots for the following from your system?

1. Communication Channel 1

2. Communication Channel 2

3. In R/3 - TCODE "SMGW" - the logged on clients view showing the registered server (the prog id).

If you can send this to realogy2007 @ gmail.com, that will really give us some pointers...

thanks.

[Former Member · Accepted solution]

I have the same issue regarding same ProgramID for multiple R/3 clients in Sender Communication Channel. Did you find a way to solve this in XI, or is the only option to create multiple RFC destination with unique ProgramID, and then CALL FUNCTION 'test' IN BACKGROUND TASK DESTINATION 'Destination_01, 02, 03, etc.' in each client?

Yours sincerely

Stig Praefcke

[Former Member · Accepted solution]

Hello

There is a setting in the communication channel - under "advanvced settings" called "Verify Sender system" - uncheck this box on all the relevant RFC channels. This should solve the problem.

Thanks,

thezone.