Calling function in database

Hi all,
Ive searched the forums and still cant seem to get a solution. What im trying to do is call a function in my database that returns a number. Im calling this from answers but i get the error below
Error Codes: OPR4ONWY:U9IM8TAC:OI2DL65P
+State: HY000. Code: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 43113] Message returned from OBIS. [nQSError: 17001] Oracle Error code: 904, message: ORA-00904: "GET_OPEN_BAL_OBIEE": invalid identifier at OCI call OCIStmtExecute. [nQSError: 17010] SQL statement preparation failed. (HY000)+
+SQL Issued: SELECT 0 s_0, "Customer and Account Information UBS"."FACT All Account Entry View"."AC_BRANCH" s_1, "Customer and Account Information UBS"."FACT All Account Entry View"."DRCR_IND" s_2, "Customer and Account Information UBS"."FACT All Account Entry View"."TRN_DT" s_3, CASE "Customer and Account Information UBS"."FACT All Account Entry View"."DRCR_IND" WHEN 'D' THEN "Customer and Account Information UBS"."FACT All Account Entry View"."LCY_AMOUNT"*(-1) WHEN 'C' THEN "Customer and Account Information UBS"."FACT All Account Entry View"."LCY_AMOUNT" ELSE "Customer and Account Information UBS"."FACT All Account Entry View"."LCY_AMOUNT" END s_4, EVALUATE('GET_OPEN_BAL_OBIEE(%1)' ,'01-01-2014') s_5 FROM "Customer and Account Information UBS" WHERE (("FACT All Account Entry View"."CUST_GL" = 'A') AND ("FACT All Account Entry View"."EVENT" <> 'REVL') AND ("FACT All Account Entry View"."AC_NO" ="DIM Customer Accounts"."CUST_AC_NO") AND ("FACT All Account Entry View"."AC_BRANCH" = '003') AND ("FACT All Account Entry View"."TRN_DT" = timestamp '2013-06-05 00:00:00')) FETCH FIRST 65001 ROWS ONLY+
Any ideas why ?

Found that i wasn't prefixing the schema name and the user didnt have rights to execute the function all works now

Similar Messages

Call function from data base with clob input parameter.

Hello,
In this project I use Jdev 11g.
I call function from database.
create or replace function get_fa_list (
p_fa_id_list in clob
return sys_refcursor
is
vCursor sys_refcursor;
begin
put_msg ('begin');
if p_fa_id_list is null then
put_msg ('CLOB is null!');
else
put_msg ('size CLOB: ' || dbms_lob.getlength (p_fa_id_list));
end if;
put_msg ('Save');
open vCursor for
select rownum as id, s.*
from (
select f.latitude, f.longitude, count (distinct f.res_id) as res_count, count (*) as fa_count, 16711680 as color, res_concat_distinct (f.res_id) as station_list
from mv_frequency_assignment f, table (SplitClob (p_fa_id_list, ',')) l
where f.ext_system = 'BI' and
f.ext_sys_id = l.column_value
group by f.latitude, f.longitude
) s;
put_msg ('Open and End');
return vCursor;
end get_fa_list;
I use TopLink in ejb.
i use follow code for call function and get result.
public List<TmpResPoints> findAllPointsBI(String p_id){
UnitOfWork uow = getSessionFactory().acquireUnitOfWork();
uow.beginEarlyTransaction();
StoredFunctionCall call = new StoredFunctionCall();
call.setProcedureName("get_fa_list");
call.useUnnamedCursorOutputAsResultSet();
ClobDomain c = new ClobDomain(p_id);
//System.out.println(c.toString());
call.addNamedArgumentValue("p_fa_id_list", c);
ReadAllQuery query = new ReadAllQuery();
query.setReferenceClass(TmpResPoints.class);
query.setCall(call);
List<TmpResPoints> result = (List<TmpResPoints>)uow.executeQuery(query);
uow.commit();
uow.release();
return result;
But size parameter "p_fa_id_list" is 0. (geting from temp table in Data base). this code in function >>
if p_fa_id_list is null then
put_msg ('CLOB is null!');
else
put_msg ('size CLOB: ' || dbms_lob.getlength (p_fa_id_list));
end if;)
How I can call this function from dataBase and get result?
thx,
Demka.

What is the SQL generated?
The argument should just be the Clob value (a String) not the domain object.
Also try addNamedArgument, and then pass the named argument to the query.
James : http://www.eclipselink.org

CALL FUNCTION 'crm_mktbp_merge_bps' does not write to database

Hello Experts,
i try to use the function call 'crm_mktbp_merge_bps' to merge the marketing attributes of two business partners (contact persons).
Inital situation:
Business partner 1 (lv_ap_guid) is maintained with 1 profile and its attributes.
Business partner 2 (lv_ap_guid_new) has no profile.
CALL FUNCTION 'CRM_MKTBP_READ_ALL_TPL'
    EXPORTING
      iv_objectkey             = lv_ap_guid
*   IV_AUTHORITY_CHECK       = ' '
*   IV_ACTIVITY              = '03'
*   IV_READ_DESCR            = 'X'
    TABLES
     et_return                = lt_bapi_return
     et_prtpllist             = lt_crmt_mktbp_proftpl_list
LOOP AT lt_crmt_mktbp_proftpl_list INTO ls_crmt_mktbp_proftpl_list.
CLEAR lt_bapi_return.
CALL FUNCTION 'CRM_MKTBP_MERGE_BPS'
    EXPORTING
      iv_quell_bp               = lv_ap_guid
      iv_ziel_bp                = lv_ap_new_guid
      IV_PROFILE_TEMPLATE       = ls_crmt_mktbp_proftpl_list-PROFILE_TEMPLATE_ID
    TABLES
      et_return                 = lt_bapi_return
CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'
     EXPORTING
       WAIT          = 'X'
* IMPORTING
*   RETURN        =
ENDLOOP.
The function call runs without any errors and delivers no messages in "lt_bapi_return".
However, no changes to the database are written, though i'm using the function 'BAPI_TRANSACTION_COMMIT'.
In the Tx BP i'm not able to find the new profile in Business partner 2.
Can anyone help me out with this.
Thanks.
Best Regards
Markus

Hi Markus,
I got the same problem. Have you found a solution for this?
Best regards,
Mario

What is the use of CALL FUNCTION MODULE - AT BACKGROUND TASK?

Hi experts,
I found Call functional module in background task will make the FM run at the next commit work as some people said. So I have some questions:
1 if we use COMMIT WORK commend, the pending FM will be called? If there are several FMs called at background task, what is the sequence of them? How many conditions will trigger the running of these FMs?
2 Where can I find the log of this pending FMs? In SAP library, it says there are 2 tables. But I checked these tables and can only find the FM name and user of it. And I can not understand content of these tables. It seems one is for the main information of FM, and the other is for the data of the FM, maybe the parameters.
3 If I call a FM in this way, Can I canncel it before the next commit work in some way?
Finally, thanks for reading and help.

HI,
When the COMMIT WORK statement is executed, the function modules registered for the current SAP-LUW are started in the order in which they were registered. ROLLBACK WORK deletes all previous registrations for the current SAP-LUW.
If the specified destination is not available when COMMIT WORK is executed, an executable program called RSARFCSE is started in background processing. By default, this tries to start the function modules registered for a SAP-LUW in their destination every 15 minutes and up to 30 times. These parameters can be changed in the transaction SM59. If the destination does not become available within the defined time, it is recorded in the database table ARFCSDATA as the entry "CPICERR". The entry in the database table ARFCSSTATE is deleted after a standard period of eight days

Call function in background

Hi everybody,
My issue is that I have create a module function which insert into database .
loop AT t_DD02L into s_DD02L.
           CALL FUNCTION 'Z_GET_DURATION_QUERY' "in BACKGROUND TASK
             EXPORTING
               s_table       = s_DD02L-tabname
     ENDLOOP.
It doesn't insert if it's called in background and if it's called normally it works perfect!
help please,
thank you,
Sam ZA

Hi,
Please add a commit work after calling the FM. Your background task sessions are not started until this. You can see pending tRFC session in the tcode SM58..
loop AT t_DD02L into s_DD02L.
           CALL FUNCTION 'Z_GET_DURATION_QUERY' "in BACKGROUND TASK
             EXPORTING
               s_table       = s_DD02L-tabname
     ENDLOOP.
Commit work.
Cheers,
Mahesh

Performance issue: CALL FUNCTION inside a Loop.

Hi Friends
I have a Performance Issue. That is, inside a loop...endloop a CALL FUNCTION has been used which gets data from another database table. Finally it's appended into another internal table. Please see this :
LOOP AT i_mdkp.
    REFRESH lt_mdtbx.
    CLEAR lt_mdtbx.
    CALL FUNCTION 'READ_MRP_LIST'
      EXPORTING
        idtnum        = i_mdkp-dtnum
        icflag        = 'X'
      tables
        mdtbx         = lt_mdtbx
    APPEND LINES OF lt_mdtbx TO i_mdtb.
ENDLOOP.
It happens for each record available in i_mdkp. Suppose, i_mdkp have around 50000 records, it needs to call the function module till that much time.
So, I want to split it. Can I?
Please give me your valueable suggestions.
Regards
Senthil

If internal table i_mdkp has 50,000 records it does not mean that you need to run 50,000 iterations. You just need dtnum from internal table i_mdkp so you number of iterations should be eqaul to the unique number of dtnum in the internal table. Sort the internal table by dtnum and delete adjacent duplicates from the internal table comparing dtnum before looping. Look at the code below.
DATA i_mdkp_tmp LIKE TABLE OF i_mdkp.
IF NOT i_mdkp[] IS INITIAL.
i_mdkp_tmp[] = i_mdkp[].
SORT i_mdkp BY dtnum.
DELETE ADJACENT DUPLICATES FROM i_mdkp COMPARING dtnum.
REFRESH i_mdtb.
LOOP AT i_mdkp.
    CALL FUNCTION 'READ_MRP_LIST'
      EXPORTING
        idtnum = i_mdkp-dtnum
        icflag = 'X'
      TABLES
        mdtbx = lt_mdtbx.
    APPEND LINES OF lt_mdtbx TO i_mdtb.
    REFRESH lt_mdtbx.
ENDLOOP.
i_mdkp[] = i_mdkp_tmp[]
ENDIF.

Call function module in update task

Hi
I am using the follwoing logic in my prog
CALL FUNCTION 'Z_Update _Task'    In update task
EXPORTING
    t_vbak        = t_vbak.
But the program goes to dump at call function
Please let me know if the syntax i am using is correct.
Edited by: kittu reddy on Feb 28, 2008 5:29 AM

It might be the type conflict . Please check once .
Here am giving some information abt UPDATE TASK.
Why do we use this " In Update Task " ??
The main update technique for bundling database changes in a single
database LUW is to use CALL FUNCTION... IN UPDATE TASK.
How do we Use ??
A typical R/3 installation contains dialog work processes and at least one update work process. The update work processes are responsible for updating the database. When an ABAP program reaches a COMMIT WORK statement, any function modules from CALL FUNCTION... IN UPDATE TASK statements are released for processing in an update work process. The dialog process does not wait for the update to finish. This kind of update is called asynchronous update.
What is the Use... ??
Asynchronous update is useful when response time from the transaction is critical, and the database updates themselves are so complex that they justify the extra system load
Thanks
Jagadeesh

Calling Function Module in Update Task

Hello Experts,
Can anyone let me know about
Calling Function Module in Update Task.
Why do we use this " In Update Task " ??
How do we Use ??
What is the Use... ??
Kindly let me know....
Thanks and Regards
Pramod

hi,
Why do we use this " In Update Task " ??
The main update technique for bundling database changes in a single database LUW is to use CALL FUNCTION... IN UPDATE TASK.
How do we Use ??
A typical R/3 installation contains dialog work processes and at least one update work process. The update work processes are responsible for updating the database. When an ABAP program reaches a COMMIT WORK statement, any function modules from CALL FUNCTION... IN UPDATE TASK statements are released for processing in an update work process. The dialog process does not wait for the update to finish. This kind of update is called asynchronous update.
What is the Use... ??
Asynchronous update is useful when response time from the transaction is critical, and the database updates themselves are so complex that they justify the extra system load
Real time scenario.
Suppose a user wants to change an entry in a database table, or add a new one. He or she enters the necessary data, and then starts the update process by choosing Save. This starts the following procedure in the ABAP program:
Firstly, the program locks the database entry against other users, using the enqueue work process (or the message server in the case of a distributed system). This generates an entry in the lock table. The user is informed whether the update was successful, or whether the lock could not be set because of other users.
If the lock is set, the program reads the entry that is to be changed and modifies it. If the user has created a new entry, the program checks whether a record with the same key values already exists.
In the current dialog work process, the program calls a function module using CALL FUNCTION... IN UPDATE TASK, and this writes the change details as an entry in table VBLOG.
When the program is finished (maybe after further dialog steps), a COMMIT WORK statement starts the final part of the SAP LUW. The work process that is processing the current dialog step starts an update work process.
Based on the information passed to it from the dialog work process, the update work process reads the log entries belonging to the SAP LUW from table VBLOG.
The update work process passes this data to the database for updating, and analyzes the return message from the database. If the update was successful, the update work process triggers a database commit after the last database change and deletes the log entries from table VBLOG.
If an error occurred, the update work process triggers a database rollback, leaves the log entries in table VBLOG, flags them as containing errors, and sends a SAPoffice message to the user, who should then inform the system administrator.
The corresponding entries in the lock table are reset by the update work process.
Hope this is helpful, Do reward.

Call function starting new task:

I am trying to create a program in which few database update are mentioned.
after database updates , I am calling a function module using starting new task
in which I want to commit database updates inside in function module.
Problem is I want to commit only database updates if function module , not of main program. For that I tried using COMMIT WORK in function module and rollback statement after calling FM. But it is not working.COMMIT statement in FM also commiting database updates of main program also that is not required.
Can anybody help me in solving this problem.
Thanks
Ruchika

I think this may be caused by an implicit database commit performed by the system at the moment of calling a fm with "starting new task".
Try the following test:
- Put "rollback work" statement inside your fm which you call "starting new task" (instead of "commit") and check if the updates performed by the code executed before the call to this fm are stored in db - inspite of the rollback. If they are (as I suppose) this means that the commit effect you observe is not due to the "commit work" statement executed inside your fm but due to an implicit commit issued automatically at the time of calling the fm. If this is the case the solution could be placing the code which you now execute before "call function...starting new task" into a seperate fm called "in update task" - then the final commit or rollback statement in your main program should have the expected effect.
regards

Call Function

Hi,
Can any one detail the exact difference between Call Function and Call Function in Update Task.
Regards,
Sreedhar

CALL FUNCTION func IN UPDATE TASK.
Extras:
1. ... EXPORTING p1 = f1 ... pn = fn
2. ... TABLES p1 = itab1 ... pn = itabn
Effect
Flags the function module func for execution in the update task. It is not executed at once, but the data passed with EXPORTING or TABLES is placed in a database table and a subsequent COMMIT WORK then causes the function module to be executed by the update task. Update function modules must be flagged as such in the Function Builder
The return value is not set.
Addition 1
... EXPORTING p1 = f1 ... pn = fn
Effect
Values of fields and field strings specified under EXPORTING are passed from the calling program to the function module. In the function module, the formal parameters are defined as import parameters. In the interface definition, default values must be assigned to all import parameters of the update function module.
Addition 2
... TABLES p1 = itab1 ... pn = itabn
Effect
TABLES passes references to internal tables. All table parameters of the function module must have values.
Note
With update function modules, both import parameters and exceptions are ignored when the call is made.
During updating processes of function modules, you may not make any calls using the language statements SUBMIT, CALL DIALOG, CALL SCREEN, CALL TRANSACTION, COMMIT WORK or ROLLBACK WORK . All other language elements that trigger a database Commit (for example, a screen change using the MESSAGE statement) also lead to a runtime error during updating.

Wht is UPDATE TASK functionality in CALL FUNCTION??

Hi Experts,
Pls. clarify one of my simple doubt that, Wht is the functionality of UPDATE TASK, in following sttement?
call function 'Z_FM_1' in update task
I found SAP help as follow, but not understood??
Flags the function module func for execution in the update task. It is not executed at once, but the data passed with EXPORTING or TABLES is placed in a database table and a subsequent COMMIT WORK then causes the function module to be executed by the update task. Update function modules must be flagged as such in the Function Builder
The return value is not set.
thanq

Hi,
It sounds like the FM was not called but it was (rollback process).
And what is the difference between an update attribute assigning FM and this?
You control the FM update process by setting the update module attribute.
- Update with immediate start
Set this option for high priority ("V1") functions that run in a shared (SAP LUW). These functions can be restarted by the update task in case of errors.
- Update w. imm. start, no restart
Set this option for high priority ("V1") functions that run in a shared (SAP LUW). These functions may not be restarted by the update task.
- Update with delayed start
Set this option for low priority ("V2") functions that run in their own update transactions. These functions can be restarted by the update task in case of errors.
Regards,
Ferry Lianto

Call function module in backgrouns task and in update task

Hi Gurus,Pls crear me on the " Call function module in backgrouns task and in update task".
how it works and waht is the link with LUW releated to these .
also heard that commit work statement aslo linked with this.
Pls clarfiy me with expalnation of code.

Hi sridhar,
the explanation already given is correct and good. Small add-on:
All functions called during one LUW with addition IN UPDATE TASK are stored together with their actual parameters in a temporary memory area. The moment a COMMIT WORK is issued, the functions are released to be executed by a so-called update task which is running in the background. This explains why functions called in update task never return anything, no SY-SUBRC and no export or table parameters If a function called in update task raises an exception or runs into an error the calling user will get an express message informing about this. Also, all database updates done by this update process are rolled back to keep consistency.
This proceeding helps to keep database tables consistent and allows the user to keep on doing his work before all database updates are complete. You may have seen messages like "material will be changed" after saving. If you open the same material immediately, you'll get a message "object locked by...<yourself>". This means the update task is still running.
Regards,
Clemens

Commit changes after CALL FUNCTION ... IN UPDATE TASK

Hi ABAPers,
I'm a bit confused about the behaviour of Update Function Modules.
Following scenario:
In our transaction (Modulpool with dynpros) the user clicks a butto to change some data:
1. PAI-Modul performs FORM_A
2. FORM_A calls FM_A several times in a LOOP
3. FM_A does some business logic and calls FM_B IN UPDATE TASK
4. FM_B modifies database tables
5. After the LOOP FORM_A does COMMIT WORK AND WAIT
Then the changes are not in the db immediately, the user will see the old data for a short time.
Why does the COMMIT-statement not start the Update-process?
Thanks,
Markus

Hi,
This executes all high-priority update function modules registered using CALL FUNCTION ... IN UPDATE TASK in the order of their registration and in a common database LUW. If you do not specify the addition AND WAIT, the program does not wait until the update work process has executed it (asynchronous updating). If you specify the addition AND WAIT, however, program processing after COMMIT WORK will not continue until the update work process has executed the high-priority update function modules (synchronous updating).
If all high-priority update function modules are completed successfully, the statement executes the low-priority update function modules together in a common database LUW.
here high priority function moudles are function module with V1 task.
Regards,
Siva chalasani.

Queries on Call Function In update Task

Hi ,
I have a requirement where I have to update a ztable in background once I execute the report.THe requirement is to exceute the updation in background.Will
Call funtion in update task help me?If yes, I have never used call function in update task .so can you guide me on the same.If no, how best can I acheive this?
Thanks & Regards,
Jyotsna

Hi,
look F1 to call function pls:
It is not executed at once, but the data passed with EXPORTING or TABLES is placed in a database table and a subsequent COMMIT WORK then causes the function module to be executed by the update task.
-> so in error case you can analyse err. with TA SM13
(update records)
regards Andreas

Doubt in call function

Hi,
Call Function 'FM' starting new task task-name
Exporting
What does this statement does.

Hi
chk this out
CALL FUNCTION STARTING NEW TASK
Variant 2
CALL FUNCTION func ...STARTING NEW TASK task name.
Extras:
1. ... DESTINATION dest
2. ... DESTINATION IN GROUP group name
3. ... DESTINATION IN GROUP DEFAULT
4. ... PERFORMING form ON END OF TASK
5. ... EXPORTING p1 = f1    ... pn = fn
6. ... TABLES     p1 = itab1 ... pn = itabn
7. ... EXCEPTIONS syst_except = rc MESSAGE mess
Effect
Starts the function module func asynchronously in a new session. In contrast to normal function module calls, the calling program resumes processing as soon as the function module is started in the target system. It does not wait until the function module has finished. Using CALL SCREEN, the called function module can, for example, display a screen and thus interact with the user. Note that taskname must be a valid string of at least 2 characters, preferably fewer than 8 characters. You cannot use either ' ' or SPACE as tasknames.
Notes
Note that under certain circumstances, an RFC may cause a database commit. For this reason, do not insert an RFC between two OpenSQL statements that open and close a database cursor (such as SELECT...ENDSELECT).
This variant applies only from R/3 Release 3.0, so both the client system and the server system must have Release 3.0 at least.
With this variant, the called function module must also be flagged in the Function Builder as externally callable, even if it is executed locally (without the addition Destination).
There can be no function call to the destination 'BACK' in the called function module (for more information about the destination 'BACK', see CALL FUNCTION func DESTINATION dest).
This variant does not allow you to execute external programs that you access from a TCP/IP-type detination asynchronously. (See the Transaction Tools -> Administration, Administration -> Network -> RFC destinations for maintaining destinations).
Neither does this variant allow you to display images such as lists or screens in a separate window during RFC communication using a SAProuter.
From Release 4.0 onwards, you can carry out a new, stricter system load check on RFC destinations. (In RFC destination maintenance of an R/3 connection, choose Destination -> ARFC-Optionen). Before the function module is executed, the system checks that the destination has sufficient resources available. If not, the system delays execution of the function module for a given period of time. The algorithm used to determine the system load on the target machine is the same as that used for an asynchronous RFC with the DESTINATION IN GROUP addition. Note that this option is only available for target systems from Release 3.1H onwards. This procedure is active as default.
In principle, parallel processing makes sense whenever application servers have the necessary resources. In this case, the application servers must be configured with at least 3 dialog work processes.
A program that is run in the background and uses RFC parallel processing requires at least 1 dialog work process per application server (because parallel processing takes place in a dialog work process).
If the instance profile parameter 'auth/rfc_authority_check' is set to 1, the system automatically performs an RFC authorization check. The authorization check refers to the relevant function group for the function module to be called. If no authorization is found, a runtime error occurs. You can check the authorization in advance with the function module AUTHORITY_CHECK_RFC. If the RFC communication takes places in one system and in the same user context (that is, the same client and User ID) the system does not perform an RFC authority check. For more information, see: RFC Authorization Concept.
When you are using asynchronous RFC to implement parallel windows, all these windows are closed if the caller session is the only session and terminates.
Note that asynchronous tasks that have been started are not necessarily closed when the calling program ends.
See also RFC Logons to the Target System (Remote Logon).
Addition 1
... DESTINATION dest
Effect
Executes the function module externally as a Remote Function Call (RFC); dest can be a literal or a variable. The R/3 System where the function module is executed depends on the specified destination. Externally callable function modules must be flagged as such in the Function Builder (of the target system).
Note
If the destination is not explicitly specified, the system uses the default destination 'NONE'.
Note
If, during a Remote Function Call, an error occurs in the target system, details of the error message are passed back to the calling system in the following system fields: SY-MSGNO, SY-MSGID, SY-MSGTY, SY-MSGV1, SY-MSGV2, SY-MSGV3, and SY-MSGV4. These fields are initialized before every RFC. If a short dump or a type X message occurs, the short text of the dump is transferred to the caller, and the contents of SY-MSGID, SY-MSGTY, SY-MSGNO, and SY-MSGV1 assigned by the system.
In RFC-enabled function modules, no ABAP statements are allowed that would end the RFC connection (for example, either LEAVE or SUBMIT without the AND RETURN addition).
Note
Note that a database commit occurs at each Remote Function Call (RFC). Consequently, you cannot use Remote Function Calls between pairs of statements that open and close a database cursor (such as SELECT ... ENDSELECT).
Addition 2
... DESTINATION IN GROUP group name
Addition 3
... DESTINATION IN GROUP DEFAULT
Effect
You use this addition to perform parallel execution of function modules (asynchronous calls) on a predefined group of R/3 System application servers.
You use addition 2 (DESTINATION IN GROUP group name) to perform parallel execution of function modules on a predefined group of application servers. To maintain the RFC groups, choose Tools -> Administration -> Administration ->Network -> RFC destinations -> RFC -> RFC groups. The application programmer is responsible for the availability of RFC groups in the production system. In this case the group name variable must be of the type RZLLITAB-CLASSNAME
You use addition 3 (DESTINATION IN GROUP DEFAULT) to perform parallel execution of function modules (asynchronous calls) on all currently available R/3 System application servers. However, instead of this variant, you are recommended to use an RFC group with appropriate resources for parallel processing of asynchronous calls (at least for performance reasons). Please note that the addition DESTINATION IN GROUP ' ' has the same effect as the addition DESTINATION IN GROUP DEFAULT.
When you first call a function module with these additions, the system initializes the specified RFC group (unless the group has already been explicitly identified).
To obtain current information about resources (that is, the resources available to process function modules), you can also initialize the RFC group explicitly in the program using the function module SPBT_INITIALIZE. You must perform this action before the first function module call.
In both cases, the system first ascertains the currently available resources (work processes) on the available application servers (either a group of servers or all servers). By checking the current system load of each application server, the system determines how many work processes are available to execute asynchronous calls.
After ascertaining the available resources, the asynchronous call is executed to one of the
destinations. If no resources are available at that particular time, the system executes the
exception routine RESOURCE_FAILURE (see the addition EXCEPTIONS). In the case of
an asynchronous function module call, this exception must be handled by the application
program (see example).
No resources are made available by the system if resource availability limits are exceeded:
Notes
To be taken into consideration for RFC parallel processing, an application server must have at least 3 free dialog processes.
The system triggers the exception RESOURCE_FAILURE only for asynchronous RFCs with the additions DESTINATION IN GROUP group name and DESTINATION IN GROUP DEFAULT.
At present, only one RFC group per program environment is supported for parallel execution of asynchronous calls. Using both the additions DESTINATION IN GROUP group name and DESTINATION IN GROUP DEFAULT in a program is thus not allowed.
To find out which destination was automatically selected, call the function module SPBT_GET_PP_DESTINATION immediately after the function module call with the two additions. This returns the selected RFC destination.
If you want to delete an application server from the list of the configured RFC group at runtime (for example, when the application server is not accessible for technical reasons), use the function module SPBT_DO_NOT_USE_SERVER.
Addition 4
... PERFORMING form ON END OF TASK
While the parameters for receiving results (that is IMPORTING and TABLES parameters) are specified directly as additions in the case of "conventional" function modules (see variant 2), these are logged in the FORM routine form when making an asynchronous call (see RECEIVE).
Notes
If a function module returns no result, and you are not interested in error messages that arise when executing the function module, this addition (... PERFORMING form ON END OF TASK) can be omitted.
If you want to handle the error messages that arise when executing the asynchronous function module call, you must use this addition. Also, when receiving the results in the FORM routine (see RECEIVE), you must react accordingly to the system exceptions SYSTEM_FAILURE and COMMUNICATION_FAILURE.
With asynchronous RFC, the task name uniquely identifies the asynchronous connection and thus the context called.
If several asynchronous function modules are executed consecutively to the same destination, you must assign a different task name to each.
A calling program that starts an asynchronous RFC with the PERFORMING form ON END OF TASK addition cannot switch roll areas or change to an internal mode. This is because the asynchronous function module call reply cannot be passed on to the relevant program. You can perform a roll area switch with SUBMIT or CALL TRANSACTION.
If a calling program makes asynchronous calls, finishes, and then expects responses, it cannot receive these responses.
To wait for the reply to a started asynchronous function module, use the WAIT command with the addition PERFORMING form ON END OF TASK. Here, WAIT must be in the same program context (mode).
Note that executing asynchronous calls is subject to a roll area change.That is, subroutines performed to receive asynchronous calls can take place while other asynchronous calls are being made. Thus as a developer you must ensure that subroutines can be executed at any time. You must not make assumptions about the implicit processing sequence.
Addition 5
... EXPORTING p1 = f1 ... pn = fn
Effect
Passes values of fields and field strings from the calling program to the function module. In the function module, the formal parameters are defined as import parameters.
Addition 6
... TABLES p1 = itab1 ... pn = itabn
Effect
Passes references to internal tables.
Addition 7
... EXCEPTIONS syst_except = rc MESSAGE mess
Effect
While any exceptions arising in the called function module are handled by the second
addition (see the FORM subroutine RETURN_INFO), this addition can handle two special
system exceptions, (as with function module calls with the DESTINATION addition):
SYSTEM_FAILURE
is triggered, if a system crash occurs on the receiving side.
COMMUNICATION_FAILURE
is triggered if there is a connection or communication problem.
In both cases, you can get a description of the error with the optional ... MESSAGE messaddition
Note
In principle, you should always react to these two system exceptions, whether you are making an asynchronous function module call or receiving results.
Examples
Calling a transaction in a seperate session.
DATA: MSG_TEXT(80) TYPE C. "Message text
Asynchronous call to Transaction SM59 -->
Create a new session
CALL FUNCTION 'ABAP4_CALL_TRANSACTION' STARTING NEW TASK 'TEST'
DESTINATION 'NONE'
EXPORTING
      TCODE = 'SM59'
EXCEPTIONS
    COMMUNICATION_FAILURE = 1 MESSAGE MSG_TEXT
    SYSTEM_FAILURE        = 2 MESSAGE MSG_TEXT.
IF SY-SUBRC NE 0.
    WRITE: MSG_TEXT.
ELSE.
    WRITE: 'O.K.'.
ENDIF.
Using RFC groups to parallelize function module calls(RFC parallel processing)
TYPES: BEGIN OF TASKLIST_TYPE,
         TASKNAME(4) TYPE C, "Verwaltung der Tasks
         RFCDEST     LIKE RFCSI-RFCDEST,
      END OF TASKLIST_TYPE.
DATA: INFO LIKE RFCSI, C, "Message text
      JOBS TYPE I VALUE 10, "Number of parallel jobs
      SND_JOBS TYPE I VALUE 1, "Sent jobs
      RCV_JOBS TYPE I VALUE 1, "Received replies
      EXCP_FLAG(1) TYPE C, "Number of RESOURCE_FAILUREs
      TASKNAME(4) TYPE N VALUE '0001', "Task name administration
      TASKLIST TYPE TABLE OF TASKLIST_TYPE,
      WA_TASKLIST TYPE TASKLIST_TYPE.
DO.
CALL FUNCTION 'RFC_SYSTEM_INFO'
       STARTING NEW TASK TASKNAME DESTINATION IN GROUP DEFAULT
       PERFORMING RETURN_INFO ON END OF TASK
       EXCEPTIONS
         COMMUNICATION_FAILURE = 1
         SYSTEM_FAILURE        = 2
         RESOURCE_FAILURE      = 3.
CASE SY-SUBRC.
    WHEN 0.
Administration of asynchronous tasks
        WA_TASKLIST-TASKNAME = TASKNAME.
        CLEAR WA_TASKLIST-RFCDEST.
        APPEND WA_TASKLIST TO TASKLIST.
        WRITE: / 'Started Task: ', WA_TASKLIST-TASKNAME COLOR 2.
      TASKNAME = TASKNAME + 1.
      SND_JOBS = SND_JOBS + 1.
      JOBS     = JOBS - 1. "Number of existing jobs
      IF JOBS = 0.
        EXIT. "Job processing finished
      ENDIF.
    WHEN 1 OR 2.
Handling of communication and system failure
    WHEN 3. "No resources available at present
Receive reply to asynchronous RFC calls
      IF EXCP_FLAG = SPACE.
         EXCP_FLAG = 'X'.
First attempt for RESOURCE_FAILURE handling
         WAIT UNTIL RCV_JOBS >= SND_JOBS UP TO '0.01' SECONDS.
      ELSE.
Second attempt for RESOURCE_FAILURE handling
         WAIT UNTIL RCV_JOBS >= SND_JOBS UP TO '0.1' SECONDS.
      ENDIF.
      IF SY-SUBRC = 0.
        CLEAR EXCP_FLAG. "Reset flag
      ELSE. "No replies
        "Endless loop handling
      ENDIF.
    ENDCASE.
ENDDO.
Receive remaining asynchronous replies
WAIT UNTIL RCV_JOBS >= SND_JOBS.
LOOP AT TASKLIST INTO WA_TASKLIST.
    WRITE:/   'Received Task:', WA_TASKLIST-TASKNAME COLOR 1,
          30 'Destination: ', WA_TASKLIST-RFCDEST COLOR 1.
ENDLOOP.
FORM RETURN_INFO USING TASKNAME.
RECEIVE RESULTS FROM FUNCTION 'RFC_SYSTEM_INFO'
    IMPORTING RFCSI_EXPORT = INFO
    EXCEPTIONS
      COMMUNICATION_FAILURE = 1
      SYSTEM_FAILURE        = 2.
RCV_JOBS = RCV_JOBS + 1. "Receiving data
    IF SY-SUBRC NE 0.
Handling communication and system failure
   ELSE.
     READ TABLE TASKLIST WITH KEY TASKNAME = TASKNAME
                INTO WA_TASKLIST.
     IF SY-SUBRC = 0. "Daten registrieren
       WA_TASKLIST-RFCDEST = INFO-RFCDEST.
       MODIFY TASKLIST INDEX SY-TABIX FROM WA_TASKLIST.
     ENDIF.
   ENDIF.
ENDFORM.
plz reward if useful

Calling function in database

Similar Messages

Maybe you are looking for