Problem in XML Message creation ( after a perform on commit)

[former_member288936]

Dear experts,

I have a question regarding and ABAP proxy I'm trying to trigger from a BADI.

Well, I added a perform on commit to the BADI FI_F110_SCHEDULE_JOB ; that's mean my routine schould be triggered after all updates of the tables are done.

Though I'm facing a trouble with the XML message generation, I can't seem to be able to generate the message until after I re-run the program a second time( so apparently the problem is not in the proxy).

Do I need to add a

WAIT UP TO XX SECONDS.

until all the updates are done? or what exactly?

Regards,

Houriya

[Ryan-Crosby]

Hi Houriya,

This is straight from the SAP help - it demonstrates that the PERFORM is executed in sequence after the statement is reached but before the DB commit actually happens. You will need to rethink your approach for whatever you are trying to handle in the F110 BADI.

Regards,

Ryan Crosby

[former_member288936]

Hi Ryan,

Thanks for the replay.

The problem is that I can't use any BTE, as it will affect the execution of the transaction and that's not what what we want .

Another thing is that this works fine the second time after repeating the same test.

Do you have any suggestions?

Regards,

Houriya

[Ryan-Crosby]

Hi Houriya,

What exactly is it that you are trying to accomplish in the BADI implementation via the PERFORM ... ON COMMIT?

Regards,

Ryan Crosby

[former_member288936]

Hi Ryan ;

I'm trying to trigger an ABAP proxy after the creation of a payment proposal( this- the payment proposal - updates certain tables with the proposal information), I need to retreive these information and send them to an external system.

After analysing the standard prog of F110 while the generation of proposal, I noticed a commit work that assures the update of the tables .

That's why in the BADI I added a perform on commit that will trigger the abap proxy after extracting the data that just got inserted in the DB.

Regards,

Houriya

[Ryan-Crosby]

Hi Houriya,

Given the details of what you are trying to do I would suggest the following approach at a high level when you execute the BADI:

FORM submit_job_form.

DATA: lv_jobname  TYPE tbtcjob-jobname,
      lv_jobcount TYPE tbtcjob-jobcount.

* Create job
lv_jobname = 'SOME_JOB_NAME'.
CALL FUNCTION 'JOB_OPEN'
  EXPORTING
    jobname          = lv_jobname
  IMPORTING
    jobcount         = lv_jobcount
  EXCEPTIONS
    cant_create_job  = 1
    invalid_job_data = 2
    jobname_missing  = 3
    OTHERS           = 4.

IF sy-subrc = 0.
  * Submit proxy wrapper
  SUBMIT my_proxy_wrapper_program
    VIA JOB lv_jobname
    NUMBER  lv_jobcount
    WITH p_laufd = gv_laufd
    WITH p_laufi = gv_laufi
    WITH p_xvorl = gv_xvorl.

* Release job
  CALL FUNCTION 'JOB_CLOSE'
    EXPORTING
      jobcount             = lv_jobcount
      jobname              = lv_jobname
      strtimmed            = 'X'
    EXCEPTIONS
      cant_start_immediate = 1
      invalid_startdate    = 2
      jobname_missing      = 3
      job_close_failed     = 4
      job_nosteps          = 5
      job_notex            = 6
      lock_failed          = 7
      invalid_target       = 8
      OTHERS               = 9.
ENDIF.

ENDFORM.

If you execute something like this in a PERFORM ... ON COMMIT then you would pass the necessary parameters to the wrapper program that would be triggered when the job kicks off. The job however should not kick off until a COMMIT is performed on the database meaning you should get the delay that you need for the proxy to pick up the data in REGUH/REGUP.

Regards,

Ryan Crosby

[former_member288936]

Hi Ryan,

Thank you for the replay,

So what you are suggesting is that I put this code in the perform .. on commit I added to the BADI ?

Regards,

Houriya

[Ryan-Crosby]

Hi Houria,

Yes, the overall idea is that the FORM will execute once a COMMIT is issued and it will be responsible for opening the job, then a SUBMIT of the wrapper program that executes the proxy, and lastly closing the job. Once the DB commit actually happens should be the point at which the job will start running with the start immediately parameter set. This should allow for the wrapper program and thus proxy to run normally and execute as expected with all of the data existing in the database.

Regards,

Ryan Crosby

[former_member288936]

Hi Ryan,

I tried your suggestion, and I still have the same problem the message is not triggered from the first try

Regards,

Houriya

[Ryan-Crosby]

Hi Houriya,

In that case you can experiment with using the scheduled start date and time instead of start immediately for the 'JOB_CLOSE' FM call. If you add a 5-10 second delay based on the current system time and date then it may help. Must be that all of the DB work has not completed in the case of an immediate start on the job creation.

Regards,

Ryan Crosby

[former_member288936]

Do you mean those fields :SDLSTRTDT, SDLSTRTTM?

Regards,

Houriya

[Ryan-Crosby]

Yes, but you would have to not set the value for the other parameter for starting immediately also.

[Sandra_Rossi]

You must debug what's going on first, to understand why it doesn't work and then determine the solution. Add a breakpoint at the first statement inside your subroutine. The debugger will stop at it during the next COMMIT WORK after your PERFORM x ON COMMIT (cf SAP's diagram provided by Ryan). Any reason why you're using this obsolete statement PERFORM x ON COMMIT ? (instead of CALL FUNCTION IN UPDATE TASK; moreover, I can't say whether FI_F110_SCHEDULE_JOB is the good place)

[former_member288936]

Hi Sandra,

What's the difference between perform on commit and call function in update Task?

I've already debugged a several times. I can't find anything wrong , because once I delete the payment proposal a second time and rerun it again the message is sent successfuly.

Reagards,

Houriya

[Sandra_Rossi]

See the ABAP documentation for the differences and the huge advantage of CALL FUNCTION IN UPDATE TASK.

Anyway, this kind of issue is often difficult to handle. It can be anything. Too bad...