Data Interfaces Application Development in the ABAP/4 Development Workbench Week 4

Transcription

1 R Data Interfaces Application Development in the ABAP/4 Development Workbench Week 4

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

3 Chapter 1 Basic Techniques l l l Overview of linking options Overview of Basis interfaces Overview of basic components

4 Chapter 1 Objectives l l Main terms and components for communications interfaces. 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)

5 Linking Options Overview 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.

6 Basis Interfaces of the R/3 System R/3 System Database server Application server 1 Frontend (SAPGUI)... 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

7 Indirect Communication I Data transfer using files w READ DATASET <path> INTO <rec> w TRANSFER <rec> TO <path> 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: in the Reads a file in the file system where the SAPGUI is running into an internal table R/3 System. WS_DOWNLOAD: Stores the contents of an internal table as a file on the SAPGUI machine.

8 Indirect Communication II Batch input seq. file Read sequential file Batch input preparation Import data R/3 System MM PP SD R/3 FI CO AM QM PM HR Client / Server ABAP/4 IS WF PS Batch input is based on file transfer with additional update. 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.

9 Transferring Time-critical Data Example: Local warehouse Warehouse A Warehouse B MM PP QM PM SD R/3 Client / Server ABAP/4 HR FI IS CO WF AM PS 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.

10 Direct Communication I Program-to-program communication (CPI-C) Phase Local warehouse Central computer system II Set up connection Connection setup accepted II III Data transfer Close connection "Goods xyz received" ok 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.

11 Direct Communication II Remote call to a routine (RFC) 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.

12 Direct Communication Techniques - OLE OLE Remote Function 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.0- compatible applications can communicate with R/3 3.0 via this interface. SAP s implementation of the OLE layer is based on RFC API commands.

13 Network: TCP/IP and SNA LU6.2 R/3 TCP/IP TCP/IP - R/2 - External systems SNI (BS2000) Windows NT UNIX TCP/IP R/3 SNA LU6.2 - R/2 - External systems IBM Host systems Communication is possible between SAP applications and with external 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.

14 ISO-OSI 7-Layer Model RFC CPI-C 7 6 LU6.2 (APPC) TCP/IP (sockets) SDLC Ethernet Token Ring X.25 Ethernet Token Ring 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.

15 SAP Gateway (CPI-C Handler) PP QM MM PM R/3 SD R/3 Client / Server ABAP/4 HR FI IS CO WF AM PS PP QM MM PM R/3 SD R/3 Client / Server ABAP/4 HR FI IS CO WF AM PS SAP gateway IBM/SNI host R/2 External program The SAP gateway is used for every CPI-C or RFC communication. 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.

16 Side Information Tables Contents: Symbolic destination Partner LU Partner program > addressed in the program ---> target machine or Logical Unit (SNA) ---> name of partner program Side information tables R/3 R/2 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.

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

18 Chapter 2 Linking Options l l l Communication between R/3 Systems Communication between R/3 and R/2 Systems Communication between R/3 and external systems

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

20 Communication Between SAP Systems R/3 R/3 IBM SNI R/2 R/2 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) The question of which system sets up the connection will also be discussed in more detail.

21 Communication: R/3 External Programs 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.

22 Technical Representation of the SAP Gateway Functionality of the SAP gateway R/3 R/3 gwrd gwrd dispatcher gwwp dispatcher gwhost LU6.2 TCP/IP R/2 (IBM) R/2 (SNI) X1SA X1SA gwrd 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.

23 SAP Side Information Tables (CPI-C) R/2: XCOM XCOM DEST LU TP... TGB LU1 CP1C2 R/3: TXCOM TXCOM DEST LU TP Prot... ABC LU2 CPIC2 E UNIX NT Windows OS/2 sideinfo DEST = GWHOST GWHOST = is0001 GWSERV = sapgw00 LU = hw5001 TP = sapgw00 PROTOCOL = 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.

24 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 MAN User name Password S Argument of table XCOM BC Miller Demo D TGB 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.

25 Communication Between Two R/3 Systems hs5001, sapgw00 hs5101, sapgw01 System T01 System T02 TCP/IP Table TXCOM (T01) Dest LU TP Prot Gateway host Gateway service BC415A hs5101 sapgw01 I BC415B hs5101 sapgw01 I hs5101 sapgw01 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.

26 Communication Between R/3 and R/2 R/3 IBM SNI IMS CICS DCAM UTM R/2 R/2 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.

27 R/3 R/2 Communication (IBM) hs5001 UNIX, NT (T01) R/3 ABAP/4 Connection setup from R/3 hs5002 SAP gateway SNA subsystem Host (K50) R/2 ABAP/4 TCP/IP (remote) shared memory (local) LU6.2 Table RFCDES (T01) Gateway options RFC destination K50 Gateway host: hs5002 Connection type 2 Gateway service: sapgw00 Table TXCOM (T01) Dest LU TP Prot Gateway host Gateway service K50 C hs5002 sapgw00 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.

28 R/2 R/3 Communication (IBM) Connection setup from R/2 hs5000 hs5001, sapgw00 Host (K50) R/2 ABAP/4 LU6.2 SNA subsystem Progr: gwhost SAP gateway TCP/IP (remote) shared memory (local) UNIX, NT (T01) SAP gateway R/3 ABAP/4 Table XCOM (K50) Side info from gwhost Dest LU TP T01 MP30 T01 (hs5000) DEST = T01 LU = hs5001 TP = sapgw00 GWHOST = hs5001 GWSERV = sapgw00 Protocol = I 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.

29 R/3 R/2 Communication (SNI) Connection setup from R/3 UNIX, NT (T01) R/3 ABAP/4 TCP/IP BS2000 (K50) SAP gateway R/2 ABAP/4 Table RFCDES Gateway options 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]).

30 R/2 R/3 Communication (SNI) Connection setup from R/2 BS2000 (K50) R/2 ABAP/4 Progr: gwhost TCP/IP hs5001, sapgw00 UNIX, NT (T01) SAP gateway R/3 ABAP/4 Table XCOM (K50) Side info from gwhost Dest LU TP Comm. type BS2R3 T01 H Dest = T01 LU = hs5001 TP = sapgw00 GWHOST = hs5001 GWSERV = sapgw00 Protocol = I The connection is set up via the SAP gateway of the R/3 System. 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=<program name>(gwhost) LU=<target machine> (host name_1) TP=<dispatcher> (sapdpxx) GWHOST=<GW machine> (host name_2) GWSERV=<GW services> (sapgwyy) Protocol=<I> (I) For an RFC connection, you need the appropriate entry in the table RFCD.

31 R/3 External Program (UNIX) External program on SAP-supported UNIX platforms hs5001, sapgw00 hs5002, sapgw01 UNIX (T01) R/3 ABAP/4 UNIX SAP gateway UNIX External program TCP/IP (remote) shared Memory (local) TCP/IP Table RFCDES (T01) Table TXCOM (T01) Gateway options 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 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.

32 R/3 External Program (TCP/IP) l Systems not supported by SAP, but accessible via TCP/IP UNIX, NT R/3 SAP gateway CPI-C / RFC socket program TCP/IP External socket program DEC OpenVMS HP MPE IBM host system IBM AS400 SNI host 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).

33 R/3 External Program (Windows NT) UNIX, NT R/3 SAP gateway NT SAPgui exec SAPgui data stream (TCP/IP) External program TCP/IP NT SAP gateway External program Windows NT supports the CPI-C and RFC interfaces. 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

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

35 R/3 External Program (WfW, Windows 3.1) SAPgui data stream (TCP/IP) UNIX, NT R/3 SAP gateway SAPgui Windows exec External 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.

36 R/3 External Program (OS/2) UNIX, NT UNIX, NT R/3 SAP gateway SAPgui data stream (TCP/IP) TCP/IP OS/2 OS/2 SAPgui exec External program External 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.

37 R/3 IBM Host / AS400 External program based on IBM CPI-C or APPC UNIX OS/2 UNIX NT R/3 SAP gateway SNA subsystem LU6.2 LU6.2 IBM host AS400 APPC CPI-C APPC CPI-C 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.

38 External Program (TCP/IP) R/3 hs5001, sapgw00 T01 External program SAP gateway TCP/IP R/3 ABAP/4 Side info of the external program Dest = T01 LU = hs5001 TP = sapgw00 GWHOST = hs5001 GWSERV = sapgw00 Protocol = I 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/<sid>/dvebmgs00/data) and defined for the SAP gateway ID (<SID>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=<Symbolic destination> GWHOST=<GW machine> GWSERV=<GW services> PROTOCOL=<I> LU=<Target machine> TP=<Gateway>

39 External Program (LU6.2) R/3 External system External program LU6.2 SNA subsystem Program: gwhost SAP gateway TCP/IP (remote) shared memory (local) hs5001, sapgw00 UNIX, NT (T01) SAP gateway R/3 ABAP/4 Side info from gwhost Dest = T01 LU = hs5001 TP = sapgw00 GWHOST = hs5001 GWSERV = sapgw00 Protocol = I 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.

40 Gateway Monitor Gateway connection table (SAP system) LU name TP name User Status Symb.dest Conv ID... hs1234 sapgw01 BC CONNECTED X hs2345 sapgw01 LOTZ CONNECTED X hs2345 sapgw01 TILLINGER CONNECTED X Gateway connection table (operating system) No. CLIENT (LU/TP) USER STATE SDEST CONNID hs1234 sapgw01 BC CONNECTED X hs2345 sapgw01 LOTZ CONNECTED X hs2345 sapgw01 TILLINGER CONNECTED X 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/<sid>/sys/profile/<sid_instance> gwmon pf= /usr/sap/<sid>/sys/profile/<sid_instance>.

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

42 Chapter 3 Remote Function Call l l l Synchronous RFC Asynchronous RFC Transactional RFC

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

44 Supporting RFC on Heterogenous Platforms R/3 RFC RFC RFC R/2 R/3 External system RFC RFC for R/2 systems is available from Release 5.0E. RFC for R/3 systems is available from Release 2.0. 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).

45 RFC Features Automatic data conversion Automatic logon to the SAP partner system Automatic conversion of all RFC data types Automatic communication flow control Development environment: Remote debugging RFC 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.

46 ABAP/4 Function Modules Function Library FM maintenance FM_02 Interface Import Export Tables Exceptions Program Documentation Administration 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 (*).

47 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 t CALL FUNCTION 'TEST' EXPORTING f1 = a1 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.

48 External Functions External program... Call RFC function A... Function 1 (Prg. routine) Function 2 (Prg. routine)... 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.

49 REMOTE FUNCTION CALL (RFC) SAP system A ABAP/4 program... CALL FUNCTION 'FUNC' DESTINATION 'DEST' EXPORTING IMPORTING CHANGING TABLES f1 = a1 f2 = a2 f3 = a3 t1 = tab EXCEPTIONS COMMUNICATION_FAILURE = 1 SYSTEM_FAILURE = 2... 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.

50 ... Function Modules: RFC Capability l l Transaction: SE37, Administration RFC-enabled function modules Process type Normal Remote Function Call supported Update with immediate start 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.

51 Table RFCDES 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 Connections via ABAP/4 driver You edit the table RFCDES with transaction SM59. 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 X Partner is an external RFC program based on TCP/IP. 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).

52 Destinations BACK, SPACE and NONE System A System B... CALL FUNCTION 'B' DESTINATION 'B' FUNCTION B FUNCTION A.... CALL FUNCTION 'A' DESTINATION 'BACK' ENDFUNCTION. Result A... Result B ENDFUNCTION. 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.)

53 Remote Debugging R/3 A REPORT CUGE. PARAMETERS... DATA... CALL FUNCTION 'RFC_CUSTOMER_GET' DESTINATION 'B'... R/3 B FUNCTION RFC_CUSTOMER_GET. DATA... SELECT * FROM KNA ENDFUNCTION.... Remote debugging is possible between two R/3 systems. 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.

54 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.... 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).

55 Asynchronous RFC with Return of Data R/3 server A R/3 server B (same or other R/3) PROGRAM RS 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.... FUNCTION FUNC1.... ENDFUNCTION. AT USER-COMMAND.... 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.

56 Asynchronous RFC: Parallel Processes PROGRAM PARAL 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.

57 RFC Dialog R/3 System 1 R/3 System 2 Variant 1: Synchronous PROGRAM RS CALL FUNCTION 'DIALOG'. DESTINATION FUNCTION DIALOG.... CALL SCREEN '100'.... ENDFUNCTION. Screen 100 Screen 100 Variant 2: Separated PROGRAM RS CALL FUNCTION 'DIALOG'. DESTINATION... STARTING NEW TASK 'A'... Caller session 1st session Screen 100 2nd session 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.

58 Transactional RFC (trfc) R/3 SD FI MM CO PP R/3 AM Client / Server QM ABAP/4 PS PM WF HR IS Table RFCDES: TRFC options R/3 Automatic job scheduling Job trfc Function module(s) SD FI MM CO PP R/3 AM Client / Server QM ABAP/4 PS PM WF HR IS Program with trfc Administration tables DB Administration transaction SM58 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

59 trfc Syntax PROGRAM ASYN 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.

60 trfc: Tables and Scheduling ABAP/4 progam CALL FUNCTION... IN BACKGROUND TASK EXPORTING... TABLES... CALL FUNCTION... IN BACKGROUND TASK EXPORTING... TABLES... ARFCSSTATE ARFCSDATA DB COMMIT WORK. Transaction SM58 Transactional RFC Log file Caller FM Target system Date Time Status PAUL xyz R3B 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.

61 RFC Between R/3 and External Programs R/3 System External system ABAP/4... CALL... FUNCTION... DESTINATION... External RFC server program Function module RFC FUNCTION... ENDFUNCTION. 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.

62 External RFC Program: Client 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).