BAPI Development For Accessing SAP

Haga clic para modificar el estilo de título del patrón
z Haga clic para modificar el estilo de texto del patrón

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
BAPI Development for Accessing SAP
 Offilog 2001 Universidad (Salvador Seda) / 1
Course Overview - 1
Objetivos del curso
A la finalización del curso será capaz de:
• Identificar
z Haga clic para modificarObjetos dede
el estilo negocio
texto del patrón
• Identificar y utilizar las BAPIs
z Segundo nivel
• Crear RFCs
z Tercer nivel
• Ampliar la funcionalidad de las BAPIS
z Cuarto nivel
• Utilizar las BAPIs en el entorno ALE
z Quinto nivel
Course Overview - 2
Contenido del curso
Introducción
z Haga
Unidad 1 clic para modificar
Conceptos el estilo
básicos BAPIde texto del patrón
z Segundo
Unidad 2 nivel
Creación Módulos de función RFC
z Tercer
Unidad 3 nivelObjetos de negocio
z Cuarto
Unidad 4 nivelUtilización de BAPIs
z Quinto
Unidad 5 nivelAmpliaciones y modificaciones
Unidad 6 BAPIs y ALE
Course Overview - 3
Contenido del curso
Introducción
z Haga
Conceptos el estilo
z Segundo
Unidad 2 nivel
z Tercer
z Cuarto
z Quinto
Course Overview - 4
Escenarios de integración
A la finalización de la introducción será capaz de:

z Haga clic para modificar
• Entender el estilo
varios de texto
escenarios del patrónentre
de integración
SAP y sistemas no-SAP.
z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
Course Overview - 5
Interfaces

BAPIel estilo de texto del patrón
ALE
z Segundo nivel
E DI
z Tercer nivel
z Cuarto nivel
z Quinto nivel OLE
Open Interfaces
RFC
CPI-C
TCP/IP LU6.2
mySAP.com is an open system. It supports a variety of network communication protocols. Information

can be exchanged between component systems and non-SAP applications.
SAP supports the Transmission Control Protocol / Internet Protocol (TCP/IP) and System Network
Architecture: Logical Unit 6.2 (SNA LU6.2) protocols. Communication within mySAP.com uses the
standard protocol TCP/IP. LU6.2 was developed by IBM and is used to communicate with mainframe-
based SAP R/2 Systems.
SAP R/3 application programming supports the following communication interfaces: common
programming interface communication (CPI-C), remote function call (RFC), and object linking and
embedding (OLE) automation. Other interfaces are based on these technologies, for example
communication using Business Application Programming Interfaces (BAPIs), Electronic Data Interchange
(EDI) or according to an Application Link Enabling (ALE) distribution model.
For more information about communication, see the online documentation. You can also order a free
“Interface Adviser” Knowledge CD from SAP that uses many practical examples to explain
communication in mySAP.com Systems. See also the SAP Service Marketplace, which contains additional
information, such as under the alias /int-adviser.
Course Overview - 6
Remote Function Call
R/3 System Externes System R/2 System

ABAP External ABAP
z Segundo Program
nivel Program Program
z Tercer
RFCnivel
Interface RFC Interface RFC Interface
z Cuarto nivel
z Quinto nivel
RFC Interfaces
ABAP Program ABAP Program ABAP Program
R/3 System
Remote Function Call (RFC) is a communications interface based on CPI-C, but with more functions and
easier for application programmers to use. You can use SAP R/3 and SAP R/2 Systems as well as external
applications as RFC communication partners. For more information, see SAP Notes 13903 and 116051.
RFC is the protocol for calling special subroutines (function modules) over the network. Function modules
are comparable with C functions or PASCAL procedures. They have a defined interface through which
data, tables and return codes can be exchanged. Function modules are managed in the SAP R/3 System in
their own function library, called the Function Builder (transaction SE37).
The Function Builder provides application programmers with a useful environment for programming,
documenting and testing function modules that can be called locally as well as remotely.
You maintain the parameters for RFC connections using transaction SM59. The SAP R/3 System is also
delivered with an RFC-SDK (Software Development Kit) that uses extensive C libraries to allow external
programs to be connected to the SAP R/3 System.
Course Overview - 7
Objetos de negocio
Haga clic y BAPIs
para modificar el estilo de título del patrón
BOR: Business Object Repository BAPIs are used for:
Distributed scenarios (ALE)
contains
z Segundo nivel mySAP.com HR FI

BAPI
BAPI
Components
z Tercer nivel
BAPI
BAPI CO
BO
BO BAPI
BAPI
BAPI BO
BAPI BO
z BO: Business
Cuarto Object
nivel BOR Internet/Intranet
For example, sales
BO
BO order
z Quinto nivel BAPI
BAPI
BO
BO
BAPI
BAPI
BO
BO
contains
BAPI
BAPI
method
Business Workflow
External Programs
BAPI: Business Application

Programming Interface
BAPI
BAPI
For example, create an order Customer and Partner Developments
...
Business objects form the basis for communicating on high (user-friendly) network layers. For example,
they enable the SAP R/3 System to support the Internet and desktop programs to be connected. The goal
of SAP’s object-oriented strategy is to integrate objects at a business level rather than on a purely technical
level. You can create and manage business objects using transaction SWO1.
Business objects:
y Form the basis of well-defined communication between client / server systems.
y Are business-oriented: there are objects such as “customer”, “order” or “employee”.
y Provide business functions (methods). For a “customer” object, for example, there are
“Create customer” and “View customer” methods. These names support clear and therefore
error-free programming.
y Are managed centrally in the SAP R/3 System in the Business Object Repository (BOR).
Business Application Programming Interfaces (BAPIs) are functional interfaces. They use the business
methods from the business objects. BAPIs may be addresses within or outside the SAP R/3 System. You
can create and manage BAPIs using the transaction BAPI.
For specifications and more information about BAPIs, see the alias “bapi” in the SAP Service
Marketplace.
Course Overview - 8
ALE - Application
Haga Link Enabling
clic para modificar el estilo de título del patrón
Distributed
z Business
Haga clicProcesses
para modificar el estilo de texto del patrón
z Segundo nivel Accounting
Central Controlling
Information systems:
z Tercer nivel Inventory
Purchasing
z Cuarto nivel Sales
PP Central Purchasing Sales, distribution, and

z Quinto nivel
Inventory management Reference system for billing
Internal sales, master data and tax Sales of trade goods
distribution, and billing data Inventory Management
Local purchasing Local Controlling
PM
ALE is the exchange of messages controlled from a business point of view

y By synchronous and asynchronous communication
y Using BAPI interfaces and IDoc Data containers
y With consistent data storage
- The applications do not use a central database
- They are supplied by regional, closed databases with their own data basis
y Between loosely linked R/3 applications.
An ALE business process is an integrated, cross-system business process. ALE business processes run
between:
y Several SAP R/3 Systems
For example, Logistics, Finances and HR on separate systems
y R/3 and non-SAP R/3 systems
For example, in SAP R/3, external warehouse control system
y R/3 and Web/Desktop systems
Possible linkages of ALE business processes:
y Loose linkage (asynchronous, message-based)
y Tight linkage (synchronous)
y A combination of both
Course Overview - 9
EDI Architecture

Documents el estilo de
EDI Messages IDoctexto
Type del patrón
SAP Documents
z Segundo nivel
Control record
z Tercer nivel
z Cuarto nivel Data
record
z Quinto nivel
Control record
Ext. application EDI subsystem IDoc interface SAP R/3 Application
Electronic Data Interchange (EDI) describes the electronic exchange of structured business data between
applications.
EDI architecture consists of:
y EDI-enabled applications; they allow business transactions to be processed automatically
y The IDoc interface; this was designed as an open interface and consists of the intermediate documents
(IDocs) and the corresponding function modules, which create the interface to the application.
y The EDI subsystem; this converts the intermediate documents into EDI messages and back. SAP does
not supply this element of the EDI architecture.
The main component of the IDoc interface is the IDoc type. An IDoc is an SAP standard that specifies the
structure and format of the data to be transferred electronically. It was developed to support the EDIFACT
and ANSI X12 standards. IDocs are identified uniquely using a control record. The application data
records form the core. The status records log the status of an IDoc as it is passed from the application to
the trading partner and back.
XML will most likely be used more and more for transferring business information between enterprises.
Course Overview - 10
Transferencia de datos utilizando Batch Input
External System SAP R/3 System

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
Batch Input
SAP Interfaces
Sequential File
and Checks
When you transfer data from one SAP R/3 System to another, or from an external system to an SAP R/3
System, you must ensure the integrity of the data that is transferred. This means the external data must be
subjected to the same checks and controls as data that was entered manually online.
As the online checks in transactions are very comprehensive and are partly used across applications, it is
very difficult to program them yourself.
The best and easiest way is to use the online checks in SAP transactions, which also includes using SAP
transactions for data transfer.
The methods used to transfer external data are known as "batch input” methods.
For many areas, SAP provides standardized external data transfer methods. These methods use batch
input, call transaction and direct input programming methods. The SAP standard direct input methods
are controlled using the Data Transfer Workbench (transaction SXDA). If no SAP standard transfer
method is available, you can program transfers using batch input or call transaction. For more information,
see the next slide.
Transferencia de datos utilizando Batch Input
BATCH INPUT: CALL TRANSACTION: DIRECT INPUT:
Sequential Sequential Sequential
File File File
z Segundo
BDC- nivel
BDC-Tabelle BDC-
BDC-Tabelle
z Tercer nivel
z Cuarto nivel
Queue File SAP
CALL
z Quinto nivel TRANSACTION
Transfer
Program
Batch
Batch Input
Input Function
Function
Application
Application Function
Function Application
Application Function
Function
SAP SAP SAP

Database Database Database
With batch input, transfer data is buffered as a Batch Data Communication (BDC) table in a queue file
(batch input session). In the next step, the system processes this session, that is, the data is transferred to
the application transaction within the batch input environment and therefore entered in the database.
SAP R/3 Systems enable you to record a transaction in dialog mode. You can use this recording to
generate a batch input session and a transfer program.
Alternatively to batch input, you can also call the transaction directly (Call Transaction) after a data
record is taken from the sequential file and placed in the BDC table. The read and write process for the
queue file does not apply here.
The batch input and call transaction methods access application transactions within the component system.
The data is therefore subjected to the same consistency checks before it is transferred as data in the dialog
mode.
Direct input programs execute the consistency checks and update the data in the database, without having
to access the application transactions. Direct input methods are used in a few SAP standard transfer
methods such as transferring bills of material and documents). These processes are only programmed by
SAP developers.
Integración Office
Haga clic para medianteelOLE
modificar estilo de título del patrón
Frontend SAP R/3 System

z Segundo nivel
z Tercer nivel
SAP GUI
OLE Client
ABAP Program
z Cuarto nivel
PC Program
z Quinto nivel Function Module
OLE Server
Function Module
PC Program
Function Module
RFC Interface RFC Interface
Object linking and embedding (OLE) is an object-oriented method for program-to-program

communication. You can connect office applications that support OLE2 automation (for example, Word
and Excel) to mySAP.com components systems. In this way, users can use some SAP R/3 functions
within their usual desktop environment.
The office programs’ OLE functions are specified in the type information. This information contains a
description of the methods, attributes and parameters. Type information can be language-independent.
When using OLE, the component system can play two separate roles:
y If the component system is acting as an OLE client, then the user calls the desktop program from the
ABAP application. OLE commands are transferred from the ABAP code as remote function calls
(RFCs) through the SAP GUI to the PC. The SAP GUI maps RFC calls to OLE commands for the PC
application.
y If the component system is acting as an OLE server, functions from that component system can be
called from the desktop application. In the component system, function calls and BAPIs are triggered by
business objects. After the data is processed successfully, the business object sends the data back to the
desktop program.
There are now pushbuttons in many standard transactions, which can be used to download data to a
Frontend program using OLE.
SAP Automation

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
Internet Transaction
Haga clic Server
Internet Transaction Server (ITS)

Service
z Segundo nivel Files
z Tercer nivel User Query Input
DIAG
z Cuarto
Internetnivel
HTTP
Internet
CGI WGate TCP/IP AGate
Comp.
Browser Server RFC system
z Quinto nivel
HTML Page Output
HTML CSS
Templates Files
• Connection: Web Server / Component system

• Logging on in component systems
• Data receipt, conversion to HTML
The web server and component system is connected through SAP’s Internet Transaction Server
(ITS). The ITS is used for the following tasks:
y Data exchange (for example using protocol conversion);
y Logging on in a component system;
y Forwarding of data to component systems, conversion of output into HTML;
y Status administration.
The ITS consists of two components:
y Wgate: The interface to the Web server. The WGate and the Web server must be running on the
same hardware. As well as the Common Gateway Interface (CGI), SAP supports the secure
interfaces ISAPI (Microsoft) and NSAPI (Netscape).
If you are using Microsoft’s IIS Web servers, you can find the WGate as a DLL file in the Scripts
folder.
y Agate: Exchanges data with the component systems. It can be run on the same hardware as the
WGate (single host) or on its own server (dual host). Several files that are stored on the AGate
configure the ITS. Among these are:
- Service files: Specify the component system and logon data (client, user, and password)
- HTML Business Templates: HTML with additional commands, placeholders for display fields
- CSS files: Describe the optical and functional layout of the generated HTML pages
SAP Business Connector
SAP
SAP
z Haga clic para modificar elSystem
estilo
System
de texto del patrón
XML
z Segundo
SAP
nivel HTML
BC SAP Business Connector
Tercer nivel
z SAP Web
Web
SAP
System
System Browser
Browser
z Cuarto nivel
z Quinto nivel Internet Technology
SAP BC or XML
B2Bi Server HTML/ Web
Web
XML Content
Content
Non
Non SAP
SAP XML XML Server
Server
Systems
Systems Interface
Web
Web
Non
Non SAP
SAP Applic-
Applic-
Systems
Systems ations
ations
Contenido del curso
Introducción
z Haga
Conceptos el estilo
z Segundo
Unidad 2 nivel
z Tercer
z Cuarto
z Quinto
Qué es una BAPI?
Business Application Programming Interface
Interface nivel
zz Segundo bien definido para datos y procesos de R/3
Implementado
zz Tercer nivel como una RFC
Métodonivel
zz Cuarto de un objeto de negocio del Business Object Repository
z Quinto nivel
SAP created the Business Framework to allow the technical integration and exchange of business data
among SAP components and between SAP and non-SAP components. Important components of the
Business Framework are the Business Application Programming Interfaces (BAPIs), which represent
visible interfaces at the component boundaries and whose properties serve to integrate these
components.
BAPIs represent well-defined, internally consistent units that always represent business facts and leave
a consistent database state behind.
The business contents can be standardized, since BAPIs not only allow the integration of the SAP
system and other software components at a technical level, but also at the business level.
Stability and compatibility
Once SAP has released a BAPI, its interface definitions and parameters will remain stable in the long
term, which means application programs will not be affected by changes to the underlying SAP
software or data. If upward-compatible enhancements are made to the BAPIs, the stability of the
existing applications is not affected.
Openness
BAPIs can be accessed from any widespread development platform.
Usos

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
BAPIs can be used for the following types of integration:

Connecting R/3 Systems to the Internet using the SAP Business Connector or Internet Application
Components (IACs)
BAPIs also allow the creation of true component software, as they enable standardized communication
between SAP components. The aim is to encapsulate the functions of the SAP system in independent
business components that are integrated through a common interface (the BAPIs).
The integration of new SAP components (such as Advanced Planner and Optimizer (APO) and
Business Information Warehouse (BW)), non-SAP software, and legacy systems
Implementation of distributed R/3 scenarios with asynchronous connections using Application Link
Enabling (ALE)
Using PC programs as frontends to the R/3 System These can be developed with Visual Basic
(Microsoft), for example, or with Visual Age for Java (IBM)
Workflow applications that extend beyond system boundaries
Customers’ and partners’ own developments
Atributos

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
You can access BAPIs from external clients like methods access objects, which are themselves an
instance in the client.
SAP guarantees that no incompatible changes will be made to the interfaces of BAPIs.
You can also use BAPIs within the R/3 System to access business data. This makes it easier for
customers and partners to add to the functions offered by the system.
Displaying data that is transmitted to a BAPI or that is returned from a BAPI must be done from the
calling program.
The return parameter RETURN contains success or error messages for the BAPI, and depending on the
SAP R/3 Release has the dictionary structure BAPIRETURN, BAPIRETURN1, BAPIRET1,
BAPIRET2 or BAPIRET2_FIX. The (common) relevant fields of these structures are:
TYPE (Message type: S(uccess), E(rror), W(arning), I(nformation) ) ;
ID (message class) ; NUMBER (message number) ; MESSAGE (message text) ;
MESSAGE_V1 , MESSAGE_V2 , MESSAGE_V3 , MESSAGE_V4 (message variables)
If the transmission is successful, RETURN is either completely empty (all the fields have their initial
fields for their types), or only the TYPE field has the value 'S'. Refer to the documentation to find out
which applies to the BAPI you are using.
Actualización de base de datos

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
Database updates in BAPIs are always performed by an update. The update type (synchronous or
asynchronous) is specified when you call the COMMIT-BAPIs.
In BAPIs containing database updates, a COMMIT / ROLLBACK WORK is not used. Closing or
rejecting a BAPI-LUW occurs by calling a special BAPI from the service object BapiService (object
type 'SAP0001').
BAPI TransactionCommit (relevant function module BAPI_TRANSACTION_COMMIT)
BAPI TransactionRollback (relevant function module BAPI_TRANSACTION_ROLLBACK)
BAPIs Estándar

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
The above BAPIs exist for many business objects.

Depending on the object, you can use additional BAPIs.
(For example, CheckPassword for the business object 'Customer')
Ejemplo

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
Contenido del curso
Introducción
z Haga
Conceptos el estilo
z Segundo
Unidad 2 nivel
z Tercer
z Cuarto
z Quinto
RFC – Introducción

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
RFC – Introducción

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
RFC – Posibilidades

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
RFC is available for R/3 as of Release 2.1A. For R/2, RFC is available as of Release 5.0D with
limitations regarding error handling and data volume. These limitations have been eliminated with
Release 5.0H. SAP plans to implement these corrections from version 5.0H on all releases as of 5.0D.
The following RFC couplings are possible in the SAP environment:
- R/3 to R/3: (the systems involved may have different releases)
- R/3 to external system: (external platforms are all R/3 server and front-end platforms)
- R/3 to R/2: (R/2 may run on IBM or SNI platforms)
- R/2 to external system: (external platforms are all R/3 server and front-end platforms)
You should note which communication partner initiated the connection either the server or the client).
This has a strong influence on the configuration and the programming.
If there is no RFC support offered by SAP for a specific platform, you can use the underlying CPI-C
interface. If this does not work, you must use suitable platform-specific programming (for example,
socket programming) to build a connection to the SAP communication components.
RFC de clic
Haga sistema
para SAP a SAPel estilo de título del patrón
modificar

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
The only difference between a remote call of a function module to another server and a local call is a
special parameter (destination) that specifies the target server on which the program is to be executed.
There are three types of RFC calls:
Synchronous RFC call: The calling program stops until the function module has been processed on
the target server and any results have been returned to the caller. Only then does the calling program
continue processing.
Asynchronous RFC call: The calling program runs parallel to and independently of function module
processing in the target system. Programmers are responsible for the processing of the results. In
addition, the target system must also be available at the time of the RFC call.
Requisitos
Haga clic para
para sistemas
modificarno-SAP
el estilo de título del patrón
z RFC Library, available for
Win32
z Haga (librfc32.dll)
clic para modificar el estilo de texto del patrón
Linux nivel
z Segundo
Other SAP-supported Unix flavors
z Tercer nivel
OS/390
z Cuarto nivel
OS/400
z Quinto nivel
OS/2
Macintosh (client only)
Soluciones paramodificar
Haga clic para RFC el estilo de título del patrón
z Windows
SAP
z Haga clicDCOM
para Connector
modificar el estilo de texto del patrón
SAP ActiveX
z Segundo nivel Controls
Java nivel
zz Tercer
SAP Java Connector (JCO)
z Cuarto nivel
SAP Business Connector
z Quinto nivel
Lenguajes
Haga clic de programación
z Java
C clic para modificar el estilo de texto del patrón
zz Haga
Cualquier
zz Segundo lenguaje que soporte ActiveX
nivel
Visual
z Tercer Basic
nivel
Visual
z Cuarto C++
nivel
many others
z Quinto nivel
Destinos
Haga clicRFC

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
Destinos
Haga clicRFC – modificar
para Conexión el
SAP
estilo de título del patrón

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
Destinos
Haga clicRFC – modificar
para Conexión el
Externa

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
For connections to external RFC server programs, you need a destination with the type T. there are 2
variations of the T type:
1. Start: The external program is started when communication is being established.
a) On the application server: The external program is started on the current R/3 application server.
You must give the complete program path including the program names.
b) On the explicit host: The external program is started on the specified host.
You must specify the following:
- Host name --> Name of the machine where the external program is located
- Path --> Complete path including program names on an external host
c) Front end workstation: The external program is started on the current front end at runtime via the
SAPgui. You must enter the compete (absolute) path of the program including program names.
2. Registration: These destination variations let you access a program that has already started, which
has registered itself on a gateway. This program must be started manually beforehand and registers
itself using an RFC call with a program ID on a gateway (see the online documentation). With this
variant, the start time is not required. It is suited to starting a program frequently. You must specify
the following:
- Program-ID --> ID under which the external server program registered on the SAP gateway
- Gateway --> Host and TCP/IP service of the gateway where the external
program registered (If the gateway is the one for the current application server, this
information is not required.)
Remote Function
Haga clic Call
z Interface estándar y bidireccional para la integración entre
sistemas SAP y sistemas no-SAP
z Diferentes variantes
z Segundo nivel
• Síncrona
z Tercer nivel
• Asíncrona
z Cuarto nivel
• Transaccional
z Quinto nivel
• Queued
RFC Síncrona
z Cliente espera hasta que el proceso se termina

z Haga
z sRFC clic para
tiene modificarde
parámetros elentrada
estilo dey texto del patrón
de salida
Segundode
z Gestión
z nivel
errores sencilla
z Tercer nivel
z Cuarto nivel
z Quinto nivel
RFC Flujo
Haga clicsíncrono

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
With synchronous RFC, processing stops in the calling program until the called remote function is
processed and its output is returned. Then in the calling program, the processing continues after the
call.
RFC Flujo
Haga clicsíncrono - Sintaxis

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
The statement CALL FUNCTION ... DESTINATION enables you to call remote ABAP function
modules or C routines in external server programs.
When you call a function in this way, always include handling for the standard exceptions
COMMUNICATION_FAILURE and SYSTEM_FAILURE.
The exception COMMUNICATION_FAILURE is resolved by the system if the specified destination
in the sideinfo table RFCDES is not maintained, or if the connection to the remote system cannot be
established.
The exception SYSTEM_FAILURE is resolved if the function module or C routine that you want to
start in the remote system is not available.
RFC Flujo
Haga clicsíncrono - Contexto

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
The connection to a remote destination remains intact for as long as the context of the calling program
remains active. The function groups addressed in the remote destination remain active for as long as the
calling program itself remains active (this is the same as with local calls). This means that if you call
two function modules from the same function group one after the other, they can both access the same
global data of the function group.
Each function module called using synchronous RFC forms its own logical unit of work (LUW)
RFC Flujo
Haga clicsíncrono - Debugg

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
You can debug function modules called remotely in R/3 - R/3 connections.
RFC Flujo
Haga clicAsíncrono

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
In an asynchronous Remote Function Call, the called remote function is started and then continues
processing on its own immediately in the calling program. Remote function processing is separate
from the calling program. The function output can be received later in the program.
Asynchronous RFC is intended for parallel processing of processes.
RFC Flujo
Haga clicAsíncrono - Sintaxis

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
With the addition STARTING NEW TASK <task name> you can call a remote function module
asynchronously. You can use any task name.
The function module that you call is executed in its own work process.
You can also use aRFC in background processing. Note, however, that even here, each aRFC call
occupies a dialog work process.
In the sideinfo table RFCDES, you can set the number of aRFC calls for each destination using the
aRFC options. After these aRFC calls an automatic load check is performed on the target server. If
resource bottlenecks are detected, the system waits for a short time for the next aRFC call,
meant for the same remote system, and the client program is rolled out of its work process. It can then
receive results from previous aRFC calls.
During the call, you may not specify an IMPORTING addition since the call does not wait for the end
of the function module. Here, you can only handle the two system exceptions,
COMMUNICATION_FAILURE and SYSTEM_FAILURE for the same reason. The function module
output must be received and the function module-specific exceptions must be handled later on in a
different place. (See following slides)
Receiving the function module output and handling the function module-specific exceptions are
optional, however.
RFC Flujo
Haga clicAsíncrono – Confirmación
para modificar el estilo de (1)
título del patrón

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
A program can receive output (parameters and exceptions) from a function module that is running
asynchronously.
To implement this, when you call use the addition "PERFORMING <subprogram> ON END OF
TASK", where the specified subroutine must exist in your program, and through which the output of
the function module is received using command "RECEIVE RESULTS FROM FUNCTION
<fbname> . .". When the function module ends, the subroutine is called automatically.
The subroutine must also have a formal parameter with any name you choose. When the subroutine is
called, it receives the accompanying task name. This parameter lets you see which aRFC call just
ended, and you can receive the relevant
output using the RECEIVE RESULTS FROM FUNCTION command.
The subroutine may not contain any statements that interrupt the program execution (such as CALL
SCREEN, SUBMIT, COMMIT WORK, WAIT, RFCs, W or I messages). WRITE statements in this
subroutine specially defined for aRFC have no effect.
The subroutine can only be executed automatically if the calling program is in rollout status. ->
"WAIT UNTIL" statements (see next slide).
The addition KEEPING TASK with the RECEIVE statement causes the function group context that
was loaded remotely to wait until the calling program has ended. This lets you use the old remote
context with later aRFC calls with the same task name.
RFC Flujo
Haga clicAsíncrono – Confirmación
para modificar el estilo de (2)
título del patrón

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
The language element WAIT UNTIL with the addition PERFORMING is only useful with aRFC, and
otherwise has no effects.
When the WAIT UNTIL statement is executed, the conditions specified are checked.
If it is fulfilled, the program processing continues directly after the WAIT UNTIL statement.
Otherwise the system waits in rollout status for the output from the aRFCs. If the aRFC output is now
returned, the form routine specified during the call is executed and is sent back to the WAIT UNTIL
statement.
This check/wait procedure repeats until the WAIT conditions are fulfilled, or until there are no more
open RFC calls.
Note that the WAIT UNTIL statement sets the SY-SUBRC. Therefore, store the SY-SUBRC value
(set in the form routine by exceptions-handling in RECEIVE RESULTS) in its own global variable
before leaving the form routine, if you need this value again later (after WAIT UNTIL).
RFC Flujo
Haga clicAsíncrono – Ejemplo

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
In this program example, the are two aRFCs, and when the aRFCs are confirmed, the subroutine UP1
is always executed.
This subroutine uses parameter T to separately decide which function module just returned its output.
Then the corresponding RECEIVE RESULTS statement is used to receive (and process)
the output.
After processing an aRFC output, you must correspondingly adjust the WAIT UNTIL condition.
(Here: Set flag1 or flag2)
RFC Flujo
Haga clicTransaccional

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
Whereas with synchronous and asynchronous RFC each call makes up a single logical unit of work
(LUW) in the remote system, you can use transactional RFC to bundle several remote functions into
one LUW (with an automatic rollback mechanism in case of error).
You can use tRFC with the addition IN BACKGROUND TASK, which you must place before the
DESTINATION entry. If you specify a COMMIT WORK statement, you bundle all the previously
transmitted tRFCs in one LUW.
tRFCs are also called asynchronously. Unlike aRFC, the output from the called function module
cannot be received.
-> No IMPORTING . . . / PERFORMING . . . ON END OF TASK when calling;
-> No RECEIVE RESULTS FROM FUNCTION . . .
In the source system, you can use the administration transaction SM58 that lets you display and modify
tRFC-LUWs.
RFC Flujo
para modificar–elMecanismo ejecución

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
tRFC calls are first stored in the local tRFC tables ARFCSSTATE and ARFCSDATA. The execution
status of the LUWs is logged in table ARFCSSTATE, while ARFCSDATA contains the input data for
the tRFCs.
If you do not want to execute a remote LUW immediately, rather trigger it at a later time, call the
function module START_OF_BACKGROUNDTASK before the COMMIT WORK statement
locally. Here, you must enter the date and time of execution.
The COMMIT WORK statement automatically schedules an immediate job or a job set for a later start
time to remotely call the LUW. In the job execution, the relevant data is read from the tRFC tables,
and the corresponding tRFCs are transmitted. If the remote LUW is executed successfully, the
accompanying entries are deleted from the tRFC tables. If an error occurs, an automatic repeat
mechanism, or rollback mechanism is activated (see next slide).
If the update is triggered locally because of the COMMIT WORK statement, the tRFCs are only
executed when the local update is successfully completed.
RFC Flujo
para modificar–elErrores

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
If a connection cannot be made to the partner, this is logged in the tRFC status table ARFCSSTATE
(which you can see by using Transaction SM58), and the job is rescheduled. You can set in the
destination the number of times the system repeats the effort to connect, and the time intervals, by
using the tRFC options. The default is a maximum 30 times with a 15 minute interval.
If, after a tRFC-LUW is successfully executed in the partner system in one of the function modules, the
program terminates with an A/X-message (MESSAGE A/X...) or triggers an exception (RAISE...),
- all the changes made in the current LUW are automatically rolled back in the remote system, and
- the remote program termination is logged in the tRFC status table ARFCSSTATE (viewable using
SM58) in the source system.
The entries relevant to the LUW remain in the tRFC tables and the execution job is not rescheduled.
In this case, you can find the remote error using Transaction SM58, and you have to correct the
problem in the remote system. Afterward you must trigger the remote execution again also in
Transaction SM58.
If you want to cancel and roll back this remote execution from a remote function module of a tRFC-
LUW, but you also want to reschedule the job in the source system (for example, because a master
record that is to be processed is locked and the LUW must be executed again), call the function module
RESTART_OF_BACKGROUNDTASK in the remote function module instead of MESSAGE A... or
RAISE...
RFC Flujo
Haga clicQueue

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
With tRFC, generated LUWs are processed independently of each other. This means, the order in
which they are processed is not always the order in which they are generated.
To ensure that tRFC-LUWs are processed in the same order as they were generated, you can use qRFC
as an extension of tRFC.
qRFC is available as of Release 4.6A and can be used in R/3-R/3 connections as well as R/3-external
connections.
RFC Flujo
Haga clicQueue - Sintaxisel estilo de título del patrón
para modificar

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
RFC Flujo
Haga clicQueue - Datos el estilo de título del patrón
para modificar

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
The tRFC-LUWs belonging to a queue are stored in the tRFC tables ARFCSSTATE and
ARFCSDATA. However, you cannot maintain or display these LUWs using Transaction SM58. You
must use the queue administration transaction SMQ1.
The queue data (queue attributes + pointers to the relevant tRFC-LUWs in the tRFC tables) is stored in
the TRFCQOUT table, which you can maintain using Transaction SMQ1.
The following functions are available:
- List queues
- Display queues with a list of accompanying LUWs and function modules including input data
- Start/stop transmitting the queues
- Delete queues
If an LUW error occurs in the remote system, the queue is rolled back there. The relevant LUW and all
of the other LUWs in the queue remain in the queue and in the tRFC tables. After correcting the error,
you can use Transaction SMQ1 to transmit the queue again.
Creación
Haga clicRFC
para(1)modificar el estilo de título del patrón
z Código fuente similar al de cualquier módulo de función

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
Function modules are special external subroutines stored in a central library called the Function
Builder. The R/3 System provides numerous predefined function modules that you can call from your
ABAP programs, and you can create your own customer function modules.
The interface facilitates and standardizes the passing of inbound and outbound parameters. For
example, you can assign default values to the inbound parameters of function modules.
You can combine several function modules to form a function group in the Function Builder. Since you
can define global data that can be accessed from all function modules of one function group, it is
reasonable to include function modules that operate with the same data, for example an internal table,
in one function group.
Creación
Haga clicRFC
para(2)modificar el estilo de título del patrón

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
RFC - Atributos

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
RFC - Import

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
Importing parameters, which are received by the function module

By default, all parameters are passed by reference. To avoid unwanted side effects, you can only
change exporting and changing parameters in the function module. If you want to pass parameters by
value, you must select the relevant option when you define the interface.
RFC - Export

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
Exporting parameters, which are returned by the function module

RFC - Modificación

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
Changing parameters, which are both received and returned.

RFC - Tablas

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
RFC - Excepciones

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
RFC – Código
Haga clic parafuente
modificar el estilo de título del patrón

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
RFC – Ejecutar

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
RFC – Ejecutar

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
Contenido del curso
Introducción
z Haga
Conceptos el estilo
z Segundo
Unidad 2 nivel
z Tercer
z Cuarto
z Quinto
Business
Haga clicObjects

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
A business object type is the representation of a business entity, like an employee or a

sales order, in the SAP system. It encompasses both the functionality (in the form of
methods) and the data (in the form of attributes) of this entity. In the process, the
implementation details of the business object type are hidden from the enduser, and the
business object type itself is accessed through defined functions (methods/BAPIs).
This is referred to as encapsulation.
Tipo declic
Haga objeto
parae modificar
instancia el estilo de título del patrón

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
Ejemplos
Haga clicBusiness Objectsel estilo de título del patrón
para modificar

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
Business
Haga clicObject Repository
para modificar el (BOR)

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
Componentes demodificar
Haga clic para Aplicación
el estilo de título del patrón

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
Business
Haga clicObject Browser el estilo de título del patrón
para modificar
Transacción SWO2
z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
Business
Haga clicObject Builder el estilo de título del patrón
para modificar
Transacción SWO1
z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
Ejemplo Objeto

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
Tipo de objeto - Definición
Object type Program

Interfaces
z Segundo nivel Virtual attributes
z Tercer nivel Key Field references
fields
z Cuarto nivel Object references
Attributes ABAP Code
z Quinto nivel
Synchronous Transaction
Methods
Asynchronous Function module
Events Report
BOR is a client-independent directory of all defined object types

Each object type is assigned to a development class and, therefore, indirectly to an application component.
Objetos
Keys Attributes Methods

Business Object
z Segundo nivel Repository
z Tercer nivel
Table 1 Table 2 TA01
z Cuarto nivel Application
Key Fields Key Fields TA02
z Quinto nivel ReportXX
Change documents, status management ...
Events
Note: Events are dealt with later in a separate unit

The application data (tables) and the changes and queries (transactions and reports) that can be performed on this data
are encapsulated in the Business Object Builder.

This encapsulation is used
y To simplify process modeling
y As a standard interface for the workflow runtime system
Utilización de objetos
Step definition
z Haga clic para modificar el estilo de texto
Conditional Forkdel patrón
branch
z Segundo nivel
Loop
z Tercer nivel
z Cuarto nivel
z Quinto nivel
Container operation
Wait for
event
Event
creator
Objects are used in

y Tasks → Executing methods
y Control structures → Querying attributes
y Container operation → Querying attributes
y Wait steps, event creator → Triggering or receiving events
y Check FM, receiver type FM → Querying attributes
y Receiver function module → Receiving events
y Roles → Querying attributes
y Secondary methods → Calling methods
Objeto - Propiedades
z Data encapsulation
Haga
z z clic para modificar el estilo de texto del patrón
Inheritance
Segundo
z z nivel
Polymorphism
z Tercer nivel
z Cuarto nivel
z Quinto nivel
Object definitions and implementations can only be manipulated via the Business Object Builder.
Data encapsulation - definition: Abstraction for the modeler, irrespective of the concrete SAP tables, transactions,
etc.
Data encapsulation - runtime: A standard interface for calling application functionality is available to the workflow
runtime system, irrespective of the actual implementation.
Inheritance: Object properties such as attributes, methods and events are passed on to subtypes. Properties inherited
can be redefined in the subtype.
Polymorphism: Depending on the object type, the object manager always selects the relevant implementation for the
property requested. This property is implemented technically using the "late binding" principle.
Dynamic call interface for calls from the workflow runtime system.
Campos clave
z Specification of object key
zz Several keypara
Haga clic fields possible
zz Reference to underlying application table(s)
Segundo nivel
zz Client
Tercernot necessary
nivel
z Cuarto nivel
z Quinto nivel
The English ABAP Dictionary names are proposed automatically as the names of the key fields.
Key fields must be character-based.
The concatenated key fields can contain a maximum of 70 characters.
Atributos
z Database or virtual attributes
zz Type
Hagainformation from ABAP
clic para modificar Dictionary
el estilo field
de texto delorpatrón
object type
z Segundo nivel
z Single-line and multiple-line attributes
z Tercer nivel
z Cuarto nivel
z Quinto nivel
Database attributes are read from the associated application table and buffered in the object. Source code is
generated beforehand by the Business Object Builder for this purpose.
Virtual attributes are calculated on calling.
There are different macros for single-line and multiple-line attributes.
Atributos virtuales
z Explicit implementation required

Haga clic para
zz Calculation modificar
upon attributeelaccess
estilo de texto del patrón
z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
The Business Object Builder cannot generate a source code for virtual attributes. The algorithm required for
calculation of the attribute value must therefore always be explicitly programmed.
Typical examples:
language-dependent texts
time-dependent values
net/gross values
object references
Atributos multilínea
z Correspond to internal tables
zz Are almost
Haga always
clic para virtual attributes
zz Can contain
Segundo either database fields or object references
nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
Example:
y List of purchase requisitions for a material (BUS1001.PurchaseRequisition).
Métodos síncronos/asíncronos
z Synchronous method
Result returned directly to calling program
Return of exceptions possible
z Segundo nivel
z Asynchronous method
z Tercer nivel
Result can only be returned via an event
z Cuarto nivel
Only restricted exceptions possible
z Quinto nivel
Method itself does not wait for a possible terminating event
(Import) parameters can be defined in both.

Asynchronous methods are always necessary if the encapsulated application functionality uses updating.
Asynchronous methods can only trigger exceptions in the "dialog part".
Métodos síncronos
Method
Export
z Segundo nivel Import Result
Exceptions
z Tercer nivel
Caller
z Cuarto nivel Time

z Quinto nivel
z All display methods

z All methods that do not write their changes to the
database using the update task
The solid arrows represent the control flow.

The broken arrows represent the transfer of data and control flow.
The dotted line represents the waiting time of the caller.
Métodos asíncronos
Method Dialog Update

z Segundo nivel Import
z Tercer
Caller nivel
z Cuarto nivel
Time
z Quinto nivel
z All methods that write their changes to the database

using the update task
z Processes must be synchronized
The solid arrows represent the control flow.

The broken arrows represent the data transfer.
The dotted line represents the waiting time of the caller.
The distinction between synchronous and asynchronous applies to both dialog and background methods.
It is up to the caller to coordinate a resynchronization as necessary.
It is up to the method to make the synchronization possible technically (→ Events).
Comunicación con métodos
z Communication via parameters

z Haga clic parameters
Import para modificar el estilo de texto del patrón
z Segundo
Export nivel
parameters
z Tercer
z nivel
Communication via result
z Cuarto
z nivel
Communication via exceptions
z Quinto nivel error
Temporary
Application error
System error
z Communication via event
Synchronous methods support communication via parameters, results and exceptions.

Asynchronous methods support communication via import parameters. An event should be triggered once they have
been processed.
Export parameters should be avoided. Use a result instead. The result can be multiple-line. Parameters should be
avoided completely if the value can also be read as an object attribute.
If the result is based on a fixed value domain, automatic branching is possible via these values in the WF definition.
If object attributes on the database are changed in the method, the Business Object Builder object buffer must be
invalidated with the macro SWC_REFRESH_OBJECT.
The type of exception subsequently determines error handling in the work item.
Exceptions are generally triggered via the macro EXIT_RETURN. There are two special macros,
EXIT_OBJECT_NOT_FOUND and EXIT_CANCELLED, the latter is used to return a user termination in a
synchronous method. User terminations reported in this way are then treated as temporary errors.
Reacción a excepciones – Paso de diálogo
Step
z Haga clic para modificar el estilo de texto
(method) del patrón
z Segundo nivel
Tercer nivel
z Temp. Sys. Temp. Sys.
OK
error error error error
z Cuarto nivel
z Quinto nivel
In process Error Subsequent Subsequent Subsequent
step step step
Not modeled Modeled
Reacción a excepciones – Paso de fondo
Step
(method)
z Segundo nivel
Temp. Temp. Sys. Temp. Temp. Sys.
OK
Tercer nivel
z error error error error error error
Without With counter Without counter With counter

Cuarto nivel
zcounter
In process In process In process
z Quinto nivel
Error Error Subsequent Subsequent Subsequent Subsequent
step step step step
Not modeled Modeled
Background steps also offer the option of modeling a repeat counter for a temporary error.
If this repeat counter is modeled and an error occurs, the step is repeated automatically as often as defined, before
either assuming "error" or "completed" status (with subsequent execution of the subsequent step modeled).
Virtual Attributes - Background Method
Virtual Attributes Background Methods
z Haga
Read orclic para
calculate modificar
individual values el estilo deortexto
Read del
calculate patrón
a list of
or a list of homogeneous values heterogeneous values
z Segundo nivel
Calculate values which are not
z Tercer nivel dependent on other attributes or
system values
z Cuarto nivel Change values
z Quinto nivel Evaluation in workflow

Evaluation and execution in
workflow manager manager, execution in
work item manager
Buffering of the results in the No buffering of results
Business Object Builder
Fixed communication with the All communication methods
caller possible
The buffering of the virtual attributes must be programmed explicitly in the implementation of the attribute.
The return of the value of a virtual attribute to the caller corresponds, in principle, to a result value of a method.
Eventos
z Definition and implementation are separate

Haga clic
zz Default para modificar
parameters el estilo
need not be setdeexplicitly
texto del patrón
Segundo nivel
zz User-defined parameters are set explicitly via container
z macros
Tercer nivel
zz Documentation
Cuarto nivel is indispensable
z Quinto nivel
Only definitions of events in the Business Object Builder.

Default parameters are in the include RSWEINCL.
The following parameters are always incorporated:
Triggering object (type, key and object reference)
Name of event
Language, date and time
Triggering user.
User-defined parameters are only possible for events that are programmed explicitly. Parameters should not be
object attributes of the triggering object.
Tipo de objeto - Estados
z Modeled
z Not
Hagaaccessible
clic para at runtime.el estilo de texto del patrón
modificar
zz Implemented
Segundo nivel
Only in tests or internal use, possibly unstable.
z Tercer nivel
z Released
Cuarto nivel
z Released for use by the customer. Only upward-
z compatible enhancements possible.
Quinto nivel
z Obsolete
The functionality has been replaced. The old
functionality is still supported for two releases.
The "modeled" status is the only status in which execution is not possible. Customers should, however, only use
components with the "released" status.
The release information should be noted when a component's status changes to "obsolete".
Tipo de objeto - Parámetros
z Object name
z Descriptive name
Haga clic para for objects
modificar of this
el estilo detype
texto del patrón
zz Default
Segundomethod
nivel
Display for presenting an object instance
z Tercer nivel
z Default attribute
z Cuarto nivel
Identifying attribute of an object instance
z Quinto nivel
The object name is used as the element name in the container definition, for example.
The default method is used, for example, when you double-click objects in a list of object links.
The default attribute is used, for example, to display objects in lists.
Implementando campos clave
Key Field SalesDocument x
Key field SalesDocument

Object type Bus2032
Release 21A
Status Released
Texts
zName Segundo nivel
Sales document
Description Sales document
z Tercer
Data type referen. nivel
Reference table VBAK
z Cuarto nivel
Reference field
VBELN
Search help
include <object>.
begin_data object. " Do not change.. DATA is generated
z Quinto nivel * only private members may be inserted

* into structure private
data:
" begin of private,

" to declare private attributes remove comments and
" insert private attributes here ...
" end of private,
begin of key,
salesdocument like vbak-vbeln,
end of key,
end_data object. " Do not change.. DATA is generated
Each object type has a program that implements the object type.
The macro instructions required for programming are incorporated via the include <object>.
The Business Object Builder always works with object references. These references are used to read and manipulate
the actual application data. An object reference of this kind must be created in the calling program with the macro
SWC_CREATE_OBJECT before a method is called or an attribute determined.
Each object program contains the variable SELF which, in turn, contains a reference to the object instance with
which the program was called.
The object-key-sales document variable (generally: object-key-<name of key>) is declared in conjunction with the
BEGIN_DATA OBJECT macro.
The declaration between BEGIN_DATA and END_DATA is generated entirely from the definition data.
Atributos de los campos
Attribute DocumentDate x
Attribute DocumentDate
Object type VBAK
get_table_property vbak.
Release 30A
z Haga clic para modificar eldata

Status Released
subrc like sy-subrc.
Texts
** Fill
Fill TABLES
TABLES VBAK
VBAK to
to enable
enable Object
Object Manager
Manager
Name Document date ** Access
Access to
to Table
Table Properties
Properties
z Segundo nivel
Description Document date (inbound or outbound) perform select_table_vbak using subrc.
Source if subrc ne 0.
z Tercer nivel
Virtual
exit_object_not_found.
endif.
Database field
end_property.
z Cuarto nivel
Attribute properties
form select_table_vbak using subrc like sy-subrc.
Multiple-line
if object-_vbak-mandt is initial and
z Quinto nivel
Mandatory
Instance-independent
object-_vbak-vbeln is initial.
select single * from vbak client specified
where mandt = sy-mandt and
Data type referen. vbeln = object-key-salesdocument.
Dictionary subrc = sy-subrc.
Reference table VBAK if subrc ne 0. Exit. Endif.
Reference field AUDAT object-_vbak = vbak.
Search help else.
subrc = 0.
Object type vbak = object-_vbak.
Inverse attribute endif.
endform.
Source code is generated in the implementation program to read the date from the application table.
The source code between GET_TABLE_PROPERTY and END_PROPERTY is generated entirely from the
definition data. The form select_table_<table name> is also generated automatically for the actual database access.
The macro EXIT_OBJECT_NOT_FOUND returns the exception "Object not found". This exception corresponds to
the T100 message OL826.
Atributos de los campos
Attribute SoldToParty x
Attribute OrderingParty
Object type VBAK
Release 30A get_table_property vbak.
z Haga clic para modificar el estilo
Status Released
de
data subrc liketexto
sy-subrc. del patrón
Texts
* Fill TABLES VBAK to enable Object Manager
z Segundo nivel
Name
Description
Ordering party
Ordering party
* Access to Table Properties
perform select_table_vbak using subrc.
if subrc ne 0.
z Tercer nivel
Source
exit_object_not_found.
endif.
Virtual
Database field
z Cuarto nivel end_property.
Attribute properties form select_table_vbak using subrc like sy-subrc.

if object-_vbak-mandt is initial and
z Quinto nivel
Multiple-line
object-_vbak-vbeln is initial.
Mandatory select single * from vbak client specified
Instance-independent where mandt = sy-mandt and
vbeln = object-key-sealesdocument.
Data type referen. subrc = sy-subrc.
if subrc ne 0. Exit. Endif.
Dictionary
object-_vbak = vbak.
Reference table VBAK else.
Reference field KUNNR subrc = 0.
Search help vbak = object-_vbak.
endif.
Object type KNA1 Customer endform.
Inverse attribute
The source code between GET_TABLE_PROPERTY and END_PROPERTY is generated entirely from the
definition data.
The macro EXIT_OBJECT_NOT_FOUND returns the exception "Object not found". This exception corresponds to
the T100 message OL826.
An object reference is generated automatically as an attribute value. This procedure only works correctly if the
referenced object type has precisely one key field. Otherwise, the attribute must be implemented itself.
Implementando atributos virtuales
Attribute SalesGroup x
Attribute SalesGroup
Object type Z_Bus2032
Release 40A
z Haga clic para modificar el estilo

begin_datade texto del patrón
Status Modeled
object.
Texts begin of key,
Name ...
z Segundo nivel
Sales group
Description Sales group (impl. as virt. attr.) end of key,
salesgroup type swc_object.
Source end_data object.
z Tercer nivel
Virtual get_property salesgroup changing container.
Database field
z Cuarto nivel
select single * from vbak
where vbeln = object-key-salesdocument.
Multiple-line
* create object(-reference)
z Quinto nivel
Mandatory
Instance-independent swc_create_object
object-salesgroup 'TVKGR' vbak-vkgrp.
Data type referen.
Dictionary * write object(-reference) into container
Reference table swc_set_element container
Reference field 'SalesGroup' object-salesgroup.
Search help
end_property.
z Object type TUKGR Sales group
Inverse attribute
The data declaration is generated from the definition data and is used as a runtime buffer.
The implementation between GET_PROPERTY and END_PROPERTY must be created manually, since there is no
other definition information. The object reference to be returned, in particular, must be created explicitly via the
macro SWC_CREATE_OBJECT.
Both the Business Object Builder runtime buffer "object-salesgroup" and the associated container element
"SalesGroup" must be completed for data transfer.
Implementando atributos virtuales multilinea
Attribute Items x
Attribute Items begin_data object.
begin of key,
Object type VBAK
...
Release 30A
end of key,
Status Released
z
Texts
Haga clic para modificar el estilo de texto del patrónitems type swc_object occurs 0.
end_data object.
get_property items changing container.

Name
SegundoSalesnivel
zDescription
Items
document items * Declare data
tables vbap.
Source data item type swc_object.
zz VirtualTercer nivel data: begin of vbap_key,
vbeln like vbap-vbeln,
Database field posnr like vbap-posnr,
z Cuarto nivel end of vbap_key.

data vbap_tab like vbap occurs 0 with header line.
Multiple-line * Select data
Quinto nivel
z Mandatory select * from vbap into table vbap_tab
Instance-independent vbap_key-vbeln = object-key-salesdocument.
Data type referen. * Create object reference

Dictionary loop at vbap_tab.
vbap_key-posnr = vbap_tab-posnr.
Reference table
swc_create_object item 'VBAP' vbap_key.
Reference field
append item to object-items.
Search help endloop.
z Object type VBAP Sales item * Assign object reference to container element
Inverse attribute swc_set_table container 'Items' object-items.
end_property.
The data declaration is generated from the definition data and is used as a runtime buffer.
The implementation between GET_PROPERTY and END_PROPERTY must be created manually, since there is no
other definition information. The object reference to be returned, in particular, must be created explicitly via the macro
SWC_CREATE_OBJECT.
Both the Business Object Builder runtime buffer "object-salesgroup" and the associated container element
"SalesGroup" must be completed for data transfer.
The actual implementation of the attribute also contains a query as to whether the runtime buffer is completed.
Implementando métodos síncronos
begin_method display changing container.
Method Display x
Method Display set parameter id 'AUN' field object-key-

Object type Z_Bus2032 salesdocument.
Release 40A
call transaction 'VA03' and skip first
screen.
Status Implemented
z Segundo nivel
Method Display x
end_method.
Method Display
Name
TercerObject
z Description nivel
type
Release
Z_Bus2032
40A
General Status
ResultABAP
type Implemented
z Cuarto nivel
Name Display
Dialog Description Display object
Synchron
z Quinto nivel General Result type ABAP
Result para
Instance-ind Function module

API function
VA02 Transaction
Dialog module
Report
Miscellaneous
Name VA03
The implementation between BEGIN_METHOD and END_METHOD is generated from the definition data.
The macro SWC_REFRESH_OBJECT must also be called after the application functionality for synchronous
methods that can change object attributes, in order to delete the object buffer.
Implementando métodos asíncronos
Method DeliveryBlockReset x
Method DeliveryBlockReset
Release
Status
40A
Implemented
z Segundo nivel Method Edit

Method DeliveryBlockReset
x
begin_method deliveryblockreset changing container.
Name Object type Z_Bus2032 select single * from vbak
z Tercer nivel
Description
General
Release
Status
ResultABAP
type
40A
Implemented
if vbak-lifsk <> space.
* invoke method only if delivery lock is set
Name ResetDelBlock set parameter id 'AUN'
z Cuarto nivel
Dialog
Synchron
Description Reset delivery block field object-key-salesdocument.
call transaction 'VA02' and skip first screen.
Result paraGeneral Result type ABAP
endif.
z Quinto nivel
Instance-ind end_method.
Function module
API function
VA02 Transaction
Dialog module
Report
Miscellaneous
Name VA02
The implementation between BEGIN_METHOD and END_METHOD is generated from the definition data. The
generated source text has been extended so that the transaction is only called if a delivery block is set.
It is not necessary to call the macro SWC_REFRESH_OBJECT in this case, because the object context is always lost
in an asynchronous method
The terminating event must be triggered within the transaction called.
The single-step task that encapsulates this method requires at least one terminating event.
Implementando
Haga clic paraexcepciones
Object Type BUS1001: Display Exceptions For Method GETMISSEDVIEWS
Object Edit Goto Utilities View System Help

Exceptions
z Segundo
No. Object type Temp.nivel
App. Syst. AppArea Message Message text
1000 BUS1001 MA 279 & blocked by another user
7000 BUS1001 M3 195 No selectable views
z Tercer nivel
Exception 1000 begin_method getmissedviews changing container.
Cuarto nivel
z Exception
Object type
1000
BUS1001
...
call function 'ENQUEUE_EMMARAE'
exporting
Release 30D matnr = object-key-material
Quinto
z Error type nivel _scope
_wait
= '2'
= 'X'
Temporary error exceptions
Application error foreign_lock = 1.
System error if sy-subrc ne 0.
* temporary error - material currently locked by another user
exit_return 1000 object-key-material space space space.
Message
Application area MA endif.
Message 279 ...
& blocked by another user end_method.
No source code is generated for triggering an exception.

Every exception must correspond to a T100 message.
Up to four parameters, which correspond to the four parameters of the T100 message, can be transferred with the
EXIT_RETURN macro.
The triggering of exceptions is the same for all error types.
Implementando parámetros de transferencia
Object Type BUS2032: Edit Parameters for Method CREATE
Other view Program Exceptions

Overview
Parameter Object type Creation rel. Impl. Man. Exp. begin_method create changing container.
SalesDocumentType VBAK 21A
z Segundo nivel
TransactionCode VBAK 21A data: salesdocumenttype like tvak-auart,
transactioncode like t180-tcode.
Parameter SalesDocumentType
Object type VBAK
z Tercer nivel Release

swc_get_element container
21A
'SalesDocumentType' salesdocumenttype.
. Texts set parameter id 'AAT' field salesdocumenttype.
Name Sales document type
z Cuarto nivel Description Sales document type swc_get_element container

'TransactionCode' transactioncode.
Parameter properties
z Quinto nivel
set parameter id 'AAT' field salesdocumenttype.
Import Mandatory call transaction transactioncode.
Export .
Multiple-line
.
.
Data type reference
Dictionary
Reference table TVAK
Reference field AUART
Search help
Object type
The parameter transfer source code is generated entirely from the definition data.
Single-line input parameters are generally read via the macro SWC_GET_ELEMENT, and output parameters
written via the macro SWC_SET_ELEMENT.
The macros SWC_GET_TABLE and SWC_SET_TABLE are used for multiple-line parameters.
Resultados
Method
Method Approve
Approve x
Method Approve
Object type FORMABSENC begin_method approve changing container.
z
Release
Status
Haga clic para
30A
Released
modificar eldata:
estilo de like
proc_state texto del patrón
swxformabs-procstate.
z
Name
Segundo nivel call function 'SWX_FORMABS_APPROVE'
exporting
Approve formnumber = object-key-number
Description Approve form
z Tercer nivel importing
proc_state = proc_state
General Result type ABAP exceptions
z Cuarto nivel form_not_found = 01

aborted = 02.
Dictionary
Dictionary case sy-subrc.
when 00.
Quinto
z Reference
Reference table
field
nivel
SWXFORMABS
PROCSTATE
swc_set_element container result proc_state.
when 01.
Search help exit_return 1301 space space space space.
{ Object
{ Object type
type when 02.
exit_cancelled.
endcase.
Multiple-line
Multiple-line
end_method.
The result parameter must be set explicitly under the name "result" using the macro SWC_SET_ELEMENT. The
constant "result" is predefined and need not be defined explicitly.
Implementando acceso a atributos
Attribute SalesGroup x
Attribute SalesGroup
Release 40A

Status Modeled
Texts
z Segundo nivel
Name
Description
Sales group
Sales group (impl. as virt. attr.)
include <CNTN01>.
parameters: sales_order_key like vbak-vbeln.
z Tercer nivel
Source
data: sales_order type swc_object,
Virtual sales_group type swc_object.
Database field
z Cuarto nivel * create object(-reference)
swc_create_object
sales_order 'Z_BUS2032' sales_order_key.
z Quinto nivel
Multiple-line
Mandatory if sy-subrc ne 0.
Instance-independent ” do your own error handling
endif.
Data type referen.
Dictionary * read attribute SalesGroup of order
Reference table swc_get_property sales_order 'SalesGroup' sales_group.
Reference field
Search help
Object type TUKGR Sales group

Inverse attribute
The include <cntn01> must always be incorporated in the calling program. This include is also incorporated in the
implementation program via the include <object>.
Before attribute access, an object reference must be created by calling the macro SWC_CREATE_OBJECT. Error
handling measures must be incorporated if the object reference cannot be created.
Attribute access for single-line attributes uses the macro SWC_GET_PROPERTY, and for multiple-line attributes
the macro SWC_GET_TABLE_PROPERTY - irrespective of whether a virtual or a database attribute is read.
Attributes cannot be set via macros. Object values can only be changed via methods.

Implementando llamada a métodos
Object Type BUS2032: Display Parameters For Method CONVERTTOCOMPCURRENT
Parameter CompCurrent
Other view Program Exceptions
Parameter CompCurrency
Overview
Object type VBAK
z Segundo nivel
Parameter Object type Created Release 40A
CompCurrency VBAK 40A
NetvalueInCompCurr VBAK 40A Texts
Name Comparison currency
z Tercer nivel include <CNTN01>.
Description Comparison currency
z Cuarto nivel
data: sales_order type swc_object, Parameter properties
comp_curreny like vbak -waerk default ...,
new_value like vbak -netwr. Import Mandatory
swc_container method_container. Export
z Quinto nivel * create object( -reference)

swc_create_object sales_order
Multiple -line
Data type reference

'BUS2032 ' sales_oder_key.
if sy -subrc ne 0. Dictionary
” do your own error handling Reference table VBAK
endif. Reference field WAERK
Search help
* set import parameters for this method
Dictionary
swc_set_element method_container
'CompCurrency ' comp_currency.
* call method now

swc_call_method sales_order
'ConvertToCompCurrency ' method_container.
* read export parameter

swc_get_element method_container
 SAP AG 1999
'NetvalueInCompCurrency ' new_value.
The include <cntn01> must always be incorporated in the calling program. This include is also incorporated in the
implementation program via the include <object>.
Before attribute access, an object reference must be created by calling the macro SWC_CREATE_OBJECT. Error
handling measures must be incorporated if the object reference cannot be created.
The import parameters of the method must also be completed before the method call.
The actual method call is implemented with the macro SWC_CALL_METHOD.
The export parameters can be read after the call.

Macros
z Macros for object processing in include <cntn01>
Container
z Haga macros,
clic para for example
modificar setting
el estilo or reading
de texto container
del patrón
elements
z Segundo nivel
Object macros, for example creating objects or reading

z Tercer nivelvalues
attribute
Objects
zz Cuarto can also be manipulated outside the
nivel
workflow via macros
z Quinto nivel
The macro number must always be included if you are working in a program with objects. The macro is included
automatically in the Business Object Builders implementation programs via <object>.
Only macros from <cntn01> may be used to manipulate objects and containers.

Macros parapara
Haga clic crear y definirel
modificar objetos
z Object reference
Declaration
DATA: <obj_ref> TYPE SWC_OBJECT
z Segundo nivel
Creation
z Tercer nivel
SWC_CREATE_OBJECT <obj_ref> <obj_type> <obj_key>
z Cuarto nivel
z Quinto nivel
When SWC_CREATE_OBJECT is called, the method "ExistenceCheck" of the associated object type is always
called implicitly, in order to prevent references to non-existent objects.

Macros para atributos y métodos
z Attribute access
SWC_GET_[TABLE_]PROPERTY <obj_ref> <attribute> <value>
z Method call
z Segundo nivel
SWC_CALL_METHOD <obj_ref> <method> <container>
z Tercer nivel
z Cuarto nivel
z Quinto nivel
An object reference must be created before an object macro is called (for example, for attribute access or method
call).
These macros are not usually used in object implementation, but are required in the program that the object uses.
If the <method> is SPACE for SWC_CALL_METHOD, the default method is executed.

Macros para levantar eventos
z Triggering exceptions
EXIT_RETURN <exception_no> <var1> ... <var4>
z Segundo nivel
EXIT_OBJECT_NOT_FOUND
z Tercer nivel
EXIT_CANCELLED
z Cuarto nivel
z Quinto nivel
EXIT_RETURN - trigger general exceptions (similar to T100 messages).

EXIT_OBJECT_NOT_FOUND - specified object instance not found.
EXIT_CANCELLED - action cancelled by user (for example, in methods after BACK).
It is not necessary to define the exceptions EXIT_OBJECT_NOT_FOUND and EXIT_CANCELLED explicitly in a
method.
Customer-defined exceptions must be in the customer name range.

Macros
Haga para la gestión
clic para de objetos
z Type and key
SWC_GET_OBJECT_TYPE
z Haga clic para modificar el<obj_ref>
estilo de<obj_type>
texto del patrón
SWC_GET_OBJECT_KEY <obj_ref> <obj_key>
z Segundo nivel
z Refreshing object types
z Tercer nivel
SWC_REFRESH_OBJECT <obj_ref>
z Cuarto nivel
z Quinto nivel
When a work item is executed, the objects in the associated container are automatically refreshed.

Macros para container
z Definition and initialization
SWC_CONTAINER
z Haga <cont> el estilo de texto del patrón
clic para modificar
SWC_CREATE_CONTAINER <cont>
z Segundo nivel
z Reading and setting elements
z Tercer nivel
SWC_GET/SET_ELEMENT <cont> <element> <value>
z Cuarto nivel
SWC_GET/SET_TABLE <cont> <element> <int_tab>
z Quinto nivel
The container macros are also located in the include <cntn01>.

All types of container are manipulated via these macros (for example, task, role, event).

Delegación
Process definition BOB
BUS1001
TS0001 TS0002
SAP BUS1001. BUS1001. Edit
z Haga clic para modificar el estilo de texto del Display
Standard Edit patrón
Display
z Segundo nivel BUS1001
Edit
z Tercer
Inheritance
nivel
TS9001 TS9002 TS9003
Display
ZBUS1001. ZBUS1001. ZBUS1001.
Edit Display Release ZBUS1001
z Cuarto nivel Edit
Display
z Quinto nivel Release
BUS1001
BUS1001
Edit
Display
TS0001 TS0002 TS9004
Delegation BUS1001. BUS1001. BUS1001.
Edit Display Release ZBUS1001
Edit
Display
Release
Problem:
How can customers use their own object extensions with the tasks, events, etc. supplied by SAP
Without having to change the application program where events are triggered,
Without having to redefine existing tasks.
Solution:
Define subtype and delegation.
Delegation "covers" the original supertype.
Continue to use the supertype.
Gray/Top: Behavior without inheritance
Red/Middle: Behavior with inheritance
Blue/Bottom: Behavior with delegation - the object type BUS1001 is regarded as having the properties of
Z_BUS1001 (that is,
additional events, attributes and methods).
In the Business Object Builder itself, you can only see from the basic data for a supertype whether a delegation has
been defined.

Contenido del curso
Introducción
z Haga
Conceptos el estilo
z Segundo
Unidad 2 nivel
z Tercer
z Cuarto
z Quinto

BAPIs

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel

BAPIs
Haga –clic
Separando Qué y el
para modificar Cómo

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel

Características
Haga clic parade las BAPIS
Las BAPIs son identificadas por el nombre del objeto seguido del nombre de la
BAPI (p.e. Material.CheckAvailability())
z Segundo nivel
z Tercer
Existen nivel
algunas BAPIs comunes para muchos objetos. Por ejemplo la BAPI
GetList()
z Cuarto devuelve
niveluna lista de instancias de un tipo de objeto.
z Quinto nivel
Los cambios en la base de datos se realizan completamente o no se realizan.
Las BAPIs no puede devolver ninguna pantalla de diálogo.
Los usuarios que ejecutan la BAPI deben tener las autorizaciones necesarias.

Catálogo depara
Haga clic BAPIs
•Transacción BAPI

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel

Catálogo
Haga clicdepara
BAPIs
En él podemos ver los diferentes parámetros de una BAPI, así como los campos clave,
z Haga clic
documentación para modificar
y nombre de la funciónel estilo
asociada de texto del patrón
z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel

Catálogo
Haga clicdepara
BAPIs
•Repositorio de SAP: Ifr.sap.com

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel

Acceso a BAPI

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel

Ejemplo – Como
Haga clic RFC
El acceso se realiza de manera similar al de una RFC. Desde SAP:

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel

Ejemplo – Como
Haga clic RFC
El acceso se realiza de manera similar que al de una RFC. Desde Visual Basic:

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel

Ejemplo – Como
Haga clic BAPI
Desde Visual Basic:

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel

Herramientas BOR
z Transacciones SAP
z Haga clic paraBusiness
BAPI modificar el estilo
Object de texto
Browser del
(BAPIs patrón
only)
z Segundo
SWO1 nivel
Business Object Builder (all objects)
SWO2
z Tercer nivel Business Object Browser (all objects)
SE11
z Cuarto nivel Data Dictionary
SE37 Function Builder
z Quinto nivel

Transaccion Handling
z All 3.1 update BAPIs execute their own COMMIT WORK.
zzBAPIs
Haga since
clic para4.0 are not supposed
modificar el estilo detotexto
do this.
del patrón
zzDouble-check
Segundo nivel which category the BAPIs you want to use fall
into.
z Tercer nivel
There is no metadata attribute for this
z Cuarto nivel
Read the documentation
z Quinto
OSSnivel
Note 131838 should list all BAPIs that execute their own
COMMIT WORK
If in doubt, test...
z Be careful when using BAPIs from both categories in the
same session.
z Your own BAPIs must use the Update Task to support the
new concept.

Commit/Rollback BAPIs
z Supported starting with 4.5 by the BapiService methods
TransactionCommit
WAIT parameter allows the client program to wait for the
z Segundo nivel of the Update Task.
completion
Return
z Tercer nivelparameter (filled only when WAIT = "X")
TransactionRollback
z Cuarto nivel
z Supported starting with 4.0 by the RFC-enabled functions
Quinto nivel
z modules
BAPI_TRANSACTION_COMMIT
BAPI_TRANSACTION_ROLLBACK

Contenido del curso
Introducción
z Haga
Conceptos el estilo
z Segundo
Unidad 2 nivel
z Tercer
z Cuarto
z Quinto

Ampliaciones y modificaciones
Pasos para el desarrollo de una nueva BAPI, ampliación o modificación:

z Haga
clic para modificar el estilo de texto del patrón
Análisis
z Segundo
nivel
Diseño
Implementación
z Tercer nivel
Test
z Cuarto y liberación
nivel
z Quinto nivel
Análisis: Determinar que procesos de negocio se van a implementar como BAPI

Diseño: Definir el interface
Implementación: Definir estructuras de datos, implementar el programa, definir la BAPI en el BOR
Test y liberación

Análisis
Describir el escenario
z Haga
clic para
Definir modificar
propósito el estilo de texto del patrón
y alcance
z Segundo
nivel los pasos individuales y secuencias
Identificara
Identificar
z Tercer nivel los datos que se intercambiaran
Gestión
z Cuarto nivel de errores
z Quinto nivel
Definir el escenario en el explorador BAPI
En la transacción BAPI en la pestaña proyecto, implementar
nueva BAPI. Un asistente aparece

Diseño
Un usuario debe ser capaz de implementar la llamada de una

BAPI correctamente
z Haga en un sistema
clic para modificar el estiloexterno,
de texto sin
del conocimientos
patrón
de SAP.
z Segundo nivel
z Tercer nivel
Los parámetros y métodos deben seguir las convenciones.
z Cuarto nivel
z Quinto nivel
Existen algunas BAPIs estándares:
GetList y GetDetail
CreateFromData, Change, Delete
Algunas convenciones para métodos:

Si es una BAPI estándar usar el nombre genérico como por ejemplo GetList o GetDetail
Método en ingles (max 30 caracteres)
Los componentes individuales del nombre deben estar separados por una mayúscula
Underscores no están permitidos
Cada BAPI tiene un parámetro return como export o tabla
Cada BAPI debe tener un parametro ExtensionIn y otro ExtensionOut para posibles ampliaciones
Algunas convenciones para parámetros:

Si son estándares usar los nombres correspondientes (pe RETURN)
Nombres en ingles y claros (max 30)

Implementacion nueva BAPI

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
Definir estructuras de datos

Implementar las funciones
y No se pueden ejecutar COMMIT WORK
y No se puede utilizar CALL TRANSACTION, SUBMIT REPORT
y Nos se usan excepciones (tabla RETURN)
y Tipo RFC
y Los parametros deben hacer referencia a estructuras BAPIs
Crear el tipo de objeto y métodos en el BOR


z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel

y Tipo RFC


z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel

y Tipo RFC


z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel

y Tipo RFC

Test y liberación
Comprobar:
Documentación
z Segundo nivelBAPI
Sintaxis
z Tercer nivel
Semántica BAPI
z Cuarto
Uso nivel
en aplicaciones externas
z Quinto
Uso nivel
en diferentes plataformas
Liberar
Liberar función
Liberar objeto
Liberar BAPI

Ampliación y modificaciones
Los cambios a realizar en una BAPI pueden ser:

Ampliaciones el estilo de texto del patrón
(recomendado)
z Segundo nivel
Modificaciones
z Tercer nivel
z Cuarto nivel
z Quinto nivel
Las modificaciones no se podrán hacer sobre el objeto original, se deberá crear un subtype

Ampliación
Se utilizará los parámetros ExtensionIn y ExtensionOut como

containers
z Haga clicdepara
la información
z Segundo nivel
Cada BAPI nivel
z Tercer deberá contener un máximo de dos exits, una para
comprobar la estructura ExtensionIn, la segunda para realizar
Cuarto de
z proceso
el nivel
entrada y extracción de datos en ExtensioinOut
z Quinto nivel

Tipos Ampliación
Basado en tablas de SAP, para appends de cliente o datos de

la
z base
Hagadeclic
datos nomodificar
para gestionados por la
el estilo deBAPI
texto del patrón
z Segundo nivel
Incluyendo tablas de cliente, para informar tablas propias
z Tercer nivel
z Cuarto nivel
Sin afectarnivel
z Quinto a la base de datos, por ejemplo un nuevo criterio
de selección en GetList

Basado en tablas de SAP
Existe una BAPI que gestiona la creación de registros en la

tabla STRAVELAG.
Se
z quiere añadir
Segundo a la tabla STRAVELAG un append con los
nivel
campos:
z Tercer nivel
PLANETYPE (S_PLANETYPE) CHAR 10
z Cuarto nivel
COMPANY (S_CARRNAME) CHAR 20
z Quinto nivel
SEATSMAX (S_SEATSMAX) INT4 10
La bapi deberá actualizar también dichos campos

Basado en tablas de SAP: Append
Extensión de la tabla BAPI: Creación de una estructura

BAPI_TE_<nombre tabla a ampliar>
z Haga clic para modificar el estilocon la clave
de texto delde la misma y
patrón
el mismo append utilizado (los datos del append no debe
z Segundo
superar nivel
los 960 caracteres)
z Tercer nivel
z Cuarto nivel
Extensión de los parámetros de la BAPI (ExtensionIn), basada
en
z laQuinto
estructura
nivel BAPIPAREX
Structure: Nombre de la tabla BAPI
Valuepart1…4: El contenido concatenado para los
datos del append precedido de la clave
Creación exits

Basado en tablas de SAP: Datos no gestionados
El método GetDetail muestra todos los datos de la tabla

STRAVELAG exceptuando
z Haga clic para modificar URL y LANGU,
el estilo de texto pero el cliente lo
del patrón
requiere.
z Segundo nivel
z Tercer nivel
Se crearía una tabla BAPI con estos dos campos a través de un
z Cuartoy nivel
APPEND se gestionaría de la misma forma que en el caso
anterior
z Quinto nivel

Contenido del curso
Introducción
z Haga
Conceptos el estilo
z Segundo
Unidad 2 nivel
z Tercer
z Cuarto
z Quinto

ALE/IDoc:
Haga cliccontenido
z Intermediate Documents (IDocs)
z Application Link Enabling (ALE)
z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel

Procesos de negocio distribuidos
z Distributed applications require distributed business processes
Available
z z ALE
Haga clic Business
para Processes
modificar el estiloin
destandard
texto del patrón
R/3 - R/3 nivel
z Segundo
R/3 - New
z Tercer Dimension Components
nivel
R/3 - Non-SAP
z Cuarto nivel
z If a scenario is not available in the standard, you can enhance
z Quinto nivel
existing scenarios or create new ones.
z Due to legal or technical reasons, some distributed scenarios
might not be possible at all
Information about the enhancement of existing or the creation of new scenarios are available in:
y training class BC621
y R/3 online documentation
ALE Programming
BAPI Programming
y R/3 interface adviser
Some scenarios are not possible to implement for legal or business reasons
y e.g.: It makes no sense to link a logistic system to the financial system only by synchronous
communication. This would disable most of the logistic transactions if the communication is down or
there are problems within the financial system. The required postings within the general ledger could
not be done. A scenario with asynchronous communication is required.

IDocs
z An IDoc is a container for the data of a business object or

z technical
Haga clicR/3
paraobject
zz Each IDocnivel
Segundo has a message type. This indicates the type of
business object or the business function of the data.
z Tercer nivel
z Message types have processing rules in the receiving
Cuarto nivel
z system.
Quinto
zz An IDocnivel
contains the data in a segment hierarchy. The
IDoc type describes the technical structure of the IDoc.
z IDoc types have versions.
Technical R/3 objects for IDocs with a message type exist, for example, audit data (ALEAUD) and
distribution group (CONDA2)
An IDoc has different characteristics: database table, text, HTML file, XML datastream, RFC call
parameters.

Concepto de IDOC
Î Asynchronous
Haga
z Î clic para modificar el estilo de texto del patrón
Document-related
z Segundo nivel
z Tercer nivel1
System System 2
z Cuarto nivel
SAP Document
Document
IDoc Transaction
z Quinto nivel Message
R/3 System EDI subsystem

R/3 System
R/2 System
3rd party software
The key concepts of IDoc (i.e. Intermediate Document) are:

y communication is asynchronous and
y related to one document, i.e. transaction.
Following these concepts IDoc facilitates distributed processes rather simply invoking functions.
IDoc is the SAP standard interface to link application systems via messaging. Whereas one system is
asumed to be SAP system R/3, the other system could be
y EDI subsystem,
y system R/3,
y system R/2 or
y any third-party application software.
IDoc is available for system R/3 from release 2.1A on.
IDoc is available for system R/2 from release 5.0F on.

Tipos de registro
z Haga Control
clic para modificar IDoc-ID
Record
el estilo de texto del patrón
Sender-ID
Receiver-ID
z Segundo nivel IDoc type and logical message
External structure
z Tercer nivel
Data Record IDoc-ID
Sequence/Hierarchy
z Cuarto nivel Segment Format definition for
• header data
z Quinto nivel • item data
Status Record IDoc-ID

Status information
Each IDoc in the SAP database consists of

y exact one control record,
y a number of data records, which span a tree of segments, and
y a set of status records, though their number grows over time.
The data to be exchanged between two systems via the IDoc interface carries in one transmission
y IDocs (consisting only of control and data records), or
y status information (consisting only of status records).
Status information is expected to be sent to the IDoc interface to report on outbound IDocs. There is no
status information sent for inbound IDocs by SAP in general.
For individual status reporting in both directions and with all port types logical message STATUS is
implemented by IDoc type SYSTAT01.
Total length of records in version 2 (Releases 3.x):
y Control Record 464 bytes (plus 1 line delimiter)
y Data Record 55 bytes envelope, up-to 1,000 bytes segment (plus 1 line delimiter)
y Status Record 382 bytes (plus 1 line delimiter)
Total length of records in version 3 (Releases 4.x):
y Control Record 524 bytes (plus 1 line delimiter)
y Data Record 63 bytes envelope, up-to 1,000 bytes segment (plus 1 line delimiter)
y Status Record 562 bytes (plus 1 line delimiter)

Tipos de IDOC
z Haga clicRecord
Control para modificar el estilo de texto del patrón
z Segundo nivel
Data Records
z Tercer nivel
E1HDDOC E1TLSUM
z Cuarto
M nivel
1 C 1
z Quinto nivel E1HDADR E1ITDOC

C 5 M 1
E1ITSCH
Tree of Segments C 99 C 5
Status Records
Each IDoc type is defined by its segments and their properties. These are segmenttype / segmentname,
position / sequence and iteration / status.
SAP segmenttypes (internal representation) begin with 'E1', all the corresponding segmentnames
(external representation) begin with 'E2‘.
Field length and data types are compared where applicable with data element directories of
UN/EDIFACT, ANSI X12 and SAP‘s Data Repository.
Codes for coded fields (currencies, countries, units of measure) are taken from ISO standards.
The segments in the example above can be interpreted as follows
y E1HDDOC Document Header
y E1HDADR Header Addresses
y E1ITDOC Item Details
y E1ITSCH Item Schedule
y E1TLSUM Trailor Section

Definición

Basis Type
z Segundo nivel
z Tercer nivel = IDoc Type
z Cuarto nivel
z Quinto nivel
Basis Type
+ Extension
= IDoc Type
IDoc = Intermediate Document !

An IDoc type is a hierarichal, complex data structure constructed by segments, intended to carry a
complete business document. Formally basis types and extensions are distinguished as IDoc types. The
instance of such a document in „IDoc format“ is an IDoc of a well-defined IDoc type.
An extension extends a basis type (SAP standard) with customer specific segments. All the customer
segments are assigned in a direct or indirect way to segments of the basis type. The segments of the
basis type are the „roots“ of the sub-trees constructed by the customer segments.
In the control record the IDoc type constructed by an extension is identified by the fields
IDOCTYP name of the basis type, and
CIMTYP name of the extension.
Examples:
y IDoc type ORDERS01 as standard, i.e. without an extension:
- field IDOCTYP has content ORDERS01
- field CIMTYP is empty
y IDoc type ORDERS01 as standard, but with an extension:
- field IDOCTYP has content ORDERS01
- field CIMTYP has the extension‘s name as content

Estructura de un IDOC
Components of an IDoc Structure of the data records

Control record (IDoc type) Hierarchy level 2
z Haga clic para modificar elHeader
IDoc type information: basic type, extension,
estilo de texto del
segment mandatory
patrón
Header segment
mandatory Curr.
Curr. No.
No. 11 Transfer
Transfer No.
No. 00
IDoc type, message type, sender and reciver
z Segundo nivel
information. Technical information: release,
Hierarchy level 3
serialization information, creation date and time
Segment
Segment 11
z Tercer nivel
Data records
mandatory
mandatory Curr.
Curr. No.
No. 22 Transfer
Transfer No.
No. 11
E1HDR xxxxxxxx
Segment
Segment 33
z Cuarto
E1SEG1
E1SEG2
nivel
xxxxxxxxxxxxxxx
xxxx
optional
optional Curr.
Curr. No.
No. 33 Transfer
Transfer No.
No. 11
E1SEG3 xxxx Hierarchy level 4

z Quinto nivel
E1SUB1 xxxxxxx
Subsegment
Subsegment 11 Curr.
Curr. No.
No. 44 Transfer
Transfer No.
No. 33
E1SUB2 xxxxxxxxxxxxxxx
E1SEGM4 xxxx
E1SEGM5 xxxx Subsegment
Subsegment 22 Curr.
Curr. No.
No. 55 Transfer
Transfer No.
No. 33
E1SUB3 xxxxxxxx
Status records in database Hierarchy level 3

“For processing" 16:22:34 Segment
Segment 44 Curr.
Curr. No.
No. 66 Transfer
Transfer No.
No. 11
“Successfully processed" 16:22:42

Segment
Segment 55 Curr.
Curr. No.
No. 77 Transfer
Transfer No.
No. 11
Status records are data records assigned locally to an IDoc - they not part of an IDoc . They are not
sent together with the IDoc.

Relación entre tipo de mensaje y tipo de IDOC
1. Order
Message type:el estilo de texto del patrón
ORDERS
IDoc type : ORDERS01 (3.0A)
z Segundo nivel ORDERS02 (3.0D)
ORDERS03 (4.0A)
ORDERS04 (4.5A) Sales
z Tercer nivel
Customer
2. Order confirmation
z Cuarto nivel Message type: ORDRSP
IDoc type : ORDERS0x
z Quinto nivel
3. Delivery
Message type: DESADV
IDoc type : DESADV01 (3.0A)
DELVRY01 (4.0A)
DELVRY02 (4.5A)
4. Billing document
Message type: INVOIC
IDoc type : INVOIC01 (3.0A)
INVOIC02 (4.0A)
Message types specify the semantics of application data. The message type is usually based on an
EDIFACT message type.
The syntax (structure information) of the data is described in the IDoc type.

Flujo de datos
Outbound Data Inbound

z Segundo nivel
Application MM
SD
Application
...
z Tercer nivel
Message
z Cuarto nivelControl Workflow
z Quinto nivel
IDoc Interface & IDoc IDoc Interface &
ALE Services ALE Services
System 2 File System 2

e.g. EDI subsystem tRFC e.g. EDI subsystem
XML
...
Please read the left (outbound) from top and the right (inbound) from bottom.
Message Control is in use with transactions of the supply chain, applications MM and SD, in outbound
processing.
Workflow is conditional with all inbound processing by all SAP applications.
Nevertheless Workflow is in use with all SAP applications to report on exceptions in the implemented
processes. For details please refer to the notification and monitoring section.

Flujo outbound
SAP Application
Document
z Segundo nivel
z Tercer nivel Control (NAST)
Message
z Cuarto nivel Document
NAST
Record
z Quinto nivel
IDoc Interface & ALE Services
IDoc
System 2, e.g. EDI subsystem
SAP applications can create IDocs under control of Message Control or on their own.
An IDoc can go from an application through Message Control into the IDoc interface. The IDoc
interface is invoked by either form-routine EDI_PROCESSING or ALE_PROCESSING in program
RSNASTED. In the IDoc interface the IDoc is passed to ALE services (conditional) and later on
transferred to system 2 according to its port definition.
Applications that do not use Message Control will create IDocs directly. They invoke function module
MASTER_IDOC_DISTRIBUTE and pass the IDocs to ALE services, where the IDocs will be
preprocessed according to ALE customizing.
All IDocs are transferred according to the port definition,
y most common between R/3 systems is the (asynchronous) transactional RFC interface
(standard ALE scenario)
y most common between R/3 system and EDI subsystem is the flat file interface
(standard EDI scenario).

Flujo Inbound
System 2, e.g. EDI subsystem

IDoc
z Segundo nivel
z Tercer nivel IDoc Interface & ALE Services
z Cuarto nivel
IDoc +
z Quinto nivelProcess
SAP Business Workflow IDoc +

Function Module
Document
SAP Application
System 2, e.g. the EDI subsystem, sends IDocs to the SAP system R/3.
All IDocs are received via a port with its related port definition,
y most common between R/3 systems is the (asynchronous) transactional RFC interface
(standard ALE scenario)
y most common between R/3 system and EDI subsystem is the flat file interface
(standard EDI scenario).
The IDocs enter the SAP system at the IDoc interface. The IDoc interface accepts the IDocs, passes the
IDocs either through ALE services or to workflow management.
The ALE services can be customized to post IDocs to the application directly via means of CALL
FUNCTION or via means of workflow management.

Tipos de puertas
SAP Application
IDoc Interface & ALE Services
z Segundo nivel
z Tercer nivel
IDoc & IDoc &
IDoc IDoc IDoc
status status
z Cuarto nivel
z Quinto nivel
File
tRFC CPI-C ABAP XML
+ RFC
EDI ALE EC
R/2 Any
Any Any Any
2.1 on 4.5 on 4.6 on
3.0 on 3.0 on
The IDoc interface offers 5 different communication channels, defined by the appropriate port types,
within system R/3.
Port type „File“
Transfer of information via files and synchronous RFC for triggering of the destination by the source.
This allows transfer of IDoc data and status report.
Port type „tRFC“
Transfer of all information via (asynchronous) transactional RFC.
This is the preferred method in ALE scenarios and allows transfer of IDoc data.
Port type „CPI-C“
Transfer of all information via CPI-C. This option is in use only with system R/2 couppling based on the
R/2-IDoc interface as released in R/2, 5.0F.
This allows transfer of IDoc data and status report.
Port type „ABAP“
Transfer of all information with customer specific program logic.
This is thought to be a „Project-Exit“ for any unforseen communication channel.
Port type „XML“
Transfer of all information via XML compatible files, including DTD if requested. This port type is
released as prototype, changes and enhancements are expected for future releases.
The port type „Internet“ is not recommended for use anymore. If you plan for Web/EDI, please refer to
an EDI subsystem. If you plan for mySAP.com, please use the strategic recommendation of SAP
Business Connector with XML.
Please refer also to OSS note #315083.

ALE Arquitectura
z Interfaces between different components and

Legacy Systems
z Segundo nivel Component B
Component A
R/3
z Tercer nivel
z Cuarto nivel
z Quinto nivel
Component C
Legacy System
Component D
SAP
ALE provides the functionality to distribute and receive data to and from:
y R/3 Systems ( >= 3.0 )
y different SAP components
y R/2 Systems
y Non-SAP-Systems
It uses synchronous and asynchronous RFC's and standard communication protocols.
The data can be processed on-line or in batch mode.

Flujos entre sistemas
Application
Application
z Haga clicIDoc
IDoc data
data
para BAPI
BAPI parameters
modificar el estilo de texto parameters
del patrón BAPI
BAPI data
data
S e n d e r
Interface
Interface for
for Synchronous
z Segundo nivel
Interface
Interface for
for IDocs
(outbound)
(outbound)
IDocs asynchronous
asynchronous BAPIBAPI BAPI call
calls
calls (outbound)
(outbound)
z Tercer nivel
Basic
Basic IDoc
IDoc Legend
z Cuarto nivel tRFC
tRFC communication
communication Application
Application
z Quinto nivel tRFC

tRFC communication
communication ALE/application
ALE/application
Basic
Basic IDoc
IDoc ALE
ALE
R e c e i v e r
Interface
Interface for
for Basis
Basis
Interface
Interface for
for IDocs
IDocs asynchronous
asynchronous BAPI
BAPI
(inbound)
(inbound) calls
calls (inbound)
(inbound)
Inbound
Inbound function
function module
module for
for IDoc
IDoc BAPI
BAPI
Application
Application
Outbound function modules for asynchronous BAPI calls

y ALE_<BO>_<METHOD>
Inbound function modules for IDoc via tRFC
y INBOUND_IDOC_PROCESS (3.x)
y IDOC_INBOUND_ASYNCHRONOUS (since 4.x)
Inbound function modules for updating asynchronous BAPIs
y BAPI_<BO>_<METHOD>

Modelo de distribución
z The distribution model has a tree structure with the following

levels:
View of the distribution model
z Segundo nivel
Logical sending systems
z Tercer nivel
Logical receiving systems
z Cuarto nivelmessage types or BAPIs
Messages:
z Quinto nivel for data filtering and receiver determination
Conditions
z A connection is established by assigning
message types or BAPIs to two logical
systems
z Distribution model views are used to group
together distribution scenarios
The distribution model is client-dependent and may contain one or more views.

Sistemas lógicos
z Messages in ALE flow between logical systems
zz Logical systems
Haga clic are defined
para modificar cross-client
el estilo de textoindel
R/3.
patrón
zz Precisely
Segundo one
nivellogical system is assigned to one client When
messages are posted, this logical system is transferred into
Tercer niveldocuments
z application
z Cuarto nivel
CAUTION WHEN
z Quinto nivelRENAMING THE LOGICAL SYSTEM OF A CLIENT
Other characteristics of logical systems

y Logical systems have a technical name up to 10 characters long and an explanatory short text.
y The maintenance of logical systems is an ALE Customizing activity
y Application documents with an empty logical system or with the logical system of the current client
are interpreted as local documents.
Problems with the logical system name
y If the logical system name of a client is changed, the modeling of the ALE message flow may
become inconsistent.
y If the logical system name of a client is changed, application documents may become invisible
because the application classifies them as external documents.
y As of R/3 Release 4.5A a logical system must be assigned to each client. For this reason,
meaningless logical system names had often been assigned that had to later be renamed. When the
logical systems were renamed, the problems with application documents described above occurred.
y ALE provides a tool to rename logical system names in application tables. You can find more
information in ALE Customizing or in a note.

Acuerdos de interlocutor
z Partner profiles control the processing of inbound and
outbound IDocs
z They can be generated in the maintenance transaction for the
Segundo nivel
z distribution model
z Tercer nivel
z Important parameters:
z Cuarto nivel
The size of IDoc packets per RFC call
z Quinto nivel
The size of IDoc packets for processing
Output and processing mode: collect or process immediately
Partner profiles are client-dependent.

Partner profiles with the partner type logical system only exist for systems which the current client
sends messages to or receives messages from.
For this reason when the partner profiles are generated, ALE only considers connections that contain
the logical system of the current client.

Proceso outbound
z Haga clic para modificar elALE

Application Communication
APIs for receiver
Determine receivers,
z Segundo
if required nivel
determination
z Tercer
Fill IDocnivel
structures Receiver Determination
and forward to ALE
z Cuarto nivel IDoc Services
Data filtering
z Quinto nivel Explicit segment filtering
Conversion of global org.units
Data conversion
Version change
APIs for creating IDocs

Creating IDocs
Writing links to
Process IDocs according
application objects
to partner profile

Proceso inbound
ALE
Application
Communication
IDocs received
z Segundo nivel via tRFC
z Tercer nivel Write IDoc to database

IDoc Services
z Cuarto nivel Explicit segment filtering
Conversion of global org.units
Data conversion
Version change
z Quinto nivel
Call application function

Function module module

Proceso con BAPIs
z Outbound processing for asynchronous BAPI calls is similar

z toHaga
IDocclic
processing
para modificar el estilo de texto del patrón
zz InSegundo
an interim step the ALE interface converts the BAPI
nivel
parameters into an IDoc with the appropriate segment
Tercer nivel
z structure and message type
Cuarto
zz For nivelusers the usage of a BAPI is transparent and
the ALE
z equivalent to classical message types
Quinto nivel

Proceso de salida
Application
ALE Communication
Determine receivers, APIs for receiver
determination
z Segundo
if required nivel
ALE interface for

Forward BAPI
z Tercer nivel
parameters to ALE
asynchronous BAPI call
z Cuarto nivel ALE services

Receiver determination
Data filtering
z Quinto nivel Data conversion
Version change
Serialization
APIs for creating IDocs

Creating IDocs
Writing links to
application objects IDoc processing by
partner profile

Proceso de entrada
z Haga clic para modificar elALE

Application Communication
estilo de textoIDocs
delreceived
patrón via tRFC
z Segundo nivel
ALE Services Write IDoc to database
z Tercer nivel Explicit segment filtering
Conversion of global org.
z Cuarto nivel units

Data conversion
Version change
Serialization using business
z Quinto nivel objects
Convert IDoc and call

BAPI BAPI

Escenarios para aplicaciones externas
z Inbound
Use IDocs as an alternative to update BAPIs if
No BAPI exists for your requirements
z Segundo nivel
You need guaranteed (once and once only) delivery
z Tercer nivel
z BAPI call via tRFC also possible
z Cuarto (remember: no outbound data)
nivel
zz Outbound
Quinto nivel
Subscribe to IDoc message types in the ALE distribution model in
order to keep an external database synchronized.
z SAP Business Connector can be used as well.

Utilizacion de BAPIs con ALE: Síncrona

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
In the application program, the following steps are involved in a synchronous BAPI call for a distributed
business process:
Distribution model query: The application program uses the distribution model to determine the
recipient and any filter values for filter objects.
Determining the RFC destination: To maintain the corresponding RFC destination, use transaction
BD97
Calling the BAPI function module using RFC: Application data is assigned to the BAPI interface, and
the BAPI function module is called in the remote system.

BD97

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
You can use transaction %' to enter a standard destination for BAPIs for a specific target system. All
BAPI calls for which no specific destination is maintained use this destination. Note that the RFC user
for the standard destination must have sufficient application authorizations.
For each BAPI call (= method call), you can maintain one destination for each target system. This means
that you can assign the RFC user the appropriate authorizations more precisely.

Modelo distribución: BAPIs

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
In the distribution model, you can use the "Add BAPI" icon to add more BAPIs to the view.
As well as the sender and recipient system, you enter the name of the business object type and the
method. For the business object type and method, enter the names from the BAPI Explorer, and not the
technical name of the business object type from the Business Object Builder.

Utilizacion de BAPIs con ALE: Asíncrona

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
To start a BAPI asynchronously in the target system, an IDoc is sent to the target system containing the
interface parameters of the BAPI and, for instance methods, the key fields of the business object. The
BAPI function module is called locally in the target system using the parameters from the IDoc.

Interface ALE para BAPIs

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
From the detail view of the BAPI Explorer, you can double click on the ALE message type to display the
ALE interface for a BAPI. This displays the transaction BDBG for displaying and
generating ALE interfaces for BAPIs.
Choose the "Display interface" icon to display elements generated for the ALE interface to the BAPI.

Interface ALE para BAPIs

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
The generated ALE interface for a BAPI includes the following elements:
Message type
IDOC type
Segment types: The elementary import parameters are grouped together in a segment type. A segment
type is created for each structured import parameter.
Function module for outbound ALE: In the outbound module, the interface parameters are copied to
the IDoc segments and a master IDoc is created. A function module is then called which transfers this
master IDoc to the ALE layer.
Function module for inbound ALE: The inbound module copies the contents of the segment fields to
the corresponding interface parameters, and calls the BAPI function module locally.

Interface ALE para BAPIs: Ejemplo

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel

Interface ALE para BAPIs: Ejemplo

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel

Outbound

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
The application program follows the following steps:

After the application data has been received, the recipient and filter values for filter objects are
determined from the distribution model.
The generated outbound module is called for the BAPI ALE interface. This generates the master IDoc
and passes it to the ALE layer.

Inbound

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
In the target system, the IDoc is first saved to the database.

Depending on the settings in the partner profile, it either is processed immediately, or as a background
job by scheduling the program RBDAPP01
If the process code ’BAPI’ is used in the partner profile, this tells the ALE layer to call the inbound
module of the ALE interface generated for the BAPI .
The inbound module copies the contents of the segment fields to the BAPI interface parameters, and
calls the BAPI function module locally.

Modelo distribución

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
To set up distribution using an asynchronous BAPI call, add the BAPI to your view of the distribution
model as in the synchronous call.

Acuerdo interlocutor outbound

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel
Generate the partner profile from the distribution model. The system enters the correct message type
and IDoc type for the BAPI.

Acuerdo interlocutor inbound

z Segundo nivel
z Tercer nivel
z Cuarto nivel
z Quinto nivel

BAPI Development For Accessing SAP

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

BAPI Development For Accessing SAP

Hochgeladen von

Copyright:

Verfügbare Formate

Haga clic para modificar el estilo de título del patrón

z Haga clic para modificar el estilo de texto del patrón