BAPI Development for Accessing SAP

Course Overview - 1

Offilog 2001 Universidad (Salvador Seda) / 1

Haga clic para modificar el estilo de ttulo del patrn

z Haga clic para modificar el estilo de texto del patrnz Segundo nivelz Tercer nivelz Cuarto nivelz Quinto nivel

BAPI Development for Accessing SAPBAPI Development for Accessing SAP

Course Overview - 2




Objetivos del curso

A la finalizacin del curso ser capaz de:

Identificar Objetos de negocio

Identificar y utilizar las BAPIs

Crear RFCs

Ampliar la funcionalidad de las BAPIS

Utilizar las BAPIs en el entorno ALE

Course Overview - 3




Introduccin

Unidad 1 Conceptos bsicos BAPI

Unidad 2 Creacin Mdulos de funcin RFC

Unidad 3 Objetos de negocio

Unidad 4 Utilizacin de BAPIs

Unidad 5 Ampliaciones y modificaciones

Unidad 6 BAPIs y ALE

Contenido del curso

Course Overview - 4




Introduccin







Contenido del curso

Course Overview - 5




A la finalizacin de la introduccin ser capaz de: Entender varios escenarios de integracin entre

SAP y sistemas no-SAP.

Escenarios de integracin

Course Overview - 6




Interfaces

RFC

CPI-C

TCP/IP LU6.2

OLEOpen InterfacesOpen Interfaces

EDIEDI

ALEALE

BAPIBAPI

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.

iguzmanResaltado

Course Overview - 7

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.




Remote Function Call

R/3 System

R/3 System R/2 SystemExternes System

ABAP Program ABAP ProgramABAP Program

ABAPProgram

ExternalProgram

ABAPProgram

RFC Interface RFC Interface RFC Interface

RFC Interfaces

iguzmanResaltado

iguzmanResaltado

iguzmanResaltado

iguzmanResaltado

iguzmanResaltado

Course Overview - 8




Objetos de negocio y BAPIs

BAPIs are used for:

Distributed scenarios (ALE)

mySAP.com Components

Internet/Intranet

Business Workflow

External Programs

Customer and Partner Developments

...

BOR: Business Object Repository

BO: Business ObjectFor example, sales

order

BAPI: Business ApplicationProgramming InterfaceFor example, create an order

cont

ains

cont

ains

met

hod

HR FI

CO

BORBOR

BAPIBAPI

BAPIBAPIBOBOBAPIBAPI

BAPIBAPI BOBO

BAPIBAPIBOBOBAPIBAPI

BAPIBAPI BOBO

BAPIBAPI

BOBO

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 SAPs 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.

iguzmanResaltado

iguzmanResaltado

Course Overview - 9




ALE - Application Link Enabling

PP Inventory management Internal sales,

distribution, and billing Local purchasing PM

Accounting Central Controlling Information systems:

Inventory Purchasing Sales

Central Purchasing Reference system for

master data and tax data

Sales, distribution, and billing

Sales of trade goods Inventory Management Local Controlling

DistributedBusiness Processes

ALE is the exchange of messages controlled from a business point of viewy By synchronous and asynchronous communicationy Using BAPI interfaces and IDoc Data containersy With consistent data storage

- The applications do not use a central database- They are supplied by regional, closed databases with their own data basisy 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 systemsy R/3 and non-SAP R/3 systems

For example, in SAP R/3, external warehouse control systemy 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

iguzmanResaltado

Course Overview - 10

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 automaticallyy 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.




EDI Architecture

Documents

Ext. application

EDI Messages

EDI subsystem

IDoc Type

IDoc interface SAP R/3 Application

SAP Documents

Datarecord

Control record

Control record

iguzmanResaltado





Transferencia de datos utilizando Batch Input

Sequential File SAP Interfacesand Checks

External System SAP R/3 System

Batch Input

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.

iguzmanResaltado

iguzmanResaltado

iguzmanResaltado


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.




Transferencia de datos utilizando Batch Input

Queue File

SAPDatabase

Application FunctionApplication Function

Batch Input FunctionBatch Input Function

BDCBDC--TabelleTabelle

BATCH INPUT:BATCH INPUT:

SAPDatabase

Application FunctionApplication Function

BDCBDC--TabelleTabelle

CALL TRANSACTION:CALL TRANSACTION:

CALLTRANSACTION

SAPDatabase

DIRECT INPUT:DIRECT INPUT:

SAPTransferProgram

SequentialFile

SequentialFile

SequentialFile

iguzmanResaltado


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.




Integracin Office mediante OLE

Frontend SAP R/3 System

PC Program

PC Program

SAP GUIABAP Program

Function Module OLE

Clie

ntO

LE C

lient

Function Module

Function Module OLE

Serv

erO

LE S

erve

r

RFC InterfaceRFC Interface RFC InterfaceRFC Interface





SAP Automation





Internet Transaction Server

Internet Transaction Server (ITS)

InternetBrowser

InternetServer

Comp.systemWGate AGateHTTP CGI TCP/IP

DIAG

RFC

Connection: Web Server / Component system Logging on in component systems Data receipt, conversion to HTML

User Query Input

CSSFiles

ServiceFiles

ServiceFiles

HTMLTemplates

OutputHTML Page

The web server and component system is connected through SAPs 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 Microsofts 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 AGateconfigure 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

iguzmanResaltado

iguzmanResaltado

iguzmanResaltado

iguzmanResaltado





SAP Business Connector

SAPSystem

SAPSystem

SAPSystem

SAPSystem

Non SAPSystemsNon SAPSystems

WebBrowser

WebBrowser

WebContentServer

WebContentServer

WebApplic-ations

WebApplic-ations

Internet Technology

XML

HTML

XML

XMLSAP

BC

XMLInterface

Non SAPSystemsNon SAPSystems

SAP BC or B2Bi Server HTML/

XML






Introduccin







Contenido del curso





Qu es una BAPI?

Business Application Programming Interface

z Interface bien definido para datos y procesos de R/3z Implementado como una RFCz Mtodo de un objeto de negocio del Business Object Repository

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 theBusiness Framework are the Business Application Programming Interfaces (BAPIs), which representvisible interfaces at the component boundaries and whose properties serve to integrate thesecomponents.

BAPIs represent well-defined, internally consistent units that always represent business facts and leavea consistent database state behind.

The business contents can be standardized, since BAPIs not only allow the integration of the SAPsystem and other software components at a technical level, but also at the business level.

Stability and compatibilityOnce 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 SAPsoftware or data. If upward-compatible enhancements are made to the BAPIs, the stability of theexisting applications is not affected.

OpennessBAPIs can be accessed from any widespread development platform.





Usos

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 communicationbetween SAP components. The aim is to encapsulate the functions of the SAP system in independentbusiness components that are integrated through a common interface (the BAPIs).

The integration of new SAP components (such as Advanced Planner and Optimizer (APO) andBusiness 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

iguzmanResaltado

iguzmanResaltado

iguzmanResaltado

iguzmanResaltado

iguzmanResaltado

iguzmanResaltado

iguzmanResaltado

iguzmanResaltado

iguzmanResaltado





Atributos

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.





Actualizacin de base de datos

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 Estndar

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





Introduccin







Contenido del curso





RFC Introduccin





RFC Posibilidades

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 sistema SAP a SAP

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 para sistemas no-SAP

z RFC Library, available for Win32 (librfc32.dll)

Linux

Other SAP-supported Unix flavors

OS/390

OS/400

OS/2

Macintosh (client only)





Soluciones para RFC

z Windows SAP DCOM Connector

SAP ActiveX Controls

z Java SAP Java Connector (JCO)






Lenguajes de programacin

z Javaz Cz Cualquier lenguaje que soporte ActiveX

Visual Basic

Visual C++

many others





Destinos RFC





Destinos RFC Conexin SAP





Destinos RFC Conexin Externa

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





z Interface estndar y bidireccional para la integracin entresistemas SAP y sistemas no-SAP

z Diferentes variantes Sncrona

Asncrona

Transaccional

Queued

Remote Function Call





RFC Sncrona

z Cliente espera hasta que el proceso se terminaz sRFC tiene parmetros de entrada y de salidaz Gestin de errores sencilla





RFC Flujo sncrono

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 sncrono - Sintaxis

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 sncrono - Contexto

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 sncrono - Debugg

You can debug function modules called remotely in R/3 - R/3 connections.





RFC Flujo Asncrono

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 Asncrono - Sintaxis

With the addition STARTING NEW TASK 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 Asncrono Confirmacin (1)

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 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 . .". 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 Asncrono Confirmacin (2)

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 Asncrono Ejemplo

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 Transaccional

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 Transaccional Mecanismo ejecucin

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 Transaccional Errores

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 Queue

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 qRFCas 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 Queue - Sintaxis





RFC Flujo Queue - Datos

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.

iguzmanResaltado





Creacin RFC (1)

z Cdigo fuente similar al de cualquier mdulo de funcin

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.





Creacin RFC (2)





RFC - Atributos





RFC - Import

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

Exporting parameters, which are returned by the function module By default, all parameters are passed by reference. To avoid unwanted side effects, you can only






RFC - Modificacin

Changing parameters, which are both received and returned. By default, all parameters are passed by reference. To avoid unwanted side effects, you can only






RFC - Tablas





RFC - Excepciones





RFC Cdigo fuente





RFC Ejecutar





Introduccin







Contenido del curso





Business Objects

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 ofmethods) and the data (in the form of attributes) of this entity. In the process, theimplementation details of the business object type are hidden from the enduser, and thebusiness object type itself is accessed through defined functions (methods/BAPIs). This is referred to as encapsulation.

iguzmanResaltado

iguzmanResaltado





Tipo de objeto e instancia





Ejemplos Business Objects





Business Object Repository (BOR)





Componentes de Aplicacin





Business Object Browser

Transaccin SWO2





Business Object Builder

Transaccin SWO1





Ejemplo Objeto





Tipo de objeto - Definicin

ProgramObject type

Interfaces

Keyfields

Methods

Events

Virtual attributes

Field references

Object references

Synchronous

Asynchronous

ABAP Code

Transaction

Report

Function module

Attributes

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 ObjectRepository

Table 1Key Fields

Table 2Key Fields

TA01

TA02

ReportXX

TA01

TA02

ReportXX

Application

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 modelingy As a standard interface for the workflow runtime system





Utilizacin de objetos

Conditionalbranch

Event creator

Loop

Fork

Wait forevent

Container operation

Step definition

Objects are used in

y Tasks Executing methodsy Control structures Querying attributesy Container operation Querying attributesy Wait steps, event creator Triggering or receiving eventsy Check FM, receiver type FM Querying attributesy Receiver function module Receiving eventsy Roles Querying attributesy Secondary methods Calling methods





Objeto - Propiedades

z Data encapsulationz Inheritancez Polymorphism

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 keyz Several key fields possiblez Reference to underlying application table(s)z Client not necessary

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 attributesz Type information from ABAP Dictionary field or

object type

z Single-line and multiple-line attributes

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 requiredz Calculation upon attribute access

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





z Correspond to internal tablesz Are almost always virtual attributesz Can contain either database fields or object references

Atributos multilnea

Example:y List of purchase requisitions for a material (BUS1001.PurchaseRequisition).





Mtodos sncronos/asncronos

z Synchronous method Result returned directly to calling program

Return of exceptions possible

z Asynchronous method Result can only be returned via an event

Only restricted exceptions possible

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".





Method

Caller

ImportExportResultExceptions

Time

Mtodos sncronos

z All display methodsz 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.





Method

Caller

Import

Dialog

Time

Update

Mtodos asncronos

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





Comunicacin con mtodos

z Communication via parameters Import parameters

Export parameters

z Communication via resultz Communication via exceptions

Temporary error

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.





Reaccin a excepciones Paso de dilogo

Step(method)

OKOK Temp.errorTemp.error

Sys.errorSys.error

Subsequent step

Subsequent step

Subsequent step

Modeled

Sys.errorSys.error

In process Error

Not modeled

Temp.errorTemp.error





Reaccin a excepciones Paso de fondo

Step(method)

OKOK Temp.errorTemp.error

Sys.errorSys.error

Subsequent step

Modeled

Sys.errorSys.error

In process

Error

Not modeled


Temp.error

Temp.error


Without counter

With counter

Error

Without counter With counter

Subsequent step

Subsequent step

Subsequent step

In processIn process

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

Read or calculate individual values or a list of homogeneous values

Evaluation and execution inworkflow manager

Buffering of the results in the Business Object Builder

Fixed communication with thecaller

Background Methods

Read or calculate a list ofheterogeneous values

Calculate values which are notdependent on other attributes orsystem valuesChange values

Evaluation in workflowmanager, execution inwork item manager

All communication methodspossible

No buffering of results

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 separatez Default parameters need not be set explicitlyz User-defined parameters are set explicitly via container

macros

z Documentation is indispensable

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 ModeledNot accessible at runtime.

z Implemented Only in tests or internal use, possibly unstable.

z ReleasedReleased for use by the customer. Only upward-compatible enhancements possible.

z ObsoleteThe 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".





z Object nameDescriptive name for objects of this type

z Default methodDisplay for presenting an object instance

z Default attributeIdentifying attribute of an object instance

Tipo de objeto - Parmetros

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

xKey Field SalesDocumentKey Field SalesDocument

Key fieldObject typeReleaseStatus

SalesDocumentBus203221AReleased

TextsNameDescription

Sales documentSales document

Data type referen.VBAKVBELN

Reference tableReference fieldSearch help

include .begin_data object. " Do not change.. DATA is generated

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

* only private members may be inserted * into structure private* only private members may be inserted * into structure private

Each object type has a program that implements the object type. The macro instructions required for programming are incorporated via the include . 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-) 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

xAttribute DocumentDateAttribute DocumentDate

AttributeObject typeReleaseStatus

DocumentDateVBAK30AReleased

Texts

NameDescription

Document dateDocument date (inbound or outbound)

Data type referen.

Source

VirtualDatabase field

Attribute propertiesMultiple-lineMandatoryInstance-independent

DictionaryReference tableReference field

Object typeInverse attribute

Search help

VBAKAUDAT

get_table_property vbak.data subrc like sy-subrc.* Fill TABLES VBAK to enable Object Manager* Access to Table Propertiesperform select_table_vbak using subrc.if subrc ne 0.exit_object_not_found.

endif.end_property.form select_table_vbak using subrc like sy-subrc.if object-_vbak-mandt is initial and

object-_vbak-vbeln is initial.select single * from vbak client specified

where mandt = sy-mandt andvbeln = object-key-salesdocument.

subrc = sy-subrc.if subrc ne 0. Exit. Endif.object-_vbak = vbak.

else.subrc = 0.vbak = object-_vbak.

endif.endform.

* Fill TABLES VBAK to enable Object Manager* Access to Table Properties

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_ 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

xAttribute SoldToPartyAttribute SoldToParty


OrderingPartyVBAK30AReleased

Texts

NameDescription

Ordering partyOrdering party

Data type referen.

Source





Search help

VBAKKUNNR

KNA1 Customer

get_table_property vbak.data subrc like sy-subrc.

perform select_table_vbak using subrc.if subrc ne 0.exit_object_not_found.

endif.end_property.form select_table_vbak using subrc like sy-subrc.if object-_vbak-mandt is initial and

object-_vbak-vbeln is initial.select single * from vbak client specified

where mandt = sy-mandt andvbeln = object-key-sealesdocument.

subrc = sy-subrc.if subrc ne 0. Exit. Endif.object-_vbak = vbak.

else.subrc = 0.vbak = object-_vbak.

endif.endform.

* Fill TABLES VBAK to enable Object Manager* Access to Table Properties

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

xAttribute SalesGroupAttribute SalesGroup


SalesGroupZ_Bus203240AModeled

Texts

NameDescription

Sales groupSales group (impl. as virt. attr.)

Data type referen.

Source




Inverse attribute

Search help

TUKGR Sales groupz Object type

begin_data object.begin of key,...

end of key,salesgroup type swc_object.

end_data object.get_property salesgroup changing container.select single * from vbak

where vbeln = object-key-salesdocument.* create object(-reference)swc_create_object

object-salesgroup 'TVKGR' vbak-vkgrp.* write object(-reference) into containerswc_set_element container

'SalesGroup' object-salesgroup.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.





Implementando atributos virtuales multilinea

xAttribute ItemsAttribute Items


ItemsVBAK30AReleased

Texts

NameDescription

ItemsSales document items

Data type referen.

Source





Search help

VBAP Sales itemz

z

begin_data object.begin of key,...

end of key,items type swc_object occurs 0.

end_data object.get_property items changing container.* Declare datatables vbap.data item type swc_object. data: begin of vbap_key,

vbeln like vbap-vbeln, posnr like vbap-posnr,

end of vbap_key.data vbap_tab like vbap occurs 0 with header line.

* Select dataselect * from vbap into table vbap_tab

where vbeln = object-key-salesdocument. vbap_key-vbeln = object-key-salesdocument.

* Create object referenceloop at vbap_tab.

vbap_key-posnr = vbap_tab-posnr. swc_create_object item 'VBAP' vbap_key. append item to object-items.

endloop.* Assign object reference to container elementswc_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 mtodos sncronos

begin_method display changing container.set parameter id 'AUN' field object-key-

salesdocument.call transaction 'VA03' and skip first

screen.end_method.

General Result type

DialogSynchronResult para

Instance-ind

Description

xMethod DisplayMethod Display

MethodObject typeReleaseStatus

DisplayZ_Bus203240AImplemented

Name

ABAP

VA02

xMethod DisplayMethod Display


DisplayZ_Bus203240AImplemented

NameDescription

DisplayDisplay object

General Result type ABAP

Function moduleAPI functionTransactionDialog moduleReportMiscellaneous

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 mtodos asncronos

begin_method deliveryblockreset changing container.select single * from vbak

where vbeln = object-key-salesdocument.if vbak-lifsk space.

* invoke method only if delivery lock is setset parameter id 'AUN' field object-key-salesdocument.

call transaction 'VA02' and skip first screen.endif.

end_method.

General Result type


Instance-ind

Description

xMethod DeliveryBlockResetMethod DeliveryBlockReset


DeliveryBlockResetZ_Bus203240AImplemented

Name

ABAP

VA02

xMethod EditMethod Edit



NameDescription

ResetDelBlockReset delivery block



Name VA02

General Result type


Instance-ind

Description

xMethod DeliveryBlockResetMethod DeliveryBlockReset



Name

ABAP

VA02

xMethod EditMethod Edit



NameDescription

ResetDelBlockReset delivery block



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 excepcionesObject Type BUS1001:Object Type BUS1001: Display Exceptions For Method GETMISSEDVIEWSDisplay Exceptions For Method GETMISSEDVIEWS

Object Edit Goto Utilities View System Help

ExceptionsExceptions

Exception 1000Exception 1000

ExceptionObject typeRelease

1000BUS100130D

Error typeTemporary errorApplication errorSystem error

MessageApplication areaMessage& blocked by another user

MA279

10007000

BUS1001BUS1001

MAM3

No. Object type Temp. App. Syst. AppArea Message Message text

279195

& blocked by another userNo selectable views

begin_method getmissedviews changing container....call function 'ENQUEUE_EMMARAE'exporting

matnr = object-key-material _scope = '2' _wait = 'X'

exceptions foreign_lock = 1.

if sy-subrc ne 0.* temporary error - material currently locked by another user

exit_return 1000 object-key-material space space space.

endif....

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.



Hag