Converting BAPI to Web Service - How to automate?

[Former Member]

Folks,

Our .NET application uses Web services to communicate with SAP. On our SAP server, about 10 BAPIs have been marked as Web Service via transaction SE37>Utilities>More utilities>Create Web Service>From function module.

We also created a document for our customer on how to do the same for each of the 10 BAPIs on their SAP server. However, doing this manually is tedious and also error-prone. I am wondering if there is a way to define a script or something that the customer can simply run. This script will mark those BAPIs that are being used as Web services.

Thank you in advance for your help.

Regards,

Peter

[Former Member]

Hi Peter,

In principle SAP provides already a service in SICF that allows you to SOAP-enable all RFC function modules. Depending on your companies policies this service might be deactivated. Also, when you retrieve the WSDL you basically have one RFC module per web service (which is something the developers might not like).

The WSDL can be retrieved via the following URL, below the WSDL generated for RFC function RFC_SYSTEM_INFO:

https://<ServerName>:<PortNumber>/sap/bc/soap/wsdl?services=RFC_SYSTEM_INFO

The WSDL points to the generic service /sap/bc/soap/rfc, which will be invoked for handling those calls.

I'm not aware of another service that allows you to group the RFC's into a single web service (without going through all those definition steps). In theory though, it shouldn't be too hard to create your own service in SICF that returns a WSDL for a group of RFC modules (with possibly another service as the SOAP processor, though if company policies permit, you could defer that to the generic one I mentioned). Maybe somebody else has some better suggestions...

Cheers, harald

[Former Member]

Hi Harald,

What you describe works perfectly but is now obsolete since WAS 6.40.

There is now a different URL for each web service and you have to configure each web service with transaction SOAMANAGER.

I don't think that it is possible (and that it would be a good idea ) to automate the web services publication.

Regards,

Olivier

[Former Member]

Hi Oliver,

Interesting, do you have any link to a SAP document indicating that the generic RFC-over-SOAP approach is obsolete (my own web search was unsuccessful)? After all, it's like RFC calls, just using another protocol. When using the generic RFC-over-SOAP service the authorization S_RFC using the function group of the executed function is still checked. So it seems in a way equivalent to executing an RFC call - just using another protocol.

So I thought the generic service is just one possible way of doing things, while the other approach of defining your web services up-front on the application server provides you more flexibility (grouping of functions, mapping, etc.). Sometimes though, you need flexibility outside SAP (scripting, limiting changes on backend, skill sets etc.) and in those cases I'd say the generic services shine.

Cheers, harald

[Former Member]

Hi Harald,

Check note [Note 1394100 - Security note: Access to RFC-enabled modules via SOAP|https://service.sap.com/sap/support/notes/1394100] and

[Note 566955 - SOAP Processor within SAP Web AS released|https://service.sap.com/sap/support/notes/566955]

Extract : "Note this information is only applicable to SAP Web AS 620. From Web AS 640, i.e. SAP NetWeaver 2004 on, please use the Web Service Framework."

That said, I have a production R/3 4.7 system in which we call 2 millions "obsolete" web services each month.

The new implementation is much better with the separate URL and with the external interface which you can use to hide the dreadful german field names with user friendly ones... You can also use Web Service Security.

Regards,

Olivier

[Former Member]

Hi Olivier,

Thanks a lot for the quick answer (and sorry for misspelling your name in my previous post). So as you quoted OSS note [1394100|https://service.sap.com/sap/support/notes/1394100]:

As of Web Application Server 640 (that is, SAP NetWeaver 2004), use the Web Service Framework.

So it looks like they're convinced that the new framework is always an improvement. which seems a bit optimistic in my opinion. Maybe that's why at the start of the note they had this comment (though more likely just a pointer for keeping existing solutions without making changes):

Check whether the service in your landscape is used for particular software solutions. If not, the following applies:
For releases higher than 610: Deactivate the service "/sap/bc/soap/rfc" in transaction SICF.

So if you use it, continue, otherwise please don't - kind of odd.

I'm not sure I fully understand the security concerns. From an authorization perspective RFC and the generic RFC-over-SOAP are equivalent - both use authorization object S_RFC, thus allowing control which RFC can be executed or not. Logon information and message content can be exposed via RFC (no SNC) or SOAP (no https/SSL). Comparing RFC and RFC-over-SOAP I could see that the SOAP solution is more complex and thus might introduce additional risks. However, that wouldn't really be an argument for the even more powerful (and more complex) new web service framework.

Anyhow, enough babbling, thanks a lot for providing the interesting background information.

Cheers, harald

[Former Member]

Hi Harald,

Thank you for your help.

Note that we don't really need WSDL. WSDLs have already been generated from our internal server, along with .NET proxy code. The BAPIs that we are using are standard BAPIs (such as BAPI_MATERIAL_SAVEDATA) and are available on all SAP servers.

We need to ship our final application to about 100 customers. I am looking at a way where the customer goes through minimal pain to web-enable just the 10 BAPIs.

Regards,

Peter