Содержание
- CALL_FUNCTION_REMOTE_ERROR
- CALL_FUNCTION_REMOTE_ERROR
- Remote Function Call (RFC) in SAP Tutorial
- What is RFC?
- Must Know Details About RFC
- The RFC Advantages:
- Types of RFC:
- Synchronous
- Asynchronous
- Transactional
- Queued
- Types of RFC Connections
- How to Code an RFC?
- CALL_FUNCTION_REMOTE_ERROR
CALL_FUNCTION_REMOTE_ERROR
We are receiving dumps — CALL_FUNCTION_REMOTE_ERROR for a single user.
«call to messaging system failed:
Error in the ABAP Application Program
The current ABAP program «/SIE/SAPLMED_SM_LIC_CMDBTRANS» had to be terminated
come across a statement that unfortunately cannot be executed.
The error occurred during an RFC call to another system.
In the target system, a short dump has been written as well.
More detailed information on the error cause can be found there.
An error occurred when executing a REMOTE FUNCTION CALL.
It was logged under the name «RFC_EXTERNAL_ABORT»
on the called page.
How to correct the error
Please refer to the notes described in the
Operating system. «Linux»
Hardware type. «x86_64»
Character length. 8 Bits
Pointer length. 64 Bits
Work process number.. 26
Shortdump setting. «full»
What can you do?
Note down which actions and inputs caused the error.
To process the problem further, contact you SAP system
Using Transaction ST22 for ABAP Dump Analysis, you can look
at and manage termination messages, and you can also
keep them for a long time.
An error occurred when executing a REMOTE FUNCTION CALL.
It was logged under the name «RFC_EXTERNAL_ABORT»
on the called page.
Database type. «ORACLE»
Database user ID.. «SAPSR3»
create on. «Linux GNU SLES-9 x86_64 cc4.1.2 «
Database version. «OCI_102, 11.2.0.2.0, V1, default»
Patch level. 500
Database. «ORACLE 10.1.0.*.*, ORACLE 10.2.0.*.*, ORACLE 11.2.*.*.*»
SAP database version. 720
Operating system. «Linux 2.6, Linux 3»
MM Used. 1131744
Transactions ID. «210a0096db0d11e3c3a300001844cfe4»
Screen. «SAPMSSY1 3004»
Information on caller of Remote Function Call (RFC):
Database Release. 700
Kernel Release. 720
Connection Type. 3 (2=R/2, 3=ABAP System, E=Ext., R=Reg. Ext.)
Call Type. «synchronous and transactional type T (emode 0, imode 0)»
Inbound Queue Name. » «
Outbound TID. «9DA3889564635372D4940242»
Outbound Queue Name..» «
Call Program. «SAPLERFC»
Function Module. «ARFC_DEST_SHIP»
Call Destination. «NONE»
Source Server. «_00»
Source IP Address. «157.163.136.149»
Additional information on RFC logon:
Logon Return Code. 0
Trusted Return Code. 0
Transactions ID. «210a0096db0d11e3c3a300001844cfe4»
Screen. «SAPMSSY1 3004»
Information on caller of Remote Function Call (RFC):
Database Release. 700
Kernel Release. 720
Connection Type. 3 (2=R/2, 3=ABAP System, E=Ext., R=Reg. Ext.)
Call Type. «synchronous and transactional type T (emode 0, imode 0)»
Источник
CALL_FUNCTION_REMOTE_ERROR
I’m building a program that will call an asynchronous RFC repeatedly, for downloading files from a DMS document server to a local directory on the presentation server.
In order to do this, I am calling the function a number of times in parallel (based on number of available processes). However, I keep getting dumps of type CALL_FUNCTION_REMOTE_ERROR, due to problems in the form defined as «on end of task». Here’s my sample code:
call function ‘ZCA_MY_DOWNLOAD_RFC’
starting new task taskname
destination in group default
performing reduce_process_counter on end of task
In the «reduce_process_counter» form, the following code is executed:
receive results from function ‘ZCA_MY_DOWNLOAD3_RFC’
changing ch_taskname = lv_taskname.
Note that the «changing» parameter is defined in the function module and is working OK in most cases.
Now, the issue is the following: In most cases, the logic functions. I have a parameter in the calling program, allowing me to specify how many RFC calls I should run in parallell (based on available processes in the app servers). However, every once in a while — and especially if I run more than 2 or 3 calls in parallel, I get the CALL_FUNCTION_REMOTE_ERROR. This occurs on the «receive results» statement, with the dump reading «ThISend: bad tm type / connection closed (no data)».
It seems to me that my RFC’s are «running wild» once I allow more than 2 or 3 of them to run in parallel. Again, there is no consistent behaviour here — some times, I can launch 5 in parallel; 8 will terminate properly, but the 9th will crash with the above error. I have implemented logging fuinctionality using a specific Z-table, so I can monitor the behaviour of bot the main program and the RFC’s. Also, by checking SM66, I see my 5 processes running peacefully in parallel, until one suddenly «explodes».
Источник
Remote Function Call (RFC) in SAP Tutorial
Updated December 29, 2022
What is RFC?
RFC is a mechanism that allows business applications to communicate and exchange information (in pre-defined formats) with other systems. RFC stands for ‘Remote Function Call’
RFC consists of two interfaces:
- A calling interface for ABAP Programs
- A calling interface for Non-SAP programs.
Any ABAP program can call a remote function using the CALL FUNCTION…DESTINATION statement. The DESTINATION parameter tells the SAP System that the called function runs in a system other than the callers.
Syntax-
Logical Destinations are defined via transaction SM59 and stored in Table RFCDES
Functions of the RFC interface
- Converting all parameter data to the representation needed in the remote system
- Calling the communication routines needed to talk to the remote system.
- Handling communications errors, and notifying the caller, if desired ( using EXCEPTIONS parameter of the CALL FUNCTION).
RFC is a SAP protocol to handle communications between systems to simplify the related programming. It is the process of calling a function module which is residing on a different machine from the caller program. RFCs can be used to call a different program on the same machine as well, but usually, it is used when ‘calling‘ and ‘called‘ function modules/ programs are running on separate machines.
In SAP, RFC Interface system is used for setting-up RFC connections between different SAP systems, and also between a SAP and an external (non-SAP) system.
Must Know Details About RFC
- SAP Uses CPIC (Common Programming Interface for Communication) Protocol to transfer data between Systems. It is SAP Specific protocol. Remote Function Call (RFC) is a communications interface based on CPI-C, but with more functions and easier for application programmers to use
- The RFC library functions support the C programming language and Visual Basic (on Windows platforms)
- RFC connections can always be used across the entire system.This means that an RFC connection you have defined in client 000 can also be used from client 100 (without any difference).
- 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 R/3 System in their own function library, called the Function Builder.
- The Function Builder (transaction SE37) provides application programmers with a useful environment for programming, documenting and Testing function modules that can be called locally as well as remotely. The R/3 System automatically generates the additional code (RFC stub) needed for remote calls.
- You maintain the parameters for RFC connections using transaction SM59. The 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 R/3 System.
- 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.
The RFC Advantages:
RFC helps to reduce the efforts of programmers, by letting them avoid the re-development of modules and methods at remote systems. It is capable enough to:
- Convert the data into the format understandable by the remote (target) system.
- Convert the data into the format understandable by the remote (target) system.
- Call up certain routines which are necessary to start communication with the remote system.
- Handle errors that might occur in the process of communication.
Types of RFC:
Synchronous
Requires both the systems (client and server) to be available at the time of communication or data transfer. It is the most common type and is required when the result is required immediately after the execution of sRFC.
sRFC is a means of communication between systems where acknowledgments are required. The resources of the Source System wait on the target system and ensure that they deliver the message/data with ACKD. The Data is consistent and reliable for communication.
The issue is if the target system is not available, the source system resources wait until target system is available. This may lead to the Processes of source system to go into Sleep/RFC/CPIC Mode at target systems and hence blocks these resources.
Used for
- For communication between systems
- For communication between SAP Web Application Server to SAP GUI
Asynchronous
It is communication between systems where acknowledgments are not required (it is similar to postcard delivery).It doesn’t require both the systems to be available at the time of execution and the result is not immediately required to be sent back to the calling system.
The Source System resource does not wait for the target system as they deliver the message/data without waiting for any acknowledgment. It is not reliable for communication since data may be lost if the target system is not available. Used for –
- For communication between systems
- For parallel processing
Transactional
It is a special form of aRFC. Transactional RFC ensures transaction-like handling of processing steps that were originally autonomous.
Transactional RFC is an asynchronous communication method that executes the called function module in the RFC server only once, even if the data is sent multiple times due to some network issue. The remote system need not be available at the time when the RFC client program is executing a tRFC. The tRFC component stores the called RFC function, together with the corresponding data, in the SAP database under a unique transaction ID (TID). tRFC is similar to aRFC as it does not wait at the target system (Similar to a registered post). If the system is not available, it will write the Data into aRFC Tables with a transaction ID (SM58) which is picked by the scheduler RSARFCSE (which runs for every 60 seconds). Used For-
- Extension of Asynchronous RFC
- For secure communication between systems
Queued
Queued RFC is an extension of tRFC. It also ensures that individual steps are processed in sequence. To guarantee that multiple LUWs (Logical Unit of Work/ Transaction) are processed in the order specified by the application. tRFC can be serialized using queues (inbound and outbound queues). Hence the name queued RFC (qRFC). Used For-
- Extension of the Transactional RFC
- For a defined processing sequence
- Implementation of qRFC is recommended if you want to guarantee that several transactions are processed in a predefined order.
Types of RFC Connections
Type 3 – entries specify the connection between ABAP systems. Here, we must specify the host name / IP address. You can, however, specify logon information if desired. This is applicable for both type of RFCs, between ABAP systems and external calls to ABAP systems
Type I – entries specify ABAP systems connected to the same database as the current system. These entries are pre-defined and cannot be modified. Example entry name: ws0015_K18_24
- ws0015=host name
- K18=system name (database name)
- 24=TCP-service name
Type T – destinations are connections to external programs that use the RFC API to receive RFCs. The activation type can be either Start or Registration. If it is Start, you must specify the host name and the pathname of the program to be started.
How to Code an RFC?
1.In the function module attributes tab (transaction code SE37), set the processing type as Remote-enabled module to create a remote function module.
2.Write the code for the function module.
3.Define the destination of the RFC server in the RFC client system that calls the remote function ( via SM59 transaction).
4.Declaring Parameters: All parameter fields for a remote function module must be defined as reference fields, that is, like ABAP Dictionary fields.
5.Exceptions: The system raises COMMUNICATION_FAILURE and SYSTEM_FAILURE internally. You can raise exceptions in a remote function just as you would in a locally called function.
Источник
CALL_FUNCTION_REMOTE_ERROR
I am getting the CALL_FUNCTION_REMOTE_ERROR when i am creating BP in CRM Module using RFC Destination.
We are calling the bapi BAPI_BUPA_CREATE_FROM_DATA in the user exit to create the business partner in CRM(after saving Address Infotype 6).
But system is giving Runtime error while committing the transaction(BAPI_TRANSACTION_COMMIT).
I am getting following Runtime error :
«The current application triggered a termination with a short dump.»
Error in ABAP application program.
The current ABAP program «SAPLXPAD» had to be terminated because one of the
statements could not be executed.
This is probably due to an error in the ABAP program.
The error occurred in an RFC call to another system.
The target system has also written a short dump.
Consult this short dump for more precise information about
the cause of the error.
What can you do?
Print out the error message (using the «Print» function)
and make a note of the actions and input that caused the
To resolve the problem, contact your SAP system administrator.
You can use transaction ST22 (ABAP Dump Analysis) to view and administer
termination messages, especially those beyond their normal deletion
An error occurred when executing a REMOTE FUNCTION CALL.
It was logged under the name «MESSAGE_TYPE_X»
on the called page.
How to correct the error
Please refer to the notes described in the
An error occurred when executing a REMOTE FUNCTION CALL.
It was logged under the name «MESSAGE_TYPE_X»
on the called page.
How to correct the error
Please refer to the notes described in the
Information on where terminated
The termination occurred in the ABAP program «SAPLXPAD» in «EXIT_SAPFP50M_002».
The main program was «MP000600 «.
The termination occurred in line 454 of the source code of the (Include)
of the source code of program «ZINCL_ZXPADU02_0006» (when calling the editor
Source code extract
Caution: Program has changed
Caution: At time of termination, Active source code no longer available
004250 ? CALL FUNCTION ‘BAPI_BUPA_CREATE_FROM_DATA’ DESTINATION w_rfcdest
004270 ? businesspartnerextern = w_bpartner
Источник
Просмотр нерешенных тем
Сообщения без ответов | Активные темы
Правила форума
ВНИМАНИЕ!
Вопросы по SAP Query и Quick View — сюда
| Автор | Сообщение | |||
|---|---|---|---|---|
|
Заголовок сообщения: Error message на вызываемой стороне при выполнении rfc вызова
|
||||
|
Собсно, сабж. Вызывается интерфейсец в другой системе, в обработке того интерфейса есть выполнение сообщения типа ‘E’, после которого сразу дамп CALL_FUNCTION_REMOTE_ERROR на вызывающей стороне и разрыв соединения. В хелпе написано что данный эксепшн в число «отлавливаемых» не входит…
|
|||
| Вернуться к началу |
|
|||
 |
Добавлено: Пн, сен 10 2007, 17:12 
|
vvvictor |
Заголовок сообщения: Re: Error message на вызываемой стороне при выполнении rfc вызова
|
|
|
John Doe написал: В хелпе написано что данный эксепшн в число «отлавливаемых» не входит… А ты как его пытаешься отловить ? CATCH ? У меня как-то был подобный прикол, но я нарисовал список exeptions у FM-a, которые в нем абсолютно не реализованы и все прокатило……. Цитата: Abyssus abyssum invocat Estote prudentes sicut serpentes
|
| Вернуться к началу |
|
|
|
John Doe |
Заголовок сообщения:
|
|
|
Да он, извиняюсь, сцуко, никак не ловится. То есть внутри rfc ФМ-ника стоит вызов BW-интерфейса. При отмене действия происходит message type E Отменено пользователем (мать его)… Дальше все по написаному — я свой эксепшн поймать не могу ЗЫ Насчет списка не заявленных эксепшнов — завтра проверю, отпишусь.
|
| Вернуться к началу |
|
|
— до него обработка не доходит.
|
sy-uname |
Заголовок сообщения: Re: Error message на вызываемой стороне при выполнении rfc вызова
|
||
|
John Doe написал: Собсно, сабж. Вызывается интерфейсец в другой системе, в обработке того интерфейса есть выполнение сообщения типа ‘E’, после которого сразу дамп CALL_FUNCTION_REMOTE_ERROR на вызывающей стороне и разрыв соединения. В хелпе написано что данный эксепшн в число «отлавливаемых» не входит… вариант N1: Цитата: For EXCEPTIONS, you can also specify an optional addition MESSAGE for the special exceptions SYSTEM_FAILURE and COMMUNICATION_FAILURE. If one of these exceptions occurs, the first line of the corresponding short dump is entered in the field mess, which must be flat and of character-type. — возможно поможет предотвратить дамп в вызывающей системе вариант N2: в вызываемой системе написать ФМ — обёртку, который уже будет вызывать лригинальный, но в EXCEPTIONS будет ещё ловить error_message.
|
||
| Вернуться к началу |
|
||
|
|
vvvictor |
Заголовок сообщения:
|
|
|
Code: call function ‘Z_SCANNER_PING’ Это, собственно то — о чем я говорил — когда не отлавливается catch-ем — запихнул в exceptions. Сам Z_SCANNER_PING никаких exceptions у меня не генерит……………… И sy-uname написал об этом выдержкой из хелпа в варианте 1. Цитата: Abyssus abyssum invocat Estote prudentes sicut serpentes
|
| Вернуться к началу |
|
|
|
John Doe |
Заголовок сообщения:
|
|
|
Объявил этот эксепшн на вызывающей стороне, не помогло.
|
| Вернуться к началу |
|
|
|
vvvictor |
Заголовок сообщения:
|
|
|
John Doe написал: Объявил этот эксепшн на вызывающей стороне, не помогло. Ну тогда вариант 2……….. Создавай на вызываемой стороне обертку и вызывай ее………….. Цитата: Abyssus abyssum invocat Estote prudentes sicut serpentes
|
| Вернуться к началу |
|
|
|
John Doe |
Заголовок сообщения:
|
|
|
Второй вариант подошел. Всем спасибо.
|
| Вернуться к началу |
|
|
Кто сейчас на конференции |
|
Сейчас этот форум просматривают: Google Feedfetcher |
| Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения |
Problem
An ABAP extraction job that uses the RFC data transfer method might not finish successfully:
1. Abort with an explicit error/exception
2. An ABAP extraction job that uses the RFC data transfer method might hang, where the job does not display any sign of progress. After a while, the job might fail with a timeout message, such as: ABAP background job time-out occurred as defined using BG_JOB_TIMEOUT property.
3. This technote can also be used to improve the extraction performance.
Resolving The Problem
For performance tuning these specific steps apply: 3, 11, 12, 14, 15, 16, 17
For generic troubleshooting complete the steps in order or identify the steps which may apply to your specific environment.
Notes:
- The transactions (t-code) specified are completed in the SAP GUI application (SAP Logon)
- These steps are generic for all RFC type data transfer (tRFC, qRFC, bgRFC). For additional steps specific to bgRFC, see technote 2001266
Steps:
1. In the ABAP stage GUI, use the Validate button (Output/General tab) to check the stage settings; make sure all checks are green before proceeding. Any errors reported should be corrected (either connection or SAP transport related). Note the validation uses a connection from the Client tier to SAP while the runtime connection is done from the Engine tier.
2
2. Verify the required Pack prerequisites are installed on both Engine and Client tiers, including the SAP SDK libraries. A link to the prerequisites technote is included in the Release Notes. For example for Pack version 8.1 or 8.2: http://www.ibm.com/support/docview.wss?uid=swg22016343
Missing prerequisites on the Engine tier may produce an unhandled exception reported in the job log.
3. Jobs using the RFC data transfer method and running at the same time must be configured to use a unique RFC destination.
- Make sure the ABAP stage meets the requirements specified in Technote 1314075.
- To manually verify the uniqueness of these values across jobs see Technote 1966231.
Note: We have recently implemented (Sep 2016) an enhancement for automatic detection of duplicate Destinations and Program IDs. The update is available as a patch (for Server and SAP tiers) for maintenance versions 7.1 and 8.0. It’s also included in version 8.0.0.1 (Fixpack 1 for 8.0).
Note there are a couple DS core patch prerequisites documented in the APAR entry below.
APAR JR50473: ENHANCE GENERATED ABAP TO DETECT IF ANOTHER PROCESS WITH SAME RFC DESTINATION NAME EXISTS AND ACTIVE AT TIME OF THE QUERY.
4. This type of error in the job log «registration of <destination> from host <hostname> not allowed»
means registration of RFC destination is not allowed from Datastage to the SAP host. Check SAP Profile parameter gw/acl_mode using t-code RZ11. If value is 1 make it 0 (zero) to allow registration. Example of full error:
Fatal: RFC server function ‘rfc_getline’ failed, returned ‘765:ERROR: RFC error has occured with the following details: %1:Error Details: BAPI: RfcListenAndDispatch Code: RFC_COMMUNICATION_FAILURE Key: RFC_COMMUNICATION_FAILURE Message: LOCATION SAP-Gateway on host SRVBRA153.tods.com / sapgw00
ERROR registration of tp ZRFC_ZRT_TP_CALC_IVA from host srvibm4bids.tods.com not allowed
5. There’s a known issue with the stage tracing in versions 6.5 — 8.0, where it may cause a job abort (or other unexpected symptoms) for certain data sets. Make sure to test with stage tracing off as well (unset environment variable DSSAP_STAGE_RUNTIME_TRACE or set it to NONE).
6. Install the latest Service Pack for your SAP system. Similar issues in the past were fixed by applying SAP Note 977283.
Also, verify the SAP system has not run out of memory — use OS specific tools. Check the SAP system logs as well.
7. If this is the first time that the job or connection is set up or if you have multiple jobs in this environment, troubleshoot connection errors by completing the steps in Technote 1393028.
8. If the job fails with a timeout message, set the background job timeout limit regardless of whether you use a background job or not.
To configure a timeout limit, complete one of the following steps:
- Change the stage property BG_JOB_TIMEOUT. For more information, see Technote 1576635.
- Set the environment variable DSR3_BG_JOB_TIMEOUT. For more information, see APAR JR38704.
The default timeout limit is 600 seconds. When you specify the timeout limit, consider the system performance and the extraction time. For very heavy loads, increase the timeout interval to several hours if required. The setting affects non-background operations as well.
9. Verify connectivity between the InfoSphere Information Server engine tier and the SAP system. To verify connectivity, use transaction SM59:
-
- Run the ABAP extraction job.
- While the job is running, test the connection, including the Unicode test.
Note: When you test connectivity, the job must be running because the dynamically created RFC destinations are deleted after the job completes.
10. If you use background jobs, use transaction SM37 to check the status. The name of the background job is the name of the ABAP program. You can delete any jobs that are no longer needed.
11. Increase the value for the Dialog Workprocesses parameter in the SAP system. Increase the value set for the parameter «rdisp/wp_no_dia» parameter using one of the transactions:
- For a temporary change, active until next instance restart: In transaction RZ11 (Maintain Profile Parameters), enter the parameter name and then click Change (you may have to enter the maintenance mode first by clicking Goto > Maintenance Mode).
- For a permanent change, active after the next instance restart: In transaction RZ10 (Edit Profiles) select the instance profile, check extended maintenance and click Change. Edit the parameter in the list, then save and activate the profile.
Note: Before making any changes to the SAP system parameters, discuss the changes with the local SAP Basis administrator. See also other relevant SAP system parameters listed below.
12. If you use static RFC destinations:
- Use transaction SM59 to verify the destination for the transported data. Verify that the destination is configured correctly and that Unicode is specified in the special options.
- If you cannot increase the number of Dialog Workprocesses, check the maximum number of connections for the RFC destination. If a high value is used, specify a lower value by completing the following steps:
- In transaction SMQS, select the destination.
- Press F6 and change the value that is specified for the Max Connections field.
Specify a number that is less than or equal to the number nodes that are available in InfoSphere Information Server. For more information, see SAP Note 1403974.
13. Verify the CPI-C connection timeout value for the destination is set to be longer than the job execution time:
-
- In transaction SMQS, select the destination.
- Press F6 and verify the value that is specified for the Max Runtime field.
To increase the default connection timeout value (SAP Gateway parameter gw/reg_timeout) complete one of the following steps:
- for a temporary change, active until next instance restart: In transaction RZ11 (Maintain Profile Parameters), enter the parameter name and then click Change (you may have to enter the maintenance mode first by clicking Goto > Maintenance Mode).
- for a permanent change, active after the next instance restart: In transaction SMGW (Gateway Monitor) click Goto > Parameter > Change.
Note: A related parameter that should be considered for increase is gw/cpic_timeout
14. The environment variable CPIC_MAX_CONV can be defined at OS level (both on the SAP Server and the DS Server). It controls the maximum number of CPIC conversations that can be initiated (default is 100). Should be increased if getting an error «max no of conversations exceeded» or to tune performance.
15. If you use tRFC, use transaction SM58 (Transactional RFC) to delete outstanding failed transactions. In addition, to automate the cleanup:
- In IBM InfoSphere Information Server Pack for SAP Applications, Version 7.0 and later, to automate deletion of failed transactions, complete the following steps:
- Open the ABAP stage properties.
- Click Output > Data Transfer Method, and then select Delete leftover LUWs.
- Recompile the job.
- In version 6.5 implement the Z_DELLUW cleanup program. For more information, see APAR JR38586.
Note: If the job still hangs after deleting the transactions in SM58 and automated cleanup, perform manual tRFC cleanup. In transaction SE38 run the report RSARFCER (Delete tRFC); enter a Date range, Destination (can use *) and User Name. From the «Status» check boxes select everything that applies, then click Execute (or press F8).
16. If you use tRFC, use transaction SM58 (Transactional RFC) to inspect the transactional status while the job is running. If the transaction status is «Recorded», the SAP System is supposed to execute that transaction via the scheduler. If the transaction remains «Recorded» try to execute it manually in the SAP GUI. If the job now completes fine, it means the issue is with the SAP scheduler — the issue needs to be resolved by the local SAP Basis administrator.
17. If you use parallel jobs, verify the combinability mode for the ABAP stage indicates the stage runs in its own process. Also, make sure more than one parallel node is available to the stage.
First, configure the DataStage parallel environment to make available at least 2 nodes to the job (see the DataStage documentation for details). The number of available nodes is displayed by the ABAP stage in the job log, e.g. Message: ABAP1,0: Info: Job1.ABAP1: Number of parallel nodes: 4.
Then, configure the stage:
- Open the ABAP stage properties
- Click Stage > Advanced
- Make sure Execution Mode = Parallel and Combinability mode = Don’t combine
- Recompile the job if any changes.
Note: an alternative method for disabling combinability only is setting the APT_DISABLE_COMBINATION environment variable to 1. Although the environment variable is set just for the specific job, it affects all stages in the job. If you have the permission to change the job, then it is recommended to use the stage level setting.
18. Use transaction SE38 to run the ABAP extraction program manually:
-
- Open the job in the InfoSphere DataStage Designer client
- Open the ABAP stage
- Click Output > ABAP Program, and then change the run method to «SAP administrator runs the program manually»
- Regenerate the program
- Re-compile and re-run the job
- Run the program manually from transaction SE38.
- Check the program status in transaction sm50.
- To check if the ABAP extraction stage is able now to start the program automatically, complete the following steps:
-
- Open the ABAP stage.
- Click Output > ABAP Program, and then change the run method to «DataStage job runs the program»
- Regenerate the program
- Re-compile and re-run the job.
-
19. If the ABAP job continues to hang:
-
- Open the ABAP stage properties
- Change the name of the ABAP program
- Change the value for the RFC destination and the program ID to new unique values
- Regenerate the ABAP program.
20. The latest maintenance code may contain relevant fixes. Users can request a patch by opening a PMR. The patches are cumulative, so requesting the latest maintenance code will include all available fixes. If the issues persist after installing the Client and Engine tiers patches and regenerating the programs, the PMR can be used to have the issue investigated further.
Other useful SAP transactions (t-code):
SM37 — Job Selection — if using background programs can check the job status (background job name is the ABAP program name)
ST11 — Error Log Files; displays all traces on the kernel: workprocess (dev_wxxx), RFC calls (dev_rfcxxx), gateway (dev_rdxxx)
ST22 — ABAP Runtime Error
SM50 — Process Overview, can see the status of the running ABAP program
SM21 — System Log
SM66 — Global Work Process Overview
Other SAP system parameters affecting tRFC and qRFC transactions:
RDISP/ASYNC_DIALOG_TIMEOUT — timeout for asynchronous dialog RFCs
RDISP/RFC_POOL_TIMEOUT — Timeout for pooled RFC connections
RFC/REDUCE_TRACELEVEL — reduces the RFC-information which is written into the WP and RFC-Traces
DBS/MSS/ADD_PROCS — maximum number of additional dirty read connections
GW/CONN_PENDING — timeout for pending connections
GW/GW_DISCONNECT — Timeout to cancel inactive gateway connections
[{«Business Unit»:{«code»:»BU059″,»label»:»IBM Software w/o TPS»},»Product»:{«code»:»SSZJPZ»,»label»:»IBM InfoSphere Information Server»},»Component»:»Pack for SAP Applications»,»Platform»:[{«code»:»PF002″,»label»:»AIX»},{«code»:»PF010″,»label»:»HP-UX»},{«code»:»PF016″,»label»:»Linux»},{«code»:»PF027″,»label»:»Solaris»},{«code»:»PF033″,»label»:»Windows»}],»Version»:»All Versions»,»Edition»:»»,»Line of Business»:{«code»:»LOB10″,»label»:»Data and AI»}}]
CALL_FUNCTION_REMOTE_ERROR
I’m building a program that will call an asynchronous RFC repeatedly, for downloading files from a DMS document server to a local directory on the presentation server.
In order to do this, I am calling the function a number of times in parallel (based on number of available processes). However, I keep getting dumps of type CALL_FUNCTION_REMOTE_ERROR, due to problems in the form defined as «on end of task». Here’s my sample code:
call function ‘ZCA_MY_DOWNLOAD_RFC’
starting new task taskname
destination in group default
performing reduce_process_counter on end of task
In the «reduce_process_counter» form, the following code is executed:
receive results from function ‘ZCA_MY_DOWNLOAD3_RFC’
changing ch_taskname = lv_taskname.
Note that the «changing» parameter is defined in the function module and is working OK in most cases.
Now, the issue is the following: In most cases, the logic functions. I have a parameter in the calling program, allowing me to specify how many RFC calls I should run in parallell (based on available processes in the app servers). However, every once in a while — and especially if I run more than 2 or 3 calls in parallel, I get the CALL_FUNCTION_REMOTE_ERROR. This occurs on the «receive results» statement, with the dump reading «ThISend: bad tm type / connection closed (no data)».
It seems to me that my RFC’s are «running wild» once I allow more than 2 or 3 of them to run in parallel. Again, there is no consistent behaviour here — some times, I can launch 5 in parallel; 8 will terminate properly, but the 9th will crash with the above error. I have implemented logging fuinctionality using a specific Z-table, so I can monitor the behaviour of bot the main program and the RFC’s. Also, by checking SM66, I see my 5 processes running peacefully in parallel, until one suddenly «explodes».
Источник
CALL_FUNCTION_REMOTE_ERROR
We are receiving dumps — CALL_FUNCTION_REMOTE_ERROR for a single user.
«call to messaging system failed:
Error in the ABAP Application Program
The current ABAP program «/SIE/SAPLMED_SM_LIC_CMDBTRANS» had to be terminated
come across a statement that unfortunately cannot be executed.
The error occurred during an RFC call to another system.
In the target system, a short dump has been written as well.
More detailed information on the error cause can be found there.
An error occurred when executing a REMOTE FUNCTION CALL.
It was logged under the name «RFC_EXTERNAL_ABORT»
on the called page.
How to correct the error
Please refer to the notes described in the
Operating system. «Linux»
Hardware type. «x86_64»
Character length. 8 Bits
Pointer length. 64 Bits
Work process number.. 26
Shortdump setting. «full»
What can you do?
Note down which actions and inputs caused the error.
To process the problem further, contact you SAP system
Using Transaction ST22 for ABAP Dump Analysis, you can look
at and manage termination messages, and you can also
keep them for a long time.
An error occurred when executing a REMOTE FUNCTION CALL.
It was logged under the name «RFC_EXTERNAL_ABORT»
on the called page.
Database type. «ORACLE»
Database user ID.. «SAPSR3»
create on. «Linux GNU SLES-9 x86_64 cc4.1.2 «
Database version. «OCI_102, 11.2.0.2.0, V1, default»
Patch level. 500
Database. «ORACLE 10.1.0.*.*, ORACLE 10.2.0.*.*, ORACLE 11.2.*.*.*»
SAP database version. 720
Operating system. «Linux 2.6, Linux 3»
MM Used. 1131744
Transactions ID. «210a0096db0d11e3c3a300001844cfe4»
Screen. «SAPMSSY1 3004»
Information on caller of Remote Function Call (RFC):
Database Release. 700
Kernel Release. 720
Connection Type. 3 (2=R/2, 3=ABAP System, E=Ext., R=Reg. Ext.)
Call Type. «synchronous and transactional type T (emode 0, imode 0)»
Inbound Queue Name. » «
Outbound TID. «9DA3889564635372D4940242»
Outbound Queue Name..» «
Call Program. «SAPLERFC»
Function Module. «ARFC_DEST_SHIP»
Call Destination. «NONE»
Source Server. «_00»
Source IP Address. «157.163.136.149»
Additional information on RFC logon:
Logon Return Code. 0
Trusted Return Code. 0
Transactions ID. «210a0096db0d11e3c3a300001844cfe4»
Screen. «SAPMSSY1 3004»
Information on caller of Remote Function Call (RFC):
Database Release. 700
Kernel Release. 720
Connection Type. 3 (2=R/2, 3=ABAP System, E=Ext., R=Reg. Ext.)
Call Type. «synchronous and transactional type T (emode 0, imode 0)»
Источник
RECEIVE
Basic form
RECEIVE RESULTS FROM FUNCTION func.
Extras:
Effect
Receives the results returned by a function module called asynchronously ( CALL FUNCTION func STARTING NEW TASK taskname ). This ABAP statement is used within a FORM routine. The form routine must have a place holder for passing the task name (for example, USING taskname — see example), and it can only be used to receive and execute simple ABAP statements. It cannot contain any statements that interrupt the program execution (such as CALL SCREEN , CALL DIALOG , CALL TRANSACTION , SUBMIT , COMMIT WORK , WAIT , Remote Function CAlls, CPIC calls), or any warning or information messages that use the MESSAGE statement.
Notes
This statement is only used in conjunction with a function module call of the form CALL FUNCTION func STARTING NEW TASK taskname . If the function module does not return any values, you do not need to define this part.
The FORM routine must contain the statement RECEIVE RESULTS FROM FUNCTION func , otherwise it cannot recieve the results, and the remote context (remote tasks ) is not concluded. This eventually leads to the application server being overloaded.
This statement has only existed since R/3 Release 3.0. Therefore, both partner systems (client and server) must have Release 3.0 of the system or higher.
You can wait for the response from an asynchronous function call ( PERFORMING form ON END OF TASK ) using the WAIT statement. WAIT must appear in the same program context.
You can collect the results of an asynchronous call in dialog mode when the roll area changes or by using WAIT (both dialog and background processing).
If the calling program ends without receiving the reply from the asynchronous function module, the values cannot be delivered.
The FORM routine in which you evaluate the relevant tasks should only be used to receive the results of the asynchronous tasks. If you use WRITE statements in the form routine, the list output is suppressed.
Note that the asynchronous task is not necessarily terminated if the calling program terminates.
Since the FORM routine runs in the same program context as the main program, they should not both use the same global data structures.
Addition 1
Effect
This addition stops the asynchronous connection from being terminated once the results have been received. Instead, the remote context (roll area) is retained until the calling program ends. This allows you to re-address and use the same context (and roll area) under the same name.
Notes
Only use this addition if you want to reuse the remote context in a later asynchronous call. Otherwise, the context is retained until the calling program ends, leading to increased memory requirements and impaired performance in the remote system.
If the remote function module contains user dialogs (lists or screens), the screen output remains active until the calling program ends. If the asynchronous call is made in debugging mode, the remote debugging dialog remains visible until the end of the caller’s dialog.
Addition 2
. IMPORTING p1 = f1 . pn = fn
Effect
IMPORTING returns values from fields and structures in the function module to the calling progam. In the function module, the corresonding parameters are defined as export parameters. You can pass any number of these parameters.
Addition 3
. TABLES p1 = itab1 . pn = itabn
Effect
TABLES passes the contents of internal tables.
Addition 4
. EXCEPTIONS except1 = rc1 . exceptn = rcn
Effect
Besides the exceptions generated by the function module called, you should also handle two special system exceptions here (as when you call function modules using the DESTINATION addition):
SYSTEM_FAILURE
is triggered if the receiving system crashes.
COMMUNICATION_FAILURE
is triggered if the connection cannot be established or the communication fails.
In either case, you can use the optional addition
to receive a description of the error.
You should always handle these two system exceptions both in the asynchronous function call and when you receive the results.
Example
DATA: INFO LIKE RFCSI,
* Result of the RFC_SYSTEM_INFO function
MSG(80) VALUE SPACE,
* Exception handling
RET_SUBRC like SY-SUBRC.
* SY-SUBRC handling
CALL FUNCTION ‘RFC_SYSTEM_INFO’
STARTING NEW TASK ‘INFO’
PERFORMING RETURN_INFO ON END OF TASK
EXCEPTIONS
COMMUNICATION_FAILURE = 1 MESSAGE MSG
SYSTEM_FAILURE = 2 MESSAGE MSG.
IF SY-SUBRC = 0.
WRITE: ‘Wait for response’.
ELSE.
WRITE MSG.
ENDIF.
.
AT USER-COMMAND.
* Return from the form routine RETURN_INFO using SET USER-COMMAND
IF SY-UCOMM = ‘OKCD’.
IF RET_SUBRC = 0.
WRITE: ‘Destination =’, INFO-RFCDEST.
ELSE.
WRITE MSG.
ENDIF.
ENDIF.
.
FORM RETURN_INFO USING TASKNAME.
RECEIVE RESULTS FROM FUNCTION ‘RFC_SYSTEM_INFO’
IMPORTING RFCSI_EXPORT = INFO
EXCEPTIONS
COMMUNICATION_FAILURE = 1 MESSAGE MSG
SYSTEM_FAILURE = 2 MESSAGE MSG.
RET_SUBRC = SY-SUBRC. «Setn RET_SUBRC
SET USER-COMMAND ‘OKCD’. «Set OK_CODE
ENDFORM.
Wie das obige Beispiel zeigt, kann man in der FORM -Routine, in der die Auswertung des betreffenden Tasks vorgenommen wird, mit Hilfe der Anweisung SET USER-COMMAND ein Listen-Ereignis ausgelöst werden. Dieses kann dann im Rahmenprogramm im AT USER-COMMAND -Zeitpunkt (z. B. zweck Administration der asynchronen Aufrufe) verarbeitet werden. Hierbei wird nicht immer gewährleistet, daß nach jedem SET USER-COMMAND der AT USER-COMMAND ausgeführt wird.
The SET USER-COMMAND statement in screen processing in this case causes the last PAI module of the preceding screen to be processed with the specified user command as its OK_CODE . This does not ensure that the user command processing is executed after each SET USER-COMMAND statement. In debugging mode, for example, the statement is ineffective (the SET USER-COMMAND event is not processed).
For the purpose of adminstration of asynchronous function module calls (especially in background mode), you can use the WAIT statement. The above example, using the WAIT statement instead of SET USER-COMMAND , would then look like this:
Example
DATA: INFO LIKE RFCSI,
* Results of RFC_SYSTEM_INFO function
MSG(80) VALUE SPACE,
* Exception handling
RET_SUBRC like SY-SUBRC,
* SY-SUBRC handling
SEMAPHORE(1) TYPE C VALUE SPACE.
* Flag for receiving asynchronous results
CALL FUNCTION ‘RFC_SYSTEM_INFO’
STARTING NEW TASK ‘INFO’
PERFORMING RETURN_INFO ON END OF TASK
EXCEPTIONS
COMMUNICATION_FAILURE = 1 MESSAGE MSG
SYSTEM_FAILURE = 2 MESSAGE MSG.
IF SY-SUBRC = 0.
WRITE: ‘Wait for the answer’.
ELSE.
WRITE MSG.
ENDIF.
.
CLEAR SEMAPHORE.
WAIT UNTIL SEMAPHORE = ‘X’.
* Return from the form routine RETURN_INFO
IF RET_SUBRC = 0.
WRITE: ‘Destination =’, INFO-RFCDEST.
ELSE.
WRITE MSG.
ENDIF.
.
FORM RETURN_INFO USING TASKNAME.
RECEIVE RESULTS FROM FUNCTION ‘RFC_SYSTEM_INFO’
IMPORTING RFCSI_EXPORT = INFO
EXCEPTIONS
COMMUNICATION_FAILURE = 1 MESSAGE MSG
SYSTEM_FAILURE = 2 MESSAGE MSG.
RET_SUBRC = SY-SUBRC. «Set RET_SUBRC
SEMAPHORE = ‘X’. «Set semaphore
ENDFORM.
Non-Catchable Exceptions
- CALL_FUNCTION_NO_RECEIVER : Data received for unknown CPIC connection. Error triggered because an answer to an asynchronous function call has been received by CPIC protocol that could not be forwarded to the correct program context. This situation occurs when you use a SUBMIT or CALL TRANSACTION statement after the PERFORMING form ON END OF TASK statement. The SUBMIT statement generates a new internal session that can prevent the results from the function call being forwarded to the internal session from which the function module was called.
Exceptions for RFC
Non-Catchable Exceptions
- Cause: The called function module has not been released for RFC.
Runtime Error: CALL_BACK_ENTRY_NOT_FOUND - Cause: Destination type is not allowed.
Runtime Error: CALL_FUNCTION_DEST_TYPE - Cause: Missing communication type (I for internal connection, 3 for R/3) when calling an asynchronous RFC
Runtime Error: CALL_FUNCTION_DESTINATION_NO_T - Cause: The destination entered does not exist.
Runtime Error: CALL_FUNCTION_NO_DEST - Cause: The destination entered (in load distribution mode) does not exist.
Runtime Error: CALL_FUNCTION_NO_LB_DEST - Cause: Data received for unknown CPI-C connection.
Runtime Error: CALL_FUNCTION_NO_RECEIVER - Cause: The function module you tried to call is flagged as one that cannot be called remotely.
Runtime Error: CALL_FUNCTION_NOT_REMOTE - Cause: An error occurred when calling the function remotely. This error is logged in the calling system.
Runtime Error: CALL_FUNCTION_REMOTE_ERROR - Cause: The logon data for the user is not complete.
Runtime Error: CALL_FUNCTION_SIGNON_INCOMPL - Cause: The attempt to log on in the form of an internal call to a target system is not valid.
Runtime Error: CALL_FUNCTION_SIGNON_INTRUDER - Cause: RFC from an external program without a valid user ID.
Runtime Error: CALL_FUNCTION_SIGNON_INVALID - Cause: The user tried to log onto the target system without a valid user ID.
Runtime Error: CALL_FUNCTION_SIGNON_REJECTED
The error code signifies the following:
1) Incorrect password or invalid user ID
2) User locked
3) Too many logon attempts
5) Error in authorization buffer (internal error)
6) No external user check
7) Invalid user type
User’s validity interval has been exceeded - Cause: No authorization for logon as a t rusted system .
Runtime Error: CALL_FUNCTION_SINGLE_LOGIN_REJ
The error code signifies the following:
0) Incorrect logon data with a valid security key.
1) Either the calling system is not a trusted t rusted system , or the security key is invalid.
2) Either the user has no RFC authorization (authorization object S_RFCACL ) or else someone tried to log on using a protected user, ‘DDIC’ or ‘SAP*’ .
3) The timestamp for the logon data is invalid. - Cause: An RFC without a valid user ID is only allowed for a system function module. The meaning of the error code is the same as for CALL_FUNCTION_SINGLE_LOGIN_REJ .
Runtime Error: CALL_FUNCTION_SYSCALL_ONLY - Cause: Data error (internal table info) when calling a function remotely
User’s validity interval has been exceeded Runtime Error: CALL_FUNCTION_TABINFO
- Cause: No memory available for the table to be imported
Runtime Error: CALL_FUNCTION_TABLE_NO_MEMORY
Cause: Only applies to asynchronous RFC: Task name is already being used
Runtime Error: CALL_FUNCTION_TASK_IN_USE
Cause: Only applies to asynchronous RFC: The specified task is already open
Runtime Error: CALL_FUNCTION_TASK_YET_OPEN
- Cause: No trusted authorization for the RFC call and trusted system
Runtime Error: CALL_RPERF_SLOGIN_AUTH_ERROR - Cause: No valid trusted entry for the calling system
Runtime Error: CALL_RPERF_SLOGIN_READ_ERROR - Cause: No RFC authorization for the user
Runtime Error: RFC_NO_AUTHORITY
Источник
REPORT ztst_call_async_rfc.
PARAMETERS: p_para TYPE char1 DEFAULT ‘X’ AS CHECKBOX.
TYPES: BEGIN OF t_tasklist,
taskname(4) TYPE C, » Задача
RESULT TYPE char50, » Статус обработки
END OF t_tasklist.
DATA:
lv_calls TYPE I VALUE 10, » Количество запусков функции
lv_max_tasks TYPE I, » Переменная для хранения максимального числа задач
lv_free_tasks TYPE I, » Переменная для хранения числа свободных задач
lv_number_of_tasks_in_use TYPE I, » Количество задач в работе
lv_started_rfc_calls TYPE I VALUE 0, » Кол-во запущенных задач
lv_finished_rfc_calls TYPE I VALUE 0, » Кол-во завершенных задач
lv_exception_flag(1) TYPE C, » Флаг ошибки запуска задачи из-за нехватки ресурсов
lv_taskname(4) TYPE N VALUE ‘0001’, » Имя задачи
lt_tasklist TYPE TABLE OF t_tasklist. » Журнал обработки RFC вызовов.
DATA: » Для обработки времени работы
lv_start_time TYPE timestampl,
lv_end_time TYPE timestampl,
lv_diff TYPE timestampl.
FIELD—SYMBOLS: <fs_tasklist> TYPE t_tasklist.
START-OF-SELECTION.
IF p_para EQ ‘X’.
GET TIME STAMP FIELD lv_start_time.
* Получение максимального числа задач и кол-во свободных для использования задач.
CALL FUNCTION ‘SPBT_INITIALIZE’
EXPORTING
group_name = »
IMPORTING
max_pbt_wps = lv_max_tasks
free_pbt_wps = lv_free_tasks
EXCEPTIONS
invalid_group_name = 1
internal_error = 2
pbt_env_already_initialized = 3
currently_no_resources_avail = 4
no_pbt_resources_found = 5
cant_init_different_pbt_groups = 6
OTHERS = 7.
IF sy—subrc <> 0.
MESSAGE ID sy—msgid TYPE sy—msgty NUMBER sy—msgno
WITH sy—msgv1 sy—msgv2 sy—msgv3 sy—msgv4.
ELSE.
WRITE : / ‘Макисмальное число задач для выполнения параллельно обработки: ‘, 80 lv_max_tasks RIGHT—JUSTIFIED.
WRITE : / ‘Доступное кол-во задач: ‘, 50 lv_free_tasks RIGHT—JUSTIFIED.
ULINE.
DO lv_calls TIMES.
PERFORM call_rfc. » Запуск RFC задачи
» call_rfc — запускает на выполнение RFC функцию в отдельном задаче (асинхронно),
» в случае если нет свободных задач, или произошла ошибка выделения задачи,
» ожидает пока не завершаться предыдущие задачи, после завершения продолжает данный цикл.
ENDDO.
» Последняя задержка пока не отработают все «последние» задачи.
WAIT UNTIL lv_finished_rfc_calls = lv_calls.
SKIP 2.
WRITE : / ‘Журнал работы RFC функций:’.
ULINE.
LOOP AT lt_tasklist ASSIGNING <fs_tasklist>.
WRITE : / <fs_tasklist>—taskname,
<fs_tasklist>—RESULT.
ENDLOOP.
SKIP.
GET TIME STAMP FIELD lv_end_time.
lv_diff = lv_end_time — lv_start_time.
WRITE: /(50) ‘Время работы’, lv_diff.
ENDIF.
ELSE.
GET TIME STAMP FIELD lv_start_time.
» Запуск функции в последовательной обработке
DO lv_calls TIMES.
CALL FUNCTION ‘Z_PAR_TEST’
EXPORTING
COUNT = 2
EXCEPTIONS
OTHERS = 99.
ENDDO.
GET TIME STAMP FIELD lv_end_time.
lv_diff = lv_end_time — lv_start_time.
WRITE: /(50) ‘Время работы’, lv_diff.
ENDIF.
*&———————————————————————*
*& Form call_rfc
*&———————————————————————*
* text
*———————————————————————-*
FORM call_rfc.
ADD 1 TO lv_number_of_tasks_in_use.
* Внимание: количество свободных задач для параллельной обработки делится между всеми
* пользователями, крайне не желательно использовать все (lv_free_tasks) для расчётов,
* их количество настраивается в тр. RZ12. В случае если все свободные задачи заняты кем
* то, программа выдаст сообщение об ошибке (Нехватке ресурсов ПФЗ), после вызова SPBT_INITIALIZE
» Если количество процессов в работе будет превышать кол-во свободных задач,
» остановим программу на ожидание освобождения задач.
IF lv_number_of_tasks_in_use > lv_free_tasks.
WRITE : / ‘Ожидаем пока завершатся предыдущие задачи’.
WAIT UNTIL lv_number_of_tasks_in_use < lv_free_tasks.
ENDIF.
CALL FUNCTION ‘Z_PAR_TEST’
STARTING NEW TASK lv_taskname
«DESTINATION IN GROUP DEFAULT
PERFORMING receive_results_from_rfc ON END OF TASK
EXPORTING
COUNT = 2
* Так как используется асинхронный вызов RFC параметры импорта здесь не указываются,
* результат работы будет получаен в форме receive…
EXCEPTIONS
communication_failure = 1
system_failure = 2
resource_failure = 3.
* Чтобы узнать на каком сервере приложений будет запущена задача, необходимо сразу после запуска
* воспользоваться ФМ — SPBT_GET_PP_DESTINATION
* Чтобы исключить выполнение задачи на полученном сервере приложений используется ФМ: SPBT_DO_NOT_USE_SERVER
*
* Администрирование групп параллельной обработки выполняется через транзакцию — RZ12
* Мануал по этому делу тут: http://help.sap.com/saphelp_nw04/helpdata/en/fa/096e92543b11d1898e0000e8322d00/frameset.htm
* Пример обработки:
** 1 — system crash occured on the receiving side
** 2 — connection or communication problem with RFC-Destination
* CALL FUNCTION ‘SPBT_GET_PP_DESTINATION’
* IMPORTING rfcdest = lf_rfcdest.
*
* CALL FUNCTION ‘SPBT_DO_NOT_USE_SERVER’
* EXPORTING server_name = lf_server
* EXCEPTIONS
* invalid_server_name = 1
* no_more_resources_left = 2
* pbt_env_not_initialized_yet = 3
* OTHERS = 4.
* IF sy-subrc <> 0.
* cf_task_failure = chars. «e-message -> missing log
* EXIT.
* ENDIF.
CASE sy—subrc.
WHEN 0.
WRITE : / ‘Запущена новая задача с именем: ‘, lv_taskname.
APPEND INITIAL LINE TO lt_tasklist ASSIGNING <fs_tasklist>.
<fs_tasklist>—taskname = lv_taskname.
lv_started_rfc_calls = lv_started_rfc_calls + 1.
ADD 1 TO lv_taskname.
WHEN 1 OR 2. «Communications failure
* Означает что сервер приложений не доступен; нет необходимости обрабатывать данное исключение,
WHEN 3. » Нет свободных задач, ожидаем.
IF lv_exception_flag = SPACE.
lv_exception_flag = ‘X’.
WRITE : / ‘Нет доступных задач ждем пока освободятся…’.
WAIT UNTIL lv_finished_rfc_calls >= lv_started_rfc_calls.
ELSE.
WRITE : / ‘Повторное ожидание освобождения задач…’.
WAIT UNTIL lv_finished_rfc_calls >= lv_started_rfc_calls.
IF sy—subrc = 0. » Ожидание было успешным
CLEAR lv_exception_flag.
ELSE. » Ожидание прервано, сбой в RFC вызове, прерывание обработки
WRITE : / ‘RFC вызов прерван’.
EXIT.
ENDIF.
ENDIF.
ENDCASE.
ENDFORM. «call_rfc
*&———————————————————————*
*& Form receive_results_from_rfc
*&———————————————————————*
* text
*———————————————————————-*
* —>VALUE(P_TASKNAME) text
*———————————————————————-*
FORM receive_results_from_rfc USING VALUE(p_taskname).
lv_number_of_tasks_in_use = lv_number_of_tasks_in_use — 1.
* Обновить статус задачи
READ TABLE lt_tasklist WITH KEY taskname = p_taskname ASSIGNING <fs_tasklist>.
IF sy—subrc = 0.
<fs_tasklist>—RESULT = ‘Задача успешно завершена’.
ELSE.
READ TABLE lt_tasklist WITH KEY taskname = lv_taskname ASSIGNING <fs_tasklist>.
IF sy—subrc = 0.
<fs_tasklist>—RESULT = ‘Ошибка в обработке задачи’.
ENDIF.
ENDIF.
* Получение результатов обработки функции, в данном случае ничего не получаем
RECEIVE RESULTS FROM FUNCTION ‘Z_PAR_TEST’.
lv_finished_rfc_calls = lv_finished_rfc_calls + 1.
ENDFORM. «RECEIVE_RESULTS_FROM_RFC