Call Transaction in background mode

[Former Member]

Hi everyone,

What I am currently trying to do is to perform a 'call transaction' while forcing the 'background processing' mode even when the user is running the program in online mode; this allows me to retrieve a lot more messages that are useful to the user than the messages generated in online mode.

As long as I have seen there is no field for that in the options table that can be passed to the 'call transaction' sentence. The only way to see that behavior while in online mode is by 'playing back' a recording thru the SHDB transaction and checking the 'Simulate background' option.

My first attempt was to set the SY-BATCH flag before doing the call transaction but it doesn't work, the flag seems to reset itself with the correct value during the call.

Any comments on this would be greatly appreciated.

Regards,

Sergio

[Former Member]

Isn't it CALL TRANSACTION ... MODE 'N', is what you are looking for?

Srinivas

[Former Member]

Instead of calling them undocumented features, may be they are "internal purpose" only features.

[RichHeilman]

You would have to create a job on the fly to do this. This example shows how to kick off a background job via an ABAP program.

report zrich_0004 .

data:   sdate type sy-datum,
        stime type sy-uzeit,
        l_valid,
        ls_params like pri_params,
        l_jobcount like tbtcjob-jobcount,
        l_jobname  like tbtcjob-jobname.

start-of-selection.

* Get Print Parameters
  call function 'GET_PRINT_PARAMETERS'
       exporting
            no_dialog      = 'X'
       importing
            valid          = l_valid
            out_parameters = ls_params.

* Open Job
  l_jobname = 'ZRICH_0005'.
  call function 'JOB_OPEN'
       exporting
            jobname  = l_jobname
       importing
            jobcount = l_jobcount.

* Submit report to job
  submit zrich_0005    
       via job     l_jobname
           number  l_jobcount
       to sap-spool without spool dynpro
           spool parameters ls_params
              and return.

* Schedule and close job.
  call function 'JOB_CLOSE'
       exporting
            jobcount  = l_jobcount
            jobname   = l_jobname
            strtimmed = 'X'
            .

[RichHeilman]

At first look, I was thinking that he was talking about MODE 'N', also, but it seems that he wants to run it "truely" in background.

Regards,

Rich Heilman

[Former Member]

> At first look, I was thinking that he was talking

> about MODE 'N', also, but it seems that he wants to

> run it "truely" in background.

>

> Regards,

> Rich Heilman

But JOB_OPEN, SUBMIT, JOB_CLOSE require the transaction he intends to submit to be an executable program, not a dialog transaction.. isn't it?

[RichHeilman]

Well, there would definitly be more work involved like put the interal table into shared memeory, then submitting the job for program B, in progam B import the data from shared memory and build the BDC, then call transaction. Program b would be doing everything in background task.

Regards,

Rich Heilman

[Former Member]

But I should question the requirement itself. If you are submitting the transaction to background, do you want it to run in a background task or background job? Background, inherently is asynchronous, so how are you planning to get the messages back to the calling program? Are you going check the background job/task status and wait until it is complete to get the result? What additional information are you getting compared to the messages you get after the call trasaction with the option "messages into msgcoll"?

Please clarify.

Srinivas

[Former Member]

set parameter DISMODE = 'N' in the options structure.

Thanks,

Rajesh.

[manuel_bassani]

Hi Sergio,

you can try to put your call trnasaction in a

call function 'Z_TRANSACTION' in background task

regards, Manuel

[Former Member]

> Hi Sergio,

> you can try to put your call trnasaction in a

>

> call function 'Z_TRANSACTION' in background task
> 

>

> regards, Manuel

but then, will it not become asynchronous?

[manuel_bassani]

Srinivas > you're right. I thought that the issue was to launch the transaction without delay for the user.

In the case of a real bk job launch i think the solution from Rich is the way.

Manuel

[former_member181962]

Hi Sergio,

Is there any other auxillary requirement that prevents you from using BDC Session method?

If not, then you can always create a session and submit the job for the created session in background.:)

Regards,

Ravi

[Former Member]

Hello fellas, thank you very much for your replies.

The actual problem is that transaction FMZ1 (Create Funds Commitment) when run in online mode delivers all check messages in a window instead of launching them as 'true' messages to be returned in the bdcmsgcoll table of the 'call transaction' sentence.

The same transaction, when run in background, sends all messages to the standard output so they are retrieved in the messages table, this is the mode I need to run the transaction on since it is part of a batch input process of thousands of documents and the goal is to generate a log of the messages generated each time the transaction is called.

Rich's idea of creating a background job seems interesting, I only would need to know how to stop the program while the job executes and how to retrieve the messages generated. The same I guess applies for the call function in background alternative.

Anybody has any idea on how the SHDB transaction achieves this without going all that way?

[RichHeilman]

I guess, if you know the job number that you could check against the table for jobs with that job number and see if its finished. You would be in an endless loop untill the job is done. This what you are looking for? It kinda defeats the purpose of a background job, but I see that this is a special issue.

Regards,

Rich Heilman

[Former Member]

Can you try setting the field SY-BINPT = 'X' before call transaction?

I am not sure, but it might work.

Bhavani.

[Former Member]

Hi Sergio,

FMZ1 internally calls this function module FMFR_CREATE_FROM_DATA which has a flag for check only. See if you can somehow use this.

Another alternative is to build BDCDATA for all your transactions and keep them in a batch input session. Then submit the batch input session, using RSBDCSUB in the background with process mentioned by Rich. You can use BP_JOB_CHECKSTATE to check if the background job completed and BP_JOBLOG_READ to read the log from that job.

Srinivas

[Former Member]

Hi Sergio,

If you want to check transaction how it is working

then you can create CATT scripts and use them.

But I have doubt in your requirement after that r u going to use the messages in your program?

If you just want to check the messages I guess CATT scripts is the good option to do that.It will create log where you can check each and evry screen in detail.

Hope this will help you.

Thanks & Regards,

Siri.

[Former Member]

Guys I finally found out how to do it, I hope this is useful for everyone, it is undocumented but by debugging the SHDB transaction found that the modes 'D' and 'Q' are available for the 'call transaction' sentence.

CALL TRANSACTION 'FMZ1'

USING BDCTAB

MODE 'Q'

MESSAGES INTO ITAB.

This executes the transaction without display and simulates background processing. The same for mode 'D' but in visible mode.

[Former Member]

Thanks Sergio for sharing this info. Good research.

[RichHeilman]

Cool. Mode "Q" and "D", huh. Interesting. Learn something new everyday!!! Good work.

Regards,

Rich HEilman

[Former Member]

Hi

You can use FM SHOW_JOBSTATE by passing the jobcount, jobname. JOBNAME would be the name that u provide to JOB_OPEN and jobcount would be returned by the same FM when it opens the job.

Loop through SHOW_JOBSTATE - till it finishes . Once the job is complete with the help of the spool number , retrive the log.

Regards

Kalpana

[Former Member]

You are right Srinivas, I will prefer that term from now on. I am glad I was able to contribute my 2 cents to this forum.

Best Regards,

Sergio.