Showing posts with label SAP ABAP RFC COMPLETE. Show all posts
Showing posts with label SAP ABAP RFC COMPLETE. Show all posts

R/3 RFC/OLE Troubleshooting

Problems connecting via RFC can usually be solved by reinstalling the full SAPGUI and/or checking your network connection with R/3.If you have problems to connect to R/3 via the RFC DLLs then you should check your network installation. It would be out of the reach of this publication to detail the causes and solutions when an RFC connection does not work.In most cases a full install of the SAPGUI on the computer which runs the calling program will secure a reliable connection, provided that you can login to R/3 problem-free with this very same SAPGUI installation.

Another trivial but often cause are simple network problems. So impossible it may appear, you should always go by the book and first check the network connection by pinging the R/3 system with the PING utility and checking the proper access authorities.However, if you successfully passed the SAPlogon method, then the problem is mostly a misspelling of object or method names or an incompatibility of the called function.

If you are quite sure that you spelled everything right and correct, and still get an error executing the SAP.FUNCTIONS.CALL method then you should investigate the function module in R/3.Generate the function group to see if there is an syntax error.

Make sure that the function is tagged as RFC allowed.

RELATED POSTS

QUEUED RFC
RFC PART 3
RFC PART 2
What is SAP Full form and its definition part one

RFC Remote Function Call

A remote function call RFC enables a computer to execute a program an a different computer within the same LAN, WAN or Internet network. RFC is a common UNIX feature, which is found also in other object-oriented operating systems. R/3 provides special DLLs for WINDOWS, NT and UNIX to allow RFC calls from and to R/3.

A Remote Function Call enables a computer to execute a program an another computer. The called program is executed locally on the remote computer using the remote computer’s environment, CPU and data storage.Remote function call is one of the great achievements of TCP/IP networks. Every computer within the network can accept an RFC-call and decides whether it wants to execute the request. Every modern FTP server implementation includes the RFC calling feature.

A classical network server stores the program code in a central location. When the program is called, the code will be transported via the network to the calling computer workstation and executed on the calling computer, consuming the caller’s resources of CPU, memory and disk.

An RFC calls the program on the remote computer. It is just like stepping over to the remote computer, typing in the program command line with all parameters and waiting for the result to be reported back to the calling computer. The calling computer does not provide any resources other than the parameters specified with the call.Here is again what an RFC does.

• It calls the program on a remote computer and specify parameters if and as necessary.

• The remote computer decides whether to fulfil the request and execute the program.

• Every manipulation done by the called program is effective in the same way as if the program had started on the remote system.

• The calling program task waits meanwhile for the called program to terminate.

• When the RFC program terminates, it returns result values if applicable.

• The called program needs not to be present on the calling computer.

• The called program can be run under a completely different operation system,so you can call a WINDOWS program from UNIX and vice versa.A typical RFC example is the internet with a web browser as the RFC client and the web server as the RFC server. Executing a server applet e.g. via CGI or a JAVA or JAVASCRIPT server side applet is actually a remote function call from the web browser to the HTTP server.If R/3 is doing RFC calls into another system, then it does exactly what a browser does when performing a request on the HTTP or FTP server.

related post

QUEUED RFC

BAPI IN BOR:

SAP business objects provide an object-oriented view of business data and processes in the R/3 System.The Business Object Repository (BOR) manages business objects, organizational objects, and technical objects in a hierarchical display corresponding to the component hierarchy in the R/3 System.Methods in a business objects let you change or display its attributes.

COMPONENTS OF OBJECT TYPE:

- Basic data: Technical details such as an internal ID, release level, transport data, and so on.

- Interfaces: List of the interface from which the object type adopts attributes, methods, and events.

- Key fields: Attributes that uniquely identify an object of this type. Usually the key fields of the underlying database tables.

- Attributes: Object attributes.

These are either values from database fields (field references), values that are calculated at runtime (virtual attributes), or pointers to other objects (object references). Object references are particularly useful in Workflow definitions, allowing you to navigate easily between objects that belong together in a particular business context.

- Methods: Calls to R/3 transactions, function modules, or other ABAP code.

BAPIs are known as API methods.

- Events:

To be used in workflow definitions. The events are only defined in the BOR. To trigger an event, you can use the following (for details, see the online documentation on workflow definition):
- Links to change documents for the underlying database fields
- Links to the status administration
- Links to message control
- Calling the function module SWE_EVENT_CREATE

WHAT IS BAPI?

BAPIs are special, remote-enabled methods of a business object, and are implemented as RFC-enabled function modules.

BAPIs can perform various functions such as:
- cretaing an object
- querying the attributes of an object
- changing the attributes of an object

USES OF BAPI:

You can use BAPIs for different applications. For example:
­ Internet application components: Where individual R/3 functions are implemented on the Internet or Intranet for users with no R/3 experience.

­ Building R/3 components Communication between the business objects from different R/3 components (applications).

­ VisualBasic / JAVA / C++ : External clients access R/3 data and processes through the BAPIs.

BAPI ATTRIBUTES:

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.

DATA BASE UPDATES WITH BAPI:

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)

ACCESSING BAPI FROM EXTERNAL SYSTEM:

When you use BAPIs, there are 2 phases that SAP supports:

Development -

The programmer needs to know which business objects are available with which BAPIs, and what the interface looks like. You can find out this information using the BAPI Browser in the Business Object Builder. The BAPI Browser is a logical view of the BOR in which only those objects are displayed that have BAPIs. The complete interface of each BAPI is displayed.

Runtime -

SAP delivers libraries for BAPI calls for various development environments (Visual Basic, C++, Java). These libraries encapsulate the technical details of the communication, enabling developers to call a BAPI from outside the system without having to worry themselves about how BAPIs are actually implemented in the system.

ACCESSING BAPI FROM ABAP:

You can only access BAPIs currently from an ABAP program using the relevant direct function call (local or remote). SAP is planning for a later release for all BOR business objects to be integrated in the class library of ABAP so that you will be able to access BAPIs from ABAP using ABAP-OO.

The naming convention for BAPI function modules is: BAPI__

There are no exceptions for BAPI function modules.
Success or error messages are returned by the RETURN export parameter, which 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.

RELATED POSTS

BAPI 1
 

R F C 3 TYPES OF RFC'S

SYNCHRONOUS R F C:


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.


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.


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) (exception:

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

If a remotely-called function module uses dialogs (for example, CALL SCREEN,
CALL TRANSACTION or lists), they are executed in the session of the caller (and are fully functional).

Note that RFC dialogs in background processing lead to a program termination with the exception SYSTEM_FAILURE (but you can use RFC within background processing).


ASYNCHRONOUS RFC :

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.


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.


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.

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


aRFC is particularly suited for implementing parallel processing in several R/3 Systems.

You can also use aRFC within the same SAP R/3 System, for example, to move some of the processing load to an application server specially used for this.

Enter the RFC destination that refers to the corresponding application server. (You can find this under Internal connections in Transaction SM59.)

You can also use aRFC locally within the same application server to implement parallel processing in several work processes.

Here you do not need to specify a destination.

Note, however, that several work processes will be occupied by your program at the same time.


LOAD BALANCING USING RFC GROUPS:

You can divided the application servers for an SAP R/3 System into different RFC groups using Transaction SM59.

When calling a function module within this R/3 System, you can specify one of the defined RFC groups using the addition DESTINATION IN GROUP , which selects the server that has the lowest load in order to execute the function module.
Instead of specifying a specific RFC group, you can also enter the word DEFAULT. The server is selected from all the application servers of the R/3 System.

If all the servers of the specified group are overloaded (see next slide), the exception RESOURCE_FAILURE is triggered.

Note that:
- You have to specify the addition DESTINATION IN GROUP after STARTING NEW TASK as opposed to the DESTINATION addition.
- You can only use this addition within the current SAP R/3 System (you cannot have additional DESTINATION entries).

For each server in the specified RFC group, the system checks if the application server has:

- a dispatcher queue load of <> 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.

EXECUTION:

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.

WHEN ERROR COMES:

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


LUW BUILDING:

If tRFCs are transmitted with different destinations before the COMMIT WORK, they are grouped into different LUWs according to their destination.

A tRFC call with the addition AS SEPARATE UNIT is always processed as a separate LUW independently of the other tRFCs.

Each tRFC-LUW is assigned a unique transaction ID (viewable with Transaction SM58).
The function module ID_OF_BACKGROUNDTASK (which is called before the COMMIT WORK) returns this ID.

You can determine the LUW execution status using the function module STATUS_OF_BACKGROUNDTASK under the transaction ID (which is called after the COMMIT WORK).

If you also called the update function modules locally before the COMMIT WORK, tRFC calls are only processed when the local update function modules have been processed successfully.

You can also call transactional C functions. However, you must use the rollback mechanism in the external server program .

RELATED POSTS

QUEUED RFC
RFC PART 2
RFC PART 1

R F C 2 REMOTE DESTIONATIONS


You maintain the RFC sideinfo table RFCDES using Transaction SM59.Depending on the remote system, maintain one destination for the corresponding type.If you want to connect to another SAP System, you need a destination with type 3. Note that the name of a type 3 destination is case-sensitive.

If you want to ensure that the RFC logon is to a particular application server, set the Load distribution option to No. In this case, you must specify the R/3 application server using the target host and system number parameters.


If you do want to use load distribution when you log on, set the Load distribution option to Yes. In this case, you must specify the system ID, the message server, and the required server group. You can find out this information in the R/3 target system from Transactions SM51 (overview of R/3 servers) and SMLG (overview of logon groups). The message server of an SAP System is contained in the profile parameter rdisp/mshosou. You can display this using Transaction RZ11 or report RSPFPAR.

In the destination, you must enter the logon data for the user created in the target system (type 'dialog' or 'CPIC'). When the destination is used, the logon to the target system occurs automatically.If the logon language is not entered in an RFC destination, the logon language of the current caller is used.If the logon data is not complete or is faulty, a logon screen from the target system appears at runtime.

If you want to connect to an R/2 system, you need a destination with type 2. In the destination you need to specify the logon data of an R/2 user with the type 'CPIC'. You must also specify the SNA gateway (for IBM-R/2) or the host gateway (for Siemens R/2) through which the connection is made.

Note that the destination name (here, it is K50) for a type 2 destination cannot be chosen at random. It must match the name of the corresponding destination in the gateway sideinfo table .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.)

These destinations are predefined standard destinations with have the following meanings:
- SPACE: Local call of a function module
- NONE: Also a local call, but the cal request is sent to the default gateway of the current application server and is handled there like an external call request. This destination is suited to the RFC test if you only have one system to test.
- BACK: You can use this destination if you want to start a function module from the called function module in the current system.
(This only functions with synchronous RFC.)


You cannot use this destination from R/2 systems.
Destination BACK cannot be used for R/3-R/2 connections.

RELATED POSTS

RFC PART 3
Analytical SAP CRm Overview
SAP CRM Solution Monitoring
CRM Backup Restoring System

REMOTE FUNCTION CALL 1

REMOTE FUNCTION CALL:

The character conversion of the data to be transmitted is performed automatically.

Both single parameters and structures are supported for conversion.

The logon for remote SAP partner systems is automatic. The user and password are stored in the table RFCDES.

RFC calls in C are available for communicating with external programs (RFC-SDK). The RFC Generator also helps you when generating RFC programs in C.


If a function module is called remotely, it runs in its own work process (its own SAP LUW) if the remote system is an R/3 System.

The remote destination can be another application server in the same or a different R/3 System, an When you call a function module locally, it runs in the same work process as the calling program.

R/2 System, or an non-SAP system.

Note that the calling program is rolled out for each remote function call, which triggers an implicit database-commit.

You maintain RFC destinations that must specify an ABAP program when calling remote function modules in the RFC sideinfo table RFCDES using Transaction SM59.
For each partner system, you need to maintain one entry in the sideinfo table.


SAP delivers the RFC Library for all current external platforms, in which RFC calls are contained for C programs. After installing the RFC Library on your external platform, you can implement RFC client or RFC server programs using RFC calls.


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.

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.


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

RELATED POSTS

RFC PART 2