Make function module calls in SAP from an external system

The RFS SDK is a collection of utilities to make programming with RFC easier. It has been replaced by the SAP .NET Connector, which can be downloaded from sapnet.sap.com. Both SDK and .NET Connector are proxy generators, that look up the definition of an RFC call in SAP repository and generate a stub in a chosen program language (e.g C#). RFC calls can be made easily from any workplace in Windows by calling the interface layer directly. All communication between Windows and SAP goes through a single library, called librfc32.dll, which is also the core of SAPgui. Also the SAP Java Connector (JCo) is only a wrapper around this librfc32.dll API. There are also a number of OCX-Wrappers available that were originally developed for the RFCSDK (wdtlog.ocx, wdtfuncs.ocx, wdtaocx.ocx) that are all found in the install directory of the SAPgui if you installed the SAPgui with development support "%ProgramFiles%SAPFrontEndSAPgui ". You can find detailed explanation about how it all works on my web site logosworld.com (Archive -> mySAP, Chapter 2 is the right starting point for you).

"1)Does SAP R/3 today provide WEB services which can be called from any client (again to call function modules)? If yes, does it require any special licenses? Perhaps XMII is the component which provides the Web services?"

You can call any SAP RFC call as a Web service also. The services make dynamic RFC calls via SOAP. The services gateway is found in SICF under the SOAP node (/sap/bc/soap):

Retrieving WSDL: http:///sap/bc/soap/wsdl?services=RFC_SYSTEM_INFO to get the WSDL for the RFC RFC_SYSTEM_INFO. Older WAS: ( http:///sap/bc/soap/wsdl11?services=RFC_SYSTEM_INFO to get the WSDL for the RFC RFC_SYSTEM_INFO.)

Making the Call: When you manage to build a proper SOAP document from the description, you can make the call: http:///sap/bc/soap/rfc?services=RFC_SYSTEM_INFO to invoke the service

"I have been working on integration (PP-PI) projects which were based on XI. However, XI seems to have been replaced by XMII."

xMII is a separate product with separate functionality that is currently positioned only as low-level middleware to guarantee interconnectivity with hardware devices like lab equipment, RFID readers, etc. XMII can mostly do the job of XI, but you should think of xMII as a kind of satellite middleware that serves as an intelligent adapter. For workflows and service monitoring you need to look for a more feature-rich XI (which does not necessarily mean XI, but then SAP has nothing else). You do not need XI to make RFC or Webservice calls to SAP ERP.

"Does using the Web service require any special licenses?"

If I understand the 54 pages license agreement of SAP correctly: No, all licenses are included. Basically, you pay what you pay for using RFC calls instead.

"Perhaps XMII is the component that provides the Web services?

No. As mentioned above, they are built in or exposed centrally via the eSOA repository, which means XI.

"2)If a customer doesn't want to invest in XMII but does want shop floor integration, what would be the cheapest solution/fastest solution (again I'm thinking somehow through RFC and trying to avoid the RFC SDK itself)? I know there are third party offerings out there and Microsoft is supposed to have adapters for it."

For super-fast and reliable interfaces with shop floors I always suggest a two step queuing scenario. Your shopfloor application should deliver data to a local message queue (a file system,. database etc.). Then a single agent does nothing other than fetch the data from the local queue and store the messages in R/3. Finally, a trigger will tell R/3 to process the newly arrived data. If you need reliable scenarios, always make a passive transfer, meaning that the receiver 'fetches' the data from the remote location. In that case you would create a small HTTP-Client routine in R/3 and simply call the Microsoft side. This also works painlessly for synchronous applications. In that case, the local application will deploy the data to the local queue, wait for some time until a message (or a semaphore) arrives, and pick up the data from the result queue. This all makes up a highly reliable and secure communication without hassling with RFC, Web services, or special middleware. Of course, if you have an agile environment, with thousands of messages, buying a strong middleware is an option. XMII is one of the solutions. XI may do the job with some extra efforts. Seeburger or Fiorano are great candidates for it as well.