Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Tracking Contact Person Changes with SAP BTE

Former Member
0 Kudos

We are using SAP BTE 00001320 to track changes to our customers. However, when changes are made in VD02 to our contact persons our FM (Z_BTE_00001320) is called but we do not get access to all the new contact person data. When our FM SELECTs the tables ADRP, ADR6 etc. from the database we see no changes to the contact person data: we get the old data.

Possible Solutions:

1. COMMIT AND WAIT

When we COMMIT inside Z_BTE_00001320 we see that we can select the tables and get the new data.
Advantage: We immediately get the new data.

Disadvantage: We are concerned however that a COMMIT inside a BTE FM is bad practice and may have negative effects elsewhere.

2. Asynchronous RFC

When we call an asynchronous RFC Z_CUSTOMER_CHANGED (to the same SAP system, STARTING NEW TASK - see below) we sometimes get the new data (presumably because of the delay and a different work process). Sometimes however not. One workaround was to build a WAIT UP TO 10 SECONDS into Z_CUSTOMER_CHANGED. So far we always get the new data if we do this.

Advantage: Most accurate solution so far.

Disadvantage: Delay of 10s. Bit of a "hack".

3. BTE 00001321

When using 00001321 (FM Z_BTE_00001321) we get the new KNVK data in a table passed to your FM. Unfortunately phone, fax and email are not there.

Advantage: You directly get new data without a delay or COMMIT.

Disadvantage: The new data is incomplete.

Questions:

1) Does anyone know why the ADRP, ADR6 changes are not yet in the DB when the BTE Z_BTE_00001320 is called? Surely a BTE is supposed to be called after all changes are commited? If that is not the case then it's like a user exit.

2) Is there a way to call a 2nd FM (FM2) from the BTE FM such that the FM2 is called only after the VD02 changes are commited? We are thinking of CALL FUNCTION IN UPDATE TASK but don't really understand if it does this.

FUNCTION Z_BTE_00001320.
*"----------------------------------------------------------------------
*"*"Local Interface:
*"  IMPORTING
*"     VALUE(I_KUNNR) LIKE  KNA1-KUNNR
*"     VALUE(I_BUKRS) LIKE  KNB1-BUKRS OPTIONAL
*"     VALUE(I_VKORG) LIKE  KNVV-VKORG OPTIONAL
*"     VALUE(I_VTWEG) LIKE  KNVV-VTWEG OPTIONAL
*"     VALUE(I_SPART) LIKE  KNVV-SPART OPTIONAL
*"     VALUE(I_XVBUP) LIKE  OFIWA-XVBUP DEFAULT 'X'
*"     VALUE(I_AKTYP) LIKE  OFIWA-AKTYP DEFAULT 'V'
*"----------------------------------------------------------------------

  CALL FUNCTION 'Z_CUSTOMER_CHANGED'
    STARTING NEW TASK 'CUSTCHANGED'
    DESTINATION sy-sysid
    EXPORTING
      customer  = i_kunnr
      wait      = 'X'
      sales_org = i_vkorg
      comp_code = i_bukrs
      tcode     = sy-tcode
      username  = sy-uname.

ENDFUNCTION.

9 REPLIES 9

former_member189779
Active Contributor
0 Kudos

You can try Calling your Z FM in background task. So the Z FM will start after commit of current SAP LUW

  CALL FUNCTION 'Z_CUSTOMER_CHANGED'  in Backgroud Task.

http://help.sap.com/saphelp_nw04/helpdata/en/8f/53b67ad30be445b0ccc968d69bc6ff/content.htm

0 Kudos

Unfortunately we are still seeing some cases where our FM is called and cannot see the new data. Are you sure that the background task waits for the current LUW? It sounds like it just executes asynchronously (i.e. in parallel) and may run before our COMMIT.

Sorry, there was a mistake. It does indeed now look like the IN BACKGROUND TASK is 100% successful.

Make that 98% successful. We are again seeing cases where the function called IN BACKGROUND TASK does NOT have access to the data.

Venkat_Sesha
Employee
Employee
0 Kudos

Hi You are trying to update the Vendor Details with a Z FM which is BAPI.

Check your Business Object which is created and check what are all the methods and events maintained there. Transaction SWO1.  Check whether you are updating all to see the data for all the tables.Hope this helps.

0 Kudos

Hi,

I am not using business objects and I am not trying to update vendors. This is the scenario:

1) A normal SAP user updates a debitor in VD02 or XD02 or XD01 etc.

2) My FM (called by BTE 00001320) should catch these changes and propagate them to a 3rd party system

My issue is catching these changes. All the scenarios so far (except the WAIT UP TO 10 SECONDS) fail to capture all the new data - apparently because it is not yet properly committed.

Here is our FM call with "IN BACKGROUND TASK" which seems to behave exactly like calling via RFC.

CALL FUNCTION 'Z_CUSTOMER_CHANGED'

  IN BACKGROUND TASK

  EXPORTING

    customer  = i_kunnr

    sales_org = i_vkorg

    comp_code = i_bukrs

    tcode     = sy-tcode

    username  = sy-uname.

The call is asynchronous but sometimes still before the current LUW is committed.

0 Kudos

ok try to add this code to the Function Module.

CALL FUNCTION 'Z_CUSTOMER_CHANGED'   IN BACKGROUND TASK AS SEPERATE UNIT. 

Also I would suggest to check the whether the Lock on the Tables which are going to update are released by checking this report RSWBO_CHECK_TLOCK.

Hope this helps

0 Kudos

Just tried it and no improvement. If you think about it, this solution is even further away than we want to be because it is outside of the context of the original updates. I think our problem is one of timing and not of context. Checking lock tables also doesn't help - a few seconds after the BTE is called all data is committed and locks released. There is no time to view it before the FM is called.

raymond_giuseppi
Active Contributor
0 Kudos

As SAP documentation specifies a  FM called in background task will be executed after the execution of high-priority update function modules (VB1)

(reference COMMIT WORK.)

Here only change documents, FM ADRESSE2_WRITE_DOCUMENT, ADRESSE3_WRITE_DOCUMENT and DEBI_WRITE_DOCUMENT, should be executed as low priority modules (VB2) as ADDR_SAVE_INTERN and CUSTOMER_UPDATE are high priority (VB1) update FMs.

So using a call function in background task in BTE 00001321 you

  • have the before and aftter value of customer tables
  • should be able to read address data from database

Could you build a small update V1 FM without parameters that only performs a WAIT UP TO 600 seconds and call this FM in update task in the BTE FM, so you can analysis via SM13 your actual update task modules scheduling ?

If you only need to update some Z-tables, you could create a low priority FM (VB2) update FM for your purpose.

Regards,

Raymond

0 Kudos

Raymond, do you mean this?

FUNCTION Z_BTE_00001320.

...

CALL FUNCTION 'Z_CUSTOMER_CHANGED' 

  IN BACKGROUND TASK 

  EXPORTING 

    customer  = i_kunnr 

    sales_org = i_vkorg 

    comp_code = i_bukrs 

    tcode     = sy-tcode 

    username  = sy-uname.

WAIT UP TO 600 SECONDS.

ENDFUNCTION.

Is this a test to see if the BTE finishes before the Z_CUSTOMER_CHANGED function? I tried it but see nothing in SM13 and also nothing in SM50.

My feeling is that this won't help because the BTE 0001320 is called before any contact person changes are made. An example.

If a customer has 4 contacts and I go into VD02 and add one more. In the BTE FM (Z_BTE_00001320) I do this:

DATA i TYPE i.
SELECT COUNT(*) FROM knvk INTO i WHERE kunnr = i_kunnr.

The result is i = 4 and not 5!

So my general problem seems to be the BTE being called before contact persons are updated. If there is no BTE for contact persons I have to put the WAIT UNTIL inside Z_CUSTOMER_CHANGED - that is the only solution so far.

0 Kudos

I looked into the SD SAP source, and the BTE is in my tests was always executed before the actual update, (The CALL is coded in forms which contain the CALL FM IN UPDATE TASK) - same observation for 1320 and 1321.

I meant a :

FUNCTION Z_RGS_INTERFACE_00001321 .

*"--------------------------------------------------------------------

*"*"Interface locale :

*"  IMPORTING

*"     VALUE(I_KNA1) LIKE  KNA1 STRUCTURE  KNA1 OPTIONAL

...

CALL FUNCTION 'Z_UPDATE_MY_DATA' IN BACKGROUND TASK

  TABLES

      T_XKNVK = T_XKNVK

      T_YKNVK = T_YKNVK

...

* And for test only, to be able to display SM13

CALL FUNCTION 'Z_SLEEP' IN UPDATE TASK.

" where Z_SLEEP is a V1 update task FM which execute a WAIT UP TO 600 SECONDS.

ENDFUNCTION.

You could replace the CALL FUNCTION 'Z_UPDATE_MY_DATA' IN BACKGROUND TASK with a CALL FUNCTION 'Z_UPDATE_MY_DATA' IN UPDATE TASK, Then replace the RFC enabled FM with an update V2 low priority FM (if you only perform allowed statement, like INSERT INTO Z_TABLE of your log data.)

In every case, don't update the data in the BTE, but execute a CALL FM IN BACKGROUND/UPDATE TASK (VB2) to update your data/perform your tasks, as you need to access database for parameter not transmitted (address data here) so after execution of ADDR_SAVE_INTERN which is an update task (VB1) FM.

Regards,

Raymond