This document describes how to develop an webMethods EntireX RPC client which can call an SAP R/3 ABAP business function. The following topics are covered here:
The following picture shows the technical communication (send/response) for an integration scenario involving a client call to SAP.
The communication runs as follows:
Your application creates an RPC call to webMethods EntireX Broker.
The SAP R/3 Gateway receives this call and transforms it to an RFC call to the SAP application server.
The ABAP (RFC enabled) function is called and then replies with an RFC to webMethods EntireX Broker.
The SAP R/3 Gateway receives the reply and transforms it to an RPC call to the calling program.
To develop this scenario
Define the ABAP function and create the IDL (Interface Definition Language).
Paste the new IDL into the existing IDL.
Compile and link the IDL to generate the executable kernels.
Download the IDL to the client environment.
Write the first client.
These steps are described in detail in the following sections.
First, you must define for your client application which ABAP function you want to call. You can do this and generate the IDL either by using the browser page in the SAP R/3 Gateway portal, or from the command line. This section describes both methods as well as some additional programming hints under the following headings:
The following sections describe the process of IDL generation. During this process, the RFC IDL tool is used. This tool acts as an EntireX RPC client and requires a running Rpc2Rfc kernel.
To generate IDL
As RPC client, the connection parameter to the Broker and service (CLASS/SERVER/SERVICE) must be set. To check or change the parameter, open the page from the menu. Refer also to the description of the System Constants Parameters.
If the webMethods EntireX Broker does
not reside on the localhost, you can change the RFC IDL Tool Host
Address.
Compile and Link existing delivered IDL for the Rpc2Rfc kernel.
Deploy new compiled shared libraries (on UNIX) or DLLs (on Windows).
The RPC Server must be running to use the RPF IDL tool. More information about starting this kernel process is provided in the section Running Task Rpc2Rfc (Client calls SAP) Kernel Environment.
You can use the page of the SAP R/3 Gateway portal to generate the IDL.
With List IDL, you can display the existing IDL at the end of a new browser page.
To generate IDL
Type your new ABAP function in the field Function name and choose .
This loads a new page with the IDL from the SAP Repository, as illustrated in the following figure:
Copy the generated contents to your clipboard and choose .
This starts a text editor at the end of the new page.
Paste the contents of the clipboard to the end of the existing IDL.
Define an 8-character-long function name between the
'' characters after the string
"Program". The long alias name is used by the ABAP
server. Later, in your COBOL or Natural business application, the ABAP function
is called using the short name you define here. With this step, you can reduce
a 32-character function name to 8 characters.
The following example shows a short name MATGETDT for the long ABAP BAPI function name BAPI_MATERIAL_GET_DETAIL.
On the page, type the additional parameters for the RFC IDL generation tool:
| Client | The 3-character client ID definition. |
| User ID | Please ask your SAP administrator for an RFC (Batch/CPIC) user definition. |
| Password | RFC password to go with the user ID. |
These parameters are passed to the running Rpc2Rfc kernel. Depending on the parameter Gateway Logon Strategy (EXX_GW_LOGON_PRIO), the Rpc2Rfc kernel will evaluate the logon.
Choose to save the above parameters and the ABAP function name. The saved parameters are now persistent, that is, when you load this page later, the same values will be displayed.
The IDL editor is accessible from the development page. First, all included functions are listed with their short and long name. To modify the IDL, use the available commands.
The In and Out column shows the size of the
transfer buffer for each request. This can help to optimize the communication
between client and server. The following table defines the parameter and the
available commands.
| Command | Description |
|---|---|
| Generate + Add | Generates the IDL of a given function in the field from the SAP repository and adds it at the end of the existing IDL file. |
| Save | Saves all parameters in the configuration of this development environment. |
| Delete | Deletes the selected function from the IDL and saves the new IDL file. The old IDL file is backed up in the history directory. |
| Compare | Compares the selected function in the IDL file
with the respository contents; differences between the two files will be
displayed on the next page. Connection parameters (Broker, service, user IDs
and passwords) are reused from the Generate IDL from Repository
dialog.
The comparison algorithm tries to find the locally defined groups
and fields in the repository. You will be notified only in cases where the
number of groups and/or fields differ. If there are more fields defined in a
local function than in the repository, a detailed description of the missing
fields will be displayed. The following picture shows the result of a
comparison between the delivered local
During a migration process this comparison report shows the differences between the SAP R/3 versions. |
| Replace | Replaces the selected function in the IDL by
the respository contents. Connection parameters (Broker, service, user IDs and
passwords) are reused from the Generate IDL from Repository
dialog.
|
| Parameter | Description |
|---|---|
| RPC Broker Service | EntireX Broker and service address of Rpc2Rfc server. |
| RPC User ID | EntireX user ID for logon with security. |
| RPC Password | EntireX password for logon with security. |
| RPC Function | Sets 8-character function name in IDL. This function name should not exist in IDL. |
| RFC Client | R/3 logon with 3-character client name. |
| RFC User ID | R/3 logon user ID. |
| RFC Password | R/3 logon password for user ID. |
| RFC Function | Retrieves the interface description from this R/3 function. |
| Number of Default Table Items | Sets the number for the array size of tables (multiple groups) in the IDL. |
It is possible to generate the IDL from the SAP Repository using the command line tool RfcIdl. It is the same tool used by the browser page.
The command line utility must have the mandatory parameters for calling:
webMethods EntireX Broker server address
ABAP function name
webMethods EntireX short function name
The utility writes the following output if called without parameters:
Usage parameter: -a<Broker ServerAddress> -e<Function short name> -f<SAP R/3 function name> -u<SAP R/3 user id> -p<SAP R/3 password> -c<SAP R/3 client> -o<ABAP function tablename>=<occurance> -x<ABAP function excluded tablename> -r<EntireX user id> -d<EntireX password> -t<Number of default table items>
The following example gets the IDL from the ABAP function BAPI_MATERIAL_GET_DETAIL:
rfcidl -alocalhost:1971@RPC/R3RFCD/CALLNAT -eMATGETDL -fBAPI_MATERIAL_GET_DETAIL
The IDL is then printed on the standard output:
Program 'MATGETDL' : 'BAPI_MATERIAL_GET_DETAIL' Is
Define Data Parameter
1 RFC_SYSTEM In Out
2 userid (A12)
2 passwd (A8)
2 client (A3)
2 ok (L)
2 message (A250)
2 operation (I2)
2 handle (I4)
2 transaction (A24)
1 MATERIAL In /* BAPIMATDET
2 Material (A18) /* Materialnummer
1 MATERIAL_GENERAL_DATA Out /* BAPIMATDOA
2 MatlDesc (A40) /* Materialkurztext
2 OldMatNo (A18) /* Alte Materialnummer
2 MatlType (A4) /* Materialart
2 IndSector (A1) /* Branche
Normally, each generated SAP R/3 ABAP business function is inserted in the IDL as one program. It is possible, however, to create more than one program in the IDL to call the same ABAP function.
For example:
Program 'FU_1'Is
Define Data Parameter
1 BAPI_MATERIAL_GETLIST (A1)
1 RFC_SYSTEM In Out
2 userid (A12)
...
End-Define
Program 'FU_2'Is
Define Data Parameter
1 BAPI_MATERIAL_GETLIST (A1)
1 RFC_SYSTEM In Out
2 userid (A12)
In this case, no alias is defined in the IDL. Instead, the gateway gets the ABAP function name from the first parameter. You can now write different parameter groups for programs FU_1 and FU_2.
Assume, by way of example, the ABAP function requires a string with a length of 1000 characters. Your client (Natural) cannot allocate a string of this length. The solution is to change the field to a multiple field.
For example:
...
1 MATERIAL_GENERAL_DATA Out
2 MatlDesc (A1000)
...
Change the field MatlDesc to a multiple field. The allocated memory must be the same.
...
1 MATERIAL_GENERAL_DATA Out
2 MatlDesc (A200/1:5)
...
The default IDL generation prints 10 occurrences for each table. The section Table Count, Offset and Fill Parameter describes how to handle more occurrences. You can, of course, define your own number of tables in the IDL.
ABAP and the webMethods EntireX IDL are restricted to 32-character field names. Each table parameter also requires 3 parameters (count, offset and fill) as postfix (see the section Table Count, Offset and Fill Parameter). If the table name has more than 25 characters, you will get an error from the IDL compiler during because the limit is reached.
Tip:
Cut the field names of table parameters, but not the table name
itself.
Generated example:
...
1 SALESORGANISATIONSELECTION_Count (I4) Out
1 SALESORGANISATIONSELECTION_Offset (I4) In
1 SALESORGANISATIONSELECTION_Fill (I4) In Out
1 SALESORGANISATIONSELECTION (/1:10) In Out /* BAPIMATRASO
...
After cutting the table parameters:
...
1 SALESORGANISATIONSEL_Count (I4) Out
1 SALESORGANISATIONSEL_Offset (I4) In
1 SALESORGANISATIONSEL_Fill (I4) In Out
1 SALESORGANISATIONSELECTION (/1:10) In Out /* BAPIMATRASO
...
Some field names are reserved for the Interface Definition Language for webMethods EntireX RPC. Therefore, these field names are replaced during . The following table shows the replacement.
| Original field name | Replace with |
|---|---|
| Program | Prog |
| Library | Libr |
| Parameter | Param |
| Structure | Structure1 |
| Version | Vers |
You can change the replacement with the "makefile" function on the page of the menu (http://YourGateway:8080/sapr3gateway/manager/devAdmin?cfg=1).
During each save step of the IDL file, it is copied to a separate subdirectory with a current time stamp. The page of the menu (http://YourGateway:8080/sapr3gateway/manager/devAdmin?cfg=1) contains the backup template with the specific sub-directory information.
Click the Compile and Link button on the Development page to start the makefile. The kernels for the executables are generated from the IDL. On the resulting page, you will see the job output of this process. Please check that the job output reports response code 0.
To activate the newly generated version for the runtime environment, you must deploy the executables (see the section Deploy Kernels) and restart the Running Task (see Running Task Rpc2Rfc (Client calls SAP) Kernel Environment).
You can download the client IDL using the button on the development page. This IDL file can be used in the webMethods EntireX Workbench to generate DCOM, Java or XML clients.
For each defined ABAP function, the compile and link process generates in Natural
a Parameter Data Area (PDA),
a subprogram for stub generation,
an example test program.
Everything is included in one SYSTRANS file, which you can download and import to your Natural Development Environment. On the first SYSTRANS upload call, you must stow the general Natural modules RFCSYSTM and RFCSYS-L.
Choose to save the generated SYSTRANS file to a local disk.
The RFCSYSTM LDA contains the technical field definition for each function. The Natural object RFCSYS-L contains constants for the technical field operation. See the section Write the First Client for more information.
Although it is possible to use the same fieldname on levels 1 and 2, for Natural the fieldnames within one PDA must be unique. You must therefore change the fieldnames on level 2.
Use the SYSTRANS Utility to import the file. The following is an example job for the mainframe environment:
//GKTTRANS JOB USER,CLASS=K,MSGCLASS=X,REGION=8M //* ------------------------------------------------------------------- //* SYSTRANS //* ------------------------------------------------------------------- //NATLOAD EXEC NATURAL //CMWKF01 DD DISP=SHR,DSN=MYHOME.R3RFC.TEXT //CMWKF04 DD DISP=SHR,DSN=MYHOME.R3RFC.LIST //CMSYNIN DD DISP=SHR,DSN=MYHOME.SAG.LOGIN(LOGINDEF) --> LOGON SYSUNLD // DD * TRANSCMD LOAD NAT-OBJECT LIBRARY R3RFC NAME * FIN /* //
By default, the SYSTRANS file is generated with the decimal character
period (.) for the numeric/packed data type. You can
change this by setting the parameter
DC
$(ERXIDL) -D OUT_DIR=$(PDA_DIR) -D "DC=," -t nat_trans.tpl
to the character in the makefile.
To change the parameter in the command line, go to , , and menu item. An editor shows the makefile.
You can also change the destination Natural library name:
ERX_LIB_FOR_SYSTRANS=$(ERX_LIB)
If your Natural client environment works
without stubs (or is stubless), the following parameter
STUBS=OFF suppresses the generation of subprograms, for
example:
$(ERXIDL) -D OUT_DIR=$(PDA_DIR) -D STUBS=OFF -t nat_trans.tpl
You can use either
or on the development page to look at a
Natural program for an example call to an APAB business function. If you have
to use stubs in Natural RPC, then you can use the subprograms to build a stub
with SYSRPC. In other cases, you will find the business interface
to the ABAP function in the PDAs.
When the SYSTRANS file is first downloaded and uploaded to your Natural development environment, the Natural Parameter Module must be adapted as an RPC Client. The tool for setting the parameter depends on the platform.
Caution:
Set the compression parameter to: COMPR=0. You will
receive runtime errors if you set it to COMPR=1. This also applies
when you use stubs.
The following example shows the Natural Configuration Utility with
parameters for a stubless RPC client. The autorpc parameter is
switched on.
On the mainframe, you can start the Natural nucleus online with the following parameters. In this example, Natural works without stubs.
RPC=(SIZE=64,MAXBUFF=32,COMPR=0,AUTO=ON,DFS=(R3RFCD,BKR034, ,ACI))
Choose on the Development page to browse the generated COBOL source. You can transport the source to your COBOL Development Environment using your file transfer utility (for example, FTP). It is possible to generate an FTP shell script (or batch on Windows) for uploading files.
Please read the Release Notes for more EntireX Communicator installation hints.
The COBOL Stubs should be generated during the job. This makes it possible to adapt the makefile to your parameters. To set the parameters in System Manager:
Go to the page of the menu or to http://YourGateway:8080/sapr3gateway/manager/devAdmin.
Select the link to the
Select the link to the . You will get an editor with the makefile.
Uncomment the ('#' lines) statements for calling ERXIDL
and set the parameter COB_PARMS. (The back slash character must be
the last character of any line that continues onto the next line.) For more
information about the parameter, please read the
EntireX Communicator
Documentation.
# Define IDL Cobol Template Parameter
# -D TARGET=BATCH [ BATCH, CICS ]
# -D SERVER=SRV1
# -D BROKER=ETB001
# -D SECURITY=NONE
# -D COMM=EXTERNAL [ NONE, EXTERNAL, LINKAGE ]
# -D QUOTE=0
COB_PARMS= -D TARGET=BATCH \
-D SERVER=SRV1 \
-D BROKER=ETB001 \
-D SECURITY=NONE \
-D COMM=EXTERNAL \
-D QUOTE=0
COBOL: $(IDL_FILE_TMP)
# echo Create Cobol Stubs...
# $(ERXIDL) $(COB_PARMS) -o $(COB_DIR) -t $(EXXTPL)/cobolclient1.tpl $(IDL_DIR)/$(ERX_LIB)_WithoutAlias.idl
# $(ERXIDL) $(COB_PARMS) -o $(COB_DIR) -t $(EXXTPL)/cobolclient2.tpl $(IDL_DIR)/$(ERX_LIB)_WithoutAlias.idl
# echo Create Cobol Programs ...
# $(ERXIDL) $(COB_PARMS) -o $(COB_DIR) -t cob_prog.tpl $(IDL_DIR)/$(ERX_LIB)_WithoutAlias.idl
# echo Create Upload FTP Script ...
# $(ERXIDL) -D SHELL=SH_or_BAT -D LOCAL_DIR=$(COB_DIR) -D REMOTE_ROOT_DIR=.. -t cob_ftp.tpl $(IDL_DIR)/$(ERX_LIB)_WithoutAlias.idl
# echo Execute FTP Script ...
# chmod +x ftp${ERX_LIB}.sh
# ./ftp${ERX_LIB}.sh host userid password destinationDirectory
Save the file.
Restart the job.
View the results with the function Browse COBOL Stubs. All COBOL
Stubs start with the character C. The example programs have the
prefix P. A program calls its stub with the current parameter data
area.
Tip:
The working storage section of a generated program source can be
used in your business program.
More information about the generated source code is on IDL COBOL Mapping.
Copy the COBOL source with FTP to the mainframe development
environment. A shell script is generated with the template
cob_ftp.tpl. See the example above to call this shell script with
the correct FTP parameter. The following listing shows the generated shell
script:
#!/bin/sh if [ $# -lt 3 ]; then echo usage: $0 host userid password [ destinationDirectory ] exit 1 fi host=$1 userid=$2 passwd=$3 dir=$4 echo open $host > ftp.txt echo user $userid $passwd >>ftp.txt echo lcd cob >>ftp.txt if [ $dir ]; then echo cd $dir >>ftp.txt fi echo put ERXCOMM.cob ERXCOMM >>ftp.txt echo put RPCSRVI.cob RPCSRVI >>ftp.txt echo put CR3SYSINF.cob R3SYSINF >>ftp.txt echo put PR3SYSINF.cob PR3SYSIN >>ftp.txt echo dir >>ftp.txt ftp -n -i < ftp.txt
This UNIX shell script copies all of the necessary COBOL sources to the FTP destination and renames them for a correct calling conversation.
Restart the job to check the FTP command and the transport of the COBOL source to your target development environment.
The transported COBOL source must compile in your development environment. The following picture illustrates the necessary COBOL modules and the calling hierarchy with the R3SYSINF function example.
Tip:
Compile and link the COBOL modules with the dynamic linker option.
In this case, the module RPCSRVI must compile only once
and the same instance must be available to others.
Start the main module (PR3SYSIN) in your target environment. The main module has generated code for
setting the IN parameter and
displaying the OUT parameter.
Tip:
Copy the generated code of working storage section, the (in- and
out-) parameter and the call statement to your business program.
Each calling function has a technical parameter
RFC_SYSTEM which contains the following fields.
1 RFC_SYSTEM In Out
2 userid (A12) /* In
2 passwd (A8) /* In
2 client (A3) /* In
2 ok (L) /* Out
2 message (A250) /* Out
2 operation (I2) /* In
2 handle (I4) /* In Out
2 transaction (A24) /* Out
The first 3 fields (userid, passwd and client) are used to identify the client in the SAP R/3 application server.
The field ok returns true or false if the call was successful. If false and an exception is thrown, the message field will contain the error text.
The operation field contains a flag indicating what the kernel process will do in the next call. The operation values can be added to perform multiple steps in a single call. If the connection to SAP is not closed, the handle field will return the RFC handle ID. You must use this handle ID in the next call to work with the remembered context on the R/3 application server side. For example, if you perform a query, the query context (result set) is remembered on the handle ID. This ID is necessary to navigate in the results.
The transaction field returns the ID for asynchronous RFC.
The operation field can contain the following values:
| Operation | Value | Description |
|---|---|---|
| OPEN | 1 | Opens the communication to the R/3 application server and returns an RFC handle. |
| CREATE_TABLES | 2 | Creates the RFC tables to receive the contents. |
| WRITE_TABLES | 4 | Puts the contents of (RPC) data into the RFC table. |
| CALL | 8 | Calls the RFC function. |
| READ_TABLES | 16 | Gets the RFC table data and puts it into the RPC buffer. |
| FREE_TABLES | 32 | Frees the memory of RFC table data. |
| CLOSE | 64 | Closes the RFC handle communication. |
| DELETE_TABLES | 128 | Frees memory of RFC table data and deletes the table handle. |
| CALL_TRANSACTION | 256 | Calls the RFC function with transaction mode. |
The following table shows predefined field constancy depending on programming language.
| Natural defined in RFCSYS-L | COBOL defined in working-storage section |
|---|---|
| OP_OPEN | OP-OPEN |
| OP_CREATE_TABLES | OP-CREATE-TABLES |
| OP_WRITE_TABLES | OP-WRITE-TABLES |
| OP_CALL | OP-CALL |
| OP_READ_TABLES | OP-READ-TABLES |
| OP_FREE_TABLES | OP-FREE-TABLES |
| OP_CLOSE | OP-CLOSE |
| OP_DELETE_TABLES | OP-DELETE-TABLES |
| OP_CALL_TRANSACTION | OP-CALL-TRANSACTION |
The operation field for a simple call to an RFC function must be set to OPEN+CALL+CLOSE.
The communication client can send large amounts of data. The first call OPENs the communication and CREATEs tables. It is possible in the first call and in subsequent calls (WRITE_TABLES) to fill the table with data. When the table has been filled, the RFC function must be called with operation CALL.
After calling (CALL) the RFC function, the client can receive the table data and any subsequent calls with the operation READ_TABLES. The communication can be closed and the memory can be freed up with the operation DELETE_TABLES plus CLOSE.
From the OPEN call until the CLOSE, the handle field must contain the same value. This value must not be changed by the client program.
If a client program closes the handle, the RFC handle will not be closed by the kernel process. It will be closed later if this handle cannot be reused within a specified amount of time (timeout). The same feature is used if the client neglects to close the handle or if the client abends.
Every table has the parameters count,
offset and fill. Each parameter
has the table name as prefix.
| Parameter | Direction | Description |
|---|---|---|
| Count | Out | Returns the whole number of records in the RFC. table |
| Offset | In | Offset (index) pointer to the working record in the RFC table. |
| Fill | In Out | Number of filled records in the RPC multiple
group. Set -1 to use the maximum defined in IDL.
|
The client program that reads or writes a table must set the offset to the beginning of the record index using the offset parameter. In subsequent calls, the offset parameter must be incremented with the number of filled records.
The fill parameter is set by the client that transports multiple records from the RPC to the RFC on the operation code WRITE_TABLES. This parameter also returns the real number of transported records on the operation code READ_TABLES.
This section explains the usage of table parameters and operation codes in abstract examples.
Note:
You must initialize the input parameter OFFSET to 0 if
your client programming language does not automatically support this feature.
The initialized value 0 is the same as
1.
It is possible to perform all communication steps in one call. After this call it is not possible to retrieve more information, for example about the result list.
/* Set sending table records
MY_INPUT_TABLE_FILL := 1 /* Send one record
MY_INPUT_TABLE[ 1 ].myField := 'Hello' /* Set value
/* Initialize receiving table
MY_OUTPUT_TABLE_OFFSET := 1 /* Read the first record
MY_OUTPUT_TABLE_FILL := 10 /* Reply 10 records as result, if possible
/* Set operation code and call SAP function
RFC_SYSTEM.operation := OP_OPEN + OP_CREATE_TABLES +
OP_WRITE_TABLES + OP_READ_TABLES +
OP_CALL + OP_CLOSE
callSAP ( RFC_SYSTEM, ... )
if RFC_SYSTEM.ok then
/* SAP has answered successfully
write 'SAP have found number of records: ' MY_OUTPUT_TABLE_COUNT
for 1 to MY_OUTPUT_TABLE_FILL
/* Print all received records
endfor
else
/* Do error handling
endif
This scenario sends data in multiple calls.
/* Initialize receiving table
MY_OUTPUT_TABLE_OFFSET := 1 /* Read the first record
MY_OUTPUT_TABLE_FILL := 10 /* Reply 10 records as result, if possible
/* Set operation code and call SAP function
RFC_SYSTEM.operation := OP_OPEN + OP_CREATE_TABLES + OP_CALL +
OP_READ_TABLES
callSAP ( RFC_SYSTEM, ... )
/* Remember the context in RFC_SYSTEM.handle for all subsequent calls
if RFC_SYSTEM.ok then
/* SAP has answered successfully
write 'SAP has found number of records: ' MY_OUTPUT_TABLE_COUNT
while RFC_SYSTEM.ok and MY_OUTPUT_TABLE_FILL > 0
/* Prepare call to get next package
MY_OUTPUT_TABLE_FILL := 10 /* Reply 10 records as result, if possible
RFC_SYSTEM.operation := OP_READ_TABLES
callSAP ( RFC_SYSTEM, ... )
for 1 to MY_OUTPUT_TABLE_FILL
/* Print all received records
endfor
/* Evaluate next OFFSET
MY_OUTPUT_TABLE_OFFSET := MY_OUTPUT_TABLE_OFFSET + MY_OUTPUT_TABLE_FILL
endwhile
/* Close communication
RFC_SYSTEM.operation := OP_CLOSE
callSAP ( RFC_SYSTEM, ... )
else
/* Do error handling
endif
If you have a large result list then you must perform multiple calls.
/* Set operation code for opening communication RFC_SYSTEM.operation := OP_OPEN + OP_CREATE_TABLES callSAP ( RFC_SYSTEM, ... ) if not RFC_SYSTEM.ok then /* Do error handling and abort endif /* Remember the context in RFC_SYSTEM.handle for all subsequent calls while not All_Data_Transfered_Flag /* Send 2 records per call MY_INPUT_TABLE_FILL := 2 /* Send 2 records MY_INPUT_TABLE[ 1 ].myField := 'Hello' /* Set value MY_INPUT_TABLE[ 2 ].myField := 'World' /* Set value /* Set operation code for sending data RFC_SYSTEM.operation := OP_WRITE_TABLES callSAP ( RFC_SYSTEM, ... ) endwhile /* Set operation code for calling SAP function and closing communication RFC_SYSTEM.operation := OP_CALL + OP_CLOSE callSAP ( RFC_SYSTEM, ... ) if not RFC_SYSTEM.ok then /* Do error handling endif
If the server functions require transaction handling, the client
should call BAPI_TRANSACTION_COMMIT or
BAPI_TRANSACTION_ROLLBACK. Both functions must be added to the
IDL.
/* Set sending table records
MY_INPUT_TABLE_FILL := 1 /* Send one record
MY_INPUT_TABLE[ 1 ].myField := 'Hello' /* Set value
/* Set operation code and call SAP function
RFC_SYSTEM.operation := OP_OPEN + OP_CREATE_TABLES +
OP_WRITE_TABLES + OP_CALL
callSAP ( RFC_SYSTEM, ... )
/* Remember the context in RFC_SYSTEM.handle for all subsequent calls
if RFC_SYSTEM.ok then
/* SAP has answered successfully
/* Delete the tables in this memory context
RFC_SYSTEM.operation := OP_DELETE_TABLES
callSAP ( RFC_SYSTEM, ... )
/* Commit transaction on server side
/* Pass remembered RFC_SYSTEM.handle
RFC_SYSTEM.operation := OP_CALL
callSAP_COMMIT ( RFC_SYSTEM, ... )
/* Close RFC communication
RFC_SYSTEM.operation := OP_CLOSE
callSAP_COMMIT ( RFC_SYSTEM, ... )
else
/* Do error handling
endif
Some keys are defined as numeric fields in SAP's database. But the
BAPI interface defines this field as alphanumeric. In this case, the field must
be set with leading 0 and alphanumeric.
MATERIAL.MATERIAL_ID = '0000000001234567890'
Some parameters are optional and have SAP's date type. Initialize a
date field optionally with the value '00000000'
VALIDATE.START_DATE = '00000000'
SAP R/3 Gateway supports the generation process for creating an XML RPC client. Your client must send an XML document to the EntireX XML RPC adapter servlet via HTTP. The EntireX XML RPC adapter servlet can run inside the IDoc XML Gateway. A new template (since version 2.3.1.06) generates
an XML document or
XSL stylesheets
for the RPC protocol.
To configure the development
Go to the administrator developer page , and .
To browse the generated files, to the developer page. Set the following values:
| Description | Browse XML RPC Documents |
| URL | ../Rpc2Rfc/dev/xml_rpc |
Click the link to open the makefile in an editor. For Windows, add the following line (to the includes section):
include xml_rpc_win.mak
For UNIX, add the following line:
include xml_rpc_unx.mak
Save the changes.
To call the included makefile step, add the target
XML_RPC to the all target line. For Windows, call the
link in the editor:
all: $(IDL_FILE_TMP) PDA $(D_ERX_LIB) $(ERX_LIB) COBOL XML_RPC
For UNIX, call the editor with and add the target:
all: $(IDL_FILE_TMP) PDA $(D_ERX_LIB) $(ERX_LIB) COBOL XML_RPC
Save the changes.
For Windows enter the value xml_rpc_win.mak in the line
XML RPC Makefile. For UNIX target operating systems enter
xml_rpc_unx.mak. Save the changes.
How to configure the generation process
As default, the following 2 lines in the xml_rpc_xxx.mak file generate the XML and XSL files in the sub-directory xml_rpc.
$(ERXIDL) -o xml_rpc -D STYLE=XML -t xml_rpc.tpl $(IDL_DIR)/$(ERX_LIB).idl $(ERXIDL) -o xml_rpc -D STYLE=XSL -t xml_rpc.tpl $(IDL_DIR)/$(ERX_LIB).idl
After XML and XSL files have been generated, the EntireX Workbench will be called in batch mode to generate the XMM mapping file. The resulting file has the name R3RPC.xmm.
Include the generated mapping file in the configuration of the
EntireX XML RPC adapter servlet. To do this, copy the mapping file to the
directory sapr3idocxmlgateway/config and rename it (with
prefix D) because this file already exists.
Change the EntireX XML RPC adapter servlet configuration (for
Windows or
UNIX)
sapr3idocxmlgateway/config/AdapterConfig.xml to include the
new mapping file with the prefix D:
...
<exx-xmm>/config/DR3RFC.xmm</exx-xmm>
...
For the changes to the EntireX XML RPC adapter servlet configuration or the mapping file to take effect, the servlet must be restarted. For example with the Tomcat web application server, use the Tomcat Manager.