Easy Application Integration: How to use the Records Management Call Handler Framework

Transcription

1 Easy Application Integration: How to use the Records Management Call Handler Framework Applies to: SAP NetWeaver > 7.0 For more information, visit the Data Management and Integration homepage. Summary This article describes how you can use the SAP Records Management Call Handler framework in order to integrate SAP applications into SAP Records Management or into other SAP applications. Author: Thomas Müller Company: Commit-Work GmbH Created on: 10 February 2009 Author Bio Thomas Müller has a Ph.D. in Mathematics and joined SAP Support in 2001 where he learned a lot about performance in ABAP programming. From 2003 to 2006 he was developing the integration of SAP SRM with SAP Records Management in the DLA strategic project. From 2006 to 2009 he developed the xft invoice manager. In 2009 with three colleagues he founded the Commit-Work GmbH SAP AG 1

2 Table of Contents Introduction...3 Creating a Frame and a Wrapper Function Module...4 Calling the Frame Function Module...6 Using Transaction SRMCALLMON...7 Exception handling...9 Scheduling the Batch Jobs for Automatic Call Handling...14 Related Content...17 Disclaimer and Liability Notice SAP AG 2

3 Introduction Everybody who has already dealt with Records Management knows the problem of updating an existing record through the change BAPI while an online dialog user is locking this record. (This problem is not specific for Records Management. It occurs in a natural way, when two different applications have to be integrated). Most developers will respect the lock and try their BAPI call later again. Normally, during the first BAPI call, the program has already collected some context data, which were necessary for the call. Those context data may change during time. So, actually the developer has to make sure not only, that the BAPI call will be performed one and only one time, but also that the BAPI call uses the right context data, that means, the developer has to store also the context data of the first call. The almost unknown Records Management Call Handler Framework helps you to fulfil these tasks. In particular, buffered function calls may be restarted automatically depending on the developer s specific implementation of an error handling. In this article we present a simple example, where the BAPI SRM_RECORD_CREATE is buffered with the help of the call handler. The article explains in detail how to register your function module for the framework, and how you can implement an error handling for your call. Of course, changing a record would be a more realistic application for the Call Handler. Anyway, SRM_RECORD_CREATE is a good example in order to demonstrate the principles. Further articles will handle the administration of the SRMCALLMON transaction and the setup of the batch jobs, that are necessary for driving the entries. Note: The Call Handler works of course completely independently of Records Management. You can use it for each supposable integration scenario with asynchronous updates and the necessity to buffer functional calls and Queue or Background RFCs are not sufficient SAP AG 3

4 Creating a Frame and a Wrapper Function Module In this first step we will create a pair of function modules for the BAPI we want to call. One of them, the frame function module, will be called instead of the BAPI, the other one, the wrapper function module will be called by the framework itself. Start transaction SE80, open the package SRM_INTEGRATION_BROKER, open the program SRM_CREATE_FUNCTIONS SAP AG 4

5 Run the program with the following parameters: Choose local objects in the following dialog. You will get the following messages: Open your local objects in transaction SE80. Rebuild the object list. You will now find your new function modules: 2009 SAP AG 5

6 Calling the Frame Function Module In this second step we will create an entry for our function call. After registration this entry will be displayed in transaction SRMCALLMON. Open the frame function module. Insert a commit work statement at the end of the function module and activate it. You need that statement, since by default the frame function module is created for registration in update task. In a real scenario, your application would do the commit work. Now test this function module with the following (or similar) test data. If you have set up a running RMS ID with a running record model and SPS ID, you can of course use them. IV_RFCDEST_ determines where the wrapper function module is called SAP AG 6

7 The following parameters determine the object, this call is done for. They are building the application key of the queue object. These parameters define also the dependency group. That means if you register more than one call for this object with the same GUID, the calls are handled as dependent objects by the framework. In particular the calls are done respecting a certain priority and time order. If the calls differ by the GUID they are treated independently. Using Transaction SRMCALLMON This section describes how you can find, start or debug your call in the monitoring transaction SRMCALLMON. Start transaction SRMCALLMON and execute the search without parameters. You will find your call entry: 2009 SAP AG 7

8 You can also display your the context interface parameters. They are buffered by the framework SAP AG 8

9 Exception Handling Go back to transaction SE80. Open again the package SRM_INTEGRATION_BROKER. Go to Enhancements->Classic BADIs. Open the sample implementation of SRM_HANDLE_EXC1 and display the exception handling code: Copy this code and create a new implementation for your function module. Note: An exception implementation is always done for a wrapper function module. In our case, this function module is z_wrapper: 2009 SAP AG 9

10 Add the wrapper function module name as filter parameter in the BADI implementation: Copy the coding from the clipboard into the method of the BADI.Save your implementation as a local object. Activate your coding and your BADI implementation. Set a break point to your coding: 2009 SAP AG 10

11 Start transaction SRMCALLMON new. Start the entry from SRMCALLMON by pushing the Start button: Ignore this popup: The debugger stops in the exception handler coding: 2009 SAP AG 11

12 In the interface table it_interface you find all the information you need in order to handle errors and exceptions. In this example we will only do a very rough error handling. Let the program run to its end. In the monitor you can see now, that the repeat counter has been increased by 1: We will now slightly modify the exception handler code in order to make it suitable to the record create BAPI. Open again your implementation and enter the following code: METHOD if_ex_srm_call_handle_exc~handle_exception_para. DATA: wa_exceptions TYPE abap_func_excpbind, wa_interface TYPE abap_func_parmbind, lo_exc TYPE REF TO cx_root, lv_text TYPE string. FIELD-SYMBOLS: <fs_help> TYPE bapiret2, <fs_rfc> TYPE ANY. LOOP AT it_interface INTO wa_interface. IF wa_interface-name = 'RETURN'. ASSIGN wa_interface-value->* TO <fs_help>. IF sy-subrc = 0. IF <fs_help>-type = 'E'. CALL METHOD io_queue->set_status_appl_error. CALL METHOD io_queue->set_red_rating. ELSE. CALL METHOD io_queue->set_status_finished. CALL METHOD io_queue->set_green_rating. READ TABLE it_interface WITH KEY name = 'IV_RFCDEST_12345' INTO wa_interface. IF sy-subrc = 0. ASSIGN wa_interface-value->* TO <fs_rfc>. IF sy-subrc = 0. CALL FUNCTION 'BAPI_TRANSACTION_COMMIT' DESTINATION <fs_rfc>. ENDIF. ENDIF. ENDIF. ENDIF. ENDIF. ENDLOOP. CALL METHOD cl_srm_fm_call_handler_api=>set_freetext EXPORTING io_queue = io_queue iv_freetext = 'First test'. "#EC_NOTEXT ENDMETHOD SAP AG 12

13 In the case that the BAPI returns an error message, the call entry status is set to application error and the rating is set to red. Otherwise the status is set to finished and the rating is set to green. Note: That a finished entry cannot be restarted. Start SRMCALLMON new and start your function again. Now you get the following result: Your application call has the status application error and you can see the result data of your call in the context data interface view: 2009 SAP AG 13

14 Scheduling the Batch Jobs for Automatic Call Handling In order to make the queue running automatically, you have to schedule at least two batch jobs. One for starting the function module calls and one for archiving the metadata and the interface data to the archive tables. You can schedule the jobs via transaction SRMCALLMON : In the main menu choose Functions- >Reports: Restart in order to schedule the driving job and Functions->Reports: Delete in order to schedule the deletion job. Important Note: The driving job uses for high performance strong parallelization via RFC (starting new task). On SAP systems with only a few dialog processes the job may stop without doing its tasks due to resource bottlenecks. In this case you had to write your own serial driving job. That can be done in the following way: Copy the report SRM_CALL_HANDLER_REPORT with all includes. Change the coding in the following way: *& * *& Report SRM_CALL_HANDLER_REPORT *& *& * *& *& *& * REPORT zzz_srm_call_handler_report. DATA ls_active_profile TYPE srm_s_rep_profile. *Get the active profile PERFORM get_active_profile CHANGING ls_active_profile. *Restart *PERFORM restart_incomplete_queues CHANGING ls_active_profile. PERFORM zrestart_incomplete_queues CHANGING ls_active_profile. *Include for deletion of 'finished' entries INCLUDE srm_call_handler_report_subf01. *Include for restart of un-finished entries INCLUDE srm_call_handler_report_subf02. *Include for actions *INCLUDE srm_call_handler_report_subf03. INCLUDE ZZZ_SRM_CALL_HANDLER_REPORTF01. Instead of the form routine restart_incomplete_queues define your own form routine zrestart_incomplete_queues with the following coding: FORM zrestart_incomplete_queues CHANGING p_ls_active_profile TYPE srm_s_rep_profil e. DATA: lt_unfinished_entries TYPE srm_t_queue, lv_loesch_minutes TYPE int4, lv_neustart_minutes TYPE int4, lt_queue_groups TYPE srm_t_qgroup, lt_group TYPE srm_t_queue, * lv_task_name(8) TYPE c, * lv_package_size TYPE int4, lv_group_lines TYPE int4, 2009 SAP AG 14

15 lv_del_index TYPE int2, * lv_max_pbt_wps TYPE i, * lv_free_pbt_wps TYPE i, * lv_exit_counter TYPE i VALUE 0, lv_text TYPE string, my_subrc TYPE sy-subrc. DATA gv_time_out TYPE char128. FIELD-SYMBOLS: * <wa_group_entries> TYPE srm_s_queue, <fs_queue_groups> TYPE srm_s_qgroup. DO 2 TIMES. IF sy-index = 1. * Get all queue entries which are not 'finished' but had no run yet REFRESH lt_unfinished_entries. PERFORM get_unfinished_ini_from_db CHANGING lt_unfinished_entries. ELSEIF sy-index = 2. REFRESH lt_unfinished_entries. PERFORM get_unfinished_entries_from_db CHANGING lt_unfinished_entries. ENDIF. *Find queue groups PERFORM get_queue_groups USING lt_unfinished_entries CHANGING lt_queue_groups. *Calculate the delay for the restart and deletion (default) PERFORM calculate_profile_minutes CHANGING p_ls_active_profile lv_loesch_minutes lv_neustart_minutes. *Get time-out of Server-Group from shared memory PERFORM get_time_out USING p_ls_active_profile-server_group CHANGING gv_time_out. *Loop over the queue groups LOOP AT lt_queue_groups ASSIGNING <fs_queue_groups>. REFRESH lt_group. CLEAR lv_group_lines. * Get qgroup into flat structure lt_group = <fs_queue_groups>-qgroup->get_qgroup( ). * Sort the group by time stamp VERY IMPORTANT!!!! SORT lt_group BY priority timestamp. * Delete the 'FINISHED' entries from group DELETE lt_group WHERE status = 'FINISHED'. * Check maximal package size lv_del_index = p_ls_active_profile-pack_size + 1. DELETE lt_group FROM lv_del_index SAP AG 15

16 * Restart queue group NOT in new task CALL FUNCTION 'SRM_RESTART_GROUP_IN_SEP_TASK' * STARTING NEW TASK lv_task_name * DESTINATION IN GROUP p_ls_active_profile-server_group EXPORTING is_active_profile = p_ls_active_profile iv_neustart_minutes = lv_neustart_minutes iv_time_out = gv_time_out TABLES it_queue_group = lt_group EXCEPTIONS * communication_failure = 1 * system_failure = 2 * resource_failure = 3 OTHERS = 0. ENDLOOP. ENDDO. ENDFORM. " ZRESTART_INCOMPLETE_QUEUES 2009 SAP AG 16

17 Related Content For more information on Records Management refer to: This is a possible application, where you can use the Call Handler in order to change personnel files: Here you can get an overview over the existing BAPIs for Records Management: SAP AG 17

18 Disclaimer and Liability Notice This document may discuss sample coding or other information that does not include SAP official interfaces and therefore is not supported by SAP. Changes made based on this information are not supported and can be overwritten during an upgrade. SAP will not be held liable for any damages caused by using or misusing the information, code or methods suggested in this document, and anyone using these methods does so at his/her own risk. SAP offers no guarantees and assumes no responsibility or liability of any type with respect to the content of this technical article or code sample, including any liability resulting from incompatibility between the content within this document and the materials and services offered by SAP. You agree that you will not hold, or seek to hold, SAP responsible or liable with respect to the content of this document SAP AG 18