DCOM Object Builder
Overview
The DCOM Object Builder is part of the DCOM Connector and serves as a development tool for creating DCOM proxies from business objects or from remote functions of the R/3 system, respectively. The generation is controlled via a graphical user interface, the Connector Wizard.
DCOM proxies act as placeholder classes for the respective objects in the R/3 system, that is, the business logic is in the R/3 system. The DLL created during the generation is assigned to an MTS package and installed there. MTS then provides a runtime environment that allows you to access R/3 components based on COM.
The DCOM Object Builder carries out this access by calling BAPIs directly, that is by directly calling the function modules that define them. This procedure offers performance advantages, since no BOR runtime is required.
Functionality
Architecture: DCOM Object Builder
In the figure below you can see how the DCOM Object Builder is integrated into the R/3 architecture:
The DCOM Object Builder is installed in the MTS. It serves as a development tool that generates DCOM proxies from R/3 components (business objects and remote functions). The generated proxies are available in the form of a DLL. To keep the DLL as small as possible, the ActiveX Template Library is used. However, this requires Microsoft Visual C++ 5.0 (or higher) to be installed on the proxy server.
A Connector Wizard installed locally on the client machine allows you to specify logon parameters and project information, to select the MTS package in which to store the COM objects, and to select the business objects or remote functions to be installed.
The components installed in the MTS use the DCOM Connector to access meta information from the BOR. The DCOM Connector communicates with the R/3 application server via RFC.
Note:
A remote generation is also possible (if the DCOM Object Builder is called from a different machine). However, in this case the DCOM Connector components must be exported and installed on the client machine.
The DCOM Object Builder itself consists of a set of COM objects required for generating the DCOM proxies and for installing the generated DLL in the MTS. The MTS then provides a runtime environment for DCOM proxies based on COM.
The generation process consists of two steps:
Source Files:
The generation creates three categories of source files that are stored in a project directory of the MTS server:
For each Project:
Project.mak Project file.
Project.cpp Apart from the obligatory function DLLMain the file contains other functions for creating object types (from a class factory) and for registration.
Project.rc Resource file of the project.
Project.idl IDL source (Interface Definition Language) with the interface description. This description is required for generating the Type Library. The file contains the definitions of all COM interfaces with the corresponding GUIDs for the selected objects of the project.
Note:
Each interface has a number for a globally unique identification, the Globally Unique ID (GUID).
Project.def DEF file with the exported functions of the DLL.
ProjectAfx.cpp The C++ source file already contains standard includes.
ProjectAfx.h Include file for standard include files (with type definitions).
ProjectRes.h The include file is created by default by the Microsoft Dev. Studio; it is needed by the resource file "Project.rc".
For each ObjectType:
ObjectType.cpp Implementation of a proxy object (for example, a business object). For calling a remote function in R/3, methods of the DCOM Connector Template Library are used.
ObjectType.h Contains the class definition for the corresponding proxy object.
ObjectType.rgs The RGS file describes the registry entries to be created (among them ProgID, InterfaceID, user and system data).
For each StructureType:
StructureType.h Describes the fields of the corresponding ABAP Dictionary table.
Note:
The generated files can be added to an existing ATL project without any problems, for example, for later modifications of the source coding.
Files After Compiling and Linking
Project.h
Contains definitions for interfaces and generates headers for interfaces to objects from R/3. It contains data from the IDL file.Project.lib LIB file
Project.log Output from the MIDL (Microsoft IDL), C++ compilers and linkers is deviated into this file. The LOG file keeps a log of all errors occurring during compilation and linking.
Project.tlb The Type Library contains the interface description revealed by objects from R/3.
Project.dll The DLL to be installed also contains the Type Library.
During installation, only the generated DLL file (Project.dll) is installed. It is installed within the MTS in a package. MTS then provides a runtime environment for the instancized proxy classes. You can now access R/3 components via their COM objects.
How are Business Objects Mapped to COM Objects?
Apart from their basic data (such as creation data), business objects from the R/3 Business Object Repository are characterized by an object description. An object description contains the definition of the key fields and specifies attributes, methods, events, and interfaces. The key fields are used for a unique identification of an instance (the corresponding object in the R/3 database).
The DCOM Object Builder generates a proxy class for each business object, which is instancized within the MTS runtime environment and then acts as COM object.
COM objects are also identified by key fields. Apart from these key fields (read-only) and the BAPI methods, a number of other standard attributes and standard methods are generated.
Attributes:
| connection parameter | Parameter | Type of Return value | Description |
| Destination | BSTR | specifies the R/3 target system | |
| UserID | BSTR | R/3 user account | |
| Password | BSTR | the password for the R/3 user specified by UserID | |
| Language | BSTR | R/3 system language | |
| Client | BSTR | R/3 client number | |
| context parameter | KeepSAPContext | BOOL | specifies if the R/3 connection should be
kept after each R/3 method call. The default value is TRUE. You have to set this property only if you don't need to keep the same R/3 connection for multiple R/3 method calls. In this case, the value FALSE should be set explicitly before any R/3 method call. This is useful only for multiple stateless method invocations of a single object. |
Standard Methods:
InitKeys( Key1 …, Key2…, … )
This method is used to initialize a local object with data of a persistent R/3 object. Using parameters Key1, Key2 … the relevant attributes of the proxy object are initialized. The typing of these parameters depends on the type of the relevant R/3 key field. However, this method call does not involve any existence check for the corresponding instance in the R/3 database. To do such a check, call instance-dependent BAPI methods such as CheckExistence or GetDetail for each instance.
DimAs( MethodName As String, ParameterName As String, pRS As VARIANT)
Use this method to create new record sets (structure and table objects) with the structure of the parameters to be specified. Only after this can you initialize them with data.
PutSessionInfo(Destination As String, UserID As String, Password As String, Language As String, Client As String)
Use this method to transfer logon parameters (destination, userID, password, language, client) in a single function call. PutSessionInfo thus provides a much better performance than any solution, in which each logon parameter is transferred separately.
GetConnectionAttribute([AttrName As String])
Use this method to query the individual attributes of an existing RFC connection. If
you do not specify a transfer parameter with <AttrName>, the method call
returns a recordset containing all attributes of the connection.
The table below contains a list of all attributes:
| AttrName | Description |
| PROCID | Process ID |
| HANDLE | RFC handle to identify the RFC connection |
| CALLS | Number of calls in the R/3 target system |
| STATE | Status of resource pooling |
| DESTINATION | Name of the RFC destination |
| SYSID | ID of the R/3 target system |
| PARTNER_HOST | Name of the R/3 application server |
| SYSTNR | System number of the R/3 target system |
| NT_USERID | Windows NT user |
| USER | User ID for the R/3 target system |
| OWN_CODEPAGE | Codepage number to integrate character sets in the client system |
| PARTNER_CODEPAGE | Codepage number in the R/3 target system |
| PARTNER_REL | System release number of the R/3 target system |
| OWN_REL | Release number of the RFC library in the client system |
| TRACE | Name of the trace file containing recordings of the RFC communication |
| CPIC_CONVID | Conversation ID of the CPI protocoll |
| LAST_FUNCTION | Name of the last called RFC function |
CommitWork( )
You can combine several writing BAPIs of different business objects into one LUW that
triggers an R/3 commit.
In R/3, this method calls the ABAP statement Commit
Work to write all changes within a session to the R/3 database.
In addition, CommitWork( ) implicitly calls SetComplete( ) to release the resources
in MTS.
AdviceRfcGuiSink(plRfcGuiSink As Object, AbapDebug As Integer, UseSapGui As Integer)
This method orders a "callback object" of the RfcGuiSink type to call the appropriate method for starting the SAP GUI. The RfcGuiSink object is implemented in the LIBRFC32.DLL. A value other than zero for AbapDebug allows the object to start the SAP GUI for the ABAP Debugger. Use a value other than zero for UseSapGui to order the RfcGuiSink object to start the SAPGUI whenever the program requires it.
Note:
For more information on establishing an own application in VB, see Tips and Notes for Programming.
How to Map Remote Functions onto COM Objects ?
There is no big difference between RFC proxies and proxies for business objects. Since function modules in the Function Library have no object instances, they are assigned by no key attributes. For the same reason, no InitKeys method is generated for the RFC proxies.
How to Map the Session Object ?Components of the Session Object
How to Use the Object Builder