SAP .NET Connector 2.0 offered a couple of different sample projects that were instrumental in my learning process.  As I mentioned in my post detailing the steps to build an RFC client, SAP no longer supplies code samples with SAP .NET Connector (NCo) 3.0.  So, I decided to make available some code examples created by my colleague, Terry DeBruicker.

This blog describes how to build a simple RFC Server using the SAP NCo 3.0. The sample program implements RFC STFC_CONNECTION.  STFC_CONNECTION is a good example to use because it contains both importing and exporting parameters.

Click here to request a .zip file containing a copy of the source code.

Along with the SAP .Net Connector 3.0, we are using Microsoft Visual Studio 2010 and the Microsoft .Net Framework 4.0 to build our sample. Prior to starting, you will have to download and install NCo 3.0 (OSS login required).

Setting up the Project

Using Visual Studio 2010, create a new console project. In the project properties, be sure to set the Target Framework to .Net Framework 4.0.

Next, add references to the SAP .Net Connector 3.0. There are two DLLs, sapnco.dll and sapnco_utils.dll.

Using App.Config to define the SAP Connections

There are several methods you can use in your solutions to define a particular SAP host. For this simple example, we are using an app.config file to define our SAP host connection information.

One of the biggest differences between NCo 3.0 and NCo 2.0 is how function metadata is retrieved and stored.  With NCo 2.0 the function metadata was downloaded from an SAP system at design  time and persisted as proxy objects that were compiled with the rest of your solution.  NCo 3.0 needs to access this metadata at runtime.  There are two methods for providing this metadata.  One method is to create the metadata in your .NET code.  The other method is to rely on the metadata stored in the SAP system.  For this example, we will rely on the SAP system to provide RFC metadata.  This metadata is retrieved using special built-in RFCs.  Therefore, not only will our program act as an RFC server, it will also need to act as an RFC client.

For basic RFC server configuration, there are two configuration sections that are used, <ClientSettings> and <ServerSettings>.  Ensure that the app.config file has a <sectionGroup> tag for both client and server settings.

An RFC server configuration is linked to a RFC repository by use of the REPOSITORY_DESTINATION attribute.  To be able to access function metadata, this attribute must match the name of a destination configuration in the client settings section.

All SAP NCo 3.0 RFC servers communicate with SAP through a SAP service called the gateway.  The server settings configuration section  defines how the program connects to the SAP gateway.  In the servers section, the NAME field identifies this app.config entry to our  program. The SAP .Net Connector 3.0 will use the values in the GWHOST, GWSERV, and PROGRAM_ID fields to register our program on the SAP Application Gateway. The PROGRAM_ID specified here must match the Registered Server Program ID specified in the RFC destination.

The SAP RFC Function Interface

SAP transaction SE37 can be used to determine the parameters for the STFC_CONNECTION function. This describes what parameters will be passed to our function, and what results are expected.

In this example, we expect to receive parameter REQUTEXT, which will be returned to the caller in ECHOTEXT. We also return a text string to the caller in field RESPTEXT.

SAP transactoin SM59 is used to configure the SAP RFC Destination. In this example, the name of the RFC Destination (NIMBUS) is the name of the development computer that is running the RFC Server. The registered program ID (NCO3_RFC_SERVER) matches our app.config file.

The Code

As an Nco developer, one of my favorite changes brought about by Nco 3.0 is how RFC server functionality is implemented. Instead of overriding generated stub method, we need to implement one or more class methods that will process the incoming RFC calls. For this there are several possibilities:

• The first option is to create one static method corresponding to each SAP function module to be implemented.  Assigning a SAP function module to a method is done by decorating the method with the RfcServerFunction attribute.
• The second method is to create one static method for that handles all SAP function modules. This is called the “default” method. Use the same RfcServerFunction method decoration as the previous option, but denote that the method is the defualt RFC handler. The Name attribute is irrelevant in this case.  These two methods for RFC Function handling can be combined in the same project.

It is also possible to use either of the two previous options with instance methods instead of static methods.  For the purposes of this example, we will use a static method to implement our RFC Server.

We will create a class that exposes a method that can be called via SAP RFC.  In our example that class is named DxsRfcServer and it contains one method that will supply the STFC_CONNECTION functionality.  Now perform the following steps to implement class.

1. Provide the RFC callable code. This is done in our DxsRfcServer class, where we have a method defined. The RfcServerFunction code attribute on line 59 identifies this function to the SAP .Net Connector as the method that implements SAP function STFC_CONNECTION. On line 60 is where we are passed two parameters that contain all of the information we need to execute our function. The IRfcFunction interface provides access to parameter values. In this case we use the .GetString() method on line 69 to extract the value of the REQUTEXT parameter. We also can return values to the RFC caller using the IRfcFunction interface by using the.SetValue() method as seen in lines 69-70.

 2.Create an array of types, with just one element that refers to our DxsRfcServer class.

3.Register the array with an RfcServer object.  Notice that on line 22, the first parameter to the .GetServer() method is the NAME field of the servers section in app.config.

4.Start the RFC server.

5.At this time, the SAP system has visibility of our program running on the application gateway. (SAP transaction SMGW Goto menu->Logged On Clients)

6.Use the test function screen in transaction SE37 to test the new function. The RFC Target System is set to the name of the RFC destination created in the previous step (in this case it is our development system name).

Here are the results:

7.The command console will also display some useful information:

The rest of the code is regular Windows Console programming and is very straight forward.

Additional Information

Follow these links for more information about NCo 3.0 programming:

• Webinar: SAP NCo 3.0 – Best Practice Guide for Upgrade from .NET Connector 2.0
• Source Code: RFC Server with NCo 3.0