NCo 3.0 Logon

One of the new features implemented to combat the malevolent for RFC client attacks is the interface IDestinationConfiguration. This interface contains method IDestinationConfiguration.GetParameters(string destinationName) which allows .NET programmers to provide their own secure method for storing and retrieving logon information, be it encrypted database, encrypted file, or even LDAP.  There is also a corresponding interface and method to secure NCo 3.0 RFC servers.

Additionally, there is updated functionality to support single sign-on (SSO) and X.509 certificates.

Say Goodbye to Data Containers and Generated Code

In SAP Connector 2.0, working with RFCs required the generation of proxy code via the SAP .NET Connector design-time tool.  This tool would convert the IMPORTING, EXPORTING, CHANGING, and TABLES parameters from the RFC you were calling/serving to .NET representations of the same.  With NCo 3.0 there is no longer any kind of generated code.  Instead of one generated proxy method for each function module, there is one single RfcFunction class, whose Invoke() method dynamically executes every given ABAP function module. Additionally, all ABAP parameters will be represented by the class RfcStructure instead of a dedicated generated class for every structure; All tables will be represented by class RfcTable.  So, instead of hard-coding all of the data and variable bindings statically at design time, NCo 3.0 now handles everything dynamically at runtime.

NCo 3.0 uses SAP’s data dictionary to determine the function interface for the called RFCs.  While this data is cached locally for performance reasons, NCo 3.0 is robust enough to detect changes in RFC interface signatures so your code will still execute if you’ve added, deleted, or changed RFC parameters.  If there arises a situation where the dynamic lookup of RFC interface signature is not wanted, there is also an option to hard code the RFC parameter metadata.

The biggest benefit of NCo 3.0′s new dynamic function handling is that NCo 3.0 no longer has a design-time component.  This releases the Visual Studio version restriction that .NET 2.0 had.  Let me rephrase that, NCo 3.0 will work with any version of Visual Studio you like! The only requirement is that at runtime, a .NET Framework version is installed that is compatible with the NCo 3.0 libraries.

Anxiously Waiting

NCo 3.0 figures to be a much-needed update to a vital SAP integration technology.  I, for one, cannot wait for the new functionality to be generally released.  Once NCo 3.0 is released we’ll be posting blogs highlighting the new features.  We’ll also include helpful information regarding a .NET Connector 2.0 to NCo 3.0 upgrade.  In the meantime, if you have any leave any questions or comments you have regarding NCo 3.0 below.  You may also email me directly at cstasila@dataxstream.com if you’d like to set up a detailed conversation.

The SAP .Net Connector simplifies creating C# programs that can interoperate with an SAP host. The SAP .Net Connector is available from the SAP Service Marketplace. You must have access to the SAP Service Marketplace to be able to download the SAP .Net Connector. The SAP .Net Connector must be installed on your development machine before we begin.

RFC is a Remote Function Call. In this case, the SAP process is a ‘client’ that is making an RFC call to our custom ‘server’ code. Our code uses the SAP .Net Connector to register on an SAP Application Gateway.

The TLA system we have been creating exists solely to demonstrate certain programming techniques involving the SAP .Net Connector and C#.  We will cover three separate parts of the solution: defining the function to SAP, creating a proxy object used to access SAP, and creating our C# code to perform the RFC function.

Defining the Function in SAP

Before we build our RFC server, we will define our RFC function in the SAP system. There are two parts we will need to create:  the Function Signature, and the RFC Destination.

Defining the RFC Function Signature

Open the SAP SE37 Function Builder screen. For the Function Module field, enter Z_RFC_TLA_HELLO_WORLD and click Create. For the Function group, press the browse button to the right of the field, then select an appropriate function Group. Enter a short text description and click Save to save the function signature.

On the Attributes tab, be sure to select the Remote-enabled module radio button.

Now we will be asked to define the parameters that are used. SAP refers to values passed to the RFC call as Import values. Values that are returned from the RFC call are called Export values.

In the Function Builder screen, on the Import tab, define a Parameter named Name. Fill in the appropriate Type and Associated Type values. Be sure to check the Pass Value check box.

On the Export tab, create a Parameter named Hello_World. This will end up storing the result of the RFC call. Define the field in the same way as the Name import field.

Save your RFC Function. Then you need to activate your RFC function. To do that, from the SE37 screen, enter the function module name. then click the Activate button.

Defining the RFC Destination

SAP can direct an RFC call to different destinations. We will create an RFC Destination using SAP function SM59. This RFC Destination is used by the SAP system to route an RFC call to our program, which previously registered itself on the SAP Application Gateway.

In the SM59 screen, click the Create button.  Enter RFC destination of TLARFCSERVER. The Connection type is T for TCP/IP. Enter a description.

On the Technical settings tab, select Activation Type of Registered Server Program.

For the Registered Server Program Program ID, enter TlaRfcSrv. The Program ID we use here must match the Program ID used when our server code connects to the SAP Application Gateway.

If you try the Test connection button, it will fail, since we have not yet registered our program on the Application Gateway. Later, we can come back to SM59 and test this and see that our RFC destination is available.

C# Code

We will create an application that can be called from an SAP host. The SAP host will pass in a name, as a string. Our application will return a hello greeting back to the calling program.

Our solution will consist of two parts.

1. The first part is the SAP .Net Connector Proxy project, named TlaRfcServerSapProxy. This will produce a Dynamic Link Library that encapsulates what we need to know to interoperate with the SAP host.
2. The second part is is our custom code project, named TlaRfcServer. This contains the code which will execute when called from the SAP host via RFC. Save the RFC destination.

Creating the SAP Proxy Project

We will use Visual Studio 2003 to create a DLL that manages the interactions with the SAP host. The SAP .Net Connector version 2.0 works with Visual Studio 2003 or 2005. To use the .Net Connector in our preferred environment of Visual Studio 2008, we will create the proxy DLL in 2003 and add that to our 2008 project. The techniques are described in our earlier post, Using the SAP .Net Connector in Visual Studio 2008.

In Visual Studio 2003, start a new Class Library project named TlaRfcServerSapProxy. Delete the default Class1.cs file that is created automatically.

From the Solution Explorer, Right-click on References and choose Add New References. Under the .Net tab, highlight SAP.Connector.dll and SAP.Connector.RFC. Click the Select button, then OK to add the SAP .Net Connector references.

Now add the SAP Connector Proxy to our project. Right click on the project and choose Add / Add New Item. Under the templates, highlight SAP Connector Proxy. In the Name field, give our proxy the name TlaRfcServerSapProxy.sapwsdl. The name we use here will become the object type name for our SAP Server Proxy object we use when we build our RFC server code.

The TlaRfcSerfverSapProxy.sapwsdl file will be displayed in Design mode. Right click on the Design surface and choose properties. This displays properties of our SAP Connector Proxy. Change the Proxy Type to Server.

Now we need to add in a reference to our SAP host so that we can pull in the signature and object model for our RFC function. Open the Server Explorer windows and expand SAP / Application Servers. Right-click on Application Servers and choose add New Server. Enter in the connection information for your SAP host. Click OK.

Expand the newly added SAP Server and right-click on Functions. Choose Add New Function Filter. In the Name Filter field, enter *HELLO* . The * is used as a wild card. Click OK to display our Z_TLA_RFC_HELLO_WORLD function in the Server Explorer.

Highlight the Z_TLA_RFC_HELLO_WORLD function in the Server Explorer, and drag it onto the TlaRfcServerSapProxy.sapwsdl design surface. This will add the necessary function signatures and object type definitions to the project.

Now attempt to build the project. It will fail, as we have not yet created the code to implement our remote function. But, when we ran the build, the SAP Connector generated an implementation stub for our server method. A new class was automatically added to our project, named TlaRfcServerSapProxyImpl.cs.

However, we desire to implement our RFC server using Visual Studio 2008.

So, we will modify this code so it will build, and later we will override the implementation from our Visual Studio 2008 project.

If you double-click on the build error, it will take you to the offending line of code. All we need to do is set the result of Hello_World to some value.  To prevent confusion with our Visual Studio 2008 code, we will just return foo.

Now build the TlaRfcSapServerProxy project and it will create TlaRfcServerSapProxy.dll, which we will use in our Visual Studio 2008 project.

Creating the RFC Server Project

Using Visual Studio 2008, create a C# console project named TlaRfcServer. In the Solution Explorer, right-click on References and choose Add New Reference. Using the Browse tab, select both SAP.Connector.dll and Sap.Connector.Rfc.dll, typically found in C:\Program Files\SAP\SAP .Net Connector 2.0.

Add a reference to the TlaRfcServerSapProxy.dll created earlier, also using the Browse tab. Add a reference to System.Web.Services using the .Net tab.

In our C# code, we need to provide the code to implement our RFC function, which we do by inheriting from TlaRfcServerSapProxyImpl and overriding the Hello World function.

On Line 3, with have our ‘using’ directive to include our custom proxy.

On line 8, we are creating a new class named SAPProxy, which is derived from our TlaRfcServerSapProxyImpl class that was created in our Visual Studio 2003 class.

On line 12 is the override of the Z_Tla_Rfc_Hello_World call. We provide our functionality and place the result in the Hello_World variable.

That concludes our class that will implement the RFC functionality.

Now we will finish off our console program so that we can establish our code on the SAP Application Gateway and execute it.

To do this,we will pass in command line arguments to our Main routine. These arguments are passed to the SAPProxy constructor, which uses them to connect to the correct SAP Application Gateway.

Each of our SAP Proxy objects are hosted by an SAPServerHost object, which is part of the SAP .Net Connector. The SAPServerHost object governs the connection to the SAP host.

Once we create the SAPProxy object and attach it to an SAPServerHost, we can start the host and that will cause our program to register and be available on the SAP Application Gateway.

Our program will continue to be available on the SAP Application Gateway as long as we have it running (until we press the enter key, in our example).

On lines 22-25, we instantiate our proxy and SAP host. Notice how we pass in the command line arguments to the SAPProxy constructor (line 25).

We start the proxy on line 29. After we have done that, we can go back to the SAP SM59 function and test our RFC destination. If things are working, that test will success.

Our code will continue to be available until we press enter at line 37, after which we stop the SAP host.

Command Line Arguments

The command line arguments consist of three parts, and are specified in the Visual Studio environment under the Debug tab of the Project Properties display.

The three parts are

-aProgram ID

-XPort

-GHost

The Program ID specified here must match the Program ID we used when creating the SAP RFC Destination. In our case this is specified as –aTlaRfcSrv.

The Port field tells SAP what TCP/IP port to use. This is specified by –XSAPGW00. The SAPGW part specifies port 3300, we add whatever the 00 is to get the actual port number. In our case we are using port number 3300, so we use –XSAPGW00. If we wanted port 3302, we would have used –XSAPGW02.

The Host field is the DNS name or IP address of the SAP server.

So, your parameters will be different but they will look something like –aTlaRfcSrv –XSAPGW00 –Ghostname

Now build and run TlaRfcServer. A console window will appear.

Go back to SAP and bring up the SM59 screen. Expand the TCP/IP connections and find TLARFCSERVER. Double click that to display the definition. When you click the Test Connection button, you should see something like :

which indicates a successful test of the RFC destination.

Now we need to test our actual RFC function. Bring up the SAP SE37 screen. In the Function Module name, enter Z_TLA_RFC_HELLO_WORLD, which matches the name of the function signature we created earlier.

Press the F8 key to test the function. The Test Function Module screen is displayed.

For the RFC Target sys, we use the RFC Function destination we created earlier, TLARFCSERVER.

For the name field, type WORLD. Press F8 to execute the RFC call.

This indicates a good test of our RFC function.

Troubleshooting

If things don’t work, check the following:

Program ID in RFC Destination matches –a parameter of TlaRfcServer command line.

Port number (SAPGW00) on TlaRfcSever comand line is set to correct port number.

Any firewalls in between the SAP host and the RFC Server program need to allow traffic in both directions over that port.

Summary

In this blog posting we have shown how you can call custom C# code from an SAP process.

This blog post describes how to receive an IDOC from an SAP system, using the SAP .Net Connector and Microsoft C#.

Introduction

The SAP .Net Connector simplifies creating C# programs that can interoperate with an SAP host. The SAP .Net Connector is available from the SAP Service Marketplace. You must have access to the SAP Service Marketplace to be able to download the SAP .Net Connector. The SAP .Net Connector must be installed on your development machine before we begin.

An IDOC is an Interface Document that is used to send or receive information to or from an SAP host.  An IDOC will consist of a header record and as many detail records as necessary. The header records follow the format of the EDI_DC40 table, and the detail records follow the format of the EDI_DD40 table. The exact format of the payload in the detail records depends on the type of IDOC being transmitted.

C# Code

We will create an application that displays the contents of IDOCs received from an SAP host. Use Visual Studio 2008 and create a new C# console application. Name the new application IdocReceive.

Add Reference to SAP .Net Connector.

In the Solution Explorer,  right-click on References and choose Add New Reference. Select both SAP.Connector.dll and SAP.Connector.Rfc.dll. Typically, these files will be found in C:\Program Files\SAP\SAP .Net Connector 2.0.

Our program will instantiate a custom class, IdocReceiver, that encapsulates the SAP transmit and receive logic.

IdocReceiver inherits from the SAP .Net Connector.  IdocReceiver overrides methods from the SAP .Net Connector to manage the flow of IDOCs from the SAP host. IdocReceiver also subscribes to two events exposed by the SAP .Net Connector that perform the actual transmission.

IDOC Receiver Main Method

Line 5 contains the reference to the SAP .Net Connector that we need.

The IdocReceiver object requires an SAPHost object that is used to configure the connection to the SAP Gateway. Line 9 instantiates the SAPHost object.

Line 14 calls the IdocReceiver constructor. The first parameter is the SAP Connection String, used to connect to the SAP host. There are three parts of an SAP Connection String:

-aProgramName is the program name as it is defined on the SAP Gateway. This value must match the Program ID configured on the SAP Gateway. Use SAP command SM59 to view the settings of the SAP Gateway.

-xSAPGWnn is the SAP Gateway number to which the IDOC receiver will register.  The SAP Gateway listens on a TCP/IP port number based on nn value. The actual port number is equal to 3300 plus the nn value. In this case nn is zero, so port 3300 is used.

-gHostName is the DNS host name of the SAP server. It is also possible to specify an IP address, like -g192.168.10.1.

Line 16 starts the SAP host, which makes it possible to begin receiving IDOCs. At this point, our program will now be visible to the SAP host, which you can verify using the Test Connection command via SAP transaction SM59. As long as the IdocReceiver object remains in scope, it will receive IDOCs.

IdocReceiver Class

To receive an IDOC, the IdocReceiver class inherits from the SAP .Net Connector SAPIdocReceiver class. To control the flow of IDOCs, the IdocReceiver class overrides certain methods of the SAPIdocReceiver class. To actually receive an IDOC, the IdocReceiver subscribes to two events exposed by the SAPIdocReceiver class.

Constructor

Here is the code for the IdocReceiver constructor.

IdocReceiver Constructor

On line 25 we declare our IdocReceiver and inherit from the appropriate SAP .Net Connector object. We use the StringWriter on Line 27 to store the contents of the actual IDOC received.

The constructor requires two parameters, the SAP Configuration string, and an SAPServerHost object that is a container for the IdocReceiver. Line 30 is where we call the base constructor.

The transfer of the IDOC raises an event at two times: when the transfer begins and when the transfer ends. On lines 32-33, we wire up our IdocReceiver methods to the BeginReceive and EndReceive events exposed by the SAPIdocReceiver class. Our IdocBeginReceive will be called at the start of the IDOC transmission, and our IdocEndReceive method will be called at the end of the IDOC transmission.

IDOC Flow Control

IDOCs flow out of an SAP system in a transactional way, in that an SAP host will send a particular IDOC once an only once. To accomplish this, the SAP host will put together one or more IDOCs into a transaction and send that off to the IdocReceiver that has registered on the SAP Gateway. The transaction is identified by a unique Transaction ID (TID) that is supplied by the SAP host. The SAP host will communicate with our IdocReceiver using the Transaction ID to control the flow of IDOCs from SAP to our program.

There are four methods of the base SAPIdocReceiver class that we need to override.

IDOC Flow Control Methods

In each case, the SAP host expects our code to return a zero if there are no difficulties. The TIDs passed as parameters can be used to verify the state of the transmission. This demonstration code leaves out any processing you may want to use to validate the state of the transaction.

The SAP host will first call the CheckTransaction method. If a zero is returned, the SAP host will call ConfrimTransaction. If a zero is then returned, the SAP host will begin transmitting IDOCs. When the transmission is complete, the SAP host will call CommitTransaction.

IDOC Reception

We use two methods to receive the actual IDOCs. At the start of the transmission, we assign a StringWriter to the EventArg, which tells the SAP .Net Connector where we want to place the payload of the transmission. When the transmission is complete, we can read from the StringWriter to extract the payload.

IDOC Reception

There can be one or more IDOCs transmitted at a time. Your code will need to parse the payload to determine what goes where.

If any of your code throws an exception, the SAP .Net Connector will detect that and alert the SAP side. The SAP side will then call your Rollback method.

Summary

Using the SAP .Net Connector makes it easy to receive an IDOC from an SAP host.

To learn more about IDOCs download the white paper: ALE & IDOC Leveraging

This blog post describes how to use an SAP .Net Connector proxy, created in a VS 2003 project, in a Visual Studio 2008 C# solution.

[Editor's Note] This blog is third in a multi-part series describing how to use the SAP .NET Connector:

1. Introduction to the SAP .Net Connector
2. Building an SAP .NET Connector Proxy
3. Using the SAP .Net Connector in Visual Studio 2008

Introduction

Our previous post described how to use Visual Studio 2003 and the SAP .Net Connector to create a Dynamic Link Library containing the desired SAP functionality. The DLL contains proxies for each SAP function that we want to utilize.

We will reference that DLL in a Visual Studio 2008, and use it to retrieve system information from an SAP host.

As a demonstration, we are creating the TLA System, which exists solely to demonstrate certain SAP .Net Connector programming techniques.

Using the SAP .Net Connector Proxy

Now we are ready to put our SAP .Net Connector Proxy to work. This will allow us to use the SAP .Net Connector in the modern Visual Studio environment.

Start a Visual Studio 2008 Project

Start a new Visual Studio 2008 Project. Use the Console Application template, and name the solution TlaSapRfcClient.

Creating a new console application

Add a Reference to the TLA SAP Proxy

Now we need to add a reference to the DLL we created earlier.

In the Solution Explorer, right click References and choose Add Reference. Using the Browse tab, find the TlaSapProxy.dll file from the TlaSapProxy project. Typically, this will be in the bin\debug folder of the TlaSapProxy folder. Click the OK button to add the reference to your project.

Adding a reference to the proxy

C# Code

Here is a Visual Studio 2008 C# program that uses the SAP .Net Connector proxy that we built earlier using Visual Studio 2003.

C# program listing

When we create an instance of the proxy in line 11, we pass in an SAP connection string. We create an object of type SAPProxy1 because that is what we named it in our Visual Studio 2003 project.

In line 20, we create an object of type RFCSI, because that is what our RFC call to Rfc_Get_System_Info will return. The type definition for RFCSI was also included in the proxy.

In line 22 we make the RFC call to the SAP host. We get full IntelliSense support that describes the parameters required.

Summary

The SAP .Net Connector is built for Visual Studio 2003. By using Visual Studio 2003 to create a DLL, we can use the SAP .Net Connector in Visual Studio 2008 (or later).

Here we have described how to use that DLL in a Visual Studio 2008 project.

The SAP .Net Connector is an SAP-supplied control that works only with Visual Studio 2003. This blog post describes how to create a VS 2003 project that will allow you to use the SAP .Net Connector in later versions of Visual Studio.

[Editor's Note] This blog is the second of a multi-part series describing how to use the SAP .NET Connector:

1. Introduction to the SAP .Net Connector
2. Building an SAP .NET Connector Proxy
3. Using the SAP .Net Connector in Visual Studio 2008

Introduction

We will use Visual Studio 2003 and create a Dynamic Link Library (DLL) that encapsulates the desired SAP .Net Connector functionality. We can use the DLL that we create in a Visual Studio 2008 project.

To illustrate the process, we will build up, over the course of several blog posts, a system that is capable of receiving an IDOC from an SAP host. This system will be known as the Three Letter Acronym system, or TLA.

Build an SAP Proxy

Our first task is to use the SAP .Net Connector to build a proxy that we can incorporate into Visual Studio 2008 projects.

The approach is to first add the SAP .Net Connector to a Visual Studio 2003 project. Then, we will attach to an SAP host to browse available functions. We will select the desired functions to be included in our SAP proxy.

Then, we will build the VS 2003 project into a DLL that can be used in Visual Studio 2008.

Start a Visual Studio 2003 Project

After you have installed the SAP .Net Connector, start a new Visual Studio for .Net 2003 project. Name the project “TlaSapProxy.” Choose the “Class Library” C# template.

Creating a new SAP Proxy project

We don’t need the default Class1.cs file that is created, so close the Class1.cs module that is displayed, and remove Class1.cs from the TlaSapProxy project.

Add a Reference to the SAP .Net Connector

Now we need to add a reference to the SAP .Net Connector. From the Solution Explorer view, expand TlaSapProxy / References. Right click on References and choose Add Reference. From the .Net tab, double-click both SAP.Connector.dll and SAP.Connector.Rfc. Click OK to add the reference to your project.

Adding References to SAP .Net Connector

Establish a Connection to an SAP Host

We will use the Visual Studio design time environment to attach to an SAP Host. From the Visual Studio View menu, select Server Explorer. Expand the SAP node. Right click on Application Servers and select Add Application Server.

For Destination Type, select Custom Logon Settings from the drop down list. Enter a valid SAP Username, Client, and Password. For the AppServerHost, enter the SAP host name, or the IP address of the desired SAP host. Be sure to fill in the Language field.

SAP Server Connection Properties

If things go well, at this point you will have an SAP Application Server established. You should see two new nodes on the Server Explorer display: BOR and Functions. Under BOR, you can expand either the Alphabetical or Hierarchical nodes to see available object definitions.

Browse SAP Functions

To display an SAP function using the Server Explorer, you have to create a function ‘filter,’ which selects which functions from the SAP Host you want to display. To do this, right click on Functions and choose Add Function Filter. In our proxy, we are going to be using some RFC functions, so, in the NameFilter field, enter RFC* (the asterisk is a wild card). Click OK, then expand Functions, then expand Filter1. After a moment, the screen will display a list of SAP functions that match our filter.

Creating a New Function Filter

SAP Function Filter Display

Select Desired SAP Functions

As you can see, there are many functions to choose from. When we build our SAP proxy, we will select just the functions we need.

For our TLA SAP Proxy we are building, we only need RFC_GET_SYSTEM_INFO. As with most SAP functions, RFC_GET_SYSTEM_INFO returns an object of a custom type that includes all of the results of the function call.

From the Visual Studio 2003 Solution Explorer, right click on the TlaSapProxy project and choose Add, then Add New Item. Scroll through the list of Templates and click on SAP Connector Proxy, then click OK to add the new item to the project.

Adding an SAP Connector Proxy Object

What you have at that point is a Visual Studio design surface to which we can add SAP function definitions. The design surface is displayed as SAPProxy1.sapwsdl. We are basically creating a WSDL file that will be used to generate our desired DLL.

Adding SAP Functions to a Proxy

To include an SAP function, in our case RFC_GET_SYSTEM_INFO, display the Server Explorer. Expand the SAP Application Servers to the desired server, then click on RFC_GET_SYSTEM_INFO. Drag RFC_GET_SYSTEM_INFO to the SAPProxy1.sapwsdl and drop it there.

The screen will display ‘Retrieve Data.’ When it is done, you will see two things added to the WSDL. First is the function call definition (method). Second is a class definition for what is returned from the function. You can right click on these and select Properties to view details of what is contained therein.

Building the Project

Now that we have selected all of the desired SAP functions that we want to include in our proxy, we are ready to build the project.

Because we selected a Class Library as our starting project template, our project is already set to build a class module (DLL). To build the DLL, right click on the TlaSapProxy project and select Build.

This will compile our WSDL file into a DLL file that we will be able to use in Visual Studio 2008.

Summary

The SAP .Net Connector is built for Visual Studio 2003. By using Visual Studio 2003 to create a DLL, we can use the SAP .Net Connector in Visual Studio 2008 (or later).

We do this by establishing a connection to an SAP host, selecting the desired functions, and creating an SAP proxy object that contains the desired functions. When we build this project, the resulting DLL can be used in Visual Studio 2008.

Our next blog post will describe how to use our newly created SAP proxy in a Visual Studio 2008 project.

DataXstream’s XstreamConnector provides a robust, high performance tool to receive SAP IDOCS. These IDOCs are then persisted to an SQL database that can be used for any other application

This article describes one of the SAP components used by the DataXstream XstreamConnector to facilitate this process.

[Editor's Note] This blog is first of a multi-part series describing how to use the SAP .NET Connector:

1. Introduction to the SAP .Net Connector
2. Building an SAP .NET Connector Proxy
3. Using the SAP .Net Connector in Visual Studio 2008

Introduction

The SAP .Net Connector is a software component supplied by SAP that makes it possible to communicate between an SAP host and a .Net program. Any .Net language can be used with the SAP .Net Connector.

Where to Find It

You can download the SAP .Net Connector from http://service.sap.com/connectors. You will have to provide your SAP Marketplace user ID and password.

What it Does

The SAP .Net Connector gives a .Net program access to an SAP host. The .Net program can logon to an SAP host and issue SAP Remote Function Calls. Parameters can be passed in to an RFC, and results data can be passed back to the .Net program.

A .Net program can also establish a connection to an SAP IDOC Gateway. The .Net program uses the SAP .Net Connector to send and receive IDOCs. There is full support for transactional integrity for IDOCS moving back and forth between the SAP host and the .Net program.

With this functionality, a Microsoft .Net program has all that it needs to query SAP metadata, call ABAP functions, or send and receive IDOCs.

What it Doesn’t Do

While the SAP .Net Connector takes care of most of the heavy lifting in communicating with an SAP host, there is still considerable work to be done before you can get something useful from it.

In particular, there is no functionality built-in to the SAP .Net Connector for parsing the various data fields from an IDOC. It is up to the receiving program to know what the format of the IDOC is, and how to extract the data from the IDOC.

One other issue to deal with is that the SAP .Net Connector is built for Visual Studio 2003. There is a work around that is easy to use that enables you to use the SAP .Net Connector with newer versions of Visual Studio. Next week we will demonstrate that work around.