soap -> PI -> rfc

[former_member201275]

I am new to PI webservices so i apologise in advance for my basic questions.

I need some help in understanding, at a high level, how to create the following PI webservice. I have been through many links on scn but this has just confused me more.

We are on sap pi 7.1

I have been given a URL, and an RFC function module. This is to be soap -> pi -> rfc. The rfc function has 2 import parameters, which it uses to create something in our backend system, and then 1 export parameter which is simply a message i.e. type BAPI_MSG.

Also I have been told it is not necessary to create an External Definition, instead I should create (in ESB), 2 service interfaces, and a message mapping, and thereafter the Config scenario. So, my first question, when I create the service interfaces i.e. 1 inbound and 1 outbound, and I type in the rfc fm and then click on the WSDL tab there is XML there generated from the rfc function. Is this correct or should I be generating the WSDL in this SI from the URL I have been given? 

Do i even need the url i have been given, because once i create the Sender Agreement i will generate a url from this and forward this to the client?

As this is soap -> pi -> rfc is this called ‘consuming a webservice? I am confused by the terminology.

Also, if anyone has any good links specific to what I need to do, for version 7.1, please send these.

Thank you in advance for all responses, I really appreciate the help.

[markangelo_dihiansan · Accepted solution]

Hi Glen,

A few comments.

Also I have been told it is not necessary to create an External Definition, instead I should create (in ESB), 2 service interfaces, and a message mapping, and thereafter the Config scenario. So, my first question, when I create the service interfaces i.e. 1 inbound and 1 outbound, and I type in the rfc fm and then click on the WSDL tab there is XML there generated from the rfc function. Is this correct or should I be generating the WSDL in this SI from the URL I have been given?  

There is no need to create a service interface if the source and target interface are the same function module. A function module is already an interface in itself If mapping is needed, only create an MM and an OM.

Do i even need the url i have been given, because once i create the Sender Agreement i will generate a url from this and forward this to the client?

As this is soap -> pi -> rfc is this called ‘consuming a webservice? I am confused by the terminology.

The URL from the sender agreement can be used. Well technically, in your scenario PI is the webservice provider and the third party is the webservice consumer.

Regards,

Mark

[former_member198060]

Hi Glen,

Sender side:

If you have been given an URL it only makes sense, if you could fetch a WSDL or XSD from there which you could use in order to generate an external definition. This would be the data type that the sender is expecting to send. If no WSDL or XSD is available, you would model the data type and message type yourself according to the requirements of the sender system.

Receiver side

For the RFC function module, you don't need to create external definitions or data types, by importing the function module you already have this side covered.

The sender in your scenario would be a consumer of a web service. That is because you are offering a web service which he can call and which will in the background trigger an RFC on the receiver system.

[former_member186851]

Hello Glen,

For Sender Side Soap:

Create a data type,Message type and Service Interface.

Then in the ID

Create one soap channel with HTTP Protocol.

create Sender/Receiver aggrement,Receiver/Interface determination.

Give the WSDL and endpoint from the sender aggrement.

They can send message using this WSDL and endpoint

For Receiver RFC.

Import the RFC in to PI ESR .

Mapp the Source to Target.

Then In the ID

Create one RFC channel mentioning Target ECC details.

create Sender/Receiver aggrement,Receiver/Interface determination.

Scenario is done.

Refer the below link for more details

Ignore the BPM part.