Professional Documents
Culture Documents
0 Page 1 of 9
Blogs
SAP .NET Connector 3.0 is now released and you surely want to know more about it.. In this weblog I want to
Give you a very short overview on what is new with the SAP .NET Connector 3.0
Show a very simple demo application on how to use the .NET Connector as a stateless client
Present a simple example of a stateless NCo server scenario.
By learning some relevant details of the two demo applications you will get some understanding of the new programming model of the .NET Connector 3.0. In addition, I mention some other use
cases such as stateful or transactional scenarios without going into any details.
NCo 3.0 brings a complete redesign of the NCo API and a new architecture that also requires some redesign of the applications using the NCo. But as you will learn in this weblog, it is worth
redesigning your applications so that they can use the new .NET Connector 3.0. The redesign of the NCo is the result of a long experience with NCo 2.0 as well as with SAP Java Connector 2.1 and
3.0. SAP has capitalized on the benefits of the NCo 2.0 and improved its strengths and as a result we have a far more powerful NCo.
This weblog is a spotlight that should give you an impression of what using the new .NET Connector 3.0 is like and a first idea of how to work with this new release of the NCO. If you are interested
in some more details look at this overview document on which my weblog is based.
If you want to download the .NET Connector 3.0 and you have a user in the SAP Service Marketplace you can download the new NCo and its documentation here:
https://service.sap.com/connectors -> SAP Connector for Microsoft .NET.
In order to store configuration data in a secure way you can now keep it on a central LDAP server and read it on the fly from an LDAP by using the following approach:
When the .NET Connector needs logon data to open an RFC connection to an Application Server ABAP, it looks into your code for the relevant information. In order to provide it you need to
implement the interface IDestinationConfiguration and register an instance of that class with the .NET Connector when you start your application. These are the necessary steps:
1. Implement the method IDestinationConfiguration.GetParameters( string destinationName). Inside this method you can retrieve the relevant configuration data in any way you like, for
example read the necessary logon parameters from a database or LDAP directory or prompt the user to input them in a dialog window. If you don ’t know logon parameters for a system
called destinationName, then just return null.
2. Create an instance of the above implementation and register it with the NCo using the method RfcDestinationManager.RegisterDestinationConfiguration().
3. You can now make client calls to the relevant destinations and NCo will automatically get access to the logon information for each backend system by calling the GetParameters() method
mentioned above.
Using this approach you obviously can write simple configurations for demo scenarios that have the configuration in clear text in the code as well as real world configurations that draw the relevant
configuration data from an LDAP server, an encrypted file or some other source of your choice.
Once the .NET Connector has initialized a connection pool for a particular RFC destination, there is no further need to provide the configuration data for any connections belonging to this
destination. Still if necessary it is possible to change the configuration data and to inform you application about this by using the event
public event RfcDestinationManager.ConfigurationChangeHandler ConfigurationChanged in the interface IDestinationConfiguration.
http://weblogs.sdn.sap.com/pub/wlg/23051 2/14/2011
SAP Network Blog: A Spotlight on the New .NET Connector 3.0 Page 2 of 9
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using SAP.Middleware.Connector;
namespace ConsoleApplication1.obj
{
public class MyBackendConfig : IDestinationConfiguration
{
public RfcConfigParameters GetParameters(String destinationName)
{
if ("PRD_000".Equals(destinationName))
{
RfcConfigParameters parms = new RfcConfigParameters();
parms.Add(RfcConfigParameters.MessageServerHost,
"some.ABAP.host");
parms.Add(RfcConfigParameters.LogonGroup, "PUBLIC");
parms.Add(RfcConfigParameters.SystemID, "ABC");
parms.Add(RfcConfigParameters.User, "user");
parms.Add(RfcConfigParameters.Password, "password");
parms.Add(RfcConfigParameters.Client, "100");
parms.Add(RfcConfigParameters.Language, "en");
parms.Add(RfcConfigParameters.PoolSize, "5");
parms.Add(RfcConfigParameters.MaxPoolSize, "10");
parms.Add(RfcConfigParameters.IdleTimeout, "600");
return parms;
}
else return null;
}
// The following two are not used in this example:
public bool ChangeEventsSupported()
{
return false;
}
public event RfcDestinationManager.ConfigurationChangeHandler
ConfigurationChanged >
}
}
As mentioned above, you need a class that implements the relevant interface IDestinationConfiguration and an implementation of the method GetParameters that puts the relevant values in the
returning parameter of the method.
Creating the client coding is very simple and straight forward:
If you are familiar with .NET Connector 2.0 two main differences will strike you:
You do not open or close any connection yourself. There is no need to do it. And, in general you cannot grab a connection itself. You create a destination and the .NET Connector provides a
connection when you need one, keeps it in a pool, closes it after the given idle timeout and takes care of all of the work related to this.
There are no proxy classes, but just function classes that serve as containers for the relevant parameters.
If you take care of closing all the brackets in the example, you can copy it to your development environment, reference the relevant .NET Connector libraries and input the configuration data for a
real Application Server ABAP that has the BAPI BAPI_COMPANY_GETDETAIL. If the user that you provide in your configuration has the authorization to call this BAPI the program will run on your
system and output a result in the console
You wonder why I have not told you which development environment is needed for the .NET Connector 3.0. There is no need to. This release does not support and as a consequence not depend on
http://weblogs.sdn.sap.com/pub/wlg/23051 2/14/2011
SAP Network Blog: A Spotlight on the New .NET Connector 3.0 Page 3 of 9
any particular development environment. To those of you who have worked with the .NET Connector 2.0 this is also new, because this is a major difference.
In addition the client configuration class from the client configuration is also needed.
http://weblogs.sdn.sap.com/pub/wlg/23051 2/14/2011
SAP Network Blog: A Spotlight on the New .NET Connector 3.0 Page 4 of 9
To those familiar with how to configure an NCo 2.0 server it will be no news how you connect via the intermediate SAP Gateway. Still, I want to spend some words on it for those who don ’t know
how to do this. You need these three values:
Hostname (the host on which the SAP Gateway runs),
Gateway service (you can compare this to a port. It has to be sapgwxx where the last double x stands for the system number) and
Program ID
in order to identify the server destination uniquely. You must provide the same values for these parameters both when defining the .NET server configuration as shown above in the code example
and when defining the RFC destination as a TCP/IP connection in the transaction SM59 as shown below in the next figure:
So much for our explanation of how to get the configuration data of our .NET server program. Next we need a class that provides the handler method for a call from an ABAP system that calls a
function module STFC_CONNECTION on our .NCo server.
http://weblogs.sdn.sap.com/pub/wlg/23051 2/14/2011
SAP Network Blog: A Spotlight on the New .NET Connector 3.0 Page 5 of 9
We output the parameter REQUTEXT on the console, return the value of this parameter in the parameter ECHOTEXT and put some variation of "Hello World ” in the parameter RESPTEXT. Both
parameters: ECHOTEXT and RESPTEXT are returned to the ABAP client.
This is what happens in this method (see the commented-out digits at the ends of the lines):
1. Register the destination for the DDIC lookups.
2. Register the server configuration.
3. Register the handler(s) and create a server instance by passing the server name and an array with the handler(s) to the constructor method.
4. Start the server.
That’s all. This simple code suffices to set up a server that can not only handle calls of the function module STFC_CONNECTION, but handle up to 5 parallel calls because we have set the
RegistrationCount to 5 in the MyServerConfig class.
Just remember: To make the program run, copy the code of all four classes MyBackendConfig (without its main method), MyServerConfig, MyServerHandler, MyServerDemo plus the information on
used name spaces to your .NET development environment. You must also adapt the configuration data accordingly so that you can connect to a real SAP Gateway and a real ABAP Application
Server.
Apart from any details, all these use cases have one feature in common: You need not directly interact with connections, that is, open and release them. Instead all connection handling is done
transparently from you by the .NET Connector 3.0. All you have to do is to provide the relevant configuration data. Of course the tRFC/qRFC/bgRFC examples are more complex as they require you
to provide the storage of the TID and the payload data and some more code. But this is another story and as many other details beyond the scope of this introductory weblog.
Summary
You have now seen how easily you can write a stateless client and stateless server scenario using the .NET Connector 3.0. You certainly have realized that the code is far more transparent because
of the separation of concerns realized in the new .NET Connector architecture:
The configuration is left to an administrator and can easily be stored outside the application proper. This makes the application code more straightforward and easier to maintain. Moreover you
can adapt or change the destination without touching the application code.
As an application developer you do not need to fiddle with the connections, but leave the complete connection management to the .NET Connector.
This is true even for stateful scenarios. You just have to tell the NCo for which lines of code you need a stateful connection. And this is all. Again you work only with destinations and leave the
handling of the connections proper to the .NET Connector.
As mentioned, other scenarios such as transactional calls are also possible in the server and the client case. They are sketched elsewhere. I hope this weblog has shown you some of the many
advantages of the NCo 3.0 and inspires you to try out the new .NET Connector 3.0. I am sure that sooner or later, you will adapt your existing applications for NCo 2.0 to NCo 3.0 and thereby make
them more transparent and secure and profit from the better design that comes with the separation of concerns.
Thomas Weiss works in the SAP NetWeaver Product Management and has built elearning tutorials on ABAP topics.
http://weblogs.sdn.sap.com/pub/wlg/23051 2/14/2011
SAP Network Blog: A Spotlight on the New .NET Connector 3.0 Page 6 of 9
Dear Thomas,
We are using SAP.NET Connector 3.0 within a web service to execute different BAPI's from a Visual Studio environment. So far we have succesfully registered a Customer Quotation in SAP from
our web service. However, when consuming the web service for a second time (creating a new quotation) we have encountered the following error: "Destination configuration already
initialized". We have made the following steps:
Are we missing something? Are we on the wrong track when using SAP.NET Connector 3.0 with web services? We appreciate any help you can give us on this subject.
Good News!!!!
2011-02-09 03:44:01 ALEX MARIN SILVA Business Card [Reply]
Hi Tomas,
2) Does The new version support the code/implementation of .NET Connector 2.0?
Hi,
Kind Regards,
Jari
Is there any possibility to use .net connector in VBA for instance in excel for Remote functional call?
Thank you
Juraj
Problem
2011-02-01 02:45:12 Moog Sébastien Business Card [Reply]
Hi Thomas
Did you faced problems when trying to send a lot of Idocs with .Net Connector 3 ?
Thanx
Problem
2011-02-04 05:47:14 Alan Todd Business Card [Reply]
Hi Sebastien,
I'm getting no problems sending Idocas to SAP, if you need any sample code drop me a line.
Problem
http://weblogs.sdn.sap.com/pub/wlg/23051 2/14/2011
SAP Network Blog: A Spotlight on the New .NET Connector 3.0 Page 7 of 9
Hi Alan
it wa a bug in the NCo decompressor. i have installed version 3.0.1 and it work fine
Thanx
Best regards
Sébastien
Idoc
2011-01-31 08:44:12 Alan Todd Business Card [Reply]
if (!context.Stateful)
context.SetStateful(true);
Idoc
2011-02-01 02:31:03 Moog Sébastien Business Card [Reply]
Hi Alan
Thank's for the reply, i set the context.SetStateful(true), unfortunately i have still the same error.
regard's
Sébastien
Idoc
2011-02-03 07:53:39 Ulrich Schmidt Business Card [Reply]
Hi Sébastien,
This is a bug in the NCo decompressor. It was fixed with version 3.0.1, just download the latest version.
Idoc
2011-02-04 06:55:49 Moog Sébastien Business Card [Reply]
Hi Ulrich ,
Thanx a lot , ist work fine
Best Regards
Sébastien
IDoc Processing
2011-01-25 09:22:36 Alan Todd Business Card [Reply]
Hi Thomas,
in order to process IDoc's on a Server component,Iam I correct to assume we need to call the IDOC_INBOUIND_ASYNCHRONOUS rfc.
Many Thanks
IDoc Processing
2011-01-26 02:04:24 Thomas Weiss Business Card [Reply]
Hello Alan,
it is possible to use the function module IDOC_INBOUND_ASYNCHRONOUS, but it might be easier to process IDOCs if you use the SAP Business Connector. Use this link to find information
on the SAP Business Connector: https://service.sap.com/connectors menu entry SAP Business Connector.
Regards
Thomas
IDoc Processing
2011-02-04 05:44:49 Alan Todd Business Card [Reply]
Hi Thomas,
just to let you know, I have a prototype program processing inbound/outbound Idocs to/from SAP using Nco 3.
http://weblogs.sdn.sap.com/pub/wlg/23051 2/14/2011
SAP Network Blog: A Spotlight on the New .NET Connector 3.0 Page 8 of 9
IDoc Processing
2011-01-26 04:36:43 Alan Todd Business Card [Reply]
Hi Thomas,
currently we are using the SAPIDocReciver and IDocSender class's from the SAP .Net Connector V.2. This has been incorporated into a Custom BizTalk Adapter. Ideally we would be
looking to replace the SAP .Net Connetor Ver 2 layer with Ver 3 of the SAP .Net Connector. Use of the SAP Business Connector would require a much greater change.
If we use the new version of the SAP .Net Connector, will we need to check the DDIC to ascertain what paramters are required for calling IDOC_INBOUND_ASYNCHRONOUS rfc.
Many Thanks
Alan
According to the 2010 SAP Guidelines for Best-Built Applications That Integrate with SAP Business Suite ...
SAP recommends that .NET developers use the SAP Enterprise Services Explorer tool for Microsoft .NET. SAP does not recommend using .NET connector."
Error
2011-01-24 11:08:49 Rodrigo Silveira Business Card [Reply]
Hi,
Error
2011-01-25 01:10:04 Thomas Weiss Business Card [Reply]
Hello Rodrigo,
we have tested the download and it worked. It might be that you tried to download the file just at the time when we substituted the files yesterday. Let us know if the problem persists.
Thomas
Error
2011-01-25 01:09:18 Thomas Weiss Business Card [Reply]
Hello Rodrigo,
we have tested the download and it worked. It might be that you tried to download the file just at the time when we substituted the files yesterday. Let us know if the problem persists.
Thomas
.NET Framework 4?
2011-01-23 16:39:41 Huseyin Akturk Business Card [Reply]
Hi,
Current NCO 3.0 is working with .NET Framework 4? Did you try it?
.NET Framework 4?
2011-01-25 01:32:43 Thomas Weiss Business Card [Reply]
Hello Huseyin,
yesterday we have uploaded a new version of JCo 3.0 that works with .NET Framework 4.0.
Regards
Thomas
.NET Framework 4?
2011-01-25 02:28:49 Huseyin Akturk Business Card [Reply]
http://weblogs.sdn.sap.com/pub/wlg/23051 2/14/2011
SAP Network Blog: A Spotlight on the New .NET Connector 3.0 Page 9 of 9
Hi Thomas,
When I checked checked version of Nco, there are two different versions; one for framework 2.0 and second is framework 4. I want to ask that will you produce a new version for each
framework?
Thanks.
Huseyin Akturk
.NET Framework 4?
2011-01-25 07:37:48 Thomas Weiss Business Card [Reply]
Hello Huseyin,
there is one version for .NET framework 2.0 to 3.5 and another version for .NET framework 4.0, because .NET framework 4.0 contains incompatible changes.
Regards
Thomas
http://weblogs.sdn.sap.com/pub/wlg/23051 2/14/2011