原文地址：http://vbsapinf.blogspot.com/2009_01_01_archive.html
Balances, Temperature measuring devices or whatever other device you can think of, over a PC’s Com port to a SAP system.
Here is a basic principle of how that works together: SAPDotNetEN.pdf (pdf reader needed)
Software requirements:
1. You have to create a RFC capable FB within the SAP environment which is done in ABAP very simple.
This FB will than retrieve or write the data from or to the SAP database.
2. You have to program a small application that communicates with the PC’s Com port and your SAP Frontend.
Newer Technologies use the Dotnet SAP Connector which is available in the SAP Marketplace.
I’m using an active-X Component that comes with the SAPGui Installation. You can use the component’s functions to logon to the SAP System and to remote call your FB to exchange the data.
You have to include SAPFunctionsOCX.dll and the SAPLogonCtrl.dll in your projects resource.
In this case here, I will read an externel Temperature device and store the measured temperatures in a database table in the minisap which I used for learning ABAP.
There are two way’s to send the data to the SAP System: 1. is to enter the data manually into the Edit-box of the VB program and press the senddata button, or send it automatically by activating the checkbox: send serial data to R3. In this case, new data is send to R3 whenever the value changes.
In the next picture you can see a small ABAP Application, the .net VB program and a graphic which show’s the Temperature curve.
VB .net source
Posted by Abdul
at 11:59 PM
0 comments
Using SAP .NET Connector
The SAP .NET Connector tool enables .NET portal components to connect to SAP systems, use the portals systems storage, SSO and user mapping. It allows portal component developers to call the functions of SAP systems, such as ERP, CRM and BW. These functions are called RFCs (Remote Function Call), or BAPIs (Business Application Program Interface). These functions are written in ABAP and are an integral part of SAP systems, but a customer can add his own functions, using ABAP development tool.
This section explains how to use the connector to develop portal components that communicate with SAP systems using RFCs.
SAP .NET Connector Overview
SAP offers several technologies to call RFC functions from outside the SAP system, like JCo for Java developers, and DCOM for unmanaged C++ developers. The SAP .Net Connector 2.0 (or NCo 2.0) is especially designed for .NET developers working inside VS2003 (For those familiar with NCo 1.0, click here to see what’s new in NCo 2.0). It allows the developer the means to easily create SAP Proxies to the required functions (C# or VB.NET), and later integrate these proxies to his project. These proxies connect to the SAP system and call the RFC functions using SAP RFC protocol or SOAP.
BAPIs are also organized in Business Objects, in a structure called BOR (Business Object Repository). Each Business Object may contain several functions and properties. For example, a Customer Business Object will contain customer-related BAPIs and a property Customer. NCo allows the developer to create proxies by searching for BAPIs alphabetically or by using the BOR,which contains friendly names for the BAPIs, and even creating a proxy for an entire Business Object.
To connect to SAP systems, NCo uses objects called Destinations to create a connection string for design-time proxy generation and for runtime function calls. Using the basic destination component, the developer can define all the necessary parameters manually. Using the SAPLogonDestination component, the user needs to select one of the target systems defined by his SAP Logon application.
In PDK for .NET this mechanism was extended and a new PortalDestination component was introduced. This object expects to reside in the context of PDK for .NET in Visual Studio or in a portal component. It uses the portal services or Web services in design-time to retrieve connection information stored in the portals systems storage. All the developer needs to select is the alias of the system he wants to use.
To use NCo in Visual Studio, you need to install it. NCo comes in a separate installation from PDK for .NET. Make sure you meet the pre-requisites of NCo.
The rest of this document explains the steps needed to connect to SAP systems. These steps are:
Defining and accessing meta data of an SAP system
Creating the proxy
Filling the proxy
Adding the proxy to the portal component
Adding a destination to the portal component
Binding controls to the data and adding code
See the tutorials demonstrating connection to SAP systems in a step-by-step walkthrough on creating portal components that connect to SAP systems.
Defining and Accessing Meta Data of an SAP System
First, define a destination in Server Explorer that points to a valid server. This Server Explorer destination is needed to connect to the SAP System and query its metadata. It doesn’t have to be the actual system you plan to use, as long as the metadata (functions, object types etc.) is identical. Using this metadata, NCo can create the needed proxies.
Once you’ve defined a valid destination node in Server Explorer, you can use this node as if it was a SAP Server in Server Explorer. This means two folders appear under this folder – Functions and BOR. Both are means to find the functions you need:
The Functions folder is used to add function filters - create groups of RFC function filtered according to their name, allowing wildcards. To add a new function filter, right-click this folder and choose Add new Filter... In the dialog that opens set the filter you want (you can use wildcards such as ‘*’ and ‘?’). Expanding the created filter folder will show all RFC functions that correspond to that filter.
The BOR folder is used to browse the Business Object Repository (see the overview section above). In this folder you can find 2 other folders – "Alphabetical" and "Hierarchical" .Each of them shows the BOR, in a different view:
The Alphabetical folder contains all business objects, sorted alphabetically. You can set the filter property for this folder to show only the business object that correspond with the filter (You can set it even before you first expand it, to avoid the time consuming task of getting all objects).
The Hierarchical folder shows a tree structure which divides the business objects according to their business orientations. Eventually you can find the functions.
Note that the functions found under the BOR Folder are the same as those found under the Functions folder, only they are renamed in the BOR. For each function you can see its properties in the property grid, and one of these properties is the functions ABAP name (which is identical for both).
Creating the Proxy
As mentioned in the overview above, in order to write code that uses RFCs, a developer first needs to create a proxy object which can handle the communication with the SAP system. This proxy needs to be created once, during design time, as part of the project or in a project of its own. Using NCo 2.0, you can create these proxies both in VB.NET or in C# , depending on the project type.
To create a proxy in a project, add a new item of type SAP Proxy to your project. This will add a sapwsdl file to the project. This file will contain all the metadata retrieved from the SAP system, when you later add functions to it. Building the project will create the actual proxy files from this sapwsdl file (much like using a web service). If you open the sapwsdl file, you will see an empty special designer. This designer is where you drag functions and components to add them to your proxy.
Filling the Proxy
When you drag the functions you wish to use to the designer, NCo will query the SAP system to get the meta-data needed to execute these functions – tables, structures etc’ – and will generate the needed objects as SAP Data types. You can drag as many functions as you want to a single proxy, but it makes good practice to use one proxy for one business logic (you can have as many proxies in your project as want). For example, you can create a proxy called "Cost Center" and drag to it the all the cost-center related functions you need. Alternatively, you can just drag the CostCenter business object itself from the BOR hierarchy tree. This will add to the proxy all functions, meta-data and Proxy Fields of the CostCenter business object.
Proxy Fields are objects that can be of any SAP Proxy object type. These fields are meant to preserve "state" of the proxy and to simplify using the proxy. You can add fields from the toolbox (located in the "SAP Proxy" tab). You can rename, choose the type and the default value of each field in its property grid. Once you added these fields, you can bind function parameters to them.
Binding the parameters of a function creates an additional overloaded function call in which the bound parameters have been removed. In addition to binding parameters to fields, you can choose to remove any un-needed parameters and to give parameters static default values (strings, numbers etc’). All this can be done by right-clicking a function in the designer, and selecting "Edit Parameters..." There, go over the parameters and edit them as you wish. To bind a parameter to a field, open the combo box of the "default" property and select the field.
In continuance of the example of the BOR proxy from above: when you drag the business object to your designer, fields will be added automatically to your proxy according to the fields defined in the business object. In addition, all functions using these fields as parameters will be bound to the fields. See SAP .NET Connector client programming documentation for many more configuration options that were not mentioned here.
Adding the Proxy to the Portal Component
Once the proxy is created you need to add an instance of it to your portal component. You can add the same proxy to as many portal components as you want, and even add the same proxy to the same portal component many times (each will be a different instance of the same proxy class). Note that if you created the proxy in a different project, each project using that proxy must include (as "copy local") the dll containing the proxy definitions, since only a single portal application project is deployed to the portal.
Adding is done by opening the toolbox in the "SAP Proxy" tab and locating the proxy you defined (all proxies that exist in the solution will appear in the toolbox). Drag this proxy to your portal component designer to add it. You can then rename it as you wish. If you look at the properties of the added proxy you can see the fields you added as properties.
Adding a Destination to the Portal Component
The proxy you added to you portal component is not connected to any specific SAP system - the system we used in order to get the meta-data might not be the system used to get the actual data. The easiest way to connect the proxy to a system, is to add a destination component to your portal component. This component can create the connection string needed to connect.
In PDK for .NET, it is recommended to use the new PortalDestination component. This component contacts a portal service to retrieve connection information stored for a desired system. Each system has an alias, so the connection string can be defined by setting a single property – System Alias. You can add as many PortalDestination objects as you wish.
To use this destination, system connection details should be set in the portal that the portal component will run in. Also, the user should have access to the system by having authentication defined (by user mapping or SSO or certificate).
To add the PortalDestination to your portal component, you have two options:
Open the toolbox in the "SAP Proxy" tab and drag it from there (If it's not there, add it to the toolbox using "Add/Remove Items..."). Then open the property grid of the added component and set the property "System Alias". You can either type it or click the ellipsis button (which will open a dialog box connected to the portal you have defined as Current Portal).
Open the server explorer and drag a destination node which is already set to a specific alias.
After you've added the PortalDestination component and set its alias property, you can see the generated connection string by looking at the connection string property. The connection details are retrieved from the current portals systems storage and the authentication is retrieved from the mapping defined for the user which is defined in the current portal.
Notice that here again the details shown are those retrieved from the portal defined as current in server explorer. So the information there might not match what you expect. To remedy this problem you can add the appropriate portal and set it as current, or simply ignore it.
Finally, you need to set the connection property of you proxy to the PortalDestination you want. You can do this in code or simply by setting Connection property in the property grid by using the combo box.
Binding Controls to the Data and Adding Code
Now, you have full access to the RFC functions you want. All you have to do is add controls to your portal component, like tables, drop downs and buttons. Bind each control to the relevant proxy fields that return information from the SAP system.
Add in the relevant places, such as button clicks event handlers, load event handlers, the actual function calls. When calling the functions, set the values you want to send to the RFC from the user selections or from code. Remember you can use the overloaded functions or the regular ones, but note that the overloaded ones will be the ones bound to the proxy fields. Eventually, call DataBind on the controls that need to display the information.