A Spotlight On The New .NET Connector 3.0

SAP Network Blog: A Spotlight on the New .NET Connector 3.
0 Page 1 of 9
Blogs
A Spotlight on the New .NET Connector 3.0 Subscribe

Thomas Weiss Print
Business Card
Permalink
Company: SAP AG
Posted on Jan. 14, 2011 06:42 AM in ABAP, Application Server, Interoperability, Interoperability .NET Share
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.
The Benefits of .NET Connector 3.0

For mass transactions or heavy load scenarios the NCo is an important alternative to Web Services or SAP Process Integration. Maybe you are still using NCo 2.0 and do not really know if and why
you should upgrade to the next NCo release. So what is the benefit of upgrading to NCo 3.0 and why should you invest in this procedure. After reading this weblog you should be convinced that the
payoff for upgrading to NCo 3.0 is worth it. In particular you will learn that NCo 3.0:
 Is more stable, robust and more secure
 Enforces a better design of your application by decoupling the connection handling from the .NET application proper
 Encourages separation of concerns: infrastructure embedding is clearly separated from business application logic
 Reduces memory consumption
 Allows dynamic programming without the need for proxy generation
 Can dynamically look up metadata (so if something changes in the related ABAP system - e.g. if parameters in a function module signatures are added or the ABAP system is switched from Non-
Unicode to Unicode, you no longer need to regenerate the proxies and recompile your solution)
 Is no longer bound to a special Visual Studio version.
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.
The Client Programming Model – Providing the Configuration

SAP has spent quite some effort on making the new NCo more secure and has placed a special emphasis on security concerns. In particular it is now much more difficult for an intruder
 To read the logon data,
 To replace the logon data in order to get a backend session on the ABAP server with more authorizations and
 To get access to an open connection that was opened for another application.
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.
The Client Programming Model – Creating the Client Code

One main difference to .NET Connector 2.0 is that there is no need to pay any attention on how to handle the connections. The internal technical details of opening, closing, and managing
connections are no longer handled by the application developer. Instead, the complete connection management is done by the .NET Connector. You no longer have to worry about this. Another
important difference lies in the way the parameters that are exchanged with the ABAP application are handled.
Take a look at the simple application below to get a first impression of what working with the .NET Connector 3.0 is like. This way you will easily grasp many of the advantages of the new NCo 3.0.
As I mentioned, for creating a demo application it is, of course, still possible to store the configuration data including the password in clear text in a configuration file. In our little demo here, we
take the password from a simple implementation of the provider method GetParameters of a class that implements the interface IDestinationConfiguration. But you should not do this in a real world
application. It is just a handy way to provide the logon information in demo scenarios.
In order to give you an example that runs on your system, I show you a complete small application. So this is what the class providing our configuration data plus some declarations looks like:
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:
public static void Main(string[] args)

{
RfcDestinationManager.RegisterDestinationConfiguration(new
MyBackendConfig());//1
RfcDestination prd = RfcDestinationManager.
GetDestination("PRD_000");//2
try
{
RfcRepository repo = prd.Repository;//3

IRfcFunction companyBapi =
repo.CreateFunction
("BAPI_COMPANY_GETDETAIL");//4
companyBapi.SetValue("COMPANYID", "001000"); //5
companyBapi.Invoke(prd); //6
IRfcStructure detail = companyBapi.
GetStructure("COMPANY_DETAIL");
String companyName = detail.
GetString("NAME1");//7
Console.WriteLine(companyName);
Console.Read();
}
// next you should handle all the relevant exceptions, but
// we will not do this here
// some exception handling
Though the example is very simple just some comments on the relevant steps (confer the outcommented digits at the end of the lines):
1. Register the relevant destination object.
2. Get the destination corresponding to the ABAP system you want to call.
3. Next you need a repository for the metadata from the ABAP Dictionary of the corresponding destination system.
4. Create a function object (that will hold the values of the relevant parameters)
5. Provide the values for the relevant importing parameters of the function.
6. Execute the function.
7. Read the exporting or returning parameters and process them.
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
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.
How to Keep the State

The example I have shown you works with a stateless synchronous RFC which means that the invoke method not only gets a connection from the relevant pool and executes it, but also resets the
session on the ABAP system and returns the connection back to the pool.
A stateless call will not do if you need to call two BAPIs and the second BAPI has to run in the same context on the ABAP Application Server as the first one. So you need a way to tell the .NET
Connector that you now need a connection that is kept open until you want the .NET Connector to close or return it to the connection pool, in other words you need to inform the .NET Connector
that you need a stateful connection.
Still, also in the case of a stateful connection, the technical handling of the connection is left to the .NET Connector. Again there is no need for you to grab a connection yourself. The .NET
Connector does all the connection handling and your code looks like this:
RfcSessionManager.BeginContext(destination);
firstBAPI.Invoke(destination);
secondBAPI.Invoke(destination);
RfcSessionManager.EndContext(destination);
With BeginContext() you get an RFC connection for your destination from the connection pool and attach it to the currently executing thread for exclusive usage. In other words with this statement
you reserve an RFC connection for your thread.
The two Invoke() calls for the first and second BAPI check, whether there is a connection bound to the current thread, and if they find one, they use it for their call. Also the context of the relevant
ABAP session is kept until the EndContext() detaches the exclusive RFC connection from the current thread, performs a backend context reset on that connection and returns the connection to the
pool.
If you work in the context of a .NET Server with a session management of its own you just need to create your own ISessionProvider object and register it with the RfcSessionManager. But this is
something I will not show or explain in any detail here.
The .NET Connector as a Server

If you use the NCo 3.0 as a server the philosophy behind the programming model is the same as in the client use case: The NCo handles many things for you so that you need not worry about
many problems, because the SAP connectivity team has solved these problems for you.
In particular this means: First of all, as in the client case, the management of the connections is done completely by the NCo, and again you can store your configuration data outside the application
proper wherever you like in any form you like. Secondly, you need no longer trouble yourself with another quite complex task that you had to take care of with the former release of the NCo: By
default, the thread management is done by the NCo 3.0.
Again I will show all relevant steps by guiding you through a simple example that presents a basic stateless NCo server. It consists of three new classes:
 A class that provides the server configuration
 A handler class that contains the code that should be executed if the relevant function module is called from the ABAP system.
 The server class.
In addition the client configuration class from the client configuration is also needed.
Providing the Server Configuration

So let us start with the class providing the server configuration:
public class MyServerConfig : IServerConfiguration

{
public RfcConfigParameters GetParameters(String serverName)
{
if ("PRD_REG_SERVER".Equals(serverName))
{
RfcConfigParameters parms = new RfcConfigParameters();
parms.Add
(RfcConfigParameters.RepositoryDestination, "PRD_000");
parms.Add(RfcConfigParameters.GatewayHost, "demoserver");
parms.Add(RfcConfigParameters.GatewayService, "sapgw00");
parms.Add(RfcConfigParameters.ProgramID, "DEMO_SERVER");
parms.Add(RfcConfigParameters.RegistrationCount, "5");
return parms;
}
else return null;
}
// The following code is not used in this example
public bool ChangeEventsSupported()
{
return false;
}
public event RfcServerManager.ConfigurationChangeHandler
ConfigurationChanged;
}
As in the client example we first need a class to provide the necessary server configuration, technically this is a class that implements the interface IServerConfiguration and as a consequence has a
GetParameters method. In this case we define a configuration with the name PRD_REG_SERVER.
For the server in NCo 3.0 with dynamic metadata lookup, you need two connections: one client connection for the DDIC lookup and a server connection to enable the ABAP system to call the .NET
Connector server. And as a consequence you need two sets of configuration data:
As for the client connection we reuse the configuration data from the previous client example PRD_000. This means that you have to include the class MyBackendConfig (but without its main
method, because we do not need this method here) if you want to run this server example.
As for the server connection you have to connect to the ABAP system by using an intermediate SAP Gateway. This is shown in the figure below:
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.
Creating a Handler Method in the Server

In general to provide one or more handler methods, we have to implement one or more methods that will process incoming RFC calls. In our example we choose one static method for each function
module. We assign an annotation to the method as shown below:
[RfcServerFunction(Name = "STFC_CONNECTION", Default = false)]
public static void Function(RfcServerContext context, IRfcFunction function)
The two parameters context and function are provided by the .NET Connector runtime when the method is called.
You could also have one static method as a default for all function modules that don’t have an explicit method assigned to them. Just set the attribute Default in the annotation to true. It is also
possible to work with instance methods in the same manner. You should use this if you create a stateful server, but I will not show this in any detail here in this introductory weblog.
So this is what the handler method for the function module STFC_CONNECTION looks like in our example:
public class MyServerHandler

{
[RfcServerFunction(Name = "STFC_CONNECTION")]
public static void StfcConnection(RfcServerContext context,
IRfcFunction function)
{
Console.WriteLine("Received function call {0} from system {1}.",
function.Metadata.Name,context.SystemAttributes.SystemID);
String reqtext = function.GetString("REQUTEXT");
Console.WriteLine("REQUTEXT = {0}\n", reqtext);
function.SetValue("ECHOTEXT", reqtext);
function.SetValue("RESPTEXT", "Hello from NCo 3.0!");
}
}
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.
Create and Run the Server

With the configurations defined and a handler class with the relevant handler method prepared we have now all we need at hand to write the server class:
public class MyServerDemo

{
public static void Main(string[] args)
{
RfcDestinationManager.RegisterDestinationConfiguration(new
MyBackendConfig());//1
RfcServerManager.RegisterServerConfiguration(new
MyServerConfig());//2
Type[] handlers = new Type[1] { typeof(MyServerHandler) };/3
RfcServer server = RfcServerManager.GetServer("PRD_REG_SERVER",
handlers);//3
server.Start();//4
Console.WriteLine("Server has been started. Press X to exit.\n");
while (true)
{
if (Console.ReadLine().Equals("X")) break;
}
server.Shutdown(true); //Shuts down
//immediately aborting ongoing requests.
}
}
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.
And Much More

Of course there is much more that you can do with the new .NET Connector 3.0 and much of it is described in the overview document I have already linked above. Just to mention a few more
scenarios that are possible with NCo 3.0:
 When creating a NCo client you can use transactional RFC tRFC/qRFC/bgRFC to make sure that the remote call is executed exactly once.
 In an analogous manner you can also use tRFC/qRFC/bgRFC in the server use case.
 You can write a stateful NCo server program interacting with .NET programs that have their own user session handling and with .NET programs that do not have this.
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.
Comment on this weblog
Showing messages 1 through 23 of 23.
Titles Only Main Topics Oldest First

 web service with sap net connector 3
2011-02-11 12:19:47 Santiago Aguirre Business Card [Reply]
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:
1. Implementation of the IDestinationConfiguration.

2. The web method for creating the quotation registers the destination configuration.
3. We use the repository in order to invoke and commit the required BAPI.
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,
Congratulations, great job!!!!
I have two questions.
1) There are support on 64 bits plataform?
2) Does The new version support the code/implementation of .NET Connector 2.0?
 .NET Compact Framework

2011-02-09 02:37:39 Jari Pakarinen Business Card [Reply]
Hi,
Is .NET Compact Framework supported ?
Kind Regards,
Jari
 Using .netconnector 3.0 with VBA ?

2011-02-01 03:16:08 Juraj Striezenec Business Card [Reply]
Is there any possibility to use .net connector in VBA for instance in excel for Remote functional call?
Any example , if possible.
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
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
Just a guess,but may need a stateful implementation and use of:
if (!context.Stateful)
context.SetStateful(true);
 Idoc
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,
"Error message: RfcCompressor: CsRGetHandle failed"
This is a bug in the NCo decompressor. It was fixed with version 3.0.1, just download the latest version.
Best Regards, Ulrich Schmidt, RFC Connectivity
 Idoc
Hi Ulrich ,
Thanx a lot , ist work fine
Best Regards
Sébastien
 IDoc Processing
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
Hi Thomas,
just to let you know, I have a prototype program processing inbound/outbound Idocs to/from SAP using Nco 3.
Very impressed with new connector, highly adaptable and dynamic.
 IDoc Processing
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.
I am a .Net/BizTalk programmer but do have full SAP support on site
Many Thanks
Alan
 SAP Guidelines may need an update

2011-01-25 08:23:29 Mario Hernandez Business Card [Reply]
According to the 2010 SAP Guidelines for Best-Built Applications That Integrate with SAP Business Suite ...
".NET Tools SOA-NET-1.
SAP recommends that .NET developers use the SAP Enterprise Services Explorer tool for Microsoft .NET. SAP does not recommend using .NET connector."
Maybe they need to update this guideline too.
 Error
2011-01-24 11:08:49 Rodrigo Silveira Business Card [Reply]
Hi,
I tried download, but shows the message:

Error Message - ObjectID not existant
 Error
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
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?
Hello Huseyin,
yesterday we have uploaded a new version of JCo 3.0 that works with .NET Framework 4.0.
I propose you should use this version.
Regards
Thomas
 .NET Framework 4?
2011-01-25 02:28:49 Huseyin Akturk Business Card [Reply]
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?
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
Showing messages 1 through 23 of 23.

A Spotlight On The New .NET Connector 3.0

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

A Spotlight On The New .NET Connector 3.0

Hochgeladen von

Copyright:

Verfügbare Formate

SAP Network Blog: A Spotlight on the New .NET Connector 3.

A Spotlight on the New .NET Connector 3.0 Subscribe

The Benefits of .NET Connector 3.0

The Client Programming Model – Providing the Configuration

The Client Programming Model – Creating the Client Code

public static void Main(string[] args)

RfcRepository repo = prd.Repository;//3

How to Keep the State

The .NET Connector as a Server

Providing the Server Configuration

public class MyServerConfig : IServerConfiguration

Creating a Handler Method in the Server

public class MyServerHandler

Create and Run the Server

public class MyServerDemo

And Much More

Comment on this weblog

Showing messages 1 through 23 of 23.

Titles Only Main Topics Oldest First

1. Implementation of the IDestinationConfiguration.

Congratulations, great job!!!!

I have two questions.

1) There are support on 64 bits plataform?

 .NET Compact Framework

Is .NET Compact Framework supported ?

 Using .netconnector 3.0 with VBA ?

Any example , if possible.

2011-02-04 06:57:57 Moog Sébastien Business Card [Reply]

Just a guess,but may need a stateful implementation and use of:

"Error message: RfcCompressor: CsRGetHandle failed"

Best Regards, Ulrich Schmidt, RFC Connectivity

Very impressed with new connector, highly adaptable and dynamic.

I am a .Net/BizTalk programmer but do have full SAP support on site

 SAP Guidelines may need an update

".NET Tools SOA-NET-1.

Maybe they need to update this guideline too.

I tried download, but shows the message:

I propose you should use this version.

Showing messages 1 through 23 of 23.

Das könnte Ihnen auch gefallen