Data Interfaces

© SAP AG
Data Interfaces
Application Development in the
ABAP/4 Development Workbench
Week 4
R

Contents I / Week 4
Chapter 1 Principles
Chapter 2 Linking Options
Chapter 3 Remote Function Call
© SAP AG
Exercises
Solutions
Chapter 4 ABAP/4 Desktop Integration
Components
Chapter 5 CPI-C Interface

Chapter 1 Basic Techniques
© SAP AG
l Overview of linking options
l Overview of Basis interfaces
l Overview of basic components

Chapter 1 Objectives
© SAP AG
l Main terms and components for communications
interfaces.
l Basic techniques of direct, cross-system
communication:
CPI-C, RFC and OLE (programming interfaces) and
the relevant system components (SAP gateway, side
information tables, transport logs)

Linking Options Overview
© SAP AG
R/3
R/3 R/2
External
system
Communication is possible between different R/3 systems, between R/3 and R/2, between R/3 and
external systems, and also between R/2 and external systems.

Basis Interfaces of the R/3 System
Database
server
Application
server 1
Frontend
(SAPGUI)
© SAP AG
R/3 System
...
Application
server 2
...
Frontend
(SAPGUI)
Database operations (SQL)
ABAP/4 Open SQL, ABAP/4 Native SQL
Batch input
CALL TRANSACTION ... USING
CPI-C
RFC
Seq. files (application server files)
Seq. files (frontend files)
OLE
RFC
At different levels in the R/3 System, there are various data communication options. These include the
following:
1) Communication with the database via ABAP/4 Open SQL or DB SQL.
2) Indirect data communication using file transfer.
3) Techniques of direct, cross-system communication in the network.
This course covers the Basis techniques for direct communication (time-critical data).
Although ABAP/4 supports the use of Native SQL, any direct database accesses to SAP tables should
be read-only. Table updates usually cause problems for data consistency because of the complexity of
table dependencies. For this reason, changes should be made using the relevant SAP transaction
programs with batch input or the ABAP/4 statement CALL TRANSACTION ... USING.
At application level, the following Basis techniques are available:
- Access to sequential files of the application server and the frontend
- CPI-C ---> program-to-program communication
- RFC ---> Remote Function Call
At frontend level, the following Basis techniques are available:
- Access to sequential files
- RFC
- OLE (Object Linking and Embedding

Indirect Communication I
© SAP AG
Data transfer using files
w READ DATASET INTO
w TRANSFER TO
w Function module: WS_UPLOAD
w Function module: WS_DOWNLOAD
seq. file
SAP R/3 naturally supports the file transfer technique on the application server and on frontends.
In ABAP/4, you implement the interface to the file system on the application server with the key words
READ DATASET and TRANSFER TO.
On frontends, you implement the interface to the file system with the following function modules:
WS_UPLOAD: Reads a file in the file system where the SAPGUI is running into an internal table
in the
R/3 System.
WS_DOWNLOAD: Stores the contents of an internal table as a file on the SAPGUI machine.

Indirect Communication II
seq. file
© SAP AG
Batch input
Read
sequential file
Batch input
preparation
Import data
Batch input is based on file transfer with additional update.
R/3 System
SD
FI
MM
PP
R/3
CO
AM AM
Client / Server
QM
ABAP/4
PS
PM
WF
HR
IS
With this process, you should note that only one system must be active at any one time. You can transfer
the files to the other system and read in the data at a later stage. Time-critical data should not be
involved here.

Transferring Time-critical Data
© SAP AG
Example: Local warehouse
Warehouse A
4 434518 759691
Warehouse B
4 434518 759691
SD
FI
MM
PP
R/3
CO
AM
Client / / Server
QM
ABAP/4 PS
PM
WF
HR
IS
Time-critical applications such as entering warehouse movements , goods receipt, or goods issue,
require direct communication between the local warehouse computer and the central system.

Direct Communication I
Program-to-program communication (CPI-C)
Phase Local warehouse Central
computer system
II
II
III
© SAP AG
Set up
connection
Data
transfer
Close
connection
"Goods xyz received"
ok
Connection setup
accepted
Data received
and updated
Connection closure
accepted
As the name (COMMON PROGRAMMING INTERFACE FOR COMMUNICATIONS) implies, CPI-
C is a general programming interface for communication purposes.
CPI-C allows two applications or two programs to communicate with each other in much the same way
as two people communicate in an ordinary telephone conversation. One program sets up the connection,
while the partner program accepts the connection. Then, application data can be exchanged until the
communication link is closed by one of the partners. You can use this method to make time-critical data
immediately available in the partner system.
The concept behind the CPI-C interface was originally developed by IBM within the framework of SAA
(System Application Architecture). Other SAA interfaces include CUA (Common User Access) and
CCS (Common Communication Support). CPI-C was later taken over by the X/OPEN group.
SAP has implemented the CPI-C interface. The CPI-C starter set is also supported.

Direct Communication II
Remote call to a routine (RFC)
© SAP AG
Local warehouse Central
computer system
Call function
ABC in
system XYZ
with the
parameters
1,2,3.
Call
Result
System XYZ
Function ABC
Process
parameter values
1, 2, 3 and
return result
The remote call to a function module (routine) in a partner system represents a further level of
complexity in the data exchange process.
RFC is related to RPC (Remote-Procedure-Call) in a UNIX-TCP/IP environment.
RFC is based on CPI-C.
SAP has implemented the RFC interface.
For application programmers, this remote call process is much easier to handle than program-toprogram
communication because data is exchanged only via defined parameters.

Direct Communication Techniques - OLE
© SAP AG
OLE OLE
Remote Function
Calls Calls
CPI-C
In a desktop environment, SAP components include a layered architecture for integration with R/3.
Apart from the RFC SDK (Software Development Kit) for desktops, SAP also supplies special OLE
products for use with Windows platforms.
OLE (Object Linking and Embedding) is a Microsoft Corporation standard. OLE 2.0 has also been
adopted by other manufacturers in their desktop applications.
OLE is an object layer which is located above the RFC interface in desktop environments. OLE 2.0compatible
applications can communicate with R/3 3.0 via this interface. SAP’s implementation of the
OLE layer is based on RFC API commands.

Network: TCP/IP and SNA LU6.2
TCP/IP
- R/2
- External systems
SNI (BS2000)
Windows NT
UNIX UNIX
© SAP AG
R/3
TCP/IP
TCP/IP
R/3
Communication is possible between SAP applications and with external systems.
SNA LU6.2
- R/2
- External systems
IBM IBM
Host systems
Data exchange is based on different transport protocols which are specific to a particular platform or
manufacturer.
Communication with an R/3 System is always via the TCP/IP protocol.
IBM platforms communicate via the SNA protocol LU6.2.
All other platforms support TCP/IP.

ISO-OSI 7-Layer Model
© SAP AG
SDLC
LU6.2
(APPC)
Ethernet
Token Ring
RFC
CPI-C
X.25
X.25
Ethernet
TCP/IP
(sockets)
In very simple terms, the ISO-OSI 7-layer model can be split into three sections:
A: At the lowest level (layer 1) are the different networks such as Ethernet, Token-Ring, X.25 etc. There
is a backup layer (2) between the network layer and the routing layer (3).
B: In the middle level (layers 3 and 4) are the transport protocols, including the well-known protocol
TCP/IP. Strictly speaking, TCP should be assigned layer 4 and IP to layer 3.
Since the SNA-LU6.2 protocol is normally based on IBM’s own SNA architecture model, it is shown in
the ISO-OSI 7-layer model on layers 3 to 6. Nevertheless, it should still be considered as a transport
protocol.
C: The session, presentation and application layers (5, 6, 7) form the upper third of the model. End-users
can only access the application layer. The programming interface CPI-C is also included at this last
level.
RFC is to be found at a higher level still. It is thus based on CPI-C.
Token Ring
...
7
6
5
4
3
2
1

SAP Gateway (CPI-C Handler)
SD
MM
PP
QM
PM
R/3
R/3
Client / / Server
ABAP/4
HR
FI
CO
AM
PS
WF
IS
© SAP AG
External
program
SAP
gateway
The SAP gateway is used for every CPI-C or RFC communication.
MM
PP PP
QM
PM
R/3
SD
R/3
Client / / Server
ABAP/4
HR
FI
CO
AM
PS
WF
IS
IBM/SNI host
The SAP gateway consists of several programs. At runtime, these can be identified as the "gw*"
processes.
If you wish, the CPI-C handler can perform a protocol conversion. You need this if, for example, you
want to set up a connection to an IBM host system.
Every application server has a gateway.
It is also possible to install an SAP gateway as a standalone instance.
The SAP gateway is ported for SNI BS2000.
R/2

Side Information Tables
Contents:
R/3
R/2
© SAP AG
Symbolic destination ---> addressed in the program
Partner LU ---> target machine or Logical Unit (SNA)
Partner program ---> name of partner program
...
Side information tables
UNIX
WINDOWS NT
WINDOWS 3.1
WINDOWS 95
OS/2
TXCOM --> CPI-C connection setup
RFCDES --> RFC connection setup
XCOM --> CPI-C, RFC connection setup
RFCD --> RFC connection setup
side info
side info
side info For SAP gateways and libraries
side info on external platforms
side info
Each system from which you set up a CPI-C communication requires a side information table. Side
information tables can be compared to telephone directories.
The terms LU (logical unit) and TP (transaction program) come from the SNA environment. In a
TCP/IP environment, different terms are used.
Side information tables contain parameters which are needed for communication purposes. The three
most important of these are:
Symbolic destination:
The program setting up a connection uses a symbolic destination which must exist in the side
information table. A symbolic destination can be compared with a name in a telephone directory.
Partner LU:
The partner LU (logical unit) specifies where the communication partner is to be found. It can be
compared with an address in a telephone directory.
Partner program:
The partner program is the program which is started in the partner system or the program to which the
connection is made. It can be compared with the telephone number of the partner.

Chapter 1 Summary
© SAP AG
l The R/3 System supports various techniques for direct
online communication between programs in different
systems and on different machines in a network.
l Connections can be set up both from and to R/3.

Chapter 2 Linking Options
© SAP AG
l Communication between R/3 Systems
l Communication between R/3 and R/2 Systems
l Communication between R/3 and external systems

Chapter 2 Objectives
© SAP AG
l The different linking options between R/3, R/2 and
external systems.
l Terms such as SAP gateway, side info tables, and
RFC tables, as well as the underlying concepts.

Communication Between SAP Systems
R/3
R/2
© SAP AG
IBM
The subsequent sections cover the following scenarios for communication between SAP systems:
R/3 - R/3 (the R/3 Systems can be different releases)
R/3 - R/2 (R/2 can be running on an IBM or an SNI platform)
R/2
R/3
The question of which system sets up the connection will also be discussed in more detail.
SNI

Communication: R/3 External Programs
© SAP AG
R/3
There are several options for communication between R/3 and external systems, but you have to know
whether an external platform is supported by SAP or not. To find out which platforms can be linked to
R/3, refer to SAP Supported Network Products.
If a platform cannot be linked to R/3 through CPI-C / RFC, this does not mean that no online
communication is possible. The options for these platforms are described in the subsequent sections.
The question of which system sets up the connection will also be discussed in more detail.

Technical Representation of the SAP Gateway
Functionality of the SAP gateway
R/3
dispatcher
R/2 (SNI)
© SAP AG
X1SA
TCP/IP
gwrd
gwrd
gwhost
gwwp
LU6.2
X1SA
gwrd
R/2 (IBM)
R/3
dispatcher
The SAP gateway or the CPI-C Handler is involved in every communication with an R/3 System.
The SAP gateway is supplied with every R/3 System.
The SAP gateway is a program pool in the R/3 System’s executable directory. All gateway programs
begin with "gw".
The SAP gateway consists of the following programs:
gwhost
gwims
gwmon
gwrd
gwwp
At runtime, you can identify gateway processes with the UNIX command "ps -ef | grep gw".
The SAP gateway is responsible both for TCP/IP and LU6.2 connections.

SAP Side Information Tables (CPI-C)
R/2: XCOM
R/3: TXCOM
UNIX
NT
Windows
OS/2
© SAP AG
XCOM
DEST DEST LU LU TP TP ...
...
TGB TGB LU1 LU1 CP1C2
CP1C2
TXCOM
DEST LU TP Prot ...
ABC LU2 CPIC2 E
sideinfo
DEST DEST = = GWHOST GWHOST
GWHOST GWHOST = = is0001
is0001
GWSERV GWSERV = = sapgw00 sapgw00
LU LU = = hw5001
hw5001
TP TP = = sapgw00 sapgw00
PROTOCOL PROTOCOL = = I
I
The side information table is a configuration table where you define the parameters that are necessary for
a communication.
The table has a different name in different systems.
In R/2, it is known as XCOM and can be maintained with Transaction TM31.
In R/3, it is known as TXCOM and can be maintained with Transaction SM54 or SM31.
In external systems, the side information table is always called sideinfo. In UNIX, for example, you can
edit side information with the editor program "vi". The side information table is used for CPI-C and RFC
connections in external systems.

The RFC Tables RFCDES (R/3) and RFCD (R/2)
Table RFCDES (R/3)
RFC destination: BC415
Connection type: 3
Target machine: hs5001 System number: 00
Description: Demo RFC connection
Language: D User: Miller
Client: 000 Password: Demo
Table RFCD (R/2)
DEST DEST MAN MAN User User name name Password Password S S Argument of table XCOM
BC415 000 Miller Demo D TGB
© SAP AG
To implement a communication with a Remote Function Call (RFC), you must make control entries in
the relevant tables.
For an RFC connection initiated from R/3, you need to make an entry in the table RFCDES.
For an RFC connection initiated from R/2, you need to make an entry in the table RFCD. This entry
points to the table XCOM.

Communication Between Two R/3 Systems
© SAP AG
hs5001, sapgw00 hs5101, sapgw01
System T01
Table TXCOM (T01)
TCP/IP
Dest LU TP Prot Gateway host Gateway service
BC415A hs5101 sapgw01 I
BC415B hs5101 sapgw01 I hs5101 sapgw01
System T02
Communication between two R/3 Systems is always based on the transport protocol TCP/IP.
For R/3 - R/3 communication, you need to maintain the R/3 tables TXCOM (for CPI-C) and RFCDES
(for RFC).
The destination Dest can be any name you choose.
LU (logical unit - related to IBM's SNA) is the "host name" of the R/3 partner system.
TP (transaction program name) is the sapgwXX of the partner system. Since a gateway service is assigned
to every application server, this name is unique.
For Prot (protocol), you enter an “I” for R/3 - R/3 communication.
The Gateway host entry is optional and specifies the host name of an alternative gateway. By default, the
system uses the gateway of the application server from which the communication is set up.
The Gateway service entry only makes sense if there is also an entry for Gateway host. It specifies the
service sapgwXX of the alternative gateway.
For an R/3 - R/3 RFC connection, you must make an entry in the table RFCDES. To maintain this table,
you use Transaction SM59. The connection type that you specify in the transaction is 3.

Communication Between R/3 and R/2
R/2
IBM
© SAP AG
IMS
CICS
R/3
R/2
SNI
DCAM
UTM
Since R/3 - R/2 communication involves a number of different scenarios, you have to decide the
following:
- Is R/2 running on IBM or SNI?
- Which transaction monitor is running on the host?
For IBM: CICS or IMS?
For SNI: DCAM or UTM?
- Which program is setting up the connection? The R/2 program or the R/3 program?
These different scenarios are covered on subsequent pages.

R/3 R/2 Communication (IBM)
© SAP AG
Connection setup from R/3
hs5001 hs5002
UNIX, UNIX, NT NT (T01) (T01)
SAP SAP gateway
gateway
Host Host (K50)
(K50)
R/3 R/3
ABAP/4
ABAP/4
SNA SNA subsystem
subsystem
R/2 R/2
ABAP/4
ABAP/4
TCP/IP (remote)
shared memory (local)
Table RFCDES (T01) Gateway options
RFC destination K50 Gateway host: hs5002
Connection type 2 Gateway service: sapgw00
Dest LU TP Prot Gateway host Gateway service
K50 C hs5002 sapgw00
LU6.2
Table TXCOM (T01) Side info SAPgateway
DEST = K50
LU = K50T00
TP = X1SA
For communication from R/3 to R/2, an SNA gateway must be active (i.e. an SAP gateway plus the
relevant SNA subsystem). Ideally, this should be installed as a standalone gateway.
For the SNA-LU6.2 connection, the specific SNA product (SNA subsystem) of the hardware
manufacturer must be installed and configured on the gateway machine.
You can find out which products are supported on which platforms, and in which version, in the overview
SAP Supported Network Products.
In the case of a CPI-C communication between R/3 and R/2 where the R/3 System is the initiator of the
communication, you need to make an entry in der R/3 table TXCOM and an entry in the gateway table
sideinfo.
Table TXCOM:
- The destination Dest can be any name you choose
- LU and TP are dummy entries and can be left blank
- Prot (protocol) must be C
In the case of an RFC communication between R/3 and R/2 where the R/3 System is the initiator of the
communication, you need to make an entry in the R/3 table RFCDES and an entry in the gateway table
sideinfo.

R/2 R/3 Communication (IBM)
Connection setup from R/2
Host Host (K50)
(K50)
R/2
R/2
ABAP/4 ABAP/4
Dest LU TP
T01 MP30 T01
(hs5000)
© SAP AG
LU6.2
hs5000
SNA SNA subsystem
subsystem
Progr: Progr: gwhost
gwhost
SAP SAP gateway
gateway
TCP/IP (remote)
shared memory (local)
Table XCOM (K50) Side info from gwhost
DEST = T01
LU = hs5001
TP = sapgw00
GWHOST = hs5001
GWSERV = sapgw00
Protocol = I
hs5001, sapgw00
UNIX, UNIX, NT NT (T01)
(T01)
SAP SAP gateway
gateway
R/3
R/3
ABAP/4
ABAP/4
The switching program gwhost is started on the machine where the SNA software is installed. gwhost
then looks for an entry in the side information table where the destination matches the TP specification in
the R/2 table XCOM (the program started by the SNA subsystem does not have to be called gwhost - it
can be copied beforehand or a symbolic link can be set up, e.g. ln -s gwhost T01). If you want to set up a
connection from R/2 to several R/3 Systems, each R/3 System must be defined at the SNA services level
on the one hand, and have its own intermediate program (e.g. T01, T02, ... ) on the other. There must of
course also be an entry in the side information table for each R/3 System. The symbolic destination is
identical with the name of the intermediate program (DEST=T02). To reach different destinations, e.g.
different R/3 Systems, this means that the intermediate program must be declared to the SNA subsystem
under different names.
You should ensure that the side information file can be found and read by the switching program. To do
this, you need to know the identity of the user who started the program. Of course, the authorizations of
the side information file must be set so that the user can read them.
The switching program is required for CPI-C and RFC connections.
For an RFC connection, you need to make the appropriate entry in the table RFCD.

R/3 R/2 Communication (SNI)
© SAP AG
Connection setup from R/3
UNIX, UNIX, NT NT (T01) (T01)
BS2000 BS2000 (K50)
(K50)
R/3
R/3
ABAP/4 ABAP/4
TCP/IP
Table RFCDES Gateway options
SAP SAP gateway
gateway
R/2 R/2
ABAP/4
ABAP/4
RFC destination K50 Gateway host: BS2GW
Connection type 2 Gateway service: sapgw00
Table TXCOM (T01)
Dest LU TP PROT Gateway host Gateway service
BS2000 C BS2GW sapgw00
On the external machine (BS2000), there must be an SAP gateway active (the connection must be set up
from the gateway of the BS2000 host).
On BS2000 machines, the SAP gateway can be accessed via TCP/IP. However, the following
requirements must be satisfied:
BS2000 version 11, DCAM version 11 (BCAM V.11 with TCP/IP)
On BS2000 machines, the SAP gateway can communicate with an UTM application or a DCAM
application.
Table TXCOM of the R/3 System:
Dest LU TP Prot Gateway host Gateway service
S50 C host name sapgwXX
The entries for LU and TP are dummy entries. For the gateway the following applies:
LU=DEST and TP=X1SA
host name is the name derived from the BCAM generation of the BS2000 host where the gateway is
running. The gateway can function with or without side information.
(Parameter: bs2/use_sideinfo [0,1]).

R/2 R/3 Communication (SNI)
© SAP AG
Connection setup from R/2
BS2000 BS2000 (K50)
(K50)
R/2
R/2
ABAP/4 ABAP/4
Progr: Progr: gwhost
gwhost
Dest LU TP Comm. type
BS2R3 T01 H
TCP/IP
UNIX, UNIX, NT NT (T01)
(T01)
R/3
R/3
ABAP/4
ABAP/4
Table XCOM (K50) Side info from gwhost
The connection is set up via the SAP gateway of the R/3 System.
hs5001, sapgw00
SAP SAP gateway
gateway
Dest = T01
LU = hs5001
TP = sapgw00
GWHOST = hs5001
GWSERV = sapgw00
Protocol = I
The communication is made by an intermediate step in the program gwhost which is running on the
BS2000 host.
Entries in the side information tables:
Table XCOM of the R/2 System:
Symbolic dest. LU (logical unit) TP (transaction prog.) Comm. type
R2R301 (gwhost) H
Table sideinfo for gwhost:
Dest=(gwhost)
LU= (host name_1)
TP= (sapdpXX)
GWHOST= (host name_2)
GWSERV= (sapgwYY)
Protocol= (I)
For an RFC connection, you need the appropriate entry in the table RFCD.

R/3 External Program (UNIX)
© SAP AG
External program on SAP-supported UNIX platforms
hs5001, sapgw00 hs5002, sapgw01
UNIX UNIX (T01) (T01) (T01)
UNIX
UNIX
R/3
R/3
ABAP/4 ABAP/4
Table TXCOM (T01)
TCP/IP (remote)
shared Memory (local)
SAP SAP gateway
gateway
Table RFCDES (T01) Gateway options
TCP/IP
RFC destination R3EXT Gateway host: hs5002
Connection type T
Program Path name Gateway service: sapgw01
Dest LU TP Prot Gateway host Gateway service
R3EXT hs5002 path name E hs5002 sapgw01
UNIX
UNIX
External External program program
For an RFC connection, you need to make the appropriate entry in the table RFCDES with Transaction
SM59.
Since the SAP gateway uses the values in TXCOM or RFCDES, you do not need an entry in the side
information table. The external program is started via the SAP gateway.
A distinction is made as to whether the SAP gateway runs on the same machine as the external program
or not.
SAP gateway and target machine identical:
The SAP gateway has a particular ID which corresponds to the user name (c11adm) used to start it.
==> The external program must be in the user’s search path and able to be started with this ID
SAP gateway and target machine different:
The SAP gateway starts the external program with Remote Shell or Remote Execute. Also, the above user
must be known in the target system and have an entry in the .rhost.

R/3 External Program (TCP/IP)
l Systems not supported by SAP, but accessible via
© SAP AG
TCP/IP
UNIX, UNIX, NT
NT
R/3 R/3
SAP gateway
CPI-C CPI-C / / RFC
RFC
socket socket program program
TCP/IP
External External
socket socket program program
DEC DEC OpenVMS
OpenVMS
HP HP MPE
MPE
IBM IBM host host system
system
IBM IBM AS400
AS400
SNI SNI host host system
system
. . . . .
.
You can also connect external systems online to R/3 Systems for which there is no CPI-C / RFC support.
This section covers systems which are accessible via TCP/IP.
Systems accessible via TCP/IP always provide programming-API sockets. The socket interface is the
API of TCP.
An SAP CPI-C / RFC program can thus communicate with a socket program.
This means, for example, that you can connect DEC OpenVMS machines, HP MPE machines, IBM
hosts, the IBM AS400 series, as well as SNI hosts via the TCP/IP protocol.
A CPI-C / RFC gateway program, which communicates a) with R/3 via CPI-C or RFC and b) with the
external socket program via sockets, thus assumes the gateway function. You must develop this gateway
program to suit your own requirements.
From the point of view of the R/3 System, only one CPI-C or RFC program is started (see also previous
page).

R/3 External Program (Windows NT)
© SAP AG
NT
NT
SAPgui
exec exec
UNIX, UNIX, NT
NT
SAP SAP gateway
gateway
SAPgui
data stream (TCP/IP)
External
External
program program
R/3 R/3
Windows NT supports the CPI-C and RFC interfaces.
TCP/IP
NT
NT
SAP SAP gateway gateway
External
External
program program
Under Windows NT, you can start an external program in either of the following ways:
1) Directly from the SAPgui.
Entry in TXCOM:
Dest LU TP Prot
R3FE Dummy Ext. prog. F
Entry in RFCDES with Transaction SM59:
Connection type: T
Program location: User
Program: /tmp/extpgm
2) From the SAP gateway.
Entry in TXCOM:
Dest LU TP Prot Gateway host Gateway
service
R3EX host name Ext. prog. E host name sapgwXX
Entry in RFCDES with Transaction SM59:
Connection type: T

Program location: Explicit
Target machine: Host name
Gateway options: Gateway host: Host name
Gateway service: sapgwXX
Program: /tmp/extpgm

R/3 External Program (WfW , Windows 3.1)
© SAP AG
UNIX, UNIX, NT
NT
R/3
R/3
SAP SAP gateway
gateway
SAPgui
data stream (TCP/IP)
SAPgui
Windows Windows
exec exec
External External
program program
An external program, usually an RFC program, is started on a Windows machine by the SAPgui. Here,
you cannot call the program through the SAP gateway.
Entry in RFCDES with Transaction SM59:
Connection type: T
Program location: User
Program: c:\tmp\extpgm
A frontend program is connected to an R/3 System via the SAP gateway which is running on an NT or
UNIX machine.
For WfW and Windows 3.1, the CPI-C interface is not supported.

R/3 External Program (OS/2)
© SAP AG
SAPgui
exec exec
UNIX, UNIX, NT
NT
UNIX, NT
R/3 R/3
SAP SAP gateway
gateway
SAPgui
data stream (TCP/IP)
External
External
program program
OS/2
OS/2
OS/2
OS/2
TCP/IP
External
External
program program
Under OS/2, the situation is the same as with Windows NT. You can start a program from the SAPgui or
through the SAP gateway. Since OS/2 has a multi-user capability, the SAP gateway does not have to be
on the OS/2 system.
An external program in OS/2 is connected to R/3 via the SAP gateway.
Under OS/2, you can start an external program from the SAPgui, via remsh or from a remote SAP
gateway.
The external program is started via remsh:
Entry in TXCOM:
Dest LU TP Prot Gateway host Gateway
service
R3FE host name Ext. prog. E
The external program is started from a remote SAP gateway:
Entry in TXCOM:
Dest LU TP Prot Gateway host Gateway
service
R3FE host name_1 Ext. prog. E host name_1 sapgwXX
For an RFC connection, you must make the appropriate entry in the table RFCDES with Transaction
SM59.

R/3 IBM Host / AS400
© SAP AG
External program based on IBM CPI-C or APPC
IBM IBM host
host
UNIX
UNIX UNIX
R/3 R/3
OS/2
UNIX
SAP SAP gateway
gateway
NT SNA subsystem
APPC
APPC
CPI-C
CPI-C
LU6.2
LU6.2
APPC
APPC
CPI-C CPI-C
AS400
AS400
If a machine can be accessed via the SNA protocol LU6.2, it always has at least the programming API
APPC (Advanced Program to Program Communication). Communication between external APPC and
SAP CPI-C programs is possible.
Normally, systems accessible via LU6.2 have CPI-C, which is easier to use and itself based on APPC.
This means that communication between external CPI-C programs and SAP CPI-C programs is
guaranteed.
Machines in the IBM AS400 series have both APPC und CPI-C. External programs are started via
SNA-LU6.2:
Entry in TXCOM:
Dest LU TP Prot Gateway host Gateway
service
R3EX host name Ext. prog. C
The name of the TXCOM destination corresponds to an entry in the side information of the SAP gateway
(see also R/3 - R/2 Communication with connection setup from R/3).
Calling an external RFC program is not possible because, at present, no SAP RFC SDK (Software
Development Kit) is supplied for the above platforms.

External Program (TCP/IP) R/3
© SAP AG
External External program program
TCP/IP
Side info of the external program
Dest = T01
LU = hs5001
TP = sapgw00
GWHOST = hs5001
GWSERV = sapgw00
Protocol = I
hs5001, sapgw00
T01
T01
SAP SAP gateway
gateway
R/3
R/3
ABAP/4
ABAP/4
The side information table "sideinfo" on the source machine must be in the current directory.
Alternatively, before calling the program, you must place the SHELL variable SIDE_INFO in the path
where the side information table is located.
The side information table "sideinfo" for the SAP gateway is stored in the data directory (e.g.
/usr/sap//DVEBMGS00/data) and defined for the SAP gateway ID (adm) by the SHELL
variable SIDE_INFO.
The information in the side information tables can be wholly or partly taken from the external program
(see SAP_CMINIT, RFC connections).
If the external program and the SAP gateway are running on the same machine, the entry in the side
information table can contain all information:
Table "sideinfo" for external program and SAP gateway:
DEST=
GWHOST=
GWSERV=
PROTOCOL=
LU=
TP=

External Program (LU6.2) R/3
External External system
system
External External program program
© SAP AG
LU6.2
SNA SNA subsystem
subsystem
Program: Program: gwhost
gwhost
SAP SAP gateway
gateway
TCP/IP (remote)
shared memory (local)
Side info from gwhost
Dest = T01
LU = hs5001
TP = sapgw00
GWHOST = hs5001
GWSERV = sapgw00
Protocol = I
hs5001, sapgw00
UNIX, UNIX, NT NT (T01)
(T01)
SAP SAP gateway
gateway
R/3
R/3
ABAP/4
ABAP/4
If the source machine is not an IBM host, this type of communication is only possible if both LU6.2
products support peer-to-peer communication (PU type 2.1).
Calling an external RFC program is not possible because, at present, no SAP RFC SDK (Software
Development Kit) is supplied for platforms accessible via LU6.2.
All other requirements are the same as those already listed for R/2 -> R/3 communication.

Gateway Monitor
Gateway connection table (SAP system)
LU name TP name User Status Symb.dest Conv ID ...
hs1234 sapgw01 BC415-01 CONNECTED X50 12345678
hs2345 sapgw01 LOTZ CONNECTED X50 12345679
hs2345 sapgw01 TILLINGER CONNECTED X50 12345680
. . .
Gateway connection table (operating system)
No. CLIENT (LU/TP) USER STATE SDEST CONNID ...
000 hs1234 sapgw01 BC415-01 CONNECTED X50 12345678
001 hs2345 sapgw01 LOTZ CONNECTED X50 12345679
002 hs2345 sapgw01 TILLINGER CONNECTED X50 12345680
. . .
© SAP AG
The purpose of the gateway monitor is to monitor connections. It allows you to display all the
connections currently managed by an SAP gateway. The gateway monitor includes the following
functions:
Displays a list of active CPIC connections
Displays a list of gateway work processes
Displays the parameters of a CPIC connection
Deletes CPIC connections
Displays memory occupancy
Displays memory contents
Manages gateway statistics
Resets the error counter
Displays gateway parameters and attributes
Provides a gateway trace facility
Security display and refresh
In R/3, you can call the gateway monitor with the Transaction SMGW, or start it at operating system
level with the executable program gwmon. When you make the call, the system provides the name of the
profile file. With UNIX, for example, the procedure is as follows:
ps -ef | grep gw --> gwrd pf=/usr/sap//SYS/profile/
gwmon pf= /usr/sap//SYS/profile/ .

Chapter 2 Summary
© SAP AG
l The SAP gateway (CPI-C handler) is used for all
communications with SAP R/3 Systems.
l SAP side information tables are configuration tables
where you define the necessary connection parameters
for a communication.
l To implement a communication via Remote Function Call
(RFC), you make control entries in the appropriate tables
(RFCDES, RFCD).
l Communications are possible between R/3 Systems,
between R/3 and R/2 Systems, as well as between R/3
Systems and external programs.

Chapter 3 Remote Function Call
© SAP AG
l Synchronous RFC
l Asynchronous RFC
l Transactional RFC

Chapter 3 Objectives
© SAP AG
l How to communicate with other SAP or external
systems using RFC (Remote Function Call).
l Different RFC call variants.
l How to maintain table RFCDES for the various
linking options.
l Development tools for RFC programs.

Supporting RFC on Heterogenous Platforms
© SAP AG
R/2
RFC
RFC
RFC for R/2 systems is available from Release 5.0E.
RFC for R/3 systems is available from Release 2.0.
R/3
RFC
R/3
RFC
External
system
RFC is also supported for systems on which no SAP system is installed. For information on which
platforms SAP supports, please refer to the document SAP Supported Network Products. SAP provides
an RFC SDK (Software Development Kit) for these platforms (executable only in R/3 from Release
2.1).

RFC Features
© SAP AG
Automatic Automatic data data conversion
conversion
Automatic Automatic logon logon to to the the SAP SAP partner partner system
system
Automatic Automatic conversion conversion of of all all RFC RFC data data types
types
Automatic Automatic communication communication flow flow control control
Development Development environment:
environment:
Remote Remote debugging
debugging
RFC RFC generator
generator
The conversion of data for transfer between linked systems is performed automatically.
LOGON to the SAP partner system is also performed automatically (the user’s name and password are
stored in the table RFCDES).
For single parameters, the conversion of all data types (CHAR, NUMC, DATE, TIME, HEX, FLTP,
INT) is supported. Please note that you should not use mixed data types (i.e. character and numeric
types) in the same transfer structure (structures and internal tables).
The communication flow between programs is controlled internally.
For R/3-to-R/3 connections, the RFC development environment provides remote debugging.
The RFC generator allows you to create external RFC programs (server and client) in C or Visual
Basic.

ABAP/4 Function Modules
© SAP AG
FM maintenance
FM_02
Interface
Import
Export
Tables
Exceptions
Program
Documentation
Administration
Function Library
FM group: FIBU
FM_01 ...
FM_02 ...
FM group: ZIBU
FM_03 ...
FM_04 ...
FM use
PROGRAM ...
TABLES ...
CALL FUNCTION
'FM_02'
EXPORTING ...
IMPORTING ...
ABAP/4 function modules are divided into function groups in the Function Library. A function group
contains functions which perform similar tasks (e.g. calendar functions) or work with the same data (1st
function fills an internal table, 2nd function edits an internal table, ...).
You can assign a group to a particular application (FI, HR) or flag it for general use (*).

Local Call of Function Modules
ABAP/4 function module ...
Import parameter Reference field Ref. type Proposal Optional Reference
f1 ...
Export parameter Reference field Ref. type Reference
f2 ...
Changing parameter Reference field Ref. type Proposal Optional Reference
f3 ...
Tables parameter Reference field Optional
t1 ...
...
CALL FUNCTION 'TEST'
EXPORTING
f1 = a1
© SAP AG
ABAP/4 program ABAP/4 function module
IMPORTING
f2 = a2
CHANGING
f3 = a3
TABLES
t1 = tab
The function
module is
executed locally
in the same
R/3 System.
FUNCTION TEST.
...
ENDFUNCTION.
In R/3, function modules are ABAP/4 programs which are stored centrally in the Function Library.
They can be called locally by any ABAP/4 program. Function modules are similar to functions in C, and
procedures in PASCAL or COBOL. Both C functions and PASCAL or COBOL procedures are also
stored in a central library.
Function modules have a defined interface. Input parameters are passed to them via the IMPORTING
or CHANGING interface. Single result parameters can be returned via the EXPORTING and
CHANGING interface, but internal tables are passed to the TABLES interface. When creating a
function module, you can define IMPORTING parameters as optional. Since they have a predefined
value, you do not have to assign a value when calling a function module.
Interface parameters should reference Dictionary reference structures.
CHANGING parameters contain fields or field strings which can be passed from the program to the
function module when the function module is called, and returned to the calling program when the
processing of the function module has finished.
For each function module, you can raise exceptions which the function module can trigger if an error
occurs.
You maintain function modules with Transaction SE37.

External Functions
External program
...
Call RFC function A
...
Function 1
(Prg. routine)
Function 2
(Prg. routine)
...
© SAP AG
LINK
...
RFC library
RFC SDK
( SAP )
RFC function set:
RFC function A
RFC function B
...
Standard functions:
Function A
Function B
...
The SAP RFC SDK (Software Development Kit) is delivered with all R/3 Systems.
As in the CPI-C SDK, the RFC SDK contains executable programs for the relevant hardware platform,
libraries, include programs, and also ABAP/4 and C programs. Accompanying text files describe the
structure of the SDK and provide information about how the programs are to be compiled on the
different platforms.
The RFC libraries provide the functionality for creating external client or server programs
(programming languages include C and Visual Basic - in general, all languages which allow you to link
C libraries). Essentially, the libraries contain the calls required for RFC such as OPEN, ACCEPT and
SEND. They also provide a number of standard function routines for testing purposes.

REMOTE FUNCTION CALL (RFC)
SAP system A
ABAP/4 program
...
CALL FUNCTION 'FUNC'
DESTINATION 'DEST'
EXPORTING
IMPORTING
CHANGING
TABLES
EXCEPTIONS
COMMUNICATION_FAILURE = 1
SYSTEM_FAILURE = 2
...
© SAP AG
f1 = a1
f2 = a2
f3 = a3
t1 = tab
SAP system B
ABAP/4 function module
FUNCTION FUNC.
...
ENDFUNCTION.
External program
C routine
Function modules can also be called by remote systems if the function module is designed for RFC.
If SAP R/2 or R/3 is the RFC server system, the function module name is FUNC. If a C program is the
RFC server program, FUNC is the name of a function installed previously with RFC API.
DEST is the symbolic destination of the partner system. The destination must be defined in the table
RFCDES.
You can use the EXPORTING and IMPORTING parameters to pass and receive field or field string
values.
With CHANGING, you can pass values of fields or field strings to or from the function module.
With TABLES, you can pass references to internal tables. Table parameters should have homogenous
data types.
All interface parameters must refer to Dictionary reference structures (unlike local calls to function
modules).
You use the EXCEPTIONS parameter to specify the exceptions the calling program is to handle itself.
...

Function Modules: RFC Capability
© SAP AG
l Transaction: SE37, Administration
l RFC-enabled function modules
Process type
Normal
Remote Function Call supported
Update with immediate start
...
Generation
Generation
Import stub
FUNCTION TEST.
SELECT *...
ENDFUNCTION.
To start a function module by remote start, it must be flagged as RFC-enabled in the function module
administration facility. If RFC support is set, the system generates an import stub when you create the
module. This import stub is part of an ABAP/4 program and is executed when the function module is
called by a remote system.

Table RFCDES
© SAP AG
Maintaining RFCDES with Transaction SM59
RFC destinations
R/2 connections
R/3 connections
Internal connections
Logical connections
CMC connections
SNA/CPI-C connections
TCP/IP connections
You edit the table RFCDES with transaction SM59.
+
+
+
+
+
+
+
+
Connections via ABAP/4 driver
The following connection types (partner system/program) are possible:
I Internal: Same SAP system; communication from application server to application server.
( => same database). You cannot maintain this type. When the system is started, the entries are set
automatically.
2 Partner system is an R/2 System.
3 Partner system is another R/3 System => other database.
S Partner is a program which can be accessed via the LU6.2 protocol. No RFC SDKs are yet
available
for these platforms. Such a partner program would have to use hard APPC calls.
L Logical partner:
Reference is to an existing destination. Existing values (e.g. user name and password) can be
overwritte and new values can be added.
M CMC (Common Messaging Call) connection. This destination is designed for an R/3-to-R/3
connection
which uses the standard programming interface CMC for mail systems.
T Partner is an external RFC program based on TCP/IP.
X The RFC data flow can be passed to a self-defined ABAP/4 program
(ABAP/4 CPI-C program).
Similarly, R/2 contains the table RFCD (which references the table XCOM).

Destinations BACK, SPACE and NONE
System A System B
...
CALL FUNCTION 'B'
DESTINATION 'B'
...
© SAP AG
FUNCTION A.
...
ENDFUNCTION.
Result A
Result B
FUNCTION B.
...
...
CALL FUNCTION 'A'
DESTINATION
ENDFUNCTION.
'BACK'
When executing a RFC function, you can call an RFC-enabled function in the calling system with
CALL FUNCTION ... DESTINATION 'BACK'. You can use the BACK destination with RFC
between two R/3 systems and between R/3 and external C programs (RFC SDK), as well as with the
RFCDES connection types 3 and T.
Two functions can call each other recursively.
If you want to execute a function module locally, you specify the destination SPACE.
You specify the destination NONE if you want to execute a function module locally, but the call to be
performed is technically a REMOTE call (i.e. via a gateway). (See RFC test without partner system.)

Remote Debugging
R/3 A
REPORT CUGE.
PARAMETERS ...
DATA ...
CALL FUNCTION
'RFC_CUSTOMER_GET'
DESTINATION 'B'
...
...
© SAP AG
Remote debugging is possible between two R/3 systems.
R/3 B
FUNCTION RFC_CUSTOMER_GET.
DATA ...
SELECT * FROM KNA1 ...
...
ENDFUNCTION.
If you run the calling program in debugging mode, the code of the remote function module is transported
to and displayed in the calling system. All the usual debugging options such as Single step and Execute
are also supported in the ABAP/4 code of the function module.

Asynchronous RFC: STARTING NEW TASK ...
R/3 server A R/3 server B (same or other R/3)
PROGRAM RS01.
.
CALL FUNCTION 'FUNC1'.
DESTINATION 'B'
STARTING NEW TASK 'ABC'
EXPORTING ...
TABLES ...
.
© SAP AG
FUNCTION FUNC1.
...
ENDFUNCTION.
You use STARTING NEW TASK to generate a new task which calls the function module. The
original program continues to run after the remote function call has been started.
The client program in the above example can receive no confirmation messages from the called
function module since IMPORTING, CHANGING or EXCEPTIONS are not possible with CALL and
because the connection is closed right after the CALL. You also cannot use the destination BACK in the
called function module.
If the called function module performs dialogs, the relevant screens are displayed in the client system in
the new session.
Using this technique, you can not only make connections to another remote R/3 System, but you can also
execute remote function modules on any computer in your own R/3 System (with distributed systems).

Asynchronous RFC with Return of Data
R/3 server A R/3 server B (same or other R/3)
PROGRAM RS01.
...
CALL FUNCTION 'FUNC1'.
DESTINATION 'B'
STARTING NEW TASK 'ABC'
PERFORMING FUNC1_RETURN ON END OF TASK.
EXPORTING ...
TABLES ...
...
FORM FUNC1_RETURN USING TASK.
...
RECEIVE RESULTS FROM FUNCTION FUNC1
IMPORTING ...
TABLES ...
EXCEPTIONS ...
...
SET USER-COMMAND '...'.
ENDFORM.
...
AT USER-COMMAND.
...
© SAP AG
FUNCTION FUNC1.
...
ENDFUNCTION.
In the above example, the called function module can return data or exceptions to the client program,
although the function module has been started asynchronously. By using the PERFORMING addition,
you ensure that the connection to the partner remains open.
When the called function module is processed, the FORM routine specified after the CALL-FUNCTION
parameter PERFORMING is called.
The FORM routine must have a formal parameter (any name is allowed). This parameter is supplied
automatically with the relevant task ID when the routine is called.
By using RECEIVE RESULTS FROM FUNCTION ... in the FORM routine, you can get the
asynchronously processed function module to return data and exceptions. By using the SET USER-
COMMAND statement, you can start the program event directly.

Asynchronous RFC: Parallel Processes
© SAP AG
PROGRAM PARAL01.
...
CALL FUNCTION 'A'
DESTINATION '1'
STARTING NEW TASK 'A'
PERFORMING 'BACK' ON END OF TASK.
CALL FUNCTION 'B'
DESTINATION '2'
STARTING NEW TASK 'B'
PERFORMING 'BACK' ON END OF TASK.
...
FORM BACK USING TASK.
CASE TASK.
WHEN 'A'. ... AFLAG = 'X'.
WHEN 'B'. ... BFLAG = 'X'.
ENDCASE.
SET USER-COMMAND 'CHECK'.
ENDFORM.
AT USER-COMMAND.
CASE SY-UCOMM.
WHEN 'CHECK'.
IF AFLAG = 'X' AND BFLAG = 'X'.
...
By starting several RFCs with STARTING NEW TASK, you can roll out calculations to other servers
(with distributed systems) or systems, or run them in parallel.
If you have to wait for the result of some or all called function modules, you can control this in the list
environment via the event AT USER-COMMAND by setting flags.
Note:
You can perform the same action in a dialog chain (screen sequence) without using SET USER-
COMMAND to trigger the AT USER-COMMAND list event. Please note that the function modules
first run separate from the client program. You do not know when the individual function modules have
finished or, consequently, when the relevant FORM routine is internally triggered. The processing of the
FORM routine is inserted into the current PAI event of the client program. PAI is then processed again
from the beginning.

RFC Dialog
R/3 System 1 R/3 System 2
Variant 1: Synchronous
PROGRAM RS01.
...
CALL FUNCTION 'DIALOG'.
DESTINATION ...
...
Screen 100
Variant 2: Separated
PROGRAM RS01.
...
CALL FUNCTION 'DIALOG'.
DESTINATION ...
STARTING NEW TASK 'A'...
Caller
session
© SAP AG
Screen 100
1st session 2nd session
FUNCTION DIALOG.
...
CALL SCREEN '100'.
...
ENDFUNCTION.
Screen 100
RFC dialog (or RFC with screens) allows you to display screens (dialog and list screens) in the client
system and process them in a remote system within a RFC.
In the called function module, you can call a screen using (for example) CALL SCREEN. The screen is
then transported and displayed in the client system. The same applies to CALL TRANSACTION,
SUBMIT AND RETURN, and CALL DIALOG.
There are two call techniques:
1) Synchronous RFC:
Here, the client program executes the call and waits until the called function module has finished. All
dialog steps executed by the called function module are displayed in the original session of the client
program. Only when the function module is finished does the client program continue processing after
CALL FUNCTION.
2) Asynchronous RFC (STARTING NEW TASK ):
Here, the client program continues processing directly after CALL FUNCTION. The function module is
run asynchronously on a remote system. All dialog steps executed by the called function module are
displayed in a new session in the client system. RFC dialog thus behaves like a remote login.
Transaction SC38 allows you to start a R/2 program. The list output of the this program is displayed in
the R/3 SAPGUI.

Transactional RFC (tRFC)
© SAP AG
R/3
Automatic job
scheduling
Program
with tRFC
DB
SD FI
MM
CO PP
R/3
AM
Client / / Server
QM
ABAP/4
PS
PM
WF
HR
IS
Administration tables
Table RFCDES:
TRFC options
Job
tRFC
Administration transaction
SM58
R/3
Function
module(s)
SD
FI
MM MM CO PP
R/3 AM
Client / Server
QM
ABAP/4
PS
ABAP/4
PS
PM
WF WF
HR IS
Transactional RFC (tRFC): You can also submit Remote Function Calls when the target system is not
available. For example, the connection to a partner system may have been interrupted or the partner
system itself is not currently active.
The function module is flagged to be run asynchronously. It is not executed immediately, but the data
passed with EXPORTING or TABLES is stored in a database table.
Automatic job scheduling is performed. The job starts the relevant function module(s) in the partner
system.
You set parameters for the relevant connection via the table RFCDES:
--> suppress background job if communication error occurs
--> attempt to set up until system instructs otherwise
--> break between two attempts

tRFC Syntax
© SAP AG
PROGRAM ASYN01.
.
.
.
CALL FUNCTION 'A'
DESTINATION '1'
IN BACKGROUND TASK
EXPORTING ...
TABLES ...
...
CALL FUNCTION 'B'
DESTINATION '1'
IN BACKGROUND TASK
EXPORTING ...
TABLES ...
COMMIT WORK.
In contrast to synchronous RFC, there is an additional parameter sequence called IN BACKGROUND
TASK
All RFC calls which contain this sequence and the same DESTINATION are stored in the database
using COMMIT WORK. These RFC calls form a Logical Unit of Work (LUW). The function
modules are executed in the target system in the same sequence in which they are submitted in the source
system.
This means that, for each target system, the RFCs submitted in a LUW form a Logical Unit of Work.
The called RFC-enabled function is executed once and only once.
Exactly Once!
This guarantees transaction integrity.
You cannot specify IMPORTING parameters with CALL.
External systems can benefit from the tRFC guarantee that a function module is executed once by using
the RFC API call RfcIndirectCall.

tRFC: Tables and Scheduling
ABAP/4 progam
CALL FUNCTION ...
IN BACKGROUND TASK
EXPORTING ...
TABLES ...
CALL FUNCTION ...
IN BACKGROUND TASK
EXPORTING ...
TABLES ...
COMMIT WORK.
Transaction
SM58
© SAP AG
ARFCSSTATE
Transactional RFC Log file
ARFCSDATA
DB
Caller FM Target system Date Time Status
PAUL xyz R3B 06.07.95 14.00 --
By using CALL FUNCTION ... IN BACKGROUND TASK, you store the called data in internal
tables.
COMMIT WORK stores the context data of the function calls in the database (general data such as the
name of the function module in table ARFCSSTATE; concrete data passed with CALL in table
ARFCSDATA). Then, the send job is scheduled.
The send job reads the database tables ARFCSSTATE and ARFCSDATA and tries to set up a
connection to the partner system. If an error occurs, the send job is re-scheduled.
You can analyze the log file with Transaction SM58. This allows you to display and edit function calls
that have not yet been executed.
If you want to send an LUW later, you can specify this event by calling the function module
START_OF_BACKGROUNDTASK before COMMIT WORK.

RFC Between R/3 and External Programs
© SAP AG
R/3 System
ABAP/4
...
CALL FUNCTION...
DESTINATION...
...
Function module
FUNCTION...
ENDFUNCTION.
RFC
External system
External
RFC server
program
External
RFC client
program
ABAP/4 programs can exchange data with an external program via the RFC interface.
External programs can call a function module in the R/3 System via the RFC interface.

External RFC Program: Client
© SAP AG
RfcOpen(...);
...
RfcCall(...);
...
RfcReceive(...);
...
RfcCall(...);
...
RfcReceive(...);
...
RfcClose(...);
}RfcCallReceive (...);
The above program is an RFC client program, i.e. it initiates a communication and connects to the RFC
server program.
RfcOpen sets up a connection to the partner system (INIT, ALLOCATE, LOGON). You are then
logged on to the SAP system.
RfcCall calls a function module (SAP system) or a function (external system) and transfers parameters
and tables.
RfcReceive allows you to receive replies after RfcCall has been called. RfcReceive waits until a reply
has been received.
Instead of RfcCall and RfcReceive, you can use a function called RfcCallReceive.
RfcClose closes the conversation with the partner system.
Between a CALL and a RECEIVE you can always use a RfcLists. This tells you whether a function has
been processed or whether the connection is still open.
You pass connection parameters via RfcOpen (at least the client, user name and password) or a side
information file. From Release 3.0, you should use saprfc.ini as the side information file. You can also
use the following features:
--> Addressing R/3 via load balancing (specify the message server)
--> An external server program can be registered at an SAP gateway
(--> Demon). This saves the start time usually required (performance option).

External RFC Program: Server
© SAP AG
main(...)
{ ...
RfcAccept(...)
...
RfcInstallFunction(...)
...
RfcDispatch(...)
...
RfcClose(...)
}
...
static RFC_RC rfcfunc(...)
...
Data processing
{ RfcGetData(...)
RfcSendData(...)
}
The above example demonstrates how an external RFC server program should be structured.
RfcInstallFunction installs all RFC-enabled functions in this program. You must explicitly declare all
program functions. This allows RfcDispatch to find them.
In addition, RfcInstallFunction automatically declares the following standard library functions:
RFC_SYSTEM_INFO: Returns system information to the calling system.
RFC_DOCU: Documents which RFC functions can be called in the program.
RFC_PING: Checks that the communication path to the program is correct.
RFC_START_GUI: Starts SAPGUI on the frontend.
ARFC_DEST_SHIP,
ARFC_DEST_CONFIRM: Used internally with transactional RFC.
You can call these in R/3 from the menu bar of Transaction SM59 when you display a RFC destination
(system information: target system, function list, test connection)
RfcDispatch waits for a function call for an internal program function and subsequently calls this
function.

The SAP RFC SDK
© SAP AG
rfcsdk/bin/rfcexec
sapinfo
startrfc
srfctest
srfcserv
trfctest
trfcserv
lib/librfc.a
include/sapitab.h
saprfc.h
text/*.doc
*.txt
*.c
The SAP RFC SDK (Software Development Kit) is delivered with every R/3 System.
The RFC SDK contains executables, libraries, include files as well as ABAP/4 and C programs for the
hardware platform. Text files describe the structure of the SDK and explain how the programs on the
various platforms are compiled and connected.
The bin directory contains a number of executables which provide test and special functionality.
The lib directory contains the function library.
Data types and prototypes of the RFC calls are defined in the saprfc.h file.
Functions for the handling of internal tables are stored in the sapitab.h file.

Desktop SDK (for Windows)
© SAP AG
Desktop SDK
RFC SDK
lib\librfc.dll ( --> 16 oder 32 Bit )
...
help
RFC Logon Manager ( VRFC )
Documentation (RFC generator etc.)
In Windows environments, RFC SDK is delivered with special utilities for constructing application
solutions in the area of desktop integration.
The desktop SDK contains additional and Windows-specific documentation concerning desktop
integration questions (see the directory help). It also provides Windows-specific software layers which
hide the actual RFC calls and thus facilitate the access to RFC solutions. Some of these additional layers
are offered as C++ classes.
The RFC Logon Manager provides a standardized logon dialog which all RFC applications under
Windows can use. It also allows you to monitor active RFC sessions.
Visual RFC (VRFC) provides optimized session management (optimized usage of sockets on the PC)
and also a number of standard dialogs (e.g. logon dialog).

SAP RFC Programs
© SAP AG
l sapinfo
l startrfc
l rfcexec
l srfctest
l srfcserv
l trfctest
l trfcserv
R/3
SD
MM
PP
R/3
FI
CO
AM
Client / / Server
QM
ABAP/4
PS
PM
WF
HR IS
The RFC SDK (Software Development Kit) contains three executable programs which are also available
in C source code. These programs are as follows:
sapinfo: Client program which sets up the connection to the partner system and retrieves various
system
information. It can be used as a connection test program.
startrfc: Client program which can start any function module in the SAP system, pass parameters
or
tables to it, and receive results in the form of parameters and tables. RFC program for
connecting external systems to an SAP System.
rfcexec: Server program which is started by an SAP system and allows you to start several
predefined
functions. It can also be used for testing the connection between an SAP system and an
external
system.
srfctest: Client program for synchronous RFC (connection and performance tests possible).
srfcserv: Server program for synchronous RFC (connection and performance tests possible).
trfctest: Client program for transactional RFC
trfcserv: Server program for transactional RFC

RFC Server: rfcexec
R/3
© SAP AG
n Three functions of rfcexec:
SD
FI
MM
CO
PP R/3
AM
Client / Server
QM
ABAP/4
PS
PM WF
HR
IS
u RFC_REMOTE_PIPE
u RFC_REMOTE_FILE
u RFC_REMOTE_EXEC
Start
Output
start
remote pipe
rfcexec
rfcexec
remote-pipe
remote-pipe
{
{
}
}
remote-file
remote-file
{
{
}
}
remote-exec
remote-exec
{
{
}
}
The SAP RFC server program rfcexec provides the three following functions as standard:
RFC_REMOTE_PIPE
Can call an operating system command or start a program. The programs’s standard output is redirected
to the SAP system and output in the SAPGUI.
RFC_REMOTE_FILE
Allows the system on which the rfcexec is started to read a file into an internal table. The contents of the
internal file can also be stored as a file on the external system.
RFC_REMOTE_EXEC
Can start a program without having to redirect the output of the program to the SAPGUI.
... ... ...

RFC: Connection and Performance Test
R/3 ABAP/4:
Server: Function modules
Client program: SRFCTEST
External RFC programs:
Client program: srfctest
Server program: srfcserv
Client program: trfctest
Server program: trfcserv
© SAP AG
ABAP/4 program SRFCTEST
Start
Possible RFC tests:
1. CONNECTION
2. PERFORMANCE
3. TRANSACTIONAL RFC
Destination
...
Selection
Result list
dest_srfcserv
Both the R/3 System and the libraries contain a number of test programs. The functionality covers
everything from connection tests to performance measurement.
ABAP/4:
SRFCTEST After starting the program, you must select the desired execution option (with the
cursor). You then specify the Logical destination and the No. of desired function
calls
(only relevant with the execution option PERFORMANCE). The execution
options
PERFORMANCE and TRANSACTION RFC allow you to specify a number of
additional parameters (e.g. the number of table lines).
C:
srfctest Client program for synchronous RFC (calls an ABAP/4 function module or a C
function)
srfcserv Server program for synchronous RFC (can be used as partner program for
srfctest or
SRFCTEST
trfctest Client program for transactional RFC
trfcserv Server program for transactional RFC
The programs use the destination NONE as the default. If you want to test other destinations, you must
maintain the table RFCDES first.

RFC Generator
l RFC generator generates C programs
© SAP AG
w Client C program
w Server C program
l RFC generator generates Visual Basic programs
w Client Visual Basic program
w Server Visual Basic program
The RFC generator is available from Release 2.1G or 2.2A. From Release 3.0, full functionality is
available as far as the generation of server programs is concerned.
For an existing function module with a fully defined interface, the RFC generator generates the relevant
C or Visual Basic programs (in the client or server version).
If you want to generate an external server program, you first have to create a dummy function module
(interface!) in R/3 (analogous to the desired function in the external server program).

RFC Generator for C Programs
FUNCTION FUNCTION ABC. ABC.
DATA_PROCESSING
DATA_PROCESSING
ENDFUNCTION.
© SAP AG
SD FI
MM
CO PP
R/3
AM
Client / / Server
QM
ABAP/4 PS
PM
WF
HR
IS
R/3
R/3 generates
programs
RFC request
result
C RFC program
... ...
main( main( ) )
{ {
RfcOpen(...);
RfcOpen(...);
... ...
RfcCallReceive(...,"ABC",...);
... ...
RfcClose(...);
RfcClose(...);
} }
In Transaction SE37, you can start the RFC generator by choosing Utilities->Interface->Generate.
You have to be in the interface display or change mode of this function module. There, you can generate
C programs.
In the subsequent dialog box, you can specify which programs are to be generated. You can also enter
the directories where the individual files are to be stored after the generation on the frontend machine.
After the generation process has been completed, the individual files are transferred to the frontend.
The accompanying text files include a description of the files to be generated or loaded on the frontend.
They also describe the compilation and/or the linking of the programs.

RFC Generator for Visual Basic Programs
FUNCTION FUNCTION ABC. ABC.
DATA_PROCESSING
DATA_PROCESSING
ENDFUNCTION.
© SAP AG
SD FI
MM
CO PP
R/3
AM
Client / / Server
QM
ABAP/4 PS
PM
WF
HR
IS
R/3
R/3 generates
programs
RFC request
result
Visual Basic RFC program
REM REM function function module module
DIM DIM ... ...
DIM DIM ... ...
RfcReceiveTxt ( ( ) )
You can use the RFC generator to generate Visual Basic programs. Downloading generated Visual
Basic programs only makes sense on Windows platforms which support Visual Basic.
The generated program starts the corresponding SAP function module without you having to include any
Visual Basic code.
... ...

RFC Example in Visual Basic
© SAP AG
Declare Function RfcOpenExt Lib "librfc.dll" ...
Declare Sub RfcClose Lib "librfc.dll" ......
hRfc = RfcOpenExt(destination, mode, host, sysnr, ...)
...
hSpace = RfcAllocParamSpace(3, 0, 1)
rc% = RfcAddExportString(hSpace, 0, "COMPANY", 7, 0, 4, MyCompany)
rc% = RfcAddExportString(hSpace, 1, "CUSTOMER", 8, 0, 10, MyCustomer)
rc% = RfcAddExportString(hSpace, 2, "YEAR", 4, 6, 4, MyYear)
thSales = ItCreate("SALES", 20 , 0, 0)
rc% = RfcAddTable(hSpace, 0, "SALES", 5, 0, 20, thSales)
RfcRc = RfcCallExt(hRfc, hSpace, "GET_SALES_BY_MONTH")
...
If RfcRc = 0 Then
RfcRc = RfcReceiveExt(hRfc, hSpace, xException)
End If
If RfcRc = 0 Then
MsgBox "Function Call Failed !"
RfcClose(hRfc)
End If
The above example shows RFC calls in a Visual Basic program fragment. Many details have been
omitted, including the access to the results of the function calls, but you the fragment does contain the
code for the following tasks:
Declaring RFC calls
Logging on to the R/3 System
Defining the parameters and calls
Error handling

Chapter 3 Summary
© SAP AG
l RFC allows you to implement program-to-program
communication between R/3 systems, R/2 systems, and
external systems. In SAP systems, you set up the connection
with ABAP/4. For external programs, you use the relevant
RFC libraries.
l There are several RFC variants (synchronous, asynchronous,
and transactional).
l In R/3, you maintain connection parameters in the table
RFCDES.
l From R/3, you can generate external RFC programs.

Exercise for Chapter 3
Report name: ZBCE##C1
Function group: ZE##
Function module: Z_BC415_##_...
Logical destination: BC415_##
##: Group number
Implement an RFC communication between two R/3 systems
to read data (airline carrier information) from a server system
and output it in the client system.
Proceed as follows:
1. Create a function group (see above) in a server system to be
specified by the instructor.
2. Program a function module assigned to this function group
(see above) and including the following functionality:
• Import parameter for the airline carrier
• Table parameter for selected records of table SCARR
• Exception for an invalid key evaluation
Use the following program fragment to allow generic
selection in table SCARR:
IF NE SPACE.
TRANSLATE USING '+_*%'.
ELSE.
= '%'.
ENDIF.
• Read the table SCARR and transfer the valid records to the
internal table.

3. Maintain a logical destination (see above) for an R/3-to-R/3
connection in the client system using Transaction SM59. The
target machine will be named by the instructor.
4. Write a report (see above) in the client system with the
following functionality:
• Parameter for airline carrier (generic entry possible)
Logical destination
Function module
• Call function module and pass relevant parameters
• Exception handling
• Output result data

Exercise 2 for Chapter 3
Report name: ZBCE##C2
Function module: TRAIN415_RFC_CALLTRANSACTION
Logical destination: BC415_##
##: group number
Realize a report to call function module
'TRAIN415_RFC_CALLTRANSACTION' using the transaction
created in the first exercise. The function module calls
transaction 'TFBA' to change customer data with modified
telephone numbers.
Proceed as follows:
1. Create the report (s.a.) in a R/3 system to be specified by the
instructor.
2. Use the customer number ( = group number), the telephone
number and the destination as report parameters.
3. Use the ‘A’ mode for the transaction to be called during the
function module call.
4. In the remote system, check which telephone data is
maintained for the customer with your group number. To do
so, use transaction TFBA in the remote R/3 System. Test your
report using another telephone number for the customer.

Exercise 3 for Chapter 3
Report name: ZBCE##C3
Function module: TRAIN415_RFC_CALLTRANSACTION
Logical destination: BC415_##
##: group number
Realize a report to call the above mentioned function module
which is to change customer data in your own system and in a
remote system using transactional RFCs.
Proceed as follows:
1. Copy the report ZBCE##C2 you have created in Exercise 2 to
report ZBCE##C3.
2. Modify the report in accordance with the description above,
that is, the function module is to be called in the own system
and in the remote system specifed by your own destination
using CALL FUNCTION ... IN BACKGROUND TASK. Use at
least the ‘N’ mode for the transactional RFC to execute
transaction TFBA in the background.
3. Use transaction SM58 to check scheduling and execution of
your function module call. If you can’t display any data, use
the explicit scheduling function module
START_OF_BACKGROUNDTASK in your program with a
later time.

Solution for Chapter 3
*&----------------------------------------------------------------
*
*& Report RS415031
*
*&
*
*&----------------------------------------------------------------
*
REPORT RS415031 .
PARAMETERS: CARRID LIKE SPFLI-CARRID,
DEST LIKE RFCDES-RFCDEST DEFAULT 'NONE',
RFC(30) DEFAULT 'TRAIN415_RFC_GET_CARRIER'.
DATA: CARRITAB LIKE SCARR OCCURS 0 WITH HEADER LINE,
MESS(80).
CALL FUNCTION RFC
CASE SY-SUBRC.
WHEN 1.
DESTINATION DEST
EXPORTING
TABLES
EXCEPTIONS
CARRID = CARRID
CARRIER = CARRITAB
NO_CARRIER_FOUND = 1
COMMUNICATION_FAILURE = 2 MESSAGE MESS
SYSTEM_FAILURE = 3 MESSAGE MESS.
WRITE: / 'You have selected an invalid carrier ID.'.
EXIT.
WHEN 2.
WRITE: / MESS.
EXIT.
WHEN 3.
WRITE: / MESS.
EXIT.

ENDCASE.
LOOP AT CARRITAB.
WRITE: / CARRITAB-CARRID,
ENDLOOP.
15 CARRITAB-CARRNAME,
40 CARRITAB-CURRCODE.
FUNCTION TRAIN415_RFC_GET_CARRIER.
*"----------------------------------------------------------------
-
*"*"Local interface:
*" IMPORTING
*" VALUE(CARRID) LIKE SCARR-CARRID DEFAULT SPACE
*" TABLES
*" CARRIER STRUCTURE SCARR
*" EXCEPTIONS
*" NO_CARRIER_FOUND
*"----------------------------------------------------------------
-
IF CARRID NE SPACE.
ELSE.
ENDIF.
TRANSLATE CARRID USING '+_*%'.
CARRID = '%'.
SELECT * FROM SCARR INTO TABLE CARRIER
IF SY-SUBRC NE 0.
WHERE CARRID LIKE CARRID.
MESSAGE E038 RAISING NO_CARRIER_FOUND.
* No data for this selection (New input please)
ENDIF.
ENDFUNCTION.

Solution 2 for Chapter 3
*&----------------------------------------------------------------
*
*& Report RS415032
*
*&
*
*&----------------------------------------------------------------
*
REPORT RS415032.
PARAMETERS: CUSTID LIKE SCUSTOM-ID,
PHONE LIKE SCUSTOM-TELEPHONE,
DEST LIKE RFCDES-RFCDEST DEFAULT 'NONE'.
DATA: CUSTITAB LIKE CUST415 OCCURS 0 WITH HEADER LINE,
TAMESS LIKE T100 OCCURS 0 WITH HEADER LINE,
SYS LIKE SY-SYSID,
MESS(80).
CUSTITAB-TELEPHONE = PHONE.
CUSTITAB-ID = CUSTID.
APPEND CUSTITAB.
CALL FUNCTION 'TRAIN415_RFC_CALLTRANSACTION'
DESTINATION DEST
EXPORTING
IMPORTING
TABLES
EXCEPTIONS
TAMODE = 'A'
SYSID = SYS
CUSTTAB = CUSTITAB
MESSTABLE = TAMESS
COMMUNICATION_FAILURE = 1 MESSAGE MESS
SYSTEM_FAILURE = 2 MESSAGE MESS.

CASE SY-SUBRC.
WHEN 1.
WRITE: / MESS.
EXIT.
WHEN 2.
WRITE: / MESS.
EXIT.
WHEN OTHERS.
LOOP AT TAMESS.
WRITE: / TAMESS.
ENDLOOP.
ENDCASE.

Solution 3 for Chapter 3
*&----------------------------------------------------------------
*
*& Report RS415033
*
*&
*
*&----------------------------------------------------------------
*
REPORT RS415033 .
PARAMETERS: CUSTID LIKE SCUSTOM-ID,
PHONE LIKE SCUSTOM-TELEPHONE,
DEST LIKE RFCDES-RFCDEST DEFAULT 'NONE',
TIME LIKE SY-UZEIT DEFAULT SY-UZEIT.
DATA: CUSTITAB LIKE CUST415 OCCURS 0 WITH HEADER LINE,
TAMESS LIKE T100 OCCURS 0 WITH HEADER LINE,
SYS LIKE SY-SYSID,
MESS(80).
CUSTITAB-TELEPHONE = PHONE.
CUSTITAB-ID = CUSTID.
APPEND CUSTITAB.
CALL FUNCTION 'TRAIN415_RFC_CALLTRANSACTION'
IN BACKGROUND TASK
DESTINATION DEST
EXPORTING
TABLES
TAMODE = 'N'
CUSTTAB = CUSTITAB.
CALL FUNCTION 'START_OF_BACKGROUNDTASK'
EXPORTING
EXCEPTIONS
STARTDATE = SY-DATUM
STARTTIME = TIME
OTHERS = 1.

IF SY-SUBRC 0.
ENDIF.
WRITE: / 'Error.'.
CALL FUNCTION 'TRAIN415_RFC_CALLTRANSACTION'
EXPORTING
TABLES
TAMODE = 'A'
IF SY-SUBRC 0.
EXIT.
ELSE.
COMMIT WORK.
ENDIF.
CUSTTAB = CUSTITAB.

Chapter 4 ABAP/4 Desktop Integration
Components
© SAP AG
l Introduction to desktop integration
l Basic principles of OLE 2.0
l Architecture of ABAP/4 desktop integration
components

Chapter 4 Objectives
© SAP AG
l Central terms and components in SAP desktop
integration.
l Basic techniques for handling SAP RFC objects in
the context of Object Linking and Embedding (OLE)
Automation.

Why Desktop Integration?
l Development of user-specific frontend applications.
l Development of solutions for communication with other
machines and integration with R/3 using Visual Basic or C.
l Analysis and processing of data with Excel within an R/3
transaction.
l Use of MS Word or Word Perfect as R/3 word processing
program.
© SAP AG
The integration of existing desktop programs is a decisive factor in the context of open interfaces to the
R/3 System.
Since the intention is to employ current programming languages to enable users to access data in R/3,
SAP supplies the RFC SDK (Software Development Kit) for frontend platforms.
If you want to access desktop documents or objects in desktop applications from R/3, Windows
frontends now allow you to make use of special desktop functionality such as OLE (Object Linking and
Embedding) for MS Windows environments which is within the scope of ABAP/4 in R/3.

SAP Desktop Integration: Tools
l Based on standards (TCP/IP, CPI-C, OLE 2.0).
l Similar handling in different operating systems (RFCs in
Windows 3.1, Windows NT, Windows95, Unix, OS/2).
l Allow developers to use their "own" programming language
(Visual Basic, C, C++).
l OLE objects and the RFC development environment conceal
the underlying complexity.
© SAP AG
For desktop integration purposes, you can use the complete RFC SDK (Software Development Kit) as
supplied for all other R/3 platforms (e.g. UNIX, Windows NT). The RFC SDK is imported explicitly to
frontends by the SAP installation program SAPSETUP.EXE which allows you to opt for "individual"
installation by selecting components of the SAP frontend programs to suit your own requirements. The
RFC SDK is included in the component "Desktop Development Kit".
In addition to the normal functionality of the RFC SDK, Windows frontends include the sub-directory
SAPSRV with OLE 2.0 Automation-specific implementations. These programs are covered in more
detail later.

Objects, Methods and Properties
© SAP AG
Core Core object object
Components
Sub-types
Behavior Behavior
Restrictions
Restrictions
Rules Rules
Properties
Methods Methods
Events
Interfaces
Objects, methods and properties are terms from the field of object-oriented programming. Before
concentrating in more detail on OLE-specific programming, these terms should be explained.
Objects have properties which characterize the objects. You can select and set these properties.
To perform special functions on the objects, you define methods (functions).
The objects themselves can be defined in object hierarchies where you can work with inherited properties
and methods.
In R/3, function modules are now presented as objects which R/3 makes available externally via the
object-oriented interface (OLE Automation). There is thus an RFC object hierarchy.

Component Architecture
© SAP AG
OLE OLE
Remote Function
Calls Calls
CPI-C
In a desktop environment, SAP components for integration with R/3 have a layered architecture.
The CPI-C foundation layer offers low-level program-to-program communication from the desktop with
an R/3 application server via TCP/IP. CPI-C itself is not available as an API for development on all
desktop platforms.
The RFC layer allows access to function modules from a wide range of platforms. Here, the underlying
CPI-C commands are concealed and transparent to the user.
OLE (Object Linking and Embedding) is an object layer which is located above the RFC interface in a
desktop environment. OLE 2.0-compatible applications can communicate with R/3 Release 3.0 via this
interface. SAP’s implementation of the OLE layer is based on RFC API commends.

Object Linking and Embedding (OLE)
What is OLE?
© SAP AG
n Object Linking and Embedding enables Windows applications
to make use of functions in an highly integrated manner.
n The Excel table below has been integrated into PowerPoint.
Expenses - Sales conference
Description Amount
Flight $1.200
Hotel $350
Entertainment $150
Meals $200
Overall total $1.900
Originally, OLE was supposed to stand for Object Linking or Embedding, since the term OLE embodies
two quite different processes.
Object Linking is very similar to DDE (Dynamic Data Exchange) which is a further development of a
intermediate file used by different programs to exchange data. For example, the OLE server program
selects data and copies it to the intermediate file, while the OLE client program can retrieve the data. The
retrieval can be performed in a number of different ways. The advantage of OLE over DDE is that the
OLE server program is also responsible for displaying the data, as shown above. Here, PowerPoint is the
OLE client program which has imported the table from the OLE server program Excel.
Object Embedding is more widespread than Object Linking. Here, an object is completely embedded in
an OLE client program. The data must then be managed by the OLE client program. The OLE server
program is called only if new objects are retrieved or exisiting objects are changed.
Object Automation represents a considerable enhancement of OLE 2.0. It allows OLE server programs
to access objects individually and OLE client programs to manipulate them using properties and
methods.

OLE 2.0 Components
Automation
Structured
Structured
storage
Data transfer
Notification
© SAP AG
Drag
and and drop drop
Component
object
model
Naming Naming and and
link tracking
Visual
editing
Compound
documents
OLE OLE 1.0 interoperability
interoperability
The OLE Automation functionality of OLE 2.0 has been implemented in R/3 Release 3.0. Other OLE
2.0 components have are not currently integrated into R/3.

OLE 2.0 Automation
l Allows an application to control the behavior of another
application in an object-oriented manner.
l OLE client
© SAP AG
n An application that can generate and control objects made
available by an OLE 2.0-compatible application (server).
l OLE server
n A server represents the objects, methods and properties of an
application to be used by another desktop application (client).
In a desktop environment, an OLE 2.0 application "registers" its own application objects that can be
generated and used by other applications. The registered objects each have specific methods and
properties. A method is a function used only for this object (e.g. in Excel, cells have the method Clear,
which deletes the contents of the cell). A property is an attribute of the object (e.g. if application has the
property Visible and its value is True, the application can be seen on the desktop).
OLE 2.0 Automation allows you to access objects and methods of another OLE 2.0-capable application
from an application program. The access is object-oriented.

R/3 and OLE 2.0 Automation
ABAP/4
SAP
objects
© SAP AG
Excel
objects
OLE Automation
Visual Visual Basic Basic / / Visual Visual C++ C++
OLE 2.0 Automation interface
Third-party
objects
Word
objects
Office components
Project
objects
This graphic illustrates the combinations between R/3 Release 3.0 and other OLE Automation-capable
applications. You can access the OLE objects of desktop applications and manipulate them from an
ABAP/4 program.
At the same time, you can also use desktop application programs to access R/3 OLE objects which are
made available on the desktop by a special SAP-specific program.
In subsequent sections, the bi-directional aspect of OLE Automation accesses is described in more detail.

OLE Client Architecture in R/3
© SAP AG
Application server Workstation
ABAP/4 program
Control
statements for
program-specific
objects
RFC RFC
SAPGUI
actual OLE
OLE2-capable
application
In the above example, the access is from ABAP/4 programs to OLE objects made available on the
desktop by application programs.
Special ABAP/4 OLE statements use the SAPGUI to make RFCs on the desktop side. The SAPGUI
software then executes OLE-specific calls from the desktop.
In this way, you can use an ABAP/4 program to control all desktop application objects made available
via an OLE 2.0 Automation server program (e.g. EXCEL, MS Word, ...).

OLE 2.0 Client Properties
l Facilitates the communication between application server
and frontend via the RFC interface.
l SpeciaI functions for OLE are implemented in the SAPGUI.
l Collected calls
© SAP AG
n When the ABAP/4 processor encounters the first non-OLE
statement, OLE 2.0 commands are sent to SAPGUI.
l Language independence
n The ABAP/4 processor uses the OLE object ID instead of the
text names for properties and methods.
Normally, all consecutive OLE statements are buffered by the ABAP/4 processor and sent to the
frontend together. Here, a statement may also refer to the results of preceding statements.
Even if the next command is not an OLE statement, developers can direct the collection to continue by
setting a series of properties in a loop. For this functionality, you must use the NO FLUSH option with
OLE calls.

OLE 2.0 Programming Tools
l Maintenance Transaction SOLE for all desktop applications
that can be controlled from ABAP/4.
l Automatic identification of desktop objects:
© SAP AG
R/3 report RSOLEINT (Transaction SOLI)
w reads the OLE object register on the desktop
w loads objects, methods and properties into R/3
l Object Browser:
R/3 report RSOLETI1 (Transaction SOLO)
w Browser for OLE objects, properties and methods
l Special OLE include for ABAP/4 programs
OLE2INCL
All applications controlled by ABAP/4 must be entered in the table TOLE which you maintain with the
Transaction SOLE. This table also indicates whether type information exists for a particular
application. Type information describes all the objects of an application, all its properties and methods,
as well as its parameters.
You can load type information into the R/3 System (table OLELOAD) with the Transaction SOLI. The
ABAP/4 processor can then perform the necessary type conversions and be language-independent of the
OLE application. For all OLE applications delivered as standard by SAP, the English version is supplied
in the OLELOAD.
In addition to runtime information in the table OLELOAD, you can also use the Transaction SOLI to
load other information such as documentation and WinHelp references. You can then access this
information in the SAP environment with the Object Browser (Transaction SOLO).
For programming in the OLE environment, you must use the OLE-specific include OLE2INCL.

ABAP/4 Statements for OLE 2.0
Five new ABAP/4 statements:
© SAP AG
DATA: object TYPE OLE2_OBJECT.
w CREATE OBJECT object class
w GET PROPERTY OF object property = field
w SET PROPERTY OF object property = field
w CALL METHOD OF object method
§ EXPORTING prop1 = field1 ... propN = fieldN
w FREE OBJECT object
You must first define the object with the above DATA statement.
CREATE OBJECT checks the existence of the object and generates an OBJECT_HANDLE. To be able
to address an OLE Automation server from ABAP/4, the server must be registered as a class in the R/3
System.
GET PROPERTY allows you to copy the property property to the field field.
SET PROPERTY sets the property property with the contents of the field field.
You use CALL METHOD to call the method method (either a literal or a variable) of the object object.
With EXPORTING, you pass the field values to the parameters of the method.
FREE OBJECT releases the resources at the frontend.
For more detailed documentation about the above key words, refer to the ABAP/4 online help.

Programming Example in ABAP/4
l Example transaction in R/3: OLE
l
© SAP AG
INCLUDE OLE2INCL.
DATA: EXCEL TYPE OLE2_OBJECT.
DATA: BOOKS TYPE OLE2_OBJECT.
DATA: CELL TYPE OLE2_OBJECT.
DATA: FILENAME(50) = 'C:\TEMP\OLE1.XLS'.
DATA: VALUE(10).
CREATE OBJECT EXCEL 'EXCEL.APPLICATION'.
SET PROPERTY OF EXCEL 'VISIBLE' = 1.
CALL METHOD OF EXCEL 'WORKBOOKS' = BOOKS.
CALL METHOD OF BOOKS 'OPEN' EXPORTING #1 = FILENAME #2 = 1.
GET PROPERTY OF EXCEL 'ACTIVECELL' = CELL.
GET PROPERTY OF CELL 'VALUE' = VALUE.
WRITE: / 'Value:', VALUE.
CALL METHOD OF EXCEL 'QUIT'.
FREE OBJECT CELL.
FREE OBJECT BOOKS.
FREE OBJECT EXCEL.
The Transaction OLE is an example of OLE client functionality of ABAP/4 in the R/3 System. It allows
you direct access to the desktop applications MS Word, Excel and Visio.
Usage example for Excel:
The "Start" button generates the Excel application object and activates the application window.
There should be an Excel file on your PC. Please enter the complete path of this file in the document
area.
The "Edit File" button opens the specified file for processing in the Excel application object. At the
same time, it generates a spreadsheet object and activates the menu bars and the tools of the desktop
application.
The "Get Cell" button copies the contents of the active call in Excel to the field in the SAP data area.
You can then change this value and write it back to the active cell in Excel with "Transfer".
The "Release" button releases the OLE object
If you change the Excel sheet with "Transfer", Excel notes this and displays another dialog box for you
to confirm whether you want to save the modified file.
The example report RS41504A implements the above ABAP/4 code.

OLE Server Architecture in R/3
Desktop workstation
© SAP AG
MS Excel
MS Access
OLE
Automation
client
O
L
E
2.0
Permanent
RFC objects
RFC
Automation
server
RFC RFC API API
R/3
System
To enable you to access them, OLE objects in the R/3 System are made available to other OLE 2.0 client
applications by the RFC Automation server program (AMRFCSRV.EXE).
The Automation server objects have been implemented as a layer via the RFC API function library. The
RFC Automation server converts the OLE calls to RFC API calls.
The R/3 SAPGUI software does not have to be installed on the frontend for a desktop user to be able to
use the Automation server objects. The only requirements are installation of the RFC SDK (Software
Development Kit) on the desktop and a Winsocket-compatible network interface for this functionality.

Automation Server
The Automation server has two service levels:
© SAP AG
n A local server for client applications that access SAP functions
n The Automation Assistant (a graphical tool that allows the user
to execute functions and transactions online).
SAP Automation Assistant
Function Import Export Table
Output log
The Automation Assistant is frontend application for Automation server objects that runs under (16 bit)
Windows.
This tool allows developers to retrieve information about the function module interface of the R/3
application server and execute the function. It is also possible to display transactions in the R/3 System
with their screens and fields.
You can use an OLE application to make the windows of the Automation Assistant visible by setting the
property "RFC.Application.Visible" to "True". In this case, the property "
RFC.Application.Server.Visible" must also be set to "True".

RFC Object Hierarchy
Exports
collection
© SAP AG
Imports
collection
Parameter
Application
Server
Function
Rows
collection
Server objects
collection
Function
collection
Structure Table
Row
Connection
Tables
collection
The above RFC object hierarchy represents the objects for OLE client programs available through the
Automation server.
When accessing these objects, programmers must observe the following sequence of steps:
Create the server object and set up the connection (connection object).
Create at least one function object for the server object.
Assign a value to the export parameter object.
Call the method function of the server object.
Use the import parameter objects to call the result of executing the function module.
Close the connection and release all objects.
The properties and methods for the individual objects are described in the online help. There now follow
some examples of programming with these objects, properties and methods.

Creating an RFC Server Object
Application
Server collection
© SAP AG
Server
Application
Server collection
Server
With "server object"
Set RFCServer = CreateObject ("RFC.ServerObject")
OR
With "application object" and the method Add
Set RFCApp = CreateObject("RFC.Application")
Set RFCObjs = RFCApp.ServerObjects
Set RFCServer = RFCObjs.Add("Server1")
To work with other objects in the RFC object hierarchy apart from the application object, you must
generate a server object.
To generate a server object, there are two options.
1. When using CreateObject("RFC.ServerObject"), the following steps are executed automatically:
a. An application object is created.
b. An entry for a new server object is added to the server collection object.
c. A server object is created.
2. When using CreateObject("RFC.Application"), the following steps are executed:
a. An application object is created.
When using RFCObjs.Add to create a server object, the following steps are executed:
a. An entry for a new server object is added to the server collection object.
b. A server object is created.

Setting Up a Connection to R/3
Logon using the method "Logon"
Set RFCConnection = RFCServer.Connection
If RFCConnection.Logon True Then
RFCServer.Application.Quit
Exit
End If
Logon using the method "Open"
RFCConnection.User= User1”
RFCConnection.System= D22”
...
RFCConnection.Open
© SAP AG
ODER
Application
Server collection
Server
Connection
To call a function module in R/3, you must set up a connection to an R/3 application server. Only one
connection is possible for each server object. There are two ways of setting up a connection:
“Logon” method:
You should use this method if the user has to enter most of the connection information. Since it
automatically displays a dialog field for entry of the logon information, you then do not need to code
this.
“Open” method:
You should use this method if you can set all the connection information in the program, since no
dialog field is automatically displayed in this case. The “Open” method works only if all the logon
information is predefined.

Calling an R/3 Function (1)
With an R/3 function module as
"dynamic" method of the server object
RESULT = RFCServer.R3FunctionName(
EXCEPTIONSTR,
PARAM1:= LocParam1,
PARAM2:= LocParam2,
PARAM3:= LocParam3)
l Import and export parameters assigned
as "specified arguments"
l OLE client application MUST support
conventions for specified arguments
l Syntax for VB for application code
© SAP AG
Function collection
Imports coll.
Application
Server collection
Server
Function
Parameter
Exports coll.
When observing the conventions governing specified arguments for calling a function module (dynamic
function object of the server), the exception string must be the first parameter in the command line.
The Automation server automatically creates a function object as well as import and export objects.
The import parameters for the function call are assigned automatically from the local parameters defined
in the command line.

Calling an R/3 Function (2.1)
Create function object that represents the
R/3 function module
Set RFCFunction =
RFCServer.Functions.Add(“R3FunctionName )
l Adds the function object to the
function collection
l OLE client application does not need
to support specified arguments
l Syntax for Visual Basic code
© SAP AG
Function collection
Imports coll.
Application
Server collection
Server
Function
Parameter
Exports coll.
For Visual Basic, programming via 'Names Arguments' is not possible. For this reason, each function
module called must be added as a function object to the function collection object with the method
“Add”.

Calling an R/3 Function (2.2)
Define values for export objects and use
"Call" method for function object
Set FunctionExports = RFCFunction.Exports
FunctionExports.Item( PARAM1 ) = LocParam1
FunctionExports.Item( PARAM2 ) = LocParam2
Result = RFCFunction.Call
Set local variable to import object to get result
of function call
Set LocParam3 = FunctionImports.Item("PARAM3")
© SAP AG
Function collection
Imports coll.
Application
Server collection
Server
Function
Parameter
Exports coll.
Before calling the function module with the method “Call”, you must also set the export parameters
using the exports collection object.
To get the import parameters after the function call, you must assign the local variable to the object item
of the import collection. This is different from dynamic retrieval where the import parameters of the local
variables are assigned automatically.

Working with Tables: Results (1)
Working with the table resulting from a function call
Access table object with Tables Collection
Set TablesColl = RFCFunction.Tables
Set TableObj = TablesColl.Item(“R3TableName )
Access table data with Rows Collection
For Each TableRow In TableObj.Rows
Cells(RowIndex, 1) = TableRow(“R3ColName1 )
Cells(RowIndex, 2) = TableRow(“R3ColName2 )
....
RowIndex=RowIndex+1
Next
© SAP AG
Function
Tables coll.
Table
Rows coll.
Row
When using a function call with specified arguments (where the function object is a dynamic method of
the server object), it is not necessary to retrieve the table object with the table collection because the
variable TableObj is automatically assigned to the table object.
The syntax used for navigation in the rows collection is specific to VBA (Visual Basic for Applications).
The construction "For Each" is not supported by Visual Basic 3.0. Programmers using Visual Basic
must access the table entries with the code specified in the next graphic.

Working with Tables: Results (2)
Working with the table resulting from a function call:
Access table data with table object "Cell"
For x = 1 to TableObj.RowCount
Cells(RowIndex, 1) = TableObj.Cell(x, R3ColName1 )
Cells(RowIndex, 2) = TableObj.Cell(x, R3ColName2 )
....
Next x
With multiple calls to a function, reset the contents with
the method "FreeTable"
TableObj.Freetable
© SAP AG
The above syntax applies for accessing table object cells with Visual Basic 3.0.
There are two other methods for working with data of a table object: UnloadTable and SetTable.
UnloadTable unloads the contents of a server table objects into a local variable, since the data changes
each time the function is called.
SetTable allows you transfer the data from a local table to a server table object.

Working with Tables: Entry (1)
Creating a table object for entry in a function call
Using a function as a dynamic method of the server object
© SAP AG
Set TableObj = RFCServer.CreateTable(“R3Tabellenname )
For x = 1 to NumRows
TableRow= TableObj.AppendRow
TableRow( R3TableField1 )= ....”
TableRow( R3TableField2 )= ...”
Next x
RESULT = RFCServer.R3FunctionName(
EXCEPTIONSTR,
PARAM1:= LocParam1,
R3TABLENAME:=TableObj,
PARAM3:= LocParam3)

Working with Tables: Entry (2)
Creating a table object for entry in a function call
Using a function that was explicitly added to the collection
Set RFCFunction = RFCServer.Functions.Add(“R3FunctionName )
Set TablesColl = RFCFunction.Tables
Set TableObj = TablesColl.Item(“R3TableName )
For x = 1 to NumRows
TableRow= TableObj.AppendRow
TableObj.Cell(x, R3TableField1 )= ...”
TableObj.Cell(x, R3TableField2 )= ..”
Next x
...
RFCFunction.Call
© SAP AG

Exercise for Chapter 4
Report name: ZBCE##D1
Main report: RS415047
##: Group number
Implement an OLE link between R/3 (OLE client) and your PC
application Excel (OLE server). The report should download
flight customer data to Excel and present it in an Excel sheet.
Proceed as follows:
1. Use the Transaction 'SOLI' to view the OLE-related objects in
your R/3 System.
2. Copy the main report RS415047 to your report ZBCE28#D1.
In your program, comment mark the locations where you have
to insert the OLE-specific ABAP/4 key words.
3. Execute the modified report. At the end, it will be necessary to
make an active switch from R/3 to the Excel application.
4. Then, you can return to the first R/3 System and test the
connection to both your programs with the CPI-C destination
you have specified.

Solution for Chapter 4
*&---------------------------------------------------------------------*
*& Report RS415041 *
*& *
*&---------------------------------------------------------------------*
REPORT RS4155041.
PARAMETERS: DISCOUNT(3) TYPE N.
*
* OLE-specific include file
*
INCLUDE OLE2INCL.
*
* Data definitions of OLE objects with type ole2_object
*
DATA: EXCEL TYPE OLE2_OBJECT.
DATA: BOOKS TYPE OLE2_OBJECT.
DATA: BOOK TYPE OLE2_OBJECT.
DATA: CELL TYPE OLE2_OBJECT.
*
* Definition of loop counter
*
DATA: I TYPE I VALUE '5'.
*
* Internal table CUSTOMER with structure of SCUSTOM table
*
DATA: BEGIN OF CUSTOMER OCCURS 0.
INCLUDE STRUCTURE SCUSTOM.
DATA: END OF CUSTOMER.
*
* Call function with program parameter DISCOUNT
* All customers with discount rates greater than or equal to discount
* are returned to the internal table CUSTOMER
*
CALL FUNCTION 'TRAIN415_RFC_NORMAL_WITHITAB'
EXPORTING
IDISC = DISCOUNT
TABLES
CUSTOM = CUSTOMER
EXCEPTIONS
INVALID_DISCOUNT = 1.
IF SY-SUBRC 0.
WRITE: / TEXT-005 .
EXIT.
ENDIF.
*
* Create object EXCEL of OLE class 'EXCEL.APPLICATION'
*
CREATE OBJECT EXCEL 'EXCEL.APPLICATION'.
CALL METHOD OF EXCEL 'WORKBOOKS' = BOOKS.
CALL METHOD OF BOOKS 'ADD' = BOOK.
*

* Fill line in EXCEL sheet with header lines of table columns
*
PERFORM FILL_CELL USING 2 1 'ID'.
PERFORM FILL_CELL USING 2 2 'Name'.
PERFORM FILL_CELL USING 2 3 'Telephone'.
PERFORM FILL_CELL USING 2 4 'Discount'.
*
* Loop at customr table and print values in EXCEL sheet
*
LOOP AT CUSTOMER.
PERFORM FILL_CELL USING I 1 CUSTOMER-ID.
PERFORM FILL_CELL USING I 2 CUSTOMER-NAME.
PERFORM FILL_CELL USING I 3 CUSTOMER-TELEPHONE.
PERFORM FILL_CELL USING I 4 CUSTOMER-DISCOUNT.
I = I + 1.
ENDLOOP.
*
* Make the EXCEL sheet visible on the desktop
*
SET PROPERTY OF EXCEL 'VISIBLE' = 1.
WRITE: / TEXT-006 .
*
* Now leave the EXCEL application
* Note: You must go to the EXCEL application and respond to
* the dialog box
*
AT LINE-SELECTION.
CALL METHOD OF EXCEL 'QUIT'.
*
* Release all OLE objects
*
FREE OBJECT CELL.
FREE OBJECT EXCEL.
FREE OBJECT BOOKS.
*
* FORM routine which fills the specified cell in the EXCEL sheet
* with the given value
*
FORM FILL_CELL USING I J VAL.
CALL METHOD OF EXCEL 'CELLS' = CELL EXPORTING #1 = I #2 = J.
SET PROPERTY OF CELL 'VALUE' = VAL.
ENDFORM.

Chapter 5 CPI-C Interface
© SAP AG
l Overview
l Basic functionality in the starter set
l Additional functionality
l Development environment

Chapter 5 Objectives
© SAP AG
l The CPI-C interface and the individual CPI-C calls.
l Basic for programming CPI-C in ABAP/4 and in C.

CPI-C Implementation
R/2
ABAP/4
© SAP AG
CPI-C implementation by SAP:
R/3
ABAP/4
External
CPI-C libraries
(SAP)
- R/3 ABAP/4 interface
- R/2 ABAP/4 interface
- External systems CPI-C libraries
cpictlib TCP/IP protocol
cpicslib LU6.2 protocol, APPC
For the currently supported platforms, see the document
"SAP Supported Network Products".
CPI-C implementation according to X/OPEN Standard
External
CPI-C libraries
(external)
e.g. CPI-C implementation by IBM according to SAA (System Application Architecture), UPIC by SNI
(Universal Programming Interface for Communication), etc.

General Flow
System 1 System 2
© SAP AG
Initialize Initialize connection
connection
Set Set up up connection
connection
Send Send data data
Receive Receive data data
Send Send data
data
Close Close connection
connection
Side Side info
info
table table
(Client)
Program 1 (Server)
Program 2
Accept Accept connection
connection
Receive Receive data data
Send Send data
data
Receive Receive data data
Close Close connection
connection
With program-to-program communication, the general flow is the same regardless of the programming
language used. The following rules apply:
- With half duplex communication, only one program is authorized to send data at any one time. When one
program is in send mode, the other is in receive mode.
- The program setting up the communication always has the right to send data first.
- The other (started) program is in receive mode first.
- Switching the direction of the communication is achieved by setting off CMRCV in send mode. Then, the
partner program can send data.
- Mutiple communication switching is possible.
One program sets up the connection ( = client); a partner program accepts the connection ( = Server).
In the communication initiator system, a side information table must exist. This table is needed for the
connection initialization.

SAP Side Information Tables
R/2: XCOM
R/3: TXCOM
UNIX
NT
Windows
OS/2
© SAP AG
XCOM
Dest Dest LU LU TP TP ...
...
ABC ABC LU1 LU1 CP1C2
CP1C2
XCOM
Dest LU TP Prot ...
ABC LU2 CPIC2 E
sideinfo
Dest Dest = = C11 C11
GWHOST GWHOST = = is0001
is0001
GWSERV GWSERV = = sapgw00 sapgw00
LU LU = = hw5001
hw5001
TP TP = = sapgw00 sapgw00
Protocol Protocol = = I
I
Each system from which you set up a CPI-C communication requires a side information table. Side
information tables can be compared to telephone directories.
This table contains entries with parameters required for communication purposes. The three most
important of these are:
Symbolic destination:
The program setting up a connection uses a symbolic destination which must exist in the side
information table. A symbolic destination can be compared with a name in a telephone directory.
Partner LU:
The partner LU (logical unit) specifies where the communication partner is to be found. It can be
compared with an address in a telephone directory.
Partner program:
The partner program is the program which is started in the partner system or the program to which the
connection is made. It can be compared with the telephone number of the partner.
Side information tables have different names in different systems:
- In R/2, the table is XCOM (maintained with Transaction TM31).
- In R/3, the table is TXCOM (maintained with Transaction SM54 or SM31)
- In external systems, the table is always called sideinfo. Under UNIX, you can maintain sideinfo with

the
editor program “vi”

Available CPI-C Functionality
ABAP/4 ABAP/4
Function libraries ( SAP )
CPI-C starter set calls CPI-C starter set calls
© SAP AG
CPI-C advanced function calls (subset)
CPI-C SAP-specific functions
The CPI-C starter set is implemented in ABAP/4 (key word COMMUNICATION).
SAP provides a number of functions for developing external CPI-C programs (also known as remote
CPI-C) on SAP-supported platforms.
These functions can be divided into three groups:
CPI-C starter set calls:
This group contains CPI-C starter set calls.
CPI-C advanced function calls:
This group contains a subset of the X/Open advanced function calls.
CPI-C SAP-specific calls:
This group contains SAP-specific functions which are either needed for communication with R/2 or R/3,
or which are optional.

CPI-C Calls in ABAP/4
© SAP AG
COMMUNICATION INIT ...
COMMUNICATION ALLOCATE ...
COMMUNICATION ACCEPT ...
COMMUNICATION SEND ...
COMMUNICATION RECEIVE ...
COMMUNICATION DEALLOCATE ...
The CPI-C starter set has been implemented in ABAP/4 with the key word COMMUNICATION and
its six variants.
For all variants, you can find the return code value of the operation either in the system field SY-
SUBRC or in the optional parameter RETURNCODE (R/2, from Rel. 5.0).

CPI-C Functions for C Programs
CPI-C starter set calls CMINIT Initialize connection
CMALLC Set up connection
CMACCP Accept connection
CMRCV Receive data
CMSEND Send data
CMDEAL Close connection
CPI-C advanced function calls CMSPLN
(subset) CMSTPN
...
CPI-C SAP-specific functions SAP_CMINIT
SAP_CMLOGON
...
© SAP AG
The CPI-C starter set and other CPI-C function calls (advanced function calls (subset) and SAP-specific
functions) are available to the programming language C for external platforms (see the document "SAP
Supported Network Products").
The CPI-C starter set consists of the following calls:
CMINIT Initialize_Conversation Define communication parameters
CMALLC Allocate_Conversation Set up conversation
CMACCP Accept_Conversation Accept conversation
CMSEND Send Send data
CMRCV Receive Receive data
CMDEAL Deallocate_Conversation Close conversation

Standard Includes (Data Definitions)
ABAP/4 C
REPORT XYZ. XYZ.
... ...
INCLUDE RSCPICDF.
INCLUDE RSEBCASC.
... ...
© SAP AG
...
#include
oder
#include "{pathname}/cpic.h"
For CPI-C programs, both ABAP/4 and C contain includes (reports or files) with data definitions on the
one hand and conversion tables on the other.
ABAP/4:
RSCPICDF: This report performs all CPI-C definitions as specified by IBM or X/Open. It defines, for
example, the different return codes.
RSEBCASC: This include program contains both the conversion tables for converting EBCDIC to
ASCII
and vice-versa.
C program:
Here, you have to include the header file cpic.h. You can specify the file name explicitly or the file must
exist in the central include directory. In this file, all constants, structures and function prototypes are
declared.
For the data conversion, you can use the file convert.txt. The explicit path to this file is declared via the
environment variable CONVERT.
...

Initializing Connections (INIT)
ABAP/4 C
... ...
COMMUNICATION INIT INIT
DESTINATION dest dest
ID ID convid convid
[ [ RETURNCODE rc rc ] ]
... ...
© SAP AG
...
CMINIT (
convid,
dest,
&rc );
...
The program setting up the CPI-C connection must first execute an INIT call. This uses a symbolic
address to access the side information file (which contains the connection and communication
parameters).
symbolic_dest: Symbolic name (entry in the side information table)
conversation_id: This value is returned by the routine and must be specified in all subsequent CPI-
C calls
for this connection.
return_code: Error code: (0 (CM_OK) --> routine executed without error).
The variables are defined in the include RSCPICDF for ABAP/4, and in the file "cpic.h" for C.
ABAP/4: DEST C 8 C: dest PCPIC_CHAR
CONVID C 8 convid PCONVERSATION_ID
RC X 2 rc CM_RETCODE
(Examples: ABAP/4: --> DATA: DEST(8) TYPE C.
C: --> PCPIC_CHAR dest = (PCPIC_CHAR)0;)
For C data types, you should note the following:
& --> is an address operator and returns a pointer to an object
* --> is a reference operator and returns the address of an object
Legend: Italics --> denote a variable
Underlined characters --> input variable which must be specified during the call
[ ... ] --> optional specification

Setting Up Connections Actively (ALLOCATE)
ABAP/4 C
... ...
COMMUNICATION
ALLOCATE
ID ID convid convid
[ [ RETURNCODE rc rc ] ]
... ...
© SAP AG
The connection is set up physically to a partner program.
...
CMALLC (
convid,
&rc );
convid: The value returned by INIT must be specified here.
You must assign appropriate types and lengths to variables:
ABAP/4: CONVID C 8
RC X 2
C: convid PCONVERSATION_ID
rc CM_RETCODE
If CMALLC is executed without error, the program for this connection will be in SEND mode.
...

Accepting Connections Passively (ACCEPT)
ABAP/4 C
...
COMMUNICATION ACCEPT
ID convid
[ RETURNCODE rc ]
...
© SAP AG
...
CMACCP (
convid,
&rc );
A passive program must accept the connection before data can be exchanged.
You should assign appropriate types and lengths to variables:
ABAP/4: CONVID C 8
RC X 2
C: convid PCONVERSATION_ID
rc CM_RETCODE
If the ACCEPT is executed without error, the program for this connection will be in RECEIVE mode.
conversation_id: This value is returned by the routine and must be specified in all subsequent CPI-
C calls
for this connection.
return_code: = 0 (CM_OK): Routine executed without error
= error code: An error has occurred
...

Sending Data (SEND)
ABAP/4 C
...
COMMUNICATION SEND
ID convid
BUFFER output
[ LENGTH send_length ]
[ RETURNCODE rc ]
...
© SAP AG
...
CMSEND (
convid,
output,
&send_length,
&request_to_send_received,
&rc );
With the SEND command, you can send data packets of up to 30,000 bytes.
All the data in the buffer output is sent to the receiving program. However, it is not actually transferred
until the buffer is full or after the next RECEIVE or DEALLOCATE.
If a particular length send_length is specified, the appropriate number of bytes is transferred from the
buffer output to the receiving program.
A SEND is allowed only within the send status.
You must assign appropriate types and lengths to variables:
ABAP/4: CONVID C 8
OUTPUT C
SEND_LENGTH P max. 30,000
RC X 2
C: convid PCONVERSATION_ID
output PCPIC_CHAR max. 30,000
send_length CPIC_INT
request_to_send_received REQUEST_TO_SEND_RECEIVED
(not evaluated)
rc CM_RETCODE
...

Receiving Data (RECEIVE)
ABAP/4 C
l ...
COMMUNICATION RECEIVE
ID convid
BUFFER input
[ LENGTH req_length ]
[ RECEIVED rec_length ]
DATAINFO datainfo
STATUSINFO statusinfo
[ HOLD ]
[ RETURNCODE rc ]
...
© SAP AG
...
CMRCV (
convid,
input,
&requested_length,
&received_length,
&data_info,
&status_info,
&request_to_send_received,
&rc );
Data is received in the buffer input in accordance with the buffer length. After the call, rec_length
contains the number of bytes placed in the buffer. The DATAINFO and STATUSINFO fields contain
information about the call.
If a RECEIVE occurs in send mode, the right to send is transferred to the receiving program, together
with any existing user data in the network buffer. The sending program then assumes RECEIVE mode.
You must assign appropriate types and lengths to variables:
ABAP/4: C:
CONVID C 8 convid
PCONVERSATION_ID
INPUT C max. 30,000 input PCPIC_CHAR
DATAINFO X 4 data_info PDATA_RECEIVED
STATUSINFO X 4 status_info PSTATUS_RECEIVED
REQ_LENGTH P requested_length CPIC_INT (max.
30,000)
REC_LENGTH X 4 received_length CPIC_INT
RC X 2 rc CM_RETCODE
request_to_send_received
PREQUEST_TO_SEND_RECEIVED
If the HOLD parameter is set, the current work process is kept (no roll-out, roll-in).
...

Status and Data Information in RECEIVE
* Status information
ABAP/4: Include report RSCPICDF
DATA: INT4(4) TYPE X.
...
DATA:
CM_NO_STATUS_RECEIVED LIKE INT4 VALUE '00000000',
CM_SEND_RECEIVED LIKE INT4 VALUE '00000001',
* Data information
CM_NO_DATA_RECEIVED LIKE INT4 VALUE '00000000',
CM_COMPLETE_DATA_RECEIVED ... VALUE '00000002',
...
typedef typedef int int STATUS_RECEIVED;
STATUS_RECEIVED;
... ...
# status_info
#define #define CM_NO_STATUS_RECEIVED CM_NO_STATUS_RECEIVED 00
#define #define CM_SEND_RECEIVED 11
# data_info
typedef typedef int int STATUS_RECEIVED;
STATUS_RECEIVED;
... ...
#define #define CM_NO_DATA_RECEIVED 00
#define #define CM_COMPLETE_DATA_RECEIVED 22
© SAP AG
C: Header file cpic.h
The status information is used to switch the send direction. The values have the following meanings:
- CM_NO_STATUS_RECEIVED --> Send direction not switched
- CM_SEND_RECEIVED --> Connection partner surrenders send rights
If the status information is set to CM_SEND_RECEIVED, the current program has the status SEND.
The data information returns details about the flow control. The different statuses are as follows:
- CM_NO_DATA_RECEIVED --> No data received
- CM_COMPLETE_DATA_RECEIVED --> All data received
- CM_INCOMPLETE_DATA_RECEIVED --> Not all available data received

Closing Connections (DEALLOCATE)
ABAP/4 C
...
COMMUNICATION DEALLOCATE
ID convid
[ RETURNCODE rc ]
...
© SAP AG
...
CMDEAL (
convid,
&rc );
This call closes the CPI-C connection. If there is still data in the buffer, it is transferred before the
connection is closed. The local system resources are then released.
Only the sending program should close the connection.
You should assign appropriate types and lengths to variables:
ABAP/4: C:
CONVID C 8 convid PCONVERSATION_ID
RC X 2 rc CM_RETCODE
...

CPI-C Return Codes
ABAP/4: Include report RSCPICDF
DATA: INT2(2) TYPE X.
...
* return code
DATA: CM_OK LIKE INT2 VALUE '0000'.
...
DATA: CM_DEALLOCATED_NORMAL LIKE INT2 VALUE '0012',
DATA: CM_PARAMETER_ERROR LIKE INT2 VALUE '0013',
...
typedef typedef int int CM_RETCODE;
CM_RETCODE;
... ...
# returncode
#define #define CM_OK CM_OK 00
... ...
#define #define CM_DEALLOCATED_NORMAL CM_DEALLOCATED_NORMAL 18 18
#define #define CM_PARAMETER_ERROR 19 19
... ...
© SAP AG
C: Header file cpic.h
Return codes provide information about the outcome of calls. You use the returned values to aid general
progran flow control and error handling in the event of communication terminations.
In ABAP/4, the return code value is copied to the system field SY-SUBRC.
The return codes are defined in the include report RSCPICDF.
The return code is 2 bytes long and has the type X.

CPI-C Advanced Function Calls
© SAP AG
CMSPLN() Sets the partner LU
CMSTPN() Sets the partner transaction program
CMCNVO() Data conversion from ASCII to EBCDIC
CMCNVI() Data conversion from EBCDIC to ASCII
CMFLUS() Immediate transfer of network buffer data
to the partner program
...
CPI-C advanced function calls:
This group contains a subset of the X/Open advanced function calls. SAP provides a subset of the
X/Open CPI-C advanced function calls for external programs.
You use CMSPLN (Set_Partner_LU_Name) and CMSTPN (Set_Transaction_Program_Name) to set
the partner LU and partner transaction programs. CMSPLN and CMSTPN only make sense after a
CMINIT and before a CMALLC, i.e. only in programs which set up a connection. Then, you can
overlay the contents of the side information file.
CMCNVO (Convert_Outgoing) and CMCNVI (Convert_Incoming) are the function calls for
converting data from EBCDIC to ASCII and vice-versa.
CMFLUS (Flush) immediately transfers network buffer data to the partner program.

CPI-C SAP-specific Functions
SAP_CMINIT() Specifies SAP gateway (active program)
SAP_CMACCP() Specifies SAP gateway (passive program)
SAP_CMLOGON() Connect string for logon to R/2 or R/3
SAP_CMCERR() Error handling
SAP_CMPERR()
SAP_CMLOADCONVTAB() Data conversion
SAP_CMMODCONVTAB()
...
© SAP AG
SAP-specific CPI-C functions are partly required for communication with SAP R/2 or R/3. Optional
SAP-specific CPI-C functions simplify the development of remote CPI-C programs.
SAP_CMINIT (optional) and SAP_CMACCP(required in a passive program) inform the program
which gateway handler is being used (gateway host, gateway service, protocol type), but these details are
generally available in the relevant side information. SAP_CMINIT only makes sense before a CMINIT.
Accordingly, the partner program must then contain a SAP_CMACCP before the CMACCP in order to
receive the communication parameters.
SAP_CMLOGON (optional) creates the connect string necessary for logging on to an R/2 or R/3
System.
SAP_CMCERR (optional) checks whether the data received by the R/2 or R/3 System is an error
message.
In the case of an error, SAP_CMPERR (optional) returns a short explanation of the error.
You can use SAP_CMLOADCONVTAB (optional) to load a special conversion table.
SAP_CMMODCONVTAB (optional) modifies an area of the current conversion table.

Communication with an ABAP/4 Program
R/3
© SAP AG
R/2
Communication program
External
system
R/2
SAP Basis System
Communication program
ABAP/4 (FORM routine)
An ABAP/4 program is interpreted by a language processor embedded in the SAP Basis System.
This architecture first requires a connection to be set up with the SAP Basis System:
R/2: X1SA R/3: sapgwxx
You must make an appropriate entry in the side information table of the system setting up the
communication.
R/3

ABAP/4 Program as Server
© SAP AG
REPORT RSCPICSV.
...
FORM FORM1.
...
COMMUNICATION ACCEPT
...
COMMUNICATION RECEIVE
...
ENDFORM.
In an ABAP/4 server program, the communication is made in a subroutine (FORM).
The FORM routine executes an ACCEPT call and then has the status allowing it to receive data.
The FORM routine can set up further communications as required.
An ABAP/4 program can contain several subroutines for communication purposes and then call them in
various sequences.

Data Conversion
© SAP AG
R/3
UNIX
ASCII
R/2
EBCDIC
MVS
VSE
BS2000
Data conversion is required between systems using the ASCII character set and those using EBCDIC,
unless the partner system is being used purely for data archiving purposes.

Conversion Commands
© SAP AG
ABAP/4:
C:
TRANSLATE field USING ASC_TO_EBC.
TRANSLATE field USING EBC_TO_ASC.
TRANSLATE field FROM CODE PAGE abc
TO CODE PAGE xyz.
CMCNVO ( output, &send_length, &rc );
CMCNVI ( input, &received_length, &rc);
SAP_CMLOADCONVTAB()
SAP_CMMODCONVTAB()
If an EBCDIC host system is attempting to communicate with an R/3 ASCII machine, the data must be
converted, but it is not important whether the sending program or the receiving program performs the
conversion.
You can use include programs (RSEBCASC in ABAP/4, cpic.h in C) to convert data. It is even possible
to convert between code pages. You must maintain the relevant code page in the SAP system. In R/3,
you do this with the Transaction SPAD.
CMCNVO() converts from ASCII to EBCDIC.
CMCNVI() converts from EBCDIC to ASCII.
For the C functions SAP_CMLOADCONVTAB() and SAP_CMMODCONVTAB(), you use a special
conversion table in the file convert.txt (for the precise syntax, see the online manual BC
Communication: Programming).

Logon String for the SAP System
l ABAP/4:
© SAP AG
w Database structure
CPICCONN
Field Length
REQID 4
REQTYPE 4
AMODE 1
IMODE 1
FILL1 2
MAND 3
NAME 12
CODE 8
LANG 1
KORR 1
PROG 8
MODN 30
l C:
w SAP_CMLOGON (
output,
&send_length,
reqid,
reqtype,
amode,
client,
usr,
pwd,
language,
prog,
form,
&rc
);
In an ABAP/4 (client) program, you can use the ABAP/4 Dictionary structure CPICCONN. Set the data
and then send the logon string with COMMUNICATION SEND.
In a C program, you first set up the logon string with SAP_CMLOGON and then send it with
CMSEND. The logon string is appropriately formatted and converted from ASCII to EBCDIC because
a logon string is expected in EBCDIC both for R/2 and for R/3.

Logon to the SAP System
Logon
CONN CPIC 1
1 4 5 8 9 10 11 12 75
Client (3)
User name (12)
FORM routine (30)
Password (8)
ABAP/4 program
Language ID (1)
Unused (1)
------------------------------------------------------------------------------------------------------------------------
Acknowledgement
Acknowledgement
© SAP AG
CPIC 1
Type
1. Negative acknowledgement
APPC CPIC 1
2. Negative acknowledgement
Request ID: APPC, FREE
FREE 1 00027 E027 User not allowed
The general header is sent only when you logon to the SAP System.
The header is twelve bytes long; the last three characters are blank.
Messages from the SAP System
The program name specifies the ABAP/4 program that contains a FORM routine. The FORM routine is
activatred internally by the SAP task handler.
If an error occurs, the connection is terminated with the request ID FREE and an error text.
As confirmation of the logon, the SAP System sends back the general header with the request ID APPC.
The data is then transferred in free format.

Logon to the Basis System
ABAP/4
REPORT RSCPIC01.
... ...
TABLES: CPICCONN.
CMINIT CMINIT ... ...
INCLUDE RSCPICDF.
CMALLC CMALLC ... ...
INCLUDE RSEBCASC.
... .
COMMUNICATION INIT ...
SAP_CMLOGON ( (
COMMUNICATION ALLOCATE ...
output, output,
CPICCONN-REQID = 'CONN'.
&sendlength,
&sendlength,
CPICCONN-REQTYPE = 'CPIC'.
"CONN", "CONN",
CPICCONN-AMODE = '1'.
"CPIC", "CPIC",
...
'1', '1',
CPICCONN-PROG = 'ABAPPROG'.
... ...
CPICCONN-MODN = 'FORM1'.
"ABAPPROG",
"FORM1"
TRANSLATE CPICCONN USING ASC_TO_EBC.
"FORM1" ); );
COMMUNICATION SEND ...
CMSEND
BUFFER CPICCONN ... CMSEND ( ( convid, convid, output, output, ... ... ); );
CMRCV
COMMUNICATION RECEIVE ...
CMRCV ( ( convid, convid, input, input, ... ... ); );
BUFFER CPICCONN ... ... ...
TRANSLATE CPICCONN USING EBC_TO_ASC.
...
© SAP AG
..
.
..
.
The logon data record must always be sent to an SAP System in EBCDIC format.
In ABAP/4, you can use the TRANSLATE statement for data conversion. The include program
RSEBCASC contains conversion tables for a conversion to IBM’s EBCDIC character set, but you can
also specify certain code pages explicitly.
In C, you can make use of the relevant functionality via the SAP libraries.
C

CPI-C Development Environment
l ABAP/4 Development Workbench
l The SAP CPI-C Software Development Kit (SDK)
© SAP AG
The SAP CPI-C SDK (Software Development Kit) is delivered with every R/3 System.
The CPI-C SDK contains excutable programs for the relevant hardware platform, libraries and include
files, as well as ABAP/4 and C programs. Accompanying text files describe the structure of the SDK
and provide important information about how programs are compiled and imported to the individual
platforms.
The directory structure in the file system is as follows:
cpicsdk - bin Executable programs
- lib Libraries
- include Header files
- text Source files, help text

SAP CPI-C Programs
© SAP AG
ABAP/4 programs
ACPICT1
ACPICT2
C programs
ccpict1t
ccpict2t
Every R/3 System delivered contains the ABAP/4 programs ACPICT1 and ACPICT2. ACPICT1 is a
client program, i.e. a program which initiates a communication. ACPICT2 is a server program started
by a partner program. Both ABAP/4 programs are supplied for the R/2 System from Release 5.0G.
The C programs ccpict1t and ccpict2t (directory cpicsdk/bin) are also delivered with the CPI-C SDK.
ccpict1t is a client program, ccpict2t is a server program.
You can use these programs at least to test the connection to the partner system or the partner program.
So, ccpict1t can call the R/3 program ACPICT2, while ACPICT1 can call ccpict2t.

Executing CPI-C Test Programs
© SAP AG
ACPICT1
CPI-C test program
Program parameters
DEST
ABAP
CONVERT
USER
PWD
ccpict1t
[1]: ccpict1t -dest R3 -abap -usr ABC -pwd XYZ
For the connection test, you need to start the program ACPICT1 in R/3. In the program parameters, you
specify the partner program. If this is a C program, you do not need to specify values for USER and
PWD (password). If you want to set up a connection to an R/2 ABAP/4 program, you must set the
ABAP and CONVERT flags, as well as USER and PWD.
You can pass the required program parameters to the client program ccpict1t via the command line. To
find out which parameters these are, execute ccpict1t without specifying any parameters.

Developing, Testing and Error Detection
l ABAP/4:
l C:
© SAP AG
Debugging
System log
Trace files
Gateway monitor
Developer traces
Debugging: Program code, tables, breakpoints, ...
You can evaluate the system log with Transaction SM21.
Trace files are generated by external CPI-C programs. You can set the trace level with the environment
variable CPIC_TRACE.
You start the gateway monitor under UNIX as follows:
gwmon pf = /sapmnt/

Chapter 5 Summary
© SAP AG
l SAP provides CPI-C functionality both in ABAP/4
(starter set) and also in libraries for external programs
(starter set, advanced function calls, SAP-specific
functions).
l When communicating with an ABAP/4 server program,
the client program must first logon to the SAP Basis
System.
l In the ABAP/4 server program, a FORM routine is
responsible for communication.
l Data conversions may have to be performed.
l There are programs for performing connection tests with
partner systems.

Exercise 1 for Chapter 5
Report name: ZBCE##E1 (active)
ZBCE##E2 (passive)
Main report: RS415057 (active)
RS415058 (passive)
Logical destination: BC415_##
##: Group number
Implement a CPI-C communication between two R/3 Systems
where the data (information about a special airline carrier) is
read from a server system and output in a client system.
Proceed as follows:
1. Create your CPIC destination with Transaction SM54 in R/3
for a server system to be specified by the instructor.
2. Copy the main report RS415057 to your report ZBCE##E1. In
your program, you must fill the places flagged with the
comment *Ad ... . From this active program, you should call
the FORM routine SEND in your passive program ZBCE##E2
which you must also create.
3. Now switch to the specified R/3 server system. There, copy
the main report RD415058 to your report ZBCE##E2. In your
program, you must fill the places flagged with the comment
*Add ... .
4. Then, you can return to the first R/3 System and use your
CPI-C destination to test the connection of both your
programs.

Solution for Chapter 5
&----------------------------------------------------------------*
*& Report RS415051 *
*& *
*&---------------------------------------------------------------*
REPORT RS415051.
TABLES SPFLI.
TABLES CPICCONN. "Logon record
INCLUDE RSEBCASC.
INCLUDE RSCPICDF.
PARAMETERS: DEST(8) DEFAULT 'BC415TIL'.
PARAMETERS: CARRID LIKE SPFLI-CARRID DEFAULT 'LH'.
DATA: SBUFFER(5) VALUE 'OK'.
DATA BEGIN OF ISPFLI OCCURS 1.
INCLUDE STRUCTURE SPFLI.
DATA END OF ISPFLI.
DATA: RBUFFER(255).
DATA: DUMMY.
DATA: CONVID(8), "Coversation ID
DI(4) TYPE X, "Data information
SI(4) TYPE X, "Status information
RL(4) TYPE X, "Receive length
CPIC_RC LIKE SY-SUBRC. "Return code

*----------------------------------------------------------------*
* Data for SAP logon *
*----------------------------------------------------------------*
CPICCONN-REQID = 'CONN'. "Request ID
CPICCONN-REQTYPE = 'CPIC'. "Type
CPICCONN-AMODE = '1'. "Mode number
CPICCONN-IMODE = ' '.
CPICCONN-FILL1 = ' '.
CPICCONN-MAND = '000'. "Client
CPICCONN-NAME = 'SAPCPIC'. "User
CPICCONN-CODE = 'ADMIN'. "Password
CPICCONN-LANG = SY-LANGU. "Language
CPICCONN-KORR = ' '. "not used
CPICCONN-PROG = 'RS415052'. "Partner program
CPICCONN-MODN = 'SEND'. "FORM routine
*----------------------------------------------------------------*
* CPI-C: CM_INIT *
*----------------------------------------------------------------*
FORMAT COLOR 1.
WRITE: / 'CM_INIT #', DEST.
COMMUNICATION INIT DESTINATION DEST ID CONVID RETURNCODE CPIC_RC.
FORMAT COLOR 2.
WRITE: / 'RC:', CPIC_RC.
IF CPIC_RC NE CM_OK.
EXIT.
ENDIF.

*----------------------------------------------------------------*
* CPI-C: CM_ALLOCATE *
*----------------------------------------------------------------*
SKIP 1.
FORMAT COLOR 1.
WRITE: / 'CM_ALLOC'.
COMMUNICATION ALLOCATE ID CONVID RETURNCODE CPIC_RC.
FORMAT COLOR 2.
WRITE: / 'RC:', CPIC_RC.
IF CPIC_RC NE CM_OK.
EXIT.
ENDIF.
*----------------------------------------------------------------*
* CPI-C: CM_SEND: Logon to SAP *
*----------------------------------------------------------------*
TRANSLATE CPICCONN USING ASC_TO_EBC.
SKIP 1.
FORMAT COLOR 1.
WRITE: / 'CM_SEND SAP logon'.
COMMUNICATION SEND ID CONVID BUFFER CPICCONN RETURNCODE CPIC_RC.
FORMAT COLOR 2.
WRITE: / 'RC:', CPIC_RC.
TRANSLATE CPICCONN USING EBC_TO_ASC.
WRITE: / 'LOGON-DATA'(001), 20 CPICCONN.
IF CPIC_RC NE CM_OK.
EXIT.
ENDIF.

*----------------------------------------------------------------*
* CPI-C: CM_RECEIVE Response to SAP logon *
*----------------------------------------------------------------*
SKIP 1.
FORMAT COLOR 1.
WRITE: / 'CM_RCV Response to logon'.
COMMUNICATION RECEIVE ID CONVID BUFFER RBUFFER RETURNCODE CPIC_RC
FORMAT COLOR 2.
WRITE: / 'RC:', CPIC_RC.
DATAINFO DI
STATUSINFO SI
RECEIVED RL.
TRANSLATE RBUFFER USING EBC_TO_ASC.
WRITE: / 'RESPONSE TO LOGON:'(002), RBUFFER(40).
IF CPIC_RC NE CM_OK.
EXIT.
ENDIF.
*----------------------------------------------------------------*
* Send parameter for selection *
*----------------------------------------------------------------*
FORMAT COLOR 1.
WRITE: / 'CM_SEND'.
*----------------------------------------------------------------*
* CPI-C: CM_SEND Send CARRID to partner program *
*----------------------------------------------------------------*
COMMUNICATION SEND ID CONVID BUFFER CARRID RETURNCODE CPIC_RC.
FORMAT COLOR 2.
WRITE: / 'RC:', CPIC_RC.
*
WHILE CPIC_RC = CM_OK.
FORMAT COLOR 1.
WRITE: / 'CM_RCV'.

*----------------------------------------------------------------*
* CPI-C: CM_RCV Receive data from sending partner program *
*----------------------------------------------------------------*
COMMUNICATION RECEIVE ID CONVID BUFFER ISPFLI RETURNCODE CPIC_RC
FORMAT COLOR 2.
WRITE: / 'RC:', CPIC_RC.
WRITE: / 'DI:', DI.
WRITE: / 'SI:', SI.
APPEND ISPFLI.
ENDWHILE.
SKIP 1.
FORMAT COLOR 1.
DATAINFO DI
STATUSINFO SI
RECEIVED RL.
WRITE: / 'Received data:'(004).
FORMAT COLOR 6.
LOOP AT ISPFLI.
NEW-LINE.
WRITE: ISPFLI-CARRID,
ENDLOOP.
ISPFLI-CONNID,
ISPFLI-CITYFROM,
ISPFLI-CITYTO.
*----------------------------------------------------------------*
* CPI-C: Deallocate *
*----------------------------------------------------------------*
SKIP 1.
FORMAT COLOR 1.
WRITE: / 'CM_DEALL'.
COMMUNICATION DEALLOCATE ID CONVID RETURNCODE CPIC_RC.
FORMAT COLOR 2.
WRITE: / 'RC:', CPIC_RC.
*&---------------------------------------------------------------*
*& Report RS415052 *
*& *

*&---------------------------------------------------------------*
REPORT RS41505D.
INCLUDE RSEBCASC.
INCLUDE RSCPICDF.
TABLES SPFLI.
DATA BEGIN OF ISPFLI OCCURS 1.
INCLUDE STRUCTURE SPFLI.
DATA END OF ISPFLI.
DATA: RBUFFER(255).
DATA: DUMMY.
DATA: CONVID(8), "Coversation ID
FORM SEND.
DI(4) TYPE X, "Data information
SI(4) TYPE X, "Status information
RL(4) TYPE X, "Receive length
CPIC_RC LIKE SY-SUBRC. "Return code
*----------------------------------------------------------------*
* CPI-C: CM_ACCEPT *
*----------------------------------------------------------------*
COMMUNICATION ACCEPT ID CONVID RETURNCODE CPIC_RC.
IF CPIC_RC NE CM_OK.
EXIT.
ENDIF.

*----------------------------------------------------------------*
* CPI-C: CM_RCV Receive carrier ID *
*----------------------------------------------------------------*
COMMUNICATION RECEIVE ID CONVID
IF CPIC_RC NE CM_OK.
EXIT.
ENDIF.
*
* Read data
*
SELECT * FROM SPFLI
BUFFER SPFLI-CARRID
RETURNCODE CPIC_RC
DATAINFO DI
STATUSINFO SI
RECEIVED RL.
WHERE CARRID = SPFLI-CARRID.
*----------------------------------------------------------------*
* CPI-C: CM_SEND Send selected data to partner program *
*----------------------------------------------------------------*
COMMUNICATION SEND ID CONVID
IF CPIC_RC NE CM_OK.
EXIT.
ENDIF.
ENDSELECT.
BUFFER SPFLI
RETURNCODE CPIC_RC.
*----------------------------------------------------------------*
* CPI-C: Deallocate *
*----------------------------------------------------------------*
COMMUNICATION DEALLOCATE ID CONVID
ENDFORM.
RETURNCODE CPIC_RC.

Outlook: Using OCX Components
R/3 application server Frontend platform
BAPI function
modules
or
customer-specific
function modules
© SAP AG
What is OCX?
RFC
gateway
R/3
application
TCP/IP
TCP/IP port
RFC
libraries
RFC API
( WInSock )
Logon
Desktop
application
Table
Table view
Includes
visualization
OCX (Ole custom Control eXtension) is an OLE object which combines the different OLE features in
one. Like DLLs, OCXs are compiled on Windows-based systems and exist in the process environment
of the application. All OCX properties and methods are primarily represented via the OLE Automation
interface.
The SAP environment contains the following OCXs:
Table OCX
Table view OCX
Logon OCX

Outlook: SAP Business Objects
l Object-oriented
approach with
R/3
l Management of
objects in the
Business
Object
Repository
l Currently, there
are about 160
core business
objects
© SAP AG
Behavior
Restrictions
Rules Methods
Events
In Release 3.0 of the R/3 System, an object-oriented approach has been directly implemented in the SAP
business workflow development. This includes encapsulation of functions and modules, and also
inheritance, i.e. hierarchical relationships between object types.
An object type is the definition/description of all objects generated at runtime. It is thus available at the
time of definition, whereas objects are always edited at runtime.
Objects are defined by a key structure which consists primarily of key fields of the relevant tables which
make up the business document. Besides the key structure, you can define other proerties which
correspond to the database fields of tables.
Methods in R/3 are the implementation of actions (e.g. performed by ABAP/4 reports, function modules
or transactions) and can be executed with the relevant object.

Outlook: SAP Business Object Active X
Architecture
© SAP AG
Win32 Win32
OLE Automation
OCX
MS Excel
Visual Basic
...
OLE Automation
clients
RFC RFC
Application Application server server
R/3 Object Broker
Business
objects
For external applications, you will be able to access business objects in R/3 by using SAP Business
Object Active X (implemented as an OCX, OLE Control eXtension).
The external application accesses R/3 objects via OLE Automation calls directed to SAP Business
Object Control. The calls are then passed on as pure RFC calls to the R/3 Object Broker.
This allows you to access all object types managed via the SAP Business Object Repository. In R/3,
you access the Object Repository with Transaction SWO1.

Outlook: Object Hierarchy
© SAP AG
Factory
Business object
The above object hierarchy shows the available OLE objects.
Business objects
collection
The factory object controls the connection to the R/3-System. It is also required to generate business
objects and collections of business objects.
The business collection object contains the individual business objects.
Business objects are local instances of R/3 business objects. As soon as an object is generated on the
desktop, the methods and properties of the relevant R/3 business object are made available for further
processing. For this reason, the business objects learn about the interfaces only at runtime.
For more information on available object methods and object properties, please refer to the online
documentation.

Outlook: Working with Business Objects
Example of processing SAP business objects
Set oBOF = CreateObject("SAP.BusinessObjectFactory")
blnLogged = oBOF.Logon
Set boWhoAmI = oBOF.GetSAPObject("USR01", "MUELLER")
...
oBOF.Logoff
blnLogged = False
© SAP AG
In the above example, a factory object is generated first. Logon to the R/3 System is performed with the
“Logon” method.
Then, the R/3 business object "USR01" is accessed with the key field value "MUELLER".
Before logoff from the R/3 System, the business object can be processed.

© SAP AG
Data Transfer
Application Development in the
ABAP/4 Development Workbench
Week 4
R

Contents II / Week 4
Chapter 1 Sequential Files
Chapter 2 Introduction to Batch Input
Processing
Chapter 3 Special Features of Batch
Input Processing
© SAP AG
Exercises
Solutions
Chapter 4 General Information about
Application-specific Batch
Input Programs
Chapter 5 CALL TRANSACTION
Chapter 6 Local Files

Chapter 1 Sequential Files
© SAP AG
l The Purpose of Sequential Files.
l Opening, Processing and Closing Files.
l Processing Files with Different Formats.

Chapter 1 Objectives
© SAP AG
l The possible uses of sequential files.
l How to process sequential files and the steps
involved.
l How to process a sequential file containing different
record types.

Overview
© SAP AG
ABAP/4 program
R/3
TRANSFER READ DATASET
Sequential file
You can process sequential files with the statements READ DATASET (for read operations) and
TRANSFER (for write operations).
The sequential file must be visible to the application server. Files on the current presentation server
cannot be processed with TRANSFER or READ DATASET. For further information about files of this
type, see the chapter Local Files.

Data Imports and Exports
© SAP AG
Fabe Farbe
Customer
program
Customer system
Sequential
file
R/3 System
SAP
program
Sequential files are located at the interface between a customer system and the R/3 System.
Sequential files are suitable for importing data from a customer system to the R/3 System and for
exporting data from the R/3 System to a customer system.

File Processing
© SAP AG
Open file
Process file
Close file
Before data records can be written to a sequential file or read from a file, the file must be opened.
After processing, the file is closed.
In the program, you call the file by its absolute file name. The absolute file name consists of the exact
path and the actual (relative) file name, e.g. '/tmp/bc180/d01' (note that file names are case-sensitive).
The format of file names is largely dependent on the operating system. You can access portable
programs with the function module FILE_GET_NAME which returns the physical name for a given
logical file name. See also the online documentation for the module in Transaction SE37 or refer to the
online ABAP/4 User’s Guide.

Opening a File
© SAP AG
OPEN DATASET
OUTPUT
FOR INPUT
APPENDING
IF SY-SUBRC NE 0.
.
.
.
To open a file, you use the statement OPEN DATASET . Depending on whether this is
successful, SY-SUBRC is set to 0 or 8. Errors are ignored.
If you do not specify any further options, the file is opened for reading.
Possible options:
FOR OUTPUT
Opens the file for writing. If the file already exists, its contents are deleted, but this applies only after
the end of the program. If the statement occurs in a program, the cursor is simply positioned at the
beginning of the file. You must then specify CLOSE DATASET in order to delete the file. If the file
does not exist, it is generated.
FOR INPUT
Opens an existing file for reading. If the file is already open, the cursor is positioned at the beginning of
the file. You do not have to specify FOR INPUT explicitly.
FOR APPENDING
Opens the file for writing at the end of the file. If the file does not exist, it is generated. If the file is
already open, the cursor is positioned at the end.

Opening a File (Binary and Text Mode)
© SAP AG
OPEN DATASET
OUTPUT
FOR INPUT
APPENDING
IN BINARY MODE
TEXT MODE
IF SY-SUBRC NE 0.
.
.
.
You can choose to open a file in binary mode or in text mode.
Possible options:
IN BINARY MODE
The data is not interpreted by the read and write operations READ DATASET and TRANSFER. The
data areas specified for these key words are input or output directly. You do not have to specify IN
BINARY MODE explicitly.
IN TEXT MODE
If you open a file with this option, the system assumes that the file has a line structure. Each time
READ DATASET or TRANSFER is executed, one line is always input/output and the data is always
processed up to the end-of-line selection. If the data area is too large for the line that is read, the
remaining area is padded with blanks. If it is too small, the end of the line is lost.
If you make no additional specification, the file is opened in binary mode.

Binary Mode and Text Mode
Binary mode Text mode
ABAP/4
program A B C
A B
A B C D
TRANSFER
© SAP AG
A B C A B A B C D
READ DATASET
ABAP/4
program A B C
A B A
B C D
READ DATASET
ABAP/4
program A B C
A B
A B C D
ABAP/4
program A B C
A B
A B C
TRANSFER
A B C A B A B C D
The example above illustrates the difference between binary mode and text mode:
Three fields of different lengths are transferred at any one time. The data is then read into three fields of
the same length.
In text mode, the operating system-specific line-end character is set after every data record.
Blanks at the end of a data record are not suppressed in text mode.

Opening a File - AT POSITION
© SAP AG
OPEN DATASET
AT POSITION
MESSAGE
The following additions exist for the OPEN statement:
AT POSITION
With this addition, you can specify a file position (in bytes) from the beginning of the file. The next read
or write operation then takes place at this point. You cannot position the cursor before the beginning of
the file.
Although this addition can be used together with IN TEXT MODE, this has little sense as the physical
format of a text file is largely dependent on the operating system.
MESSAGE
If an error occurs when opening the file, the associated operating system message is stored in the field
.
For information on other additions, refer to the online documenation.

Transferring Data Records
© SAP AG
TRANSFER TO .
Sequential
file
data
record
Each TRANSFER statement transfers one data record to a sequential file.
Before TRANSFER, you place the data record in a field or a structure.
Possible structures are field strings or table work areas.
The execution of the TRANSFER statement depends on the mode:
- Binary mode: Writes the length of the field or structure.
- Text mode: Writes a line.
If the specified file is not open, the TRANSFER statement tries to open the file FOR
OUTPUT (IN BINARY MODE) or using the additions of the last OPEN DATASET statement for this
file.
Errors which occur during the TRANSFER statement result in program termination.
The additional parameter LENGTH of the TRANSFER statement allows you to specify a
length in bytes (in the format TRANSFER TO LENGTH ). In this
case, the exact number of characters specified in is transferred. If the structure is shorter, the
record is padded (with blanks in text mode and hexadecimal zeros in binary mode). If the structure is
longer, the record is truncated.

Reading Data Records
© SAP AG
READ DATASET INTO .
Sequential
file
data
record
Each READ DATASET statement reads one record from a sequential file into a field or structure.
Possible structures are field strings or table work areas.
The execution of the READ DATASET statement depends on the mode:
- Binary mode: Reads the length of the structure.
- Text mode: Reads a line.
If the specified file is not open, READ DATASET tries to open the file (IN BINARY MODE FOR
INPUT or with the options of the last OPEN DATASET statement for this file).
If the end of the file is reached, SY-SUBRC is set to 4. Otherwise it is set to 0. If the file cannot be
opened, SY-SUBRC contains the value 8. Errors result in program termination.
READ DATASET, like TRANSFER, does not perform conversions implicitly. The data is read in as it
was written.
The additional parameter LENGTH of the READ DATASET statement allows you to specify
a length in bytes (in the format READ DATASET INTO LENGTH ).
In this case, the exact number of characters specified in is read from the data record into the
structure. If the structure is shorter, the record is padded (with blanks in text mode and with
hexadecimal zeros in binary mode). If the structure is longer, the record is truncated.

Closing/Deleting a Sequential File
© SAP AG
CLOSE DATASET .
DELETE DATASET .
You use the CLOSE DATASET statement to close a sequential file explicitly.
As with OPEN DATASET, errors are ignored.
In a program, all opened files are implicitly closed each time the screen changes, and then reopened
exactly as they were before when processing resumes.
At the end of a program, all files are closed.
Opening and closing files explicitly aids readability. Also, the advantage of using OPEN DATASET is
that you can use the addition MESSAGE to avoid a programmed termination if an error occurs when
opening the file (SY-SUBRC = 8). In addition, you should be aware that, in cases where a file is read,
or generated and read, several times in the same report, only explicit opening or closing guarantees that
the cursor will be repositioned at the beginning of the file.
A file is not closed implicitly when READ DATASET reaches the endo of a file.
You can use the DELETE DATASET to delete a sequential file explicitly. If this is
successful, SY-SUBRC is set to 0.
You can display the current state of the file in debugging by choosing Goto -> System -> System areas
and then entering (or selecting) DATASETS.

Example: Creating a File
© SAP AG
REPORT RSFFF01A.
TABLES SFLIGHT.
* INCLUDE RSFFF01B.
DATA: BEGIN OF REC,
CARRID LIKE SFLIGHT-CARRID,
CONNID LIKE SFLIGHT-CONNID,
FLDATE LIKE SFLIGHT-FLDATE,
PLANETYPE LIKE SFLIGHT-PLANETYPE,
END OF REC.
PARAMETERS
FILE(20) DEFAULT '/tmp/RSFFF01A'
LOWER CASE.
START-OF-SELECTION.
OPEN DATASET FILE FOR OUTPUT.
GET SFLIGHT.
MOVE-CORRESPONDING SFLIGHT TO REC.
TRANSFER REC TO FILE.
WRITE: / REC-CARRID, REC-CONNID,
/ REC-FLDATE, REC-PLANETYPE.
ULINE.
END-OF-SELECTION.
CLOSE DATASET FILE.
First you define the structure to be transferred. In this example, it is a field string, but it could also be a
help field, the header liner of an internal table or an ABAP/4 Dictionary work area.
The field string can also be transferred from an include report.
Next, you fill the structure. In principle, all statements that perform a value assignment can be used
here. Examples include MOVE, COMPUTE, MOVE-CORRESPONDING, MOVE TO and WRITE
TO. Refer also to the relevant online documentation.
Finally, you transfer the structure with the TRANSFER statement.

Example: ABAP/4 Dictionary Structures
© SAP AG
REPORT RSFFF01C.
TABLES: SFLIGHT, SBC420A.
PARAMETERS
FILE(20) DEFAULT '/tmp/RSFFF01A'
LOWER CASE.
GET SFLIGHT.
MOVE-CORRESPONDING SFLIGHT TO SBC420A.
TRANSFER SBC420A TO FILE.
WRITE: / SBC420A-CARRID, SBC420A-CONNID,
/ SBC420A-FLDATE, SBC420A-PLANETYPE.
ULINE.
Table structure SBC420A
--------------------------------------------------------------------
Name Type Length Meaning
--------------------------------------------------------------------
SBC420A-CARRID CHAR 03 Short description of airline company
SBC420A-CONNID NUMC 04 Code for flight connection
SBC420A-FLDATE DATS 08 Flight date
SBC420A-PLANETYPE CHAR 10 Aircraft type
REPORT RSFFF01D.
TABLES: SFLIGHT, SBC420A.
DATA: BEGIN OF REC.
INCLUDE STRUCTURE SBC420A.
DATA: END OF REC.
PARAMETERS
FILE(20) DEFAULT '/tmp/RSFFF01A'
LOWER CASE.
GET SFLIGHT.
MOVE-CORRESPONDING SFLIGHT TO REC.
TRANSFER REC TO FILE.
WRITE: / REC-CARRID, REC-CONNID,
/ REC-FLDATE, REC-PLANETYPE.
ULINE.
Dict.
You can also use structures from the ABAP/4 Dictionary for data transfer. To do this, declare the
structure with TABLES.
Then, in your program, do either of the following:
- use the work area declared with TABLES
- copy the structure for your field string with INCLUDE STRUCTURE.
You can display the ABAP/4 Dictionary structure in the ABAP/4 Editor with the SHOW command.

Example: Reading a File
© SAP AG
REPORT RSFFF01E.
TABLES SFLIGHT.
* INCLUDE RSFFF01B.
DATA: BEGIN OF REC,
CARRID LIKE SFLIGHT-CARRID,
CONNID LIKE SFLIGHT-CONNID,
FLDATE LIKE SFLIGHT-FLDATE,
PLANETYPE LIKE SFLIGHT-PLANETYPE,
END OF REC.
PARAMETERS
FILE(20) DEFAULT '/tmp/RSFFF01A'
LOWER CASE.
START-OF-SELECTION.
OPEN DATASET FILE FOR INPUT.
DO.
READ DATASET FILE INTO REC.
IF SY-SUBRC NE 0. EXIT. ENDIF.
WRITE: / REC-CARRID,REC-CONNID,
/ REC-FLDATE,REC-PLANETYPE.
ULINE.
ENDDO.
CLOSE DATASET FILE.
First you define the structure to be read. In this example, it is a field string. It can also be transferred
from an include report.
The structure used for reading with READ DATASET must match the structure used for writing with
TRANSFER.
You read the data records into your structure within a loop and process them.
READ DATASET does not require a logical database. You can therefore analyze your extract data
along with data from any logical database (which you then specify in the report attributes).

Example: Extending a File
© SAP AG
REPORT RSFFF01F.
TABLES: SFLIGHT, SBC420A.
PARAMETERS FILE(20) DEFAULT
'/tmp/RSFFF01A' LOWER CASE.
START-OF-SELECTION.
OPEN DATASET FILE FOR APPENDING
IN BINARY MODE.
GET SFLIGHT.
MOVE-CORRESPONDING SFLIGHT TO SBC420A.
TRANSFER SBC420A TO FILE.
WRITE: / SBC420A-CARRID, SBC420A-CONNID.
END-OF-SELECTION.
CLOSE DATASET FILE.
To append data records to the end of the file, you use the FOR APPENDING addition of the OPEN
DATASET statement.

Example: Variable Format (Generate)
© SAP AG
REPORT RSFFF01G.
TABLES: SFLIGHT, SBOOK.
INCLUDE RSFFF01I.
PARAMETERS:
FILE(20) DEFAULT '/tmp/RSFFF01G'
LOWER CASE.
START-OF-SELECTION.
OPEN DATASET FILE FOR OUTPUT
IN BINARY MODE.
GET SFLIGHT.
MOVE-CORRESPONDING SFLIGHT TO REC1.
MOVE 'A' TO REC1-FLAG.
TRANSFER REC1 TO FILE.
WRITE REC1-CARRID, REC1-CONNID,.......
GET SBOOK.
MOVE-CORRESPONDING SBOOK TO REC2.
MOVE 'B' TO REC2-FLAG.
TRANSFER REC2 TO FILE.
WRITE REC2-BOOKID, REC2-CUSTID,.......
END-OF-SELECTION.
CLOSE DATASET FILE.
The above example generates a sequential file with data records of different structures.
The include program is defined as follows:
DATA: BEGIN OF REC1, FLAG.
INCLUDE STRUCTURE SBC420A.
DATA: END OF REC1.
DATA: BEGIN OF REC2, FLAG.
INCLUDE STRUCTURE SBC420B.
DATA: END OF REC2.
The structure SBC420A is used for flight data, while the structure SBC420B holds reservation data.
A flag should indicate whether the next data record contains flight data or reservation data.

Example: Variable Format (Read)
© SAP AG
REPORT RSFFF01H.
TABLES: SBC420A, SBC420B.
DATA: FLAG.
PARAMETERS
FILE(20) DEFAULT '/tmp/RSFFF01G'
LOWER CASE.
START-OF-SELECTION.
OPEN DATASET FILE FOR INPUT
IN BINARY MODE.
DO.
READ DATASET FILE INTO FLAG.
IF SY-SUBRC NE 0. EXIT. ENDIF.
CASE FLAG.
WHEN 'A'.
READ DATASET FILE INTO SBC420A.
WRITE: / SBC420A-CARRID SBC420A-CONNID,
SBC420A-FLDATE, SBC420A-PLANETYPE.
WHEN 'B'.
READ DATASET FILE INTO SBC420B.
WRITE: / SBC420B-BOOKID, SBC420B-CUSTID,
SBC420B-CUSTYP, SBC420B-CLASS.
ENDCASE.
ENDDO.
END-OF-SELECTION.
CLOSE DATASET FILE.
The above program reads the data records of the file created with the previous program.
The program assumes that an ID (‘A’ or ‘B’) precedes each data record.
The file is opened in binary mode and the records are read in the length of the structure specified.

Defining Structures - Summary
Yes
© SAP AG
Write
Fill structure
Transfer structure
More data
records?
Define structures
Open file
Read
No Yes
Close file
Read data record
Process data record
End of
file?
In a file processing program, you first define the structures required for the data records with the
TABLES or DATA statement. The program uses these structures as internal buffers for the data
records.
You then open the sequential file for reading or writing with the OPEN statement.
When writing to the file, you transfer the filled structures to the file with TRANSFER statements.
When reading the file, you fill the structures set up for the data records with READ DATASET for
further processing in the program.
To close the sequential file, you exit file processing with the CLOSE DATASET statement.
No

Chapter 1 Summary
l The simplest method of organizing data is through sequential files. In
particular, they provide a convenient way of exchanging data between
systems. The TRANSFER command writes data (record by record) to a
directory on the application server; you specify the path using the notation
appropriate for the operating system. The READ DATASET command allows
the target system to read in the data and you can then continue processing it
if required. You open and close sequential files in the appropriate mode for
whatever processing is required.
© SAP AG

Exercises on Chapter 1: Sequential Files
1. Your program name: ZBCF##A1
Your group number: ##
Your directory name: /tmp
Your file name: BOOK##
Name of the include report: RSFFF01L.
Task:
Create a file with flight/reservation data. The data records are
to be entered by the user individually.
Programming hints:
a) Use the include report specified above for the data
structure.
The structure contains the airline carrier ID, flight ID, flight
date, booking ID and customer ID (CARRID,CONNID,
FLDATE, BOOKID, CUSTOMID).
b) Using the PARAMETERS statement, define a selection
screen on which the flight/reservation data can be entered.
c) Transfer the data record in text mode.
d) A new data record is to be added to the file whenever the
report is started.
2. Your program name: ZBCF##A2
Your group number: ##
Your directory name: /tmp
Your file name: BOOK##
Name of the include report: RSFFF01L
Task:

Create a program that reads in the data of your
flight/reservation file BAN## and outputs it to the screen.

Model Solution 1 for Chapter 1: Sequential Files
REPORT RSFFF011 .
* Record for sequential file defined as Dictionary structure or
* include report provided
DATA: BEGIN OF REC.
INCLUDE STRUCTURE SBC420C.
DATA: END OF REC.
* STRUCTURE SBC420C:
* CARRID, CONNID, FLDATE, BOOKID, CUSTOMID.
* Alternative:
* INCLUDE RSFFF01L.
* Create selection screen (manual data input)
PARAMETERS:
FILE(20) DEFAULT '/tmp/BOOKXX' LOWER CASE,
CARRID LIKE SFLIGHT-CARRID DEFAULT 'BA',
CONNID LIKE SFLIGHT-CONNID DEFAULT '0001',
FLDATE LIKE SFLIGHT-FLDATE DEFAULT '19960401',
BOOKID LIKE SBOOK-BOOKID DEFAULT '00000001',
CUSTOMID LIKE SBOOK-CUSTOMID DEFAULT '00000001'.
* Open file for appending in text mode
START-OF-SELECTION.
OPEN DATASET FILE FOR APPENDING IN TEXT MODE.
* Transfer data from selection screen to field string

MOVE: CARRID TO REC-CARRID,
CONNID TO REC-CONNID,
FLDATE TO REC-FLDATE,
BOOKID TO REC-BOOKID,
CUSTOMID TO REC-CUSTOMID.
* Write field string to sequential file
TRANSFER REC TO FILE.
* List output
WRITE: / REC-CARRID,
/ REC-CONNID,
/ REC-FLDATE,
/ REC-BOOKID,
/ REC-CUSTOMID.
ULINE. SKIP.
*D TEXT-001: 'Transfer data record to file:'
WRITE: / TEXT-001, FILE.
* Close the sequential file
CLOSE DATASET FILE.

Model Solution 2 for Chapter 1: Sequential Files
REPORT RSFFF012.
* Record for sequential dataset defined as Dictionary structure or
* include report provided
DATA: BEGIN OF REC.
INCLUDE STRUCTURE SBC420C.
DATA: END OF REC.
* STRUCTURE SBC420C:
* CARRID, CONNID, FLDATE, BOOKID, CUSTOMID.
* Alternative:
* INCLUDE RSFFF01L.
DATA: COUNT LIKE SY-INDEX.
* Create selection screen
PARAMETERS:
FILE(20) DEFAULT '/tmp/BOOKXX' LOWER CASE.
* Open file for reading in text mode
START-OF-SELECTION.
OPEN DATASET FILE FOR INPUT IN TEXT MODE.
DO.
READ DATASET FILE INTO REC.
* Termination condition for reading
IF SY-SUBRC NE 0.

COUNT = SY-INDEX - 1.
EXIT.
ENDIF.
* List output
WRITE: / 'Satz:', SY-INDEX,
ENDDO.
SKIP.
ULINE.
/ REC-CARRID,
/ REC-CONNID,
/ REC-FLDATE,
/ REC-BOOKID,
/ REC-CUSTOMID USING NO EDIT MASK.
*D TEXT-001: 'Data records read from file:'
WRITE: / COUNT, TEXT-001, FILE.
* Close the sequential file
CLOSE DATASET FILE.

Chapter 2 Introduction to Batch Input Processing
© SAP AG
l Overview of Batch Input
l Programming techniques for creating batch input
sessions
l Transaction SM35: Batch input administration
transaction

Chapter 2 Objectives
l The uses of batch input processing.
l Programming technique for creating batch input sessions.
l Processing batch input sessions and administration options.
© SAP AG

Task Overview
© SAP AG
External External system system
SAP R/2
SAP R/3
The reasons for transferring data without a basic interactive dialog with the user are:
The datasets are large and already exist on an electronic data medium
The data is transferred to another system and only then imported into the SAP system.

Problem Overview
© SAP AG
External
data
External
data
SAP
interfaces
Checks
You must not transfer external data directly to the SAP database.
External data must be checked before it is transferred to the SAP database.
SAP system (host)
SAP
database
SAP
database

Technique Overview
External system
SAP R/2
SAP SAP R/3 R/3
© SAP AG
Queue
Batch
input
sessions
Application
program
Large data sets are transferred to the SAP system using batch input.
SAP
database
Batch input is an automatic procedure. It is often referred to as BDC (Batch Data Communication).
To guarantee data consistency, the transfer data is subject to the same checks and updates as dialog
data which is entered interactively by the user. Examples include:
- Format checks
- Automatic value range check (against check table or fixed value range)
- Conversion of user data to program data and vice-versa
- Field default values
The transfer data is stored temporarily in the form of a batch input session in a queue file.
A batch input session is a collection of business processes (transactions).
A user dialog is simulated in a batch input procedure.

Screen Technique Overview
© SAP AG
Input
modules
PAI
Output
modules
Dialog step
Input
modules
Output
modules
PBO PAI PBO
Input Processing Input Processing
In an SAP system, dialog and background processing are controlled by screen programs.
A screen program controls one dialog step.
The components of a dialog step are:
A PBO (Process Before Output) event which prepares the screen for output
User input
A PAI (Process After Input) event which processes user input
t

Batch Input Processing
© SAP AG
SAP R/3
Customer
data
Source file
Sequential
file
Batch input program
Batch input function
Flight
connections
Reservation
data
Batch input or BDC (Batch Data Communication) is an automatic procedure for transferring data to the
SAP system without a user dialog.
A user dialog is simulated for this procedure so that the same checks and updates can be performed.
A central component of this procedure is a queue file.
This file receives the data via batch input programs and groups associated data together into ‘sessions’.
To load the data into SAP databases, you process the sessions with the batch input function (menu
options Systems -> Services-> Batch input, Transaction SM35).

Batch Input Program
© SAP AG
Batch input program
BDC
table
READ DATASET
CALL FUNCTION
Sequential file
Queue
file
Data is transferred to the queue file by batch input programs.
These programs perform the following functions:
Structure
BDCDATA
INCLUDE
STRUCTURE
ABAP/4
Dictionary
They provide structured work areas in the form of an internal table (BDC table) for the data to be
transferred.
They read in the data.
They place the data in the BDC table.
They transfer the filled BDC table to the queue file.
The BDC table receives the input for the data transfer transactions.

Batch Input Queue File
© SAP AG
Screens
SAP R/3
Queue
file
Batch input
Transaction 1 Transaction 2
Screen 1 Screen 2 Log
file
Screen 1 Screen 2
Customer
data
Flight
connections
Booking
data
The queue file collects the individual screens and combines them into sessions.
SAP
database
You process these sessions with the batch input function (choose Systems -> Services-> Batch input or
call Transaction SM35). As when you execute application functions (with add or change transactions)
in the dialog interface, this sends data to the log file. When you subsequently perform an update, the
data reaches the relevant SAP databases.
The batch input function starts the application functions specified in the relevant session (indicated by
their transaction codes).
The data from the session is now copied to the screens belonging to the online transaction specified.

Format of a Batch Input Session
© SAP AG
l User who has created the session
Session header
l Client in wh ch session is to be processed
l Session name
l Batch input user
l Date from when the session may be processed (lock date)?
l Delete session after processing (Keep function)?
Transaction
Close session
A batch input session consists of a header part (session header, described by the ABAP/4 Dictionary
structure APQI) and a data part (transactions, described by the ABAP/4 Dictionary structure APQD).
...

Creating a Batch Input Session
© SAP AG
Open batch
input session
Insert data
for transactions
Close batch
input session
Every batch input session must be opened and closed.
The data for the application functions (transactions) is inserted in the batch input session.
A batch input program can generate several consecutive batch input sessions. Parallel generation is not
possible.

Function Modules for Batch Input Program
© SAP AG
BDC_OPEN_GROUP
Client
Session name
Lock date
Delete session after
processing
BDC user name
BDC_INSERT
Transaction code
BDC table
BDC_CLOSE_GROUP
CLIENT
GROUP
HOLD
KEEP
USER
TCODE
DYNPROTAB
Function modules (function group SBDC) are available for creating batch input sessions.
You will learn about these function modules in the following slides. Refer also to the online
documentation.

Function Module BDC_OPEN_GROUP
© SAP AG
CALL FUNCTION BDC_OPEN_GROUP’
BDC_OPEN_GROUP’
EXPORTING
CLIENT =
GROUP =
HOLDDATE =
KEEP =
USER =
EXCEPTIONS
QUEUE_ERROR = 1
CLIENT_INVALID = 2
GROUP_INVALID = 3
.
.
.
You open a batch input session with the function module BDC_OPEN_GROUP.
The parameters you must specify are as follows:
CLIENT (Client)
GROUP (Session name)
USER (User name)
Specification of the following parameters is optional:
HOLDDATE (Earliest session start date)
KEEP (ID whether session should be deleted after successful processing;
KEEP = ' ': Delete session (default value)
KEEP = 'X': Do not delete session)
You receive various return values via EXCEPTIONS. You can read these with SY-SUBRC.
USER must always be specified; The user type should be BDC.
In online processing, the online user (and not the user name specified) is used for the authorization
checks.

Function Module BDC_INSERT
© SAP AG
CALL FUNCTION BDC_INSERT’ BDC_INSERT’
EXPORTING TCODE =
TABLES DYNPROTAB =
EXCEPTIONS
INTERNAL_ERROR = 1
NOT_OPEN = 2
QUEUE_ERROR = 3
TCODE_INVALID = 4
You use function module BDC_INSERT to insert the data for ONE transaction into a session.
To transfer the data, you require an internal table (BDC table).
You must specify the following parameters:
TCODE (transaction code),
DYNPROTAB (BDC table).

BDC Table
Program Screen Start Field name Field contents
x
x
© SAP AG
The BDC table holds the data for one transaction.
The contents of the BDC table are then passed to the queue file.
One table line includes the following information:
Program name, screen number, start ID, field name, field value.
... ...
... ...
... ...
The start ID 'X' is always at the beginning of a new screen. The input values are now entered for each
field in the table for this screen.
For reasons of clarity, a table line should only include either program name, screen number and start ID
or field name and field value (as above). In principle, however, all information can be included in a line.
Only the field names of fields to be changed explicitly are included.

Defining the BDC Table
© SAP AG
DATA: BEGIN OF
OCCURS .
INCLUDE STRUCTURE BDCDATA.
DATA: END OF .
SHOW BDCDATA
Field name Type Length Short text
PROGRAM CHAR 8 BDC module pool
DYNPRO NUMC 4 BDC screen number
DYNBEGIN CHAR 1 BDC start of a screen
FNAM CHAR 35 BDC field name
FVAL CHAR 132 BDC field contents
You declare the BDC table as an internal table with the ABAP/4 Dictionary structure 'BDCDATA'.
The field -FVAL differentiates between upper and lower case, but the fields -
PROGRAM and -FNAM are not case-sensitive.

Filling the BDC Table
© SAP AG
FORM .
REFRESH .
CLEAR .
MOVE: TO -PROGRAM,
TO -DYNPRO,
'X' TO -DYNBEGIN.
APPEND .
CLEAR .
MOVE: TO -FNAM,
TO -FVAL.
APPEND .
CLEAR .
MOVE: TO -FNAM,
TO -FVAL.
APPEND .
...
CLEAR .
MOVE: TO -PROGRAM,
TO -DYNPRO,
'X' TO -DYNBEGIN.
APPEND .
...
ENDFORM.
The BDC table is set up line by line. As for every internal table, you do this with MOVE and APPEND
statements.
The fields of the table header line should be reset to their initial value with CLEAR.

Function Module BDC_CLOSE_GROUP
© SAP AG
CALL FUNCTION BDC_CLOSE_GROUP’
BDC_CLOSE_GROUP’
EXCEPTIONS
NOT_OPEN = 1
QUEUE_ERROR = 2
You close a batch input session with the function module BDC_CLOSE_GROUP.
You receive various return values via EXCEPTIONS. You can read these with SY-SUBRC.

Example: Change Customer Data
© SAP AG
BC_TRAVEL data model for training
Change customer data
(Transaction TFBA)
Change cust. data
Customer number 1
Cust. name Meier
Postal code 6900
City Heidelberg
G/P cust. B
Discount [%] 10
Tel. no. 06221/66666
Save
In this example, the application function Change customer data (Transaction TFBA) demonstrates the
creation of a BDC program.
Here, a customer’s address data is to be changed.
Before writing a BDC program for the application function, you must know the application function (so
that the BDC program can simulate your input on the screen).

Preparations for BDC Program
© SAP AG
Help
F1
Technical info
Table SCUSTOM
Field ID
Code /5 or Aend
Field BDC_OKCODE
Change cust. data
Customer number_______
First perform (step by step) the application function to be simulated.
Make a note of:
- the program name and screen number for each screen
- the field and table name for every entry or cursor positioning
- the number for each function key pressed
- the screen program sequence
Program SAPMTFBA
Screen number 100
System
Status
To do this, you use the system function Status and the Technical info help function.

Preparations for BDC Program - Screen Painter
Kundendaten Change cust. ndern data
Customer number________
© SAP AG
Program SAPMTFBA
Screen number 100
System
Status
Field list
Field name Ln Cl Lg Fmt. I O
SCUSTOM ID 8 36 08 NUMC x x
...
OK 0 0 04 OK
...
...
Screen Painter
In the Screen Painter (choose Tools -> ABAP/4 Workbench -> Screen Painter, or call Transaction
SE51), you can get a complete list of fields for a particular screen. This is an alternative to the online
help function).

Structure of the BDC Table
PROGRAM SCREEN SCRNSTART FNAM FVAL
SAPMTFBA 0100 X
SAPMTFBA 0200 X
© SAP AG
SCUSTOM-ID ID
BDC_OKCODE /5
SCUSTOM-NAME CUSTNAME
SCUSTOM-POSTCODE POSTCODE
SCUSTOM-CITY CITY
SCUSTOM-CUSTTYPE CUSTTYPE
SCUSTOM-DISCOUNT DISCOUNT
SCUSTOM-TELEPHONE TELEPHONE
BDC_OKCODE /11
Before you write the batch input program, you have to run the transaction and note down the screen
numbers, screen sequence and the screen field names to be addressed later in the program. You enter
this data in the BDC table.
The field name for the OK code is the same for all screens: BDC_OKCODE. The value for the OK
code consists of a slash '/' and the function key number (example: '/11').

Declaration Part 1
© SAP AG
REPORT RSFFF02A.
PARAMETERS:
NAME LIKE APQI-GROUPID DEFAULT SY-UNAME,
ID LIKE SCUSTOM-ID DEFAULT '00000001',
CUSTNAME LIKE SCUSTOM-NAME DEFAULT 'SCHMIDT',
POSTCODE LIKE SCUSTOM-POSTCODE DEFAULT '69000',
CITY LIKE SCUSTOM-CITY DEFAULT 'HEIDELBERG',
CUSTTYPE LIKE SCUSTOM-CUSTTYPE DEFAULT 'B',
DISCOUNT LIKE SCUSTOM-DISCOUNT DEFAULT '10',
TELEFON LIKE SCUSTOM-TELEPHONE DEFAULT '06221/
123456'.
DATA:BEGIN OF BDC_TAB OCCURS 5.
INCLUDE STRUCTURE BDCDATA.
DATA: END OF BDC_TAB.
In the declaration part of the BDC program, you define the BDC table.
In this example, the data is entered directly on the selection screen (via PARAMETERS).

Creating Sessions
© SAP AG
START-OF-SELECTION.
WRITE: / 'Start BDC session creation',
SY-MANDT, NAME, SY-UZEIT.
CALL FUNCTION 'BDC_OPEN_GROUP'
EXPORTING CLIENT = SY-MANDT
GROUP = NAME
USER = 'BC420BDC'
KEEP = 'X'
PERFORM GENERATE_BDC_DATA.
CALL FUNCTION 'BDC_INSERT'
EXPORTING TCODE = 'TFBA'
TABLES DYNPROTAB = BDC_TAB.
CALL FUNCTION 'BDC_CLOSE_GROUP'.
WRITE: / 'End BDC session creation',
SY-MANDT, NAME, SY-UZEIT.
You require the function modules for opening and closing sessions.
To insert the data in the session, you set up the BDC table in a subroutine and call the function module
BDC_INSERT.

Filling the BDC Table 2
© SAP AG
FORM GENERATE_BDC_DATA.
REFRESH BDC_TAB.
CLEAR BDC_TAB.
BDC_TAB-PROGRAM = 'SAPMTFBA'.
BDC_TAB-DYNPRO = '0100'.
BDC_TAB-DYNBEGIN = 'X'.
APPEND BDC_TAB.
CLEAR BDC_TAB.
BDC_TAB-FNAM = 'SCUSTOM-ID'.
BDC_TAB-FVAL = ID.
APPEND BDC_TAB.
CLEAR BDC_TAB.
BDC_TAB-FNAM = 'BDC_OKCODE'.
BDC_TAB-FVAL = '/5'.
APPEND BDC_TAB.
Two fields are transferred for the first screen of Transaction TFBA.

Filling the BDC Table 3
© SAP AG
CLEAR BDC_TAB.
BDC_TAB-PROGRAM = 'SAPMTFBA'.
BDC_TAB-DYNPRO = '0200'.
BDC_TAB-DYNBEGIN = 'X'.
APPEND BDC_TAB.
CLEAR BDC_TAB.
BDC_TAB-FNAM = 'SCUSTOM-NAME'.
BDC_TAB-FVAL = CUSTNAME.
APPEND BDC_TAB.
CLEAR BDC_TAB.
BDC_TAB-FNAM = 'SCUSTOM-POSTCODE'.
BDC_TAB-FVAL = POSTCODE.
APPEND BDC_TAB.
CLEAR BDC_TAB.
BDC_TAB-FNAM = 'SCUSTOM-CITY'.
BDC_TAB-FVAL = CITY.
APPEND BDC_TAB.
ENDFORM.
For the second screen of Transaction TFBA, the fields 'SCUSTOM-NAME', 'SCUSTOM-
POSTCODE' and 'SCUSTOM-CITY' are transferred.

Filling the BDC Table 4
© SAP AG
CLEAR BDC_TAB.
BDC_TAB-FNAM = 'SCUSTOM-CUSTTYPE'.
BDC_TAB-FVAL = CUSTTYPE.
APPEND BDC_TAB.
CLEAR BDC_TAB.
BDC_TAB-FNAM = 'SCUSTOM-DISCOUNT'.
BDC_TAB-FVAL = DISCOUNT.
APPEND BDC_TAB.
CLEAR BDC_TAB.
BDC_TAB-FNAM = 'SCUSTOM-TELEPHONE'.
BDC_TAB-FVAL = TELEFON.
APPEND BDC_TAB.
CLEAR BDC_TAB.
BDC_TAB-FNAM = 'BDC_OKCODE'.
BDC_TAB-FVAL = '/11'.
APPEND BDC_TAB.
ENDFORM.
On the second screen of Transaction TFBA, the fields 'SCUSTOM-CUSTTYPE', 'SCUSTOM-
DISCOUNT' and 'SCUSTOM-TELEPHONE' are also transferred.
Finally, the OK code must be passed (choose Customer data -> Save). The field name for the OK code
is the same for all screens: BDC_OKCODE.
The value for the OK code consists of a slash '/' and the function key number (example: '/11') .
Alternatively, you can use the function code assigned to this function code.
When you choose Save, the data is updated. This completes batch input processing for this transaction.

Generating a Sequential File for BDC Program 1
© SAP AG
REPORT RSFFF02B.
TABLES SCUSTOM.
DATA: BEGIN OF REC,
ID LIKE SCUSTOM-ID,
POSTCODE LIKE SCUSTOM-POSTCODE,
CUSTTYPE LIKE SCUSTOM-CUSTTYPE,
END OF REC.
PARAMETERS:
FILE(30) DEFAULT '/tmp/RSFFF02B'
LOWER CASE,
CODE1 LIKE SCUSTOM-POSTCODE DEFAULT
'9999999999',
CODE2 LIKE SCUSTOM-POSTCODE DEFAULT
'1111111111',
CUST1 LIKE SCUSTOM-CUSTTYPE DEFAULT 'B',
CUST2 LIKE SCUSTOM-CUSTTYPE DEFAULT 'P'.
START-OF-SELECTION.
OPEN DATASET FILE FOR OUTPUT
In the following example, the postal code is changed according to a particular algorithm. In addition,
business customers (type B) are changed to private customers (type P), and vice-versa. For this, the
customer masters are changed with a batch input program for Transaction TFBA. A sequential file with
the required data is generated with this program.

Generating a Sequential File for BDC Program 2
© SAP AG
SELECT * FROM SCUSTOM
WHERE ID BETWEEN '00000001'AND '00000050'.
MOVE SCUSTOM-ID TO REC-ID.
IF SCUSTOM-POSTCODE(1) BETWEEN '1' AND '5'
OR SCUSTOM-POSTCODE(1) BETWEEN 'A' AND 'M'.
MOVE CODE1 TO REC-POSTCODE.
ELSE.
MOVE CODE2 TO REC-POSTCODE.
ENDIF.
IF SCUSTOM-CUSTTYPE EQ 'P'.
MOVE CUST1 TO REC-CUSTTYPE.
ELSE.
MOVE CUST2 TO REC-CUSTTYPE.
ENDIF.
TRANSFER REC TO FILE.
WRITE: / REC-ID, REC-POSTCODE, REC-CUSTTYPE.
ENDSELECT.
END-OF-SELECTION.
CLOSE DATASET FILE.
ULINE. SKIP.
WRITE: / TEXT-001, FILE.
In the example, we use the file created by the above program.
Comment:
This is only a general example. As the data for this example comes from the same SAP system, the
following batch input program could also read in the data directly with ABAP/4 Open SQL or via a
logical database (if available).

Declaration Part 2
© SAP AG
REPORT RFFF02C.
PARAMETERS:
FILE(30) DEFAULT '/tmp/RSFFF02B'
LOWER CASE,
NAME LIKE APQI-GROUPID DEFAULT SY-UNAME.
DATA:BEGIN OF BDC_TAB OCCURS 5.
INCLUDE STRUCTURE BDCDATA.
DATA: END OF BDC_TAB.
DATA:BEGIN OF REC,
ID LIKE SCUSTOM-ID,
POSTCODE LIKE SCUSTOM-POSTCODE,
CUSTTYPE LIKE SCUSTOM-CUSTTYPE;
END OF REC.
START-OF-SELECTION:
OPEN DATASET FILE FOR INPUT.
WRITE: TEXT-001, SY-MANDT, NAME, SY-UZEIT.
In the declaration part of the BDC program, you define the BDC table and a structure for reading in the
data.

Reading in the Data and Creating Sessions
© SAP AG
CALL FUNCTION 'BDC_OPEN_GROUP'
EXPORTING CLIENT = SY-MANDT
GROUP = NAME
USER = 'BC420BDC'
KEEP = 'X'.
DO.
READ DATASET FILE INTO REC.
IF SY-SUBRC NE 0. EXIT. ENDIF.
WRITE: / REC-ID USING NO EDIT MASK,
REC-POSTCODE, REC-CUSTTYPE.
PERFORM GENERATE_BDC_DATA.
CALL FUNCTION 'BDC_INSERT'
EXPORTING TCODE = 'TFBA'
TABLES DYNPROTAB = BDC_TAB.
ENDDO.
CALL FUNCTION 'BDC_CLOSE_GROUP'.
WRITE: / TEXT-002,
SY-MANDT, NAME, SY-UZEIT.
END-OF-SELECTION.
CLOSE DATASET FILE.
You require the function modules for opening and closing sessions.
To insert the data in the session, you set up the BDC table in a subroutine and call the function module
BDC_INSERT.
You set up the BDC table and call the subroutine in a loop for reading in the data with READ
DATASET.
The called subroutine is similar to the subroutine in the first program example.

Functionality of Transaction SM35
© SAP AG
Overview
Analysis
Administration
Process
Batch input sessions
Batch input process logs
Locked sessions
Display session contents
Display batch input data
Logs (extended log)
Statistics
Select sessions for deletion
Lock sessions
Release sessions
Process in foreground
Display errors only
Process in background
You can process sessions with the Batch input function (choose System -> Services -> Batch input, or
call Transaction SM35). Information is provided on status, screen sequence, screen contents, the user
doing the processing, processing mode, server, as well as the user used for the authorization check.
In Release 3.0, the user can activate Expert mode if required. This function deactivates error message
344 'Batch input data does nto exist for this screen’ for interactive session processing. This option is of
particular interest if you want to branch to other transaction processing, which does not correspond to
the screen sequence in the batch input program.
The Extended log function allows you to record W, I and S messages in addition to E messages. This
option is also available if you are processing sessions in the background.

Copying Data to Screens
© SAP AG
Sessions
TCODE
=
TFBA’
Customer no. 1
Location Berlin
PostCode11111
Tel. 123
TCODE
=
TFBA’
Customer no. 21 21
Location Hof
Post.code 93333
Tel. _
Screens
Customer no. 1
Name Hess
PostCode 11111
Location Berlin
Tel. 123
Customer no. 21 21
Name M ller
Post.code 93333
Location Hof
Tel. _
. . . . . .
Customer
master recs.
Name Hess
Post.code 87342
Location Ulm
Tel. _
Name M ller
Post.code 60000
Location Frankf.
Tel. _
When you process a session with Transaction SM35, the system uses the transaction code (TFBA in
this case) to search for the start screen. Only the relevant session data is copied to this start screen.
The subsequent screen is then processed. First the data is read from the SAP database and then the
session data is copied to the screen.
When the transaction has been processed, the system searches for the next transaction code in the
session and starts the transaction.
. . .

Processing Modes
© SAP AG
Foreground Display all dialog steps
Display errors only Display dialog steps only for error or
termination messages
Background Dialog steps not displayed, processing
takes place in the background
In the ‘Process in foreground’ mode, all screens of a transaction are displayed. The authorizations of the
user doing the processing apply. If a session terminates abnormally in test mode, you can use the
Restart function to branch directly to the session overview (where you can restart the processing).
In the ‘Display errors only’ mode, screens are displayed only when an error occurs. A transaction
contains an error if a type E (error) or type A (termination) dialog message is output. The authorizations
of the user doing the processing apply.
In the ‘Process in background’ mode, the session is processed in the background. Your screen is
available for input as soon as the session has been passed to the background control system. The
authorizations of the BDC user specified in the header part of the session apply.
When processing a session, the update mode is always synchronous (i.e. the next transaction is called
only when the update for the preceding transaction has been completed).

Batch Input Processing
© SAP AG
Function
Exit active batch input transaction and
flag as incorrect
Delete active batch input transaction in
session
Exit batch input processing and flag as
incorrect
Switch display mode from "Display errors
only" to "Process in foreground"
Switch display mode from "Display in
foreground" to "Display errors only"
OK code
/n
/bdel
/bend
/bda
/bde
In correction mode (‘Process in foreground’ or ‘Display errors only’), you can control the processing of
your session by choosing System -> Services-> Batch input or by entering a command in the command
field.

Session Status
© SAP AG
Processed
Incorrect
To be processed
Creating
Processing
Background
Session successfully processed
Session was processed, but still
contains incorrect transactions
Session created, but not yet
processed
Session currently being recorded
Session currently being processed
Session is processed in the
background
A session is assigned a status during and after processing.
Basically, the system identifies transactions that cannot be processed due to errors. These transactions
remain in the session (which becomes an error session). You can then process these sessions again and
correct the errors.

Creating and Processing Sessions
© SAP AG
Sequential files
t1
Create session
t2
SAP database
Process session
When you create batch input programs, bear in mind that session creation and session processing take
place at different times (t1 and t2). What is processed at time t2 is already planned at time t1.
Example: At time t2, the batch input system can no longer respond to dialog messages (except through
user input in correction mode).
The batch input system does not take over any SPA/GPA parameters at time t2.
t

Summary of User Preparations
© SAP AG
Run application function
Note program names
and screen numbers
Note field names
Note screen sequence
and function codes
Create BDC table layout
When you create a batch input program, you must know the transaction it is based on.
You therefore run the transaction and make a note of the screen numbers, screen sequence and screen
field names to be addressed later in the program.
You enter this data in the BDC table.

Summary of Batch Input Programs
© SAP AG
Define structure and BDC table
Open file and session
Read in data record
Fill BDC table
Insert BDC table into session
Close file and session
A batch input program must perform the above functions.

Chapter 2 Summary
© SAP AG
l Batch input is an automatic procedure suitable for
processing mass data. It is used primarily when installing
the SAP system and when transferring data from a legacy
system (external system). When programming, the data to
be transferred must already exist in the appropriate format
for the screen. Also, you must use the appropriate
function modules to generate an executable session in an
intermediate file (known as a queue file). You run sessions
by calling Transaction SM35 and the data is transferred to
the SAP system. There are several processing and
administration options available to support you.

Exercises for Chapter 2: Introduction to Batch Input
Processing
1. Your program name: ZBCF##B1
Your group number: ##
Model file name: TELXX
Your directory name: /tmp
Your session name: RSD##021SES
Name of the BDC user: BC420BDC
Task:
For your file TEL## (you may have to recreate it with program
RSFFF02D) or for the model file TELXX, write a batch input
program which enters the telephone numbers in the relevant
SCUSTOM records using transaction TFBA.
Programming hint:
For transaction TFBA, use the following screens in the order
specified:
Program name: SAPMTFBA
Screens Fields
0100 SCUSTOM-ID
BDC_OKCODE
0200 SCUSTOM-TELEPHONE
BDC_OKCODE
2. Your program name: ZBCF###B2
Your group number: ###

Your directory name: /tmp
Name of model file: KUNXX
Session name: RSD###022SES
Name of the BDC user: BC420DC
Task:
File KUNXX contains SCUSTOM data for adding new
SCUSTOM records with transaction TFBB and for changing
existing SCUSTOM records with transaction TFBA. Write a
batch input program which reads in this data and enters it in
the SCUSTOM records.
Programming hint:
The data record structure is as follows:
filled for transaction
Description Name Length TFBA TFBB
ID REC-FLAG 1 U N
Customer ID REC-ID 8 x
Name REC-NAME 25 x x
Postal code REC-POSTCODE 10 x x
City REC-CITY 25 x x
Customer type REC-CUSTTYPE 1 x x
Cust. discount REC-DISCOUNT 3 x x
Telephone REC-TELEPHONE 30 x x
This structure is defined in the include program RSFFF02F.
The ID has one of the following values:
• 'U' (Update): Change SCUSTOM record
• 'N' (New): Add this SCUSTOM record

The 'U' and 'N' records are filled almost identically, only the 'U'
records also contain a customer ID.
Use the following screens in the order specified:
Screens for task 2
Trans- Program Screens Fields
action name
TFBA SAPMTFBA 0100 SCUSTOM-ID
BDC_OKCODE
0200 SCUSTOM-NAME
SCUSTOM-POSTCODE
SCUSTOM-CITY
SCUSTOM-CUSTTYPE
SCUSTOM-DISCOUNT
SCUSTOM-TELEPHONE
BDC_OKCODE

Trans- Program Screens Fields
action name
TFBB SAPMTFBB 0100 SCUSTOM-NAME
Include program for task 2
SCUSTOM-POSTCODE
SCUSTOM-CITY
SCUSTOM-CUSTTYPE
SCUSTOM-DISCOUNT
SCUSTOM-TELEPHONE
BDC_OKCODE
0200 BDC_OKCODE
DATA: BEGIN OF REC,
FLAG,
ID LIKE SCUSTOM-ID,
NAME LIKE SCUSTOM-NAME,
POSTCODE LIKE SCUSTOM-POSTCODE,
CITY LIKE SCUSTOM-CITY,
CUSTTYPE LIKE SCUSTOM-CUSTTYPE,
DISCOUNT LIKE SCUSTOM-DISCOUNT,
TELEPHONE LIKE SCUSTOM-TELEPHONE,
END OF REC.

Model solution 1 (Chapter 2): Introduction to Batch Input
Processing
REPORT RSFFF021.
* Internal table for storing the data in screen format
DATA: BEGIN OF BDC_TAB OCCURS 5.
INCLUDE STRUCTURE BDCDATA.
DATA: END OF BDC_TAB.
* Record for the data to be transferred to the SAP System
DATA: BEGIN OF REC,
PARAMETERS:
TELEPHONE LIKE SCUSTOM-TELEPHONE,
ID LIKE SCUSTOM-ID,
NAME LIKE SCUSTOM-NAME,
END OF REC.
* Name of the batch input session
NAME LIKE APQI-GROUPID DEFAULT SY-UNAME,
* Name of the sequential file to be accessed
FILE(30) DEFAULT '/tmp/TELXX' LOWER CASE.
* Open dataset for accessing and in binary mode
START-OF-SELECTION.
OPEN DATASET FILE FOR INPUT IN BINARY MODE.
* Text-001 D: Start creating BDC session

WRITE: / TEXT-001,
SY-MANDT, NAME, SY-UZEIT.
* Create the session header
CALL FUNCTION 'BDC_OPEN_GROUP'
EXPORTING
* Access the data
DO.
CLIENT = SY-MANDT
GROUP = NAME
USER = 'BC420BDC'
KEEP = 'X'.
READ DATASET FILE INTO REC.
IF SY-SUBRC NE 0.
EXIT.
ENDIF.
WRITE: / REC-ID USING NO EDIT MASK, REC-NAME, REC-TELEPHONE.
* Subroutine for transferring the data of one transaction to the
* BDC_TAB (screen format)
PERFORM GENERATE_BDC_DATA.
* Function module for transferring the data of the BDC_TAB to the
queue file
CALL FUNCTION 'BDC_INSERT'
EXPORTING
TABLES
TCODE = 'TFBA'
DYNPROTAB = BDC_TAB.

ENDDO.
* Close the completed session
CALL FUNCTION 'BDC_CLOSE_GROUP'.
* Text-002 D: End of BDC session creation
WRITE: / TEXT-002,
SY-MANDT, NAME, SY-UZEIT.
* Close the fully accessed sequential dataset
END-OF-SELECTION.
CLOSE DATASET FILE.
*-----------------------------------------------------------------
*
* FORM GENERATE_BDC_DATA
*
*-----------------------------------------------------------------
*
* ........
*
*-----------------------------------------------------------------
*
FORM GENERATE_BDC_DATA.
REFRESH BDC_TAB.
PERFORM DYNPRO USING:

ENDFORM.
'X' 'SAPMTFBA' '0100',
' ' 'SCUSTOM-ID' REC-ID,
' ' 'BDC_OKCODE' '/5',
'X' 'SAPMTFBA' '0200',
' ' 'SCUSTOM-TELEPHONE' REC-TELEPHONE,
' ' 'BDC_OKCODE' '/11'.
*-----------------------------------------------------------------
*
* FORM DYNPRO
*
*-----------------------------------------------------------------
*
* ........
*
*-----------------------------------------------------------------
*
* --> DYNBEGIN
*
* --> NAME
*
* --> VALUE
*
*-----------------------------------------------------------------
*
FORM DYNPRO USING DYNBEGIN NAME VALUE.
IF DYNBEGIN = 'X'.
CLEAR BDC_TAB.
MOVE: NAME TO BDC_TAB-PROGRAM,

VALUE TO BDC_TAB-DYNPRO,
'X' TO BDC_TAB-DYNBEGIN.
APPEND BDC_TAB.
ELSE.
CLEAR BDC_TAB.
MOVE: NAME TO BDC_TAB-FNAM,
VALUE TO BDC_TAB-FVAL.
APPEND BDC_TAB.
ENDIF.
ENDFORM.
Model solution 2 (Chapter 2): Introduction to Batch Input
Processing
REPORT RSFFF022.
* Internal table for storing the data in screen format
DATA: BEGIN OF BDC_TAB OCCURS 5.
INCLUDE STRUCTURE BDCDATA.
DATA: END OF BDC_TAB.
* Include Report contains record for the data to be transferred to
* the SAP system
INCLUDE RSFFF02F.
DATA: TCODE LIKE SY-TCODE.
PARAMETERS:
* Name of the batch input session
NAME LIKE APQI-GROUPID DEFAULT SY-UNAME,
* Name of the sequential file to be accessed

FILE(30) DEFAULT '/tmp/KUNXX' LOWER CASE.
START-OF-SELECTION.
* Open dataset for accessing and in binary mode
OPEN DATASET FILE FOR INPUT IN BINARY MODE.
* Text-001 D: Start creating BDC session
WRITE: / TEXT-001,
SY-MANDT, NAME, SY-UZEIT.
* Create the session header
CALL FUNCTION 'BDC_OPEN_GROUP'
EXPORTING
* Access the data
DO.
CLIENT = SY-MANDT
GROUP = NAME
USER = 'BC420BDC'
KEEP = 'X'.
READ DATASET FILE INTO REC.
IF SY-SUBRC NE 0.
EXIT.
ENDIF.
* Subroutines for transferring the data of one transaction to

* the BDC_TAB (screen format), irrespective of whether an SCUSTOM
* record is updated or created
CASE REC-FLAG.
WHEN 'U'.
TCODE = 'TFBA'.
PERFORM GENERATE_BDC_DATA_TFBA.
WHEN 'N'.
TCODE = 'TFBB'.
PERFORM GENERATE_BDC_DATA_TFBB.
WHEN OTHERS.
* Text-003 D: Processing terminated due to incorrect data
WRITE: TEXT-001, REC-FLAG.
EXIT.
ENDCASE.
* Function module for transferring the data of the BDC_TAB to the
queue file
CALL FUNCTION 'BDC_INSERT'
EXPORTING
TABLES
TCODE = TCODE
DYNPROTAB = BDC_TAB.
WRITE: / REC-FLAG, REC-ID USING NO EDIT MASK,
TELEPHONE,
ULINE.
/ REC-NAME UNDER REC-FLAG,
/ REC-POSTCODE UNDER REC-NAME, REC-CITY, REC-
REC-CUSTTYPE, REC-DISCOUNT.

ENDDO.
* Close the completed session
CALL FUNCTION 'BDC_CLOSE_GROUP'.
* Text-002 D: End of BDC session creation
WRITE: / TEXT-002,
SY-MANDT, NAME, SY-UZEIT.
* Close the fully accessed sequential dataset
CLOSE DATASET FILE.

*-----------------------------------------------------------------
*
* FORM GENERATE_BDC_DATA_TFBA
*
*-----------------------------------------------------------------
*
* ........
*
*-----------------------------------------------------------------
*
FORM GENERATE_BDC_DATA_TFBA.
REFRESH BDC_TAB.
PERFORM DYNPRO USING:
ENDFORM.
'X' 'SAPMTFBA' '0100',
' ' 'SCUSTOM-ID' REC-ID,
' ' 'BDC_OKCODE' '/5',
'X' 'SAPMTFBA' '0200',
' ' 'SCUSTOM-NAME' REC-NAME,
' ' 'SCUSTOM-POSTCODE' REC-POSTCODE,
' ' 'SCUSTOM-CITY' REC-CITY,
' ' 'SCUSTOM-CUSTTYPE' REC-CUSTTYPE,
' ' 'SCUSTOM-DISCOUNT' REC-DISCOUNT,
' ' 'SCUSTOM-TELEPHONE' REC-TELEPHONE,
' ' 'BDC_OKCODE' '/11'.

*-----------------------------------------------------------------
*
* FORM GENERATE_BDC_DATA_TFBB
*
*-----------------------------------------------------------------
*
* ........
*
*-----------------------------------------------------------------
*
FORM GENERATE_BDC_DATA_TFBB.
REFRESH BDC_TAB.
PERFORM DYNPRO USING:
'X' 'SAPMTFBB' '0100',
' ' 'SCUSTOM-NAME' REC-NAME,
' ' 'SCUSTOM-POSTCODE' REC-POSTCODE,
' ' 'SCUSTOM-CITY' REC-CITY,
' ' 'SCUSTOM-CUSTTYPE' REC-CUSTTYPE,
' ' 'SCUSTOM-DISCOUNT' REC-DISCOUNT,
' ' 'SCUSTOM-TELEPHONE' REC-TELEPHONE,
' ' 'BDC_OKCODE' '/11',
* Display screen. Specification not obligatory here
ENDFORM.
'X' 'SAPMTFBB' '0200',
' ' 'BDC_OKCODE' '/3'.

*-----------------------------------------------------------------
*
* FORM DYNPRO
*
*-----------------------------------------------------------------
*
* ........
*
*-----------------------------------------------------------------
*
* --> DYNBEGIN
*
* --> NAME
*
* --> VALUE
*
*-----------------------------------------------------------------
*
FORM DYNPRO USING DYNBEGIN NAME VALUE.
IF DYNBEGIN = 'X'.
CLEAR BDC_TAB.
MOVE: NAME TO BDC_TAB-PROGRAM,
VALUE TO BDC_TAB-DYNPRO,
'X' TO BDC_TAB-DYNBEGIN.
APPEND BDC_TAB.
ELSE.
CLEAR BDC_TAB.
MOVE: NAME TO BDC_TAB-FNAM,
VALUE TO BDC_TAB-FVAL.
APPEND BDC_TAB.
ENDIF.
ENDFORM.

Chapter 3 Special Features of Batch Input
Processing
© SAP AG
l Programming step loop / table control screens in
batch input.
l Programming particular fields in batch input.
l Requirements for batch input capability.
l RSBDCSUB: Utility program for automatic session
processing.
l Batch input authorization.
l Overview of utility programs for batch input.

Chapter 3 Objectives
© SAP AG
l Accessing specific lines of a step loop / table control
screen or particular fields in batch input reports.
l Conditions which must exist for a transaction to
support batch input, and how to satisfy them.
l The various standard utility programs available for
managing sessions. In particular, how to automate
session processing using RSBDCSUB.

Example: Display and Change Flights
© SAP AG
Flight model / BC_TRAVEL
Display and Change Flights
(Transaction TCF2 )
Display
Airline carrier AA
Connection number 0064
Airline carrier AA
Connection number 0064
Date Price Curr. Plane Cap. Occup.
09.01.1996 2640.66 USD A310-300 280
10.01.1996 2220.13 USD A310-300 280
11.01.1996 1896.90 USD 727-300 280
12.01.1996 2573.94 USD 727-400 280
...
...
...
Save
In this example, Transaction TCF2 is used to change the database table SFLIGHT by adding new new
flight data (new plane type, field SFLIGHT-PLANETYPE).
...
...
1
43
96
130
...

Preparations for BDC Program - SFLIGHT
Table SFLIGHT
Field PLANETYPE
Help
F1
Technical info
Function SAVE/11
© SAP AG BC420 / 3 - 1
Table SFLIGHT
Field PLANETYPE
Technical info Help
F1
Date Price Curr. Plane Cap. Occup.
09.01.1996
10.01.1996
11.01.1996
12.01.1996
...
2640.66
2220.13
1896.90
2573.94
...
USD
USD
USD
USD
...
A310-300
A310-300
727-300
727-400
First perform (step by step) the application function to be simulated.
Make a note of:
- the program name and screen number for every screen
- the field and table name for every entry or cursor positioning
- the number for every function key activated
- the screen sequence
...
280
280
280
280
...
1
43
96
130
...
Program SAPMTCF2
Screen number 0200
System
Status
To do this, you use the Status system function and the Technical info help function.
The screen for the flight data is a table control screen. That is why the help function displays the same
field name for every field in a column.

Example: Structure of the BDC Table
PROGRAM SCREEN SCRBEGIN FNAM FVAL
SAPMTCF2 0100 X
SAPMTFC2 0200 X
© SAP AG
SFLIGHT-CARRID CARRID
SFLIGHT-CONNID CONNID
BDC_OKCODE /5 or UPDA
SFLIGHT-PLANETYPE(3) PLANE
BDC_CURSOR SFLIGHT-SEATSMAX(4)
BDC_OKCODE /11 or SAVE
You enter the information found with the help function in the BDC table.
For fields of a table control screen, you must also specify the number of the table control line in
parentheses, as a suffix to the field name, e.g. SFLIGHT-PLANETYPE(3) for the aircraft type in line
3. Lines of a step loop screens are addressed in exactly the same way.
You can also set the cursor. To do this, you use the field name 'BDC_CURSOR'. For the field value,
specify the name of the field on which the cursor is to be positioned.
For command field input, you can use the function code instead of the number of the function key. To
find out the function code of a function key, use the online help (F1). Place the cursor on the function
key field, hold down the mouse button and press F1. If you choose Extras, you get technical information
which gives the function code.

Creating Sessions - Declaration Part
© SAP AG
REPORT RSFFF03A.
DATA:BEGIN OF BDC_TAB OCCURS 5.
INCLUDE STRUCTURE BDCDATA.
DATA: END OF BDC_TAB.
PARAMETERS:
NAME LIKE APQI-GROUPID DEFAULT SY-UNAME,
CARRID LIKE SFLIGHT-CARRID DEFAULT 'AA',
CONNID LIKE SFLIGHT-CONNID DEFAULT '0064',
PLANE LIKE SFLIGHT-PLANETYPE DEFAULT 'A310-200'.
In the declaration part of the BDC program, you define the BDC table.
Enter the session name in the NAME parameter.
Enter the flight ID, flight number and aircraft type in the other parameters.

Creating Sessions
© SAP AG BC420 / 3 - 1
START-OF-SELECTION.
WRITE: / 'Start creation of BDC session',
SY-MANDT, NAME, SY-UZEIT.
CALL FUNCTION 'BDC_OPEN_GROUP'
EXPORTING CLIENT = SY-MANDT
GROUP = NAME
USER = SY-UNAME
KEEP = 'X'.
PERFORM GENERATE_BDC_DATA.
CALL FUNCTION 'BDC_INSERT'
EXPORTING TCODE = 'TCF2'
TABLES DYNPROTAB = BDC_TAB.
CALL FUNCTION 'BDC_CLOSE_GROUP'.
WRITE: / 'End creation of BDC session',
SY-MANDT, NAME, SY-UZEIT.
You require the function modules for opening and closing sessions.
To insert the data in the session, you set up the BDC table in a subroutine and call the function module
BDC_INSERT.

BDC Program: Filling the BDC Table
© SAP AG
FORM GENERATE_BDC_DATA.
REFRESH BDC_TAB.
CLEAR BDC_TAB.
BDC_TAB-PROGRAM = 'SAPMTCF2'.
BDC_TAB-DYNPRO = '0100'.
BDC_TAB-DYNBEGIN = 'X'.
APPEND BDC_TAB.
CLEAR BDC_TAB.
BDC_TAB-FNAM = 'SFLIGHT-CARRID'.
BDC_TAB-FVAL = CARRID.
APPEND BDC_TAB.
CLEAR BDC_TAB.
BDC_TAB-FNAM = 'SFLIGHT-CONNID'.
BDC_TAB-FVAL = CONNID.
APPEND BDC_TAB.
CLEAR BDC_TAB.
BDC_TAB-FNAM = 'BDC_OKCODE'.
BDC_TAB-FVAL = '/5'.
APPEND BDC_TAB.
For the first screen of Transaction TCF2, three fields are transferred.

Filling the BDC Table 5
© SAP AG
CLEAR BDC_TAB.
BDC_TAB-PROGRAM = 'SAPMTCF2'.
BDC_TAB-DYNPRO = '0200'.
BDC_TAB-DYNBEGIN = 'X'.
APPEND BDC_TAB.
CLEAR BDC_TAB.
BDC_TAB-FNAM = 'SFLIGHT-PLANETYPE(3)'.
BDC_TAB-FVAL = PLANE.
APPEND BDC_TAB.
CLEAR BDC_TAB.
BDC_TAB-FNAM = 'BDC_CURSOR'.
BDC_TAB-FVAL = 'SFLIGHT-SEATSMAX(4)'.
APPEND BDC_TAB.
CLEAR BDC_TAB.
BDC_TAB-FNAM = 'BDC_OKCODE'.
BDC_TAB-FVAL = '/11'.
APPEND BDC_TAB.
ENDFORM.
The table control fields are transferred for the second screen of Transaction TCF2.
The data is updated when you choose Save. This completes the batch input processing for this
transaction.

Special Fields
© SAP AG
OK code:
- FNAM = BDC_OKCODE’
- FVAL = /nn’
Table control field:
- FNAM = (line number)
-
Set cursor:
- FNAM = BDC_CURSOR’
- FVAL = (line number)
In a batch input program, you can address the OK code, table control / step loop fields and cursor.
The following rules apply when filling the BDC table:
The field name for the OK code is always 'BDC_OKCODE'
A table control / step loop field must have a valid line number
The field name for the cursor is 'BDC_CURSOR'.

Transaction End in Batch Input
© SAP AG
Batch input capability
Update
Return to SAP main menu
LEAVE TO TRANSACTION ' '
No batch batch input input capability
capability
Start a new transaction
- CALL TRANSACTION 'xxxx'
- LEAVE TO TRANSACTION 'xxxx'
- '/nxxxx'
- '/i' (exit mode)
In batch input processing, you can exit a transaction in one of two ways - either through an update or by
returning to the SAP main menu.
A transaction does not support batch input if it is started by LEAVE TO TRANSACTION , CALL TRANSACTION or by the command field entry '/n'.
The Delete mode function is not supported in batch input.

Report RSBDCSUB
© SAP AG
ABAP/4 development/reporting
Report RSBDCSUB
Session name
Created on
From____ to
Session status
To be processed
Incorrect
Variant
x Edit
Execute
Save
Background job
You use the report RSBDCSUB to schedule session processing.
Proceed as follows:
1. Create a variant. The selection criteria are:
- Session name (generic entries are also possible)
- Creation date
- Session status
- Target host (for the background system)
- Extended log
2. Create a background job for the report RSBDCSUB with the variant you have defined.

Processing Batch Input Sessions
© SAP AG
SAP
Dialog
process
Queue
Background
process
You can choose to process sessions in online or in the background.
Starting the session online:
- The authorizations of the user doing the processing are checked.
Starting the session in the background:
- The authorizations of the batch input user are used.

Authorizations for Batch Input Processing
© SAP AG
Object Fields Values Meaning
S_BDC_MONI Session name Specifies session names
for which a user is
authorized
Activities ABTC Process (submit) in
background
AONL Process online
DELE Delete
LOCK Sessions/logs
Lock date, Change
FREE Release terminated
sessions
ANAL Analyze sessions
The authorization object S_BDC_MONI is used for authorization checks in batch input processing.
You can use this authorization object to restrict processing to particular sessions (specifying the session
name, or make a generic entry). You can also protect specific activities in batch input processing (by
making an entry in the ‘Activities’ field).

Standard Utility Reports for Batch Input
l RSBDCREO
© SAP AG
n deletes all sessions which are flagged as successful and still in the
system, together with their logs
n physically deletes all logs for which there are no sessions
n reorganizes the log file (file is reduced if logs have been deleted)
n function integrated in SM35
l RSBDCLOG
n generates a list of batch input logs, selected by session name
n can display or delete logs and, if sessions exist, activate the analysis
n function integrated in SM35
l RSBDCDRU
n allows you to print out the contents of selected sessions
n function integrated in SM35

Chapter 3 Summary
© SAP AG
l In batch input programming, you can address step loop /
table control screens as well as particular fields, and
change them if required. Batch input capability can only
be guaranteed if the transaction sets an end flag which is
recognized by the batch input system. There are several
standard utility programs available. They support the
processing (RSBDCSUB) and management of batch input
sessions.

Exercise for Chapter 3: Special Features of Batch Input
Processing
1. Your job name: ZBCF##C1JOB
Your group number: ##
Your session name: ZBCF##C1SES
Your variant names: ZBCF##C1VAR
Task:
Create a job for your batch input program (Exercise 1, Chapter
2). The job should start the batch input program and then
process the generated session.
Programming hints:
a) Define a variant for the SAP program 'RSBDCSUB'.
b) Create a job for your batch input program 'ZBCF17#B1'.
c) Extend this job to include a request to process the variant
you have defined for the SAP program 'RSBDCSUB'.
d) Release the job and start it immediately.
e) Analyze the job log and the job results.
f) Use transaction SM35 to check that the sessions were
processed correctly. Your session directory should be
empty (successfully processed sessions are normally
deleted immediately).

Chapter 4 General Information on Applicationspecific
Batch Input Programs
© SAP AG
l Transferring data from external Systems to the SAP
system.
l Principles and examples of application-specific
standard transfer programs for batch input.
l Principles and examples of direct input.

Chapter 4 Objectives
© SAP AG
l Transferring data from external systems.
l Standard application-specific transfer programs to
support data transfer.
l The requirements for using these programs and how
to get information on them.

Overview
© SAP AG
Customer system
Customer
transfer
program
Customer DB/
sequential file
Sequential
file
Queue
file
SAP SAP system system
Batch input
program
When the batch input procedure is used to import data from a customer system, the batch input program
generally transfers the data from a sequential file.
You create the sequential file with a customer transfer program. You then use a batch input program
(the SAP transfer program) to transfer the data from the sequential file to the SAP queue file.
The SAP System offers standard batch input programs for many standard data transfer cases. This
means you do not have to write you own batch input program. However, the data you provide must be
in a predefined SAP format.

Sequential Dataset in SAP Format
© SAP AG
0
1
2
2
1
0
1
2
1
.
.
.
The data records of a sequential file must have a format that can be read by a standard SAP batch input
program.
The applications provide structure descriptions for the standard SAP batch input programs in the
ABAP/4 Dictionary.
The structure descriptions and the structure of the sequential file depend on the application. They are
described in the documentation for the standard SAP batch input programs.
Example: In Financial Accounting, there are three different types of data records:
Type 0: Session header data (e.g. session name).
Type 1: Transaction header data (e.g. transaction code).
Type 2: SAP table data (e.g. table name, field name, field contents etc.)

Data Analysis
© SAP AG
Fields and structures
in the legacy system
?
There is a data analysis at the start of every data transfer.
Fields and structures
in the SAP system
In the data analysis, you decide which data can be transferred and how. Proceed as follows:
Compare your old data with the data fields in the SAP System.
Define which fields from the old data can be transferred directly to the SAP System.
Draw up rules for filling data fields in the SAP System where old data cannot be directly used.

Transfer Program
Sequential file 1
© SAP AG
Read data records
Customer
transfer program
Structure in old format
Structure in SAP format
Write data records
Sequential file 2
The task of a customer transfer program is to create data records in SAP format and transfer them to a
sequential file. The data can then be read by a standard SAP batch input program.

Importing SAP Structures
© SAP AG
Dict. Dict.
Transfer program
TABLES
ABAP/4 program SAP
Transfer program
Dict.
structure
definitions
ABAP/4
CC
COBOL
PL/1
You require the SAP structure descriptions for the transfer program. If you write the transfer program
in ABAP/4, you use the TABLES statement to transfer the structure descriptions directly from the
ABAP/4 Dictionary.
The SAP system also supports the creation of transfer programs in other programming languages
(COBOL, C, PL/1): You generate the structure descriptions in the respective programming language
using the ABAP/4 program RDDSRCG0. These structure descriptions are then available in a sequential
file and you can include them in your transfer program.

Initializing and Converting
© SAP AG
Type C
Initializing SAP structures
Converting fields
.....
Type Type C
Type P Type Type C
For every field passed in the batch input structure, a decision must be made as to whether the value of
the field is initial (e.g. field should be reset to initial value) or whether batch input is not necessary for
this field.
If batch input data is not to be assigned to particular fields in the SAP System, the standard batch input
programs expect a special character (NODATA flag). The default special character is '/', but you can
define your own character with the field BGR00-NODATA. You must then initialize the SAP batch
input structures with this special character.
If the fields with the old structures are of a different length or type to the fields with the SAP structures,
the transfer program must perform the conversions. The fields with the SAP batch input structures are
always type C.

Other Tasks of a Transfer Program
© SAP AG
Customer
check tables
Customer
conversion tables
Transfer program
Customer
error tables
There are other tasks that customer transfer programs can perform. Examples: Individual customer data
checks can be made (to see if data should in fact be transferred, for example). Data can be converted
according to defined rules (new numbers in the SAP System are to be assigned to particular numbers in
the legacy system, for example). Incorrect data can be written in a customer error table after the data
checks.

Menu Paths
Financial accounting
global settings
Document
Document data transfer
Create variant for
document data transfer
© SAP AG
Financial accounting Treasury
Accounts receivable and
accounts payable
Consolidation
Vendor accounts Business transactions
Vendor master records Vendor single items
Create vendor master
records
SAP R/3 main menu
Tools
Business Engineering
Customizing
Implement. projects
Display SAP Ref. IMG
Generate record layout Copy vendor master data
The menu paths for finding the data transfer programs are shown for selected applications in the above
diagram. In Release 3.0, you access the Customizing functions via the installation guide.
For detailed documentation on the individual functions, press F1 and/or the extended help function.
...
...
...
...

Example: Transfer Program 1
© SAP AG
REPORT YSFFF04A.
*E SAP structures for BDC:
TABLES: BGR00, BLF00, BLFA1.
*E Old structures:
DATA: BEGIN OF OLDREC,
TELF1(10) TYPE C,
LIFNR(8) TYPE C,
ANRED(2) TYPE C,
NAME1(30) TYPE C,
END OF OLDREC.
*E Help structure for record layout initialization:
DATA: BEGIN OF AUXREC.
INCLUDE STRUCTURE BLFA1.
DATA: END OF AUXREC.
*E Target fields for conversions:
DATA: LIFNR LIKE BLF00-LIFNR,
NAME1 LIKE BLFA1-NAME1,
TELF1 LIKE BLFA1-TELF1.
*E Only for record layout initialization:
DATA: N TYPE I.
FIELD-SYMBOLS .
*E File and session names, nodata flag:
PARAMETERS:
OLDFILE(20) DEFAULT '/tmp/OLD' LOWER CASE,
SAPFILE(20) DEFAULT '/tmp/SAP' LOWER CASE,
ERRFILE(20) DEFAULT '/tmp/ERROR' LOWER CASE,
SESSION(20) DEFAULT 'B420SES041' LOWER CASE,
NODATA DEFAULT '/' LOWER CASE.
The program in the above example transfers telephone numbers from a sequential file. The data records
have the following format: Telephone number (10), vendor number (8), form of address (2), name (30).
The data is checked, converted and formatted so that it can be processed by the standard SAP batch
input program RFBIKR00.
This is a general example. All processing takes places in the same system and in ABAP/4. It would of
course be possible to simplify the data transfer in this particular case.

Example: Transfer Program 2
© SAP AG
START-OF-SELECTION.
OPEN DATASET: OLDFILE FOR INPUT IN TEXT MODE,
SAPFILE FOR OUTPUT IN TEXT MODE,
ERRFILE FOR OUTPUT IN TEXT MODE.
*E Open session:
MOVE: '0' TO BGR00-STYPE,
SESSION TO BGR00-GROUP,
SY-MANDT TO BGR00-MANDT,
SY-UNAME TO BGR00-USNAM,
NODATA TO BGR00-NODATA.
TRANSFER BGR00 TO SAPFILE.
*E Initialize record layout:
DO.
ADD 1 TO N.
ASSIGN COMPONENT N OF STRUCTURE AUXREC TO .
IF SY-SUBRC NE 0. EXIT. ENDIF.
MOVE BGR00-NODATA TO .
ENDDO.
MOVE AUXREC TO BLFA1.
Session data (such as session name, client, user name and the special character for ‘no batch input for
this field’) is passed in table structure BGR00.
The structure BLFA1 is initialized using the ASSIGN statement. Some applications (e.g.MM) also
provide special initialization routines (e.g. INIT_STRUKTUREN_ERZEUGEN in program
RMMMBIMI). For more details, refer to the online documentation for the particular batch input
program.

Example: Transfer Program 3
© SAP AG
DO.
*E Read in data record
READ DATASET OLDFILE INTO OLDREC.
IF SY-SUBRC NE 0. EXIT. ENDIF.
*E Check: Transfer only certain data records
IF OLDREC-LIFNR(5) NE 'BC420'
OR OLDREC-LIFNR(6) EQ 'BC420B'
OR OLDREC-TELF1 EQ SPACE.
TRANSFER OLDREC TO ERRFILE.
*E TEXT-001:'Data not transferred for vendor:'
WRITE: / TEXT-001, OLDREC-LIFNR.
ELSE.
*E Convert: Other vendor numbers in SAP system
IF OLDREC-LIFNR+5(1) = 'A'.
OLDREC-LIFNR+5(1) = 'B'.
ENDIF.
*E Convert: Write out abbreviations in full
CASE OLDREC-ANRED.
WHEN 'Co'. BLFA1-ANRED = 'Company'.
WHEN OTHERS. BLFA1-ANRED = NODATA.
ENDCASE.
When a data record has been read, a check is made to see if the data record should in fact be
transferred. In general, extensive checks are run using a customer check table.
If the check proves negative, the data record is placed in a customer error file.
Some data is then converted. In general, a customer table is also used here.

Example: Transfer Program 4
© SAP AG
*E Convert old format to SAP format
MOVE: OLDREC-LIFNR TO LIFNR,
OLDREC-NAME1 TO NAME1,
OLDREC-TELF1 TO TELF1.
*E Fill SAP structures
MOVE: '1' TO BLF00-STYPE,
'XK02' TO BLF00-TCODE,
LIFNR TO BLF00-LIFNR.
MOVE: '2' TO BLFA1-STYPE,
'BLFA1' TO BLFA1-TBNAM,
TELF1 TO BLFA1-TELF1,
NODATA TO BLFA1-SENDE.
*E Transfer data
TRANSFER: BLF00 TO SAPFILE,
BLFA1 TO SAPFILE.
*E TEXT-002: 'Data transferred for vendor
WRITE: / TEXT-002, OLDREC-LIFNR.
ENDIF.
ENDDO.
CLOSE DATASET: OLDFILE, SAPFILE, ERRFILE.
As the length of the old data is different, it must be converted.
The converted data can then be placed in the SAP structures.
Finally, the SAP structures can be transferred to a sequential file. They can then be analyzed by the
standard batch input program RFBIKR00.
Note: In ABAP/4, a single MOVE is sufficient to convert and fill the SAP structure (every MOVE
statement automatically performs a conversion).

Batch Input, CALL TRANSACTION and Direct
Input
© SAP AG
Batch input queue
Batch input
sessions
External data
ABAP/4
program
CALL TRANSACTION/
USING BDCDATA
Table
R/3 database
Direct input:
Function modules
instead of screens
As an alternative to batch input, there are application-specific programs that use the direct input
technique. When transferring large volumes of data (more than 10000 transactions), you can achieve
considerable improvements in performance with direct input. Like CALL TRANSACTION USING,
direct input is a means of updating data immediately (no sessions are generated). However, unlike
CALL TRANSACTION USING or batch input, no screens are involved. Instead, the data is imported
by calling function modules which check the data and then transfer it directly to the database tables.
Since direct input offers a restart mechanism in the case of an error, the programs can only run as
background jobs. You manage and start these jobs with the report RBMVSHOW or Transaction
BMV0.
Examples:
RFBIBL00 FI Can be switched between direct input, batch input and CALL
TRANSACTION. Posts documents.
RMDATIND MM Direct input. Imports material master records.
RVAFSS00 SD Direct input. Generates SD billing documents and FI follow-on
documents from an external file.
RKEVEXT0CO-PA Direct input. Transfers external data to Profitability Analysis.
RAALTD11 AM Direct input. Creates asset master records.

Tasks of a Transfer Program
© SAP AG
Define old structures
Import SAP structures
Initialize SAP structures
Read data record
Check data
Convert data
Place data in SAP structure
Transfer data record to sequential file
The above diagram gives an overview of the tasks of a transfer program (required and optional).

Data Transfer with Batch Input
© SAP AG
Analyze data
Generate SAP structures
Design transfer program
Create sequential file
Create batch input program
Create batch input session
Analyze results
Evaluate errors
The above diagram gives an overview of the activities required for a data transfer.

Chapter 4 Summary
© SAP AG
l Interface programs are often required to peform fast,
correct mass data processing, in particular the transfer of
data from external systems to the SAP System. This
chapter discussed the problems of this type of data
transfer. Standard application-related transfer programs
have been created for this purpose. The principles and
scope of these programs were explained.

Chapter 5 CALL TRANSACTION
© SAP AG
l CALL TRANSACTION USING ... vs. batch input.
l The statement CALL TRANSACTION USING ... .
l Technical implementation.

Chapter 5 Objectives
© SAP AG
l The difference between CALL TRANSACTION
USING ... and batch input, and the advantages and
disadvantages of the two processes.
l The scope of the CALL TRANSACTION USING ...
statement and the different processing and update
modes.
l The technical features of the CALL TRANSACTION
USING ... statement.

Overview
© SAP AG
Batch input:
Sequential
file
Queue file
Batch input function
Application function
SAP
database
BDC table
CALL TRANSACTION:
Sequential
file
Application function
SAP
database
BDC table
CALL
TRANSACTION
In contrast to batch input, the CALL TRANSACTION statement allows you to pass data directly to the
dialog interface (without using the queue file). To store screen data temporarily, you use an internal
table (a BDC table which has the same structure as with batch input). Then, you call the desired
transaction in your program and the system copies the data temporarily stored the BDC table to the
screens of the transaction.

The CALL TRANSACTION Statement
© SAP AG
CALL TRANSACTION
USING
MODE
UPDATE
MESSAGES INTO
:
A Display all
E Display only if if there are errors
N Display nothing
:
S Do not continue processing until
update has finished (synchronous)
A Continue processing immediately
As with batch input, you can choose a particular display mode for processing the transaction.
Unlike batch input, you can also specify an update mode. In asynchronous update processes, the called
transaction does not wait until the database updates have been performed, but passes the update to the
update task. In synchronous update processes, it waits until the update has been completed. Although
synchronous update is slower than asynchronous update, it is also more secure because the called
transaction can then report any errors to the calling program. In batch imput, the update mode is always
'S' (synchronous).
The MODE and UPDATE parameters are optional. The default for both is ‘A’ (asynchronous).
The MESSAGES INTO option allows you to store any messages output by the called
transaction in an internal table. The internal table must have the structure BDCMSGCOLL.

Technical Implementation
Roll area 1 Roll area 2
REPORT ... .
DATA: BEGIN OF OCCURS ... .
INCLUDE STRUCTURE BDC_DATA.
DATA: END OF .
:
:
PERFORM GENERATE_BDC_DATA.
CALL TRANSACTION
USING
MODE
UPDATE
:
:
CASE SY-SUBRC.
:
:
© SAP AG
The system opens a second roll area for the called transaction. There, it processes the individual screens
and copies the data from the table. When the transaction has finished, the second roll area is released
and the processing continues in the first roll area.
Notes:
In contrast to batch input, there is no error logging. Whether the called transaction is processed depends
on the authorizations of the calling user. The BDC table can only accept data for a single transaction.
This means that before the next transaction call, you must perform a REFRESH on the BDC table and
refill it with data.

Example Program - Define BDC Table
© SAP AG
REPORT RSFFF05A.
DATA:BEGIN OF BDC_TAB OCCURS 5.
INCLUDE STRUCTURE BDCDATA.
DATA: END OF BDC_TAB.
DATA: BEGIN OF MESSTAB OCCURS 5.
INCLUDE STRUCTURE BDCMSGCOLL.
DATA: END OF MESSTAB
PARAMETERS:
DISMODE DEFAULT 'A',
UPDMODE DEFAULT 'S',
ID LIKE SCUSTOM-ID DEFAULT '00000001',
CUSTNAME LIKE SCUSTOM-NAME DEFAULT 'SCHMIDT',
POSTCODE LIKE SCUSTOM-POSTCODE DEFAULT '6900',
CITY LIKE SCUSTOM-CITY DEFAULT 'HEIDELBERG',
CUSTTYPE LIKE SCUSTOM-CUSTTYPE DEFAULT 'B',
DISCOUNT LIKE SCUSTOM-DISCOUNT DEFAULT '10',
TELEFON LIKE SCUSTOM-TELEPHONE DEFAULT '24567'.
You define the BDC table in the declaration part of the program.
This CALL TRANSACTION program corresponds to the BDC program example RSFFF02A.

Example Program - Fill BDC Table
© SAP AG
START-OF-SELECTION.
WRITE: / 'Start CALL TRANSACTION', SY-UZEIT.
PERFORM GENERATE_BDC_DATA.
CALL TRANSACTION 'TFBA'
USING BDC_TAB
MODE DISMODE
UPDATE UPDMODE
MESSAGES INTO MESSTAB.
IF SY-SUBRC = 0.
WRITE: / 'Transaction successfully
processed'.
ELSE.
WRITE: / 'Error when processing'.
ENDIF.
WRITE: / 'Ende CALL TRANSACTION ', SY-UZEIT.
You fill the BDC table as in batch input (in this case with a subroutine - see BDC program
RSFFF02A).
Then, you call the desired transaction.

Return Codes and System Fields
© SAP AG
Return codes:
Value Meaning
0 Successful
< 1000 Error in dialog program
> 1000 Error in batch input processing
(see system fields)
System fields:
Field name Meaning
SY-MSGID Message ID
SY-MSGTY Message type (E,I,W,S,A)
SY-MSGNO Message number
SY-MSGV1 Message variable 1
SY-MSGV2 Message variable 2
SY-MSGV3 Message variable 3
SY-MSGV4 Message variable 4
To find out whether the processing of the called transaction was successful or not, you can read the
return code value. There are also other system fields which contain the number, ID, type and variable of
the dialog message output by the called transaction. You can use this information to display the message
text (see following page).
If you want to see all the messages output by the transaction, you should use the MESSAGES INTO
option and then evaluate the contents of .

Message Output
© SAP AG
REPORT RSFFF05B.
...
CALL TRANSACTION 'TFBA'
USING BDC_TAB
MODE DISMODE
UPDATE UPMODE
MESSAGES INTO MESSTAB.
...
MESSAGE ID SY-MSGID
TYPE SY-MSGTY
NUMBER SY-MSGNO
WITH SY-MSGV1 SY-MSGV2
SY-MSGV3 SY-MSGV4.
...
The MESSAGE statement allows you to output dialog messages of the called transaction through the
calling program.
However, the message which reports the success or failure of the processing is output automatically.
You are recommended to use the MESSAGE statement as above if you are running the program in the
background. In this case, the message is held in the log.

Batch Input / CALL TRANSACTION - Summary
© SAP AG
Batch input CALL TRANSACTION
Return code No Yes
Error logging Yes No
Processing Time-delayed Immediately
Batch input and the CALL TRANSACTION statement are two different options for copying data to
screens in an application transaction.
The above table sets out the various features of these options.

Chapter 5 Summary
© SAP AG
l CALL TRANSACTION USING ... is an alternative to the
conventional batch input process. Direct transfer of data
is particularly fast since the queue file is avoided (i.e. no
sessions are generated).
As with batch input, there is a high degree of data
integrity since the data is imported using transactions.
CALL TRANSACTION has certain advantages over batch
input (e.g. when you chooseupdate mode), but it does not
offer the same correction and administration options as
batch input.

Exercise for Chapter 5: CALL TRANSACTION
1. Name of your job: ZBCF##E1
Name of your directory: /tmp
Your group number: ##
Name of a model file: TELXX
Task:
Write a CALL TRANSACTION program for your file TEL## or
for the model file TELXX. The program should enter the
telephone numbers in the relevant SCUSTOM records using
the Transaction TFBA.
Programming hints:
Convert your batch input program ZBCF##B1 to a CALL
TRANSACTION program. For the Transaction TFBA, use the
following screens in the specified order:
Program name: SAPMTFBA
Screens Fields
0100 SCUSTOM-ID
BDC_OKCODE
0200 SCUSTOM-TELEPHONE
BDC_OKCODE

Model solution for Chapter 5: CALL TRANSACTION
REPORT RSFFF051.
* Internal table to store the data in screen format
DATA: BEGIN OF BDC_TAB OCCURS 5.
INCLUDE STRUCTURE BDCDATA.
DATA: END OF BDC_TAB.
* Internal Table of format BDCMSGCOLL to store the transaction
* messages
DATA: BEGIN OF MESSTAB OCCURS 5.
INCLUDE STRUCTURE BDCMSGCOLL.
DATA: END OF MESSTAB.
* Record for the data to be transferred to the SAP System
DATA: BEGIN OF REC,
PARAMETERS:
TELEPHONE LIKE SCUSTOM-TELEPHONE,
ID LIKE SCUSTOM-ID,
NAME LIKE SCUSTOM-NAME,
END OF REC.
* Name of the sequential file to be accessed
FILE(30) DEFAULT '/tmp/TELXX' LOWER CASE,
* Processing and update mode
DISMODE DEFAULT 'A',

UPDMODE DEFAULT 'S'.
START-OF-SELECTION.
* File opened for reading and in binary mode
START-OF-SELECTION.
OPEN DATASET FILE FOR INPUT IN BINARY MODE.
* Text-001 E: Start CALL TRANSACTION
WRITE: / TEXT-001, SY-UZEIT.
* Accessing data
DO.
READ DATASET FILE INTO REC.
IF SY-SUBRC NE 0.
EXIT.
ENDIF.
WRITE: / REC-ID USING NO EDIT MASK, REC-NAME, REC-TELEPHONE.
* Subroutine in order to tranfer the data of one transaction to
* the BDC_TAB (screen format)
PERFORM GENERATE_BDC_DATA.
* Transaction called together with data in screen format
CALL TRANSACTION 'TFBA'
USING BDC_TAB
MODE DISMODE
UPDATE UPDMODE.
* MESSAGES INTO MESSTAB.

IF SY-SUBRC = 0.
* Text-002 E: Transaction successfully processed
WRITE: TEXT-002.
ELSE.
* Text-003 E: Error in processing
WRITE: TEXT-003.
ENDIF.
MESSAGE ID SY-MSGID
ENDDO.
TYPE SY-MSGTY
NUMBER SY-MSGNO
WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
* Text-004 D: End of CALL TRANSACTION
WRITE: / TEXT-004, SY-UZEIT.
* Close the fully accessed sequential dataset
END-OF-SELECTION.
CLOSE DATASET FILE.
*-----------------------------------------------------------------
*

* FORM GENERATE_BDC_DATA
*
*-----------------------------------------------------------------
*
* ........
*
*-----------------------------------------------------------------
*
FORM GENERATE_BDC_DATA.
REFRESH BDC_TAB.
PERFORM DYNPRO USING:
ENDFORM.
'X' 'SAPMTFBA' '0100',
' ' 'SCUSTOM-ID' REC-ID,
' ' 'BDC_OKCODE' '/5',
'X' 'SAPMTFBA' '0200',
' ' 'SCUSTOM-TELEPHONE' REC-TELEPHONE,
' ' 'BDC_OKCODE' '/11'.
*-----------------------------------------------------------------
*
* FORM DYNPRO
*
*-----------------------------------------------------------------
*

* ........
*
*-----------------------------------------------------------------
*
* --> DYNBEGIN
*
* --> NAME
*
* --> VALUE
*
*-----------------------------------------------------------------
*
FORM DYNPRO USING DYNBEGIN NAME VALUE.
IF DYNBEGIN = 'X'.
CLEAR BDC_TAB.
MOVE: NAME TO BDC_TAB-PROGRAM,
VALUE TO BDC_TAB-DYNPRO,
'X' TO BDC_TAB-DYNBEGIN.
APPEND BDC_TAB.
ELSE.
CLEAR BDC_TAB.
MOVE: NAME TO BDC_TAB-FNAM,
VALUE TO BDC_TAB-FVAL.
APPEND BDC_TAB.
ENDIF.
ENDFORM.

Chapter 6 Local Files
© SAP AG
l Local files vs. files on the application server.
l Standard function modules for generating and
reading local files.
l Linking options between local files and files stored
on the application server.
l Overview: Function modules for working with local
files.

Chapter 6 Objectives
© SAP AG
l The differences between local files and files stored
on the application server and their various uses.
l The different function modules available for
processing local files.

Overview
© SAP AG
Application
server
88MHz
Presentation
server
88MHz
Application server files
Presentation server files
ABAP/4 programs run on the application server and have access to its sequential files.
You can also use an ABAP/4 program to process local files (which belong to the presentation server).

Overview
Application server
files
Presentation server
files
© SAP AG
READ DATASET
TRANSFER
UPLOAD
DOWNLOAD
ABAP/4 program
You process sequential files on the application server in ABAP/4 programs with the READ DATASET
and TRANSFER statements which allow you to copy data from/to a field string.
You process local sequential files on the presentation server with (UPLOAD and DOWNLOAD)
function modules. These copy data from/to an internal table.

DOWNLOAD and UPLOAD
CALL CALL FUNCTION
FUNCTION
DOWNLOAD’ DOWNLOAD’ DOWNLOAD’ DOWNLOAD’
File name:
File type:
© SAP AG
Convert
according to
file type
CALL CALL CALL FUNCTION
FUNCTION
UPLOAD’ UPLOAD’ UPLOAD’ UPLOAD’
File name:
File type:
Convert
according to
file type
The function module DOWNLOAD downloads the contents of an internal table to a local sequential
file.
The function module UPLOAD uploads the contents of a local sequential file to an internal table.
For the local file, you specify the absolute file name (meaning the complete path, e.g.
'/tmp/bc180/myfile' for the UNIX file myfile in the directory /tmp/bc180 or 'C: BC180 MYFILE.ABA'
for the OS/2 file MYFILE.ABA in the directory BC180 on disk drive C).
The directory must be known to the presentation server.
The choice of suitable file names is the reponsibility of the customer.
The system requests the file name and the file type interaktively.
The data is converted according to the file type.

Function Module DOWNLOAD
© SAP AG
CALL FUNCTION DOWNLOAD’ DOWNLOAD’
EXPORTING
BIN_FILESIZE =
CODEPAGE =
FILENAME =
FILETYPE =
ITEM =
MODE =
WK1_N_FORMAT =
WK1_N_SIZE =
WK1_T_FORMAT =
WK1_T_SIZE =
IMPORTING
ACT_FILENAME =
ACT_FILETYPE =
FILESIZE =
TABLES
DATA_TAB =
For the function module DOWNLOAD, you need an internal table for the data transfer. You define this
table according to your data structure at the beginning of the program and then fill it with data.
You use the MODE parameter to define the write mode ('A' to extend a file, ' ' to create a new file).
The specification of default values for the file name, file type and a header for the file dialog is optional.
The IMPORT parameters specify the values actually entered by the user for the file name, file type and
the number of downloaded bytes.
You only specify a value for the export parameter CODEPAGE when performing a DOWNLOAD to
DOS (the only possible value is 'IBM'). Otherwise, this parameter is not used.
All EXPORTING parameters are optional.
If you want to generate a binary file, you must specify the file length. In this case, the transfer table
must consist of a column of type X.

Formats
© SAP AG
Internal table (ABAP/4)
F1 F2 F3
A B C
D E F
. . .
. . .
Spreadsheet
Format DAT
A B C
D E F
. . . . . .
. . . . . .
Internal table (ABAP/4)
F1 F2 F3 . . .
A B C . . .
D E F . . .
G H I . . .
. . .
Spreadsheet
Format WK1
With UPLOAD and DOWNLOAD, another format available for conversions apart from ASC (ASCII)
and BIN (binary) is DAT for Excel. With DOWNLOAD, WK1 is also available for Excel and Lotus.
For the format DAT, table columns are divided by a tabulator character and the table lines by carriage
return and line feed.
For the format WK1, the data of a table is entered in a WK1-specific spreadsheet.

Function Module UPLOAD
© SAP AG
CALL FUNCTION UPLOAD’ UPLOAD’
EXPORTING
CODEPAGE =
FILENAME =
FILETYP =
ITEM =
IMPORTING
FILESIZE = =
TABLES
DATA_TAB =
For the function module UPLOAD, you need an internal table for the data transfer. You define this
table according to your data structure at the beginning of the program.
The specification of default values for the file name, file type and a header for the file dialog is optional.
You only specify a value for the export parameter CODEPAGE when performing a DOWNLOAD to
DOS (the only possible value is 'IBM'). Otherwise, this parameter is not used.

Example Program: DOWNLOAD
REPORT RSFFF06A.
TABLES SFLIGHT.
DATA: BEGIN OF TAB OCCURS 20.
INCLUDE STRUCTURE SBC420A.
DATA: END OF TAB.
* DATA: FILE LIKE RLGRAP-FILENAME
* VALUE '....',
* TYPE LIKE RLGRAP-FILETYPE
* VALUE 'ASC',
* LENGTH(5).
* PARAMETERS:
* MODE DEFAULT 'A'.
GET SFLIGHT.
MOVE-CORRESPONDING SFLIGHT TO TAB.
APPEND TAB.
WRITE: / TAB-CARRID, TAB-CONNID,
/ TAB-FLDATE UNDER TAB-CARRID,
/ TAB-PLANETYPE UNDER TAB-FLDATE.
END-OF-SELECTION.
© SAP AG
This example program generates a local file with SFLIGHT data.
CALL FUNCTION 'DOWNLOAD'
* EXPORTING
* FILENAME = FILE
* FILETYPE = TYPE
* ITEM = 'SFLIGHT data'
* MODE = MODE
* IMPORTING
* ACT_FILENAME = FILE
* ACT_FILETYPE = TYPE
* FILESIZE = LENGTH
TABLES
DATA_TAB = TAB.
* WRITE: / LENGTH, 'bytes downloaded to to file '
* FILE, 'format', TYPE.
When calling DOWNLOAD, it is enough to download the table with the data for the file. However, you
can also specify default values for the file dialog name, type and header. If you make no specification
about the mode, the file is always recreated (parameter MODE = ' ').

Example Program: UPLOAD
© SAP AG
REPORT RSFFF06B.
TABLES SFLIGHT.
DATA: BEGIN OF TAB OCCURS 20.
INCLUDE STRUCTURE SBC420A.
DATA: END OF TAB,
START-OF-SELECTION.
CALL FUNCTION 'UPLOAD'
TABLES
DATA_TAB = TAB.
LOOP AT TAB.
WRITE: / TAB-CARRID, TAB-CONNID,
/ TAB-FLDATE UNDER TAB-CARRID,
/ TAB-PLANETYPE UNDER TAB-FLDATE.
ENDLOOP.
This example program reads a local file with SFLIGHT data.

UPLOAD and DOWNLOAD as Standard
Functions
© SAP AG
List
Function DOWNLOAD
ABAP/4 Editor
00001
00002
00003
. .
. .
. .
Function UPLOAD
DOWNLOAD
You can call the function DOWNLOAD from a list (choose System -> List -> Save -> Local file) or
from the ABAP/4 Editor to download a list or an ABAP/4 program to a local file
This process supports certain formats.
You can call the function UPLOAD from the ABAP/4 Editor to upload an ABAP/4 program from a
local file to the ABAP/4 Editor.

Sequential File and Local File
Sequential
file
© SAP AG
TRANSFER
READ DATASET
CALLFUNCTION
DOWNLOAD’ DOWNLOAD’
CALLFUNCTION
UPLOAD’ UPLOAD’
Local sequential
file
You can use READ DATASET and DOWNLOAD to copy the contents of a sequential file to a local
sequential file via an internal table.
Conversely, you can use UPLOAD and TRANSFER to transfer data from a local sequential file to a
sequential file.

UPLOAD / DOWNLOAD - Summary
DOWNLOAD
WS_FILENAME_GET
© SAP AG
WS_DOWNLOAD
Download data
Download data
Logical file name
Read data
Read data
Get file name Get file name
Physical
file name
Execute
program
WS_EXECUTE
Get
file size
WS_UPLOAD
UPLOAD
WS_QUERY
Environment variables
The function modules UPLOAD and DOWNLOAD are a convenient way of processing local files
because they perform all the necessary activities automatically. The user is requested to specify the file
name and type interactively.
There are also other function modules you can use for file processing. These include the following:
WS_DOWNLOAD and WS_UPLOAD:
Like DOWNLOAD, except that the file name and type are not specified interactively and exceptions
must be handled by the calling program.
WS_QUERY:
checks the existence and size of a file, as well as other environment variables.
WS_EXECUTE:
starts a program on the presentation server.

Chapter 6 Summary
© SAP AG
l The R/3 System allows you to generate local files on the
frontend or the presentation server and process them
further. It provides several standard function modules
which are especially suited to this purpose. You can also
exchange data between frontend files and application
server files.

Exercises for Chapter 6: Local Files
1. Name of your job: ZBCF##F1
Your group number: ##
Name of your host directory: /tmp
Name of a host model file: BOOKXX
Name of your local directory: /tmp
Name of your local file: LOC##
Task:
Write a program which downloads your file BOOK## to the
local file LOC##.
2. Name of your program: ZBCF##F2
Your group number: ##
Name of your local directory: /tmp
Name of your local file: LOC##
Task:
Write a program which reads your local file LOC## and
displays it on the screen.

Model solutions for Chapter 6: Local Files
1.
REPORT RSFFF061.
* Internal table for local dataset defined as Dictionary structure
* or include report
DATA: BEGIN OF TAB OCCURS 20.
INCLUDE STRUCTURE SBC420C.
DATA: END OF TAB.
* STRUCTURE SBC420C:
* CARRID, CONNID, FLDATE, BOOKID, CUSTOMID.
* Alternative:
* INCLUDE RSFFF01L.
DATA: TYPE LIKE RLGRAP-FILETYPE VALUE 'ASC',
LENGTH(5).
* Create the selection screen
PARAMETERS:
HOSTFILE LIKE RLGRAP-FILENAME DEFAULT '/tmp/BOOKXX',
* LOCLFILE LIKE RLGRAP-FILENAME DEFAULT '/tmp/BC420LOCXX', "UNIX
LOCLFILE LIKE RLGRAP-FILENAME DEFAULT 'C:BC420LOCXX.ABA',
"NT/OS2
MODE DEFAULT 'A'.
START-OF-SELECTION.
* Text mode because /tmp/BOOKXX was created in text mode
OPEN DATASET: HOSTFILE FOR INPUT IN TEXT MODE,

LOCLFILE FOR OUTPUT IN TEXT MODE.
* Access data in application server file and store in an
* internal table
DO.
CLEAR TAB.
READ DATASET HOSTFILE INTO TAB.
IF SY-SUBRC NE 0. EXIT. ENDIF.
APPEND TAB.
WRITE: / TAB-CARRID, TAB-CONNID,
ULINE.
ENDDO.
/ TAB-FLDATE, TAB-BOOKID, TAB-CUSTOMID.
* Call function module DOWNLOAD. Data is downloaded using an
* internal table TAB together with the file name and file type
* The length of the file generated in this way is returned.
CALL FUNCTION 'DOWNLOAD'
EXPORTING
FILENAME = LOCLFILE
FILETYPE = TYPE
* ITEM = 'SFLIGHT data'
MODE = MODE
IMPORTING
* ACT_FILENAME = FILE
* ACT_FILETYPE = TYPE
TABLES
FILESIZE = LENGTH
DATA_TAB = TAB.

2.
*E Text-001: 'In file:'
*E Text-002: 'Format'
*E Text-003: 'bytes were downloaded'
WRITE: / TEXT-001, LOCLFILE, TEXT-002, TYPE,
REPORT RSFFF062.
LENGTH, TEXT-003.
* Internal table for local dataset defined as Dictionary structure
* or include report
DATA: BEGIN OF TAB OCCURS 20.
INCLUDE STRUCTURE SBC420C.
DATA: END OF TAB.
* STRUCTURE SBC420C:
* CARRID, CONNID, FLDATE, BOOKID, CUSTOMID.
* Alternative:
* INCLUDE RSFFF01L.
DATA: TYPE LIKE RLGRAP-FILETYPE VALUE 'ASC',
LENGTH(5).
* Create the selection screen
PARAMETERS:
* LOCLFILE LIKE RLGRAP-FILENAME DEFAULT '/tmp/BC420LOCXX', "UNIX
LOCLFILE LIKE RLGRAP-FILENAME DEFAULT 'C:BC420LOCXX.ABA'.
"NT/OS2
START-OF-SELECTION.

* Call the function module UPLOAD. Pass the name of the file to be
* accessed and its type. Returns the data in form of an internal
* table with the length of the file accessed.
CALL FUNCTION 'UPLOAD'
EXPORTING
FILENAME = LOCLFILE
FILETYPE = TYPE
* ITEM = 'SFLIGHT data'
IMPORTING
TABLES
FILESIZE = LENGTH
DATA_TAB = TAB.
* Output the internal table
LOOP AT TAB.
WRITE: / TAB-CARRID, TAB-CONNID,
ULINE.
ENDLOOP.
/ TAB-FLDATE, TAB-BOOKID, TAB-CUSTOMID.
*D Text-001: 'From file:'
*D Text-002: 'Format'
*D Text-003: 'bytes were read'
WRITE: / TEXT-001, LOCLFILE, TEXT-002, TYPE,
LENGTH, TEXT-003.

© SAP AG
Appendix IV

© SAP AG
Batch Input
Buchen Post
document Beleg
Input file
RFBIDE00
RFBIKR00
RFBISA00
RFBIBL00
session XX
DIALOG interface
Batch
input
The reports RFBIDE00, RFBIKR00, RFBISA00 and RFBIBL00 support automatic import of data
from external or legacy systems.
RFBIDE00 transfers customer master data and creates bank master data and credit limits.
RFBIKR00 transfers vendor master data and creates bank master data.
RFBISA00 transfers G/L account master data creates bank master data.
RFBIBL00 transfers documents (posting and settlement).
For further online documentation, choose Help -> R/3 library -> Financial Accounting -> Automatic
Procedures -> Batch Input

Batch Input Flow
© SAP AG
SAP unknown data SAP known data
Interface program
BI Format
SAP transfer programs
BI interface
e.g. - recurring entries
- cashed checks
SAP transfer programs
You must create an interface program to convert non-SAP data to a format recognized by SAP.
The required record structures are defined in the ABAP/4 Dictionaryt (e.g. BBKPF, BBSEG). By using
a Customizing function, you can format the record layout in the Cobol, PL1, and C programming
languages.

© SAP AG
Batch Input Structures
Typ 0 Session data
Typ 1 Transaction code and header data
Typ 2 Batch input data per table
Naming convention:
B T T T T
Batch input Table name
Examples
BGR00
BLF00
BBKPF
BLFA1
BBSEG
For each supported database table, there is an associated batch input structure.
Batch input structures are stored in the ABAP/4 Dictionary.
A batch input structure begins with the letter 'B' followed by the name of the table for which batch input
data is determined.
For each input field on a screen, there is a batch input field in the batch input structure.
The special character "/" means:
'No batch input for this field'.

© SAP AG
Master Data
Transaction f r
Create XK01 / XD01
Change XK02 / XD02
Lock XK05 / XD05
Flag for deletion XK06 / XD06
Structures ( using vendor as an example )
BGR00 Type 0 Session data
BLF00 Type 1 Transaction code,
key fields
BLFA1 Type 2 General data
BLFBK Type 2 Bank connections
BLFB1 Type 2 Company code data
BLFB5 Type 2 Dunning data
BLFM1 Type 2 Purchasing data
The central transactions listed above are supported for customers and vendors.
Depending on what is specified in the key fields of the type 1 record, the type 2 records are expected.
The structures of type 2 records do not contain the key fields of the underlying database table.
The key fields are obtained from the structures of the type 0 and type 1 records.

Example of Batch Input 1
:
© SAP AG
BGR00
BLF00
BLFA1
BLF00
BLFA1
BLFB1
BLF00
0 session - XX 001
1 XK02 0000004711 / / /
2 BLFA1 / New name /
1 XK02 0000004712 0001 / /
2 BLFA1 /
2 BLFB1 /
. . .
. . . New city /
. . .
. . .
ZB00 /
Since there are several type 2 structures, the table name must also be passed.
The bank connections are stored in a multiple case table. For this reason, there may be several records
with the structure BLFBK (BKNBK) for each transaction.
To delete a bank connection, you must set the delete flag in the structure BLFBK (BKNBK).
. . .
. . .

Documents
© SAP AG
Transaction
FB01 Post document
FB05 Post with clearing
Structures
BGR00 Type 0 Session data
BBKPF Type 1 Transaction code
and header data
BBSEG Type 2 Document segment data
BSELK Type 2 Selection header data
BSELP Type 2 Selection item data
The general posting and clearing transactions are supported.

:
© SAP AG
BGR00
BBKPF
BBSEG
BBSEG
BBKPF
BBSEG
BBKPF
Example of Batch Input 2
0 Session - XX 001
. . .
1 FB01 TTMMJJJJ DR 0001
2 BBSEG 01 0000004711 / / 1000
2 BBSEG 50 Revenues / / 1000
1 FB01 TTMMJJJJ KR 0001
2 BBSEG 31 0000004712 / / 2000 . . .
BBSEG 2 BBSEG 40 Expenses / / 2000 . . .
The structure BBSEG contains all the fields of the structure BSEG and also includes the CPD data or
the data of the differing payment recipient and the data for additional screens.
You can pass amount fields with a decimal comma.
. . .
. . .
. . .
. . .

Transfer Options per Company Code
© SAP AG
Transfer date
Status
Residual value
Determine
for each
company code
Calculate cum. insurable value
Sequence of depreciation areas
for transfer of legacy data
For each company code, you define the following:
- Transfer date
- Status
- Residual value
- "Calculate cum. insurable value" option
- Sequence of depreciation areas for transfer of legacy data
You can transfer assets from the old system starting at any point in the past. When transferring legacy
data less than a year old, it is possible to list the transactions from the last fiscal year closing up to the
time of the transfer at the time of the transfer.
If you did not maintain insurable values in your legacy system, you can calculate them when
transferring the data. When determining the sequence, the depreciation areas should first appear on the
screen with values which have for the most part been entered manually. Explicit values must be entered
both in the area of book depreciation and in investment areas. In the remaining areas, you can transfer
values from external areas and excude the option to change values.
For further online documentation, choose Help -> R/3 library -> Financial Accounting -> Asset
Accounting - System Administration -> Organizational Elements.

Transfer Options per Depreciation Area
© SAP AG
Determine
for each
depreciation
area
Replacement value
Cum. depreciation
Transfer of legacy data less than a
year old - last depreciation posting
period of legacy system
For each depreciation area, you define the following options:
“Calculate cum. replacement value"
“Recalculate cum. depreciation"
With legacy data less than one year old, the date of the last depreciation posting run in the legacy
system
If you did not maintain replacement values in your legacy system, you can calculate them when
transferring the legacy data, provided the depreciation area allows this.
You can use the option "Recalculate cum. depreciation" for test purposes.
When listing cum. values, you can enter the residual value instead of the cum. depreciation. The system
then determines the cum. depreciation at the time of transfer from the difference between the acquisition
value and the net book value.
If the depreciation has already been posted in the legacy system for legacy data less than one year old,
you can store the last posting period in the depreciation area.

© SAP AG
Automatic Transfer of Legacy Data
Legacy system
Interface program
Transfer program RAALTD01
Legacy data in transfer format
BALTD and BALTB
error-free records records with errors
D I A L O G I N T E R F A C E
ANLH
ANLA
ANLB
ANLC
.
An interface program is used to convert data from a legacy system to the format of the Dictionary tables
BALTD (master data) and BALTB (transaction data) and copy it to a sequential file.
The legacy data transfer program RAALTD01 starts a legacy data transfer transaction in the
background for error-free records. Records containgin errors are stored in the form of a batch input
session and must be processed again later.
Batch
input
The documentation of the program RAALTD01 contains precise instructions
for setting up the sequential transfer file with the interface program,
test options,
avoiding errors and interpreting those which occur,
procedure in the case of a program termination.

Transferring Assets
© SAP AG
Account control in production FI
Before AM import
Vendor Asset bal. (can be directly posted)
After AM import
1000 1000
Vendor Asset
1000 1000
Asset bal. (recon. account only)
After import, the G/L accounts must be changed from “directly postable” to “reconciliation account
only”.
1000
(RACKONT2)
T ools Business Engineering Customizing
Implement. projects SAP Reference IMG ... ”

Sequential file SAP data structure
R/3 System Batch input
session
© SAP AG
Data Transfer
External system Prices/
conditions
Transaction 1
Screen 1 Screen 2
SAP format
SAP
condition records
Customer-specific
Customer-specific
conversion conversion program
program
SAP SAP data data transfer transfer
program
program
Process Process session session
Transaction 2
. . . . . .
Screen 1 Screen 2
SAP provides transfer programs (batch input) for transferring data from legacy systems.
Data to be transferred to the R/3 System must be placed in a sequential file and the records must have
SAP structure and format. The data is transferred from the legacy system to the sequential file by a
subroutine created by the customer. Using an SAP program, you can generate data declarations in
different programming languages for SAP tables and make use of these for your conversion program.
The SAP transfer program (batch input) reads the data from the sequential file, retrieves it for transfer
to the R/3 System and uses it to create a batch input session.
When the session is processed, the data is transferred to the R/3 System. Here, a user dialog is
simulated so that the same checks are performed as in a dialog.
There are data transfer programs for
- Customer master records
- Vendor master records
- Material master records
- Condition records
- Open orders

Overview of Background Processing
© SAP AG
Features
Execution of ABAP/4 programs without dialog or
operating sytem-specific Job Control Language
Complete integration into the R/3 System
Parallel running of background and online processing
Easy to use
Distributed processing
If an ABAP/4 report has to process large volumes of data and long, complex lists, you should execute it
as a background job.

Phases of Background Job Processing
© SAP AG
Job
scheduling
Job
running
Job
overview
To execute a program in the background, you must first include it in a job.
When scheduling jobs, you define which reports you want to run. You can specify when the job is to be
executed and the print parameters.
The job can only be executed when it has been released by the administrator.
You can display jobs and manage them in the overview facility. You can display and maintain logs
generated by background processing.
Jobs are executed in special work processes.

Scheduling Background Jobs
Job name ......................
.
.
.
© SAP AG
Job Job definition definition
Save
Save
You create a job with the Job definition function.
Steps Steps
Print Print specifications
specifications
Start Start time time
Period
Period
To proceed, choose System -> Services -> Jobs or System -> Services -> Reporting -> Program ->
Background, or call Transaction SM36.
To make the request, you need to specify a job name (any name you like), the name of the program to be
started and a variant, as well as the name of a user for authorization checking purposes.
The scheduling part ends when you Save. Before doing this, you can specify the start time, how often
the job is to be repeated and the print parameters.
You can extend an existing job to include more steps. When doing this, you get a step list which you can
edit to suit your requirements.
In distributed environments, you can specify a target machine where the processing is to take place
(choose this by pressing F4).
By specifying a job class, you can determine the priority and type of a job.