Executing batch-input sessions in background jobs

[Former Member]

Isn't there any possibility to process several Batch Input sessions in one background job?

Now we create with a own written program a lot of batch input sessions and we process these sessions in a background job with program RSBDCSUB as the only step. After this job has run all the batch input sessions

are submitted in background (there are as many jobs as batch input.

This causes sometimes a performance problem for the background processes

because all of these sessions are processed as separated jobs

(sometimes more than 100 batch input sessions = more than 100 background

jobs)

[Former Member]

One way you could accomplish this, is by scheduling a backgroud job that will call program RSBDCSUB as a step and specify the BDC session name in a variant. You can repeat this in several steps. The problem is that the BDC sessions will run one after the other, so you would have to decide the priority of the sessions when you schedule the job. However, only one job will be running instead of 100 jobs.

Now, I checked everywhere and I could not find any documentation that specifies the number of steps that you can create in a job (I have never created more than six or seven steps), so you would need to try and see (trial and error).

I hope this helps.

EG

[Former Member]

An alternative but very similar approach to schedule one job per session and create a chain of jobs. I happened to be looking at some code the other day that does this. Unfortunately I don't see a way to post an attachment so here is the code below.

This code uses RSBDCBTC instead of RSBDCSUB, providing more control over the processing of the sessions.

The code for the custom program ZSBDCCHK is not provided, but it just raises an error to prevent continuation of the processing chain, if the session was processed with errors.

• Get matching batch-input sessions (and queue-ids)

SELECT QID GROUPID

FROM APQI

INTO TABLE T_SESSIONS

WHERE DESTSYS EQ SPACE

AND DESTAPP EQ SPACE

AND DATATYP EQ C_DATATYP_BDC

AND MANDANT EQ SY-MANDT

AND GROUPID LIKE V_BDC_NAME_GENERIC

AND PROGID EQ SPACE

AND FORMID EQ SPACE

AND QATTRIB EQ SPACE

AND QSTATE EQ C_STATE_TO_BE_PROCESSED.

IF SY-SUBRC NE 0.

MESSAGE A011 WITH V_BDC_NAME_GENERIC

RAISING NO_SESSIONS_FOUND.

ENDIF.

• Schedule jobs to run and check the BDC sessions created

LOOP AT T_SESSIONS.

• Build name of job to run the BDC session via RSBDCBTC

CONCATENATE ... INTO V_JOB_NAME_A SEPARATED BY '_'.

• Build name of job to check the session's status

CONCATENATE ... INTO V_JOB_NAME_B SEPARATED BY '_'.

• Start to create the job to run the BDC session

CALL FUNCTION 'JOB_OPEN'

EXPORTING JOBNAME = V_JOB_NAME_A

IMPORTING JOBCOUNT = V_JOB_ID_A

EXCEPTIONS OTHERS = 4.

IF SY-SUBRC NE 0.

RAISE-EXCEPTION UNABLE_TO_OPEN_JOB_A.

ENDIF.

SUBMIT RSBDCBTC AND RETURN

VIA JOB V_JOB_NAME_A

NUMBER V_JOB_ID_A

WITH QUEUE-ID EQ T_SESSIONS-QID.

• Start to create the job to check the BDC session.

• Scheduled to start after the previous job "A".

CALL FUNCTION 'JOB_OPEN'

EXPORTING JOBNAME = V_JOB_NAME_B

IMPORTING JOBCOUNT = V_JOB_ID_B

EXCEPTIONS OTHERS = 4.

IF SY-SUBRC NE 0.

RAISE-EXCEPTION UNABLE_TO_OPEN_JOB_B.

ENDIF.

• ABAP to check the status of a BDC session, can't be

• in the same job as RSBDCBTC because of the way that

• RSBDCBTC terminates.

SUBMIT ZSBDCCHK AND RETURN

VIA JOB V_JOB_NAME_B

NUMBER V_JOB_ID_B

WITH P_BDCMAP EQ T_SESSIONS-GROUPID

WITH P_QID EQ T_SESSIONS-QID.

• Build event parameter for job B. This will be

• scheduled to run after the SAP standard event

• SAP_END_OF_JOB. This event's parameter

• is the previous job's name followed by its job id.

V_JOB_EVENT_PARAM = V_JOB_NAME_A.

V_JOB_EVENT_PARAM+32 = V_JOB_ID_A.

• Schedule job B to run after job A. Note that we

• close (and thereby finish creating) job B before job

• A. This ensures that the second

• job will be ready to run when the first finishes.

CALL FUNCTION 'JOB_CLOSE'

EXPORTING JOBCOUNT = V_JOB_ID_B

JOBNAME = V_JOB_NAME_B

EVENT_ID = C_JOB_EVENT

EVENT_PARAM = V_JOB_EVENT_PARAM

EXCEPTIONS OTHERS = 4.

IF SY-SUBRC NE 0.

RAISE-EXCEPTION UNABLE_TO_CLOSE_JOB_B.

ENDIF.

• We don't close the job to run the BDC session until

• all of the possible jobs have been opened.

T_OPEN_JOBS-JOB_ID = V_JOB_ID_A.

T_OPEN_JOBS-JOB_NAME = V_JOB_NAME_A.

APPEND T_OPEN_JOBS.

ENDLOOP.

• If the BDC sessions are allowed to run in parallel

IF PROCESS_SERIAL EQ SPACE.

LOOP AT T_OPEN_JOBS.

• Close the remaining open jobs and start immediately

CALL FUNCTION 'JOB_CLOSE'

EXPORTING

JOBCOUNT = T_OPEN_JOBS-JOB_ID

JOBNAME = T_OPEN_JOBS-JOB_NAME

STRTIMMED = 'X'

EXCEPTIONS

OTHERS = 4.

IF SY-SUBRC NE 0.

RAISE-EXCEPTION UNABLE_TO_CLOSE_JOB_A.

ENDIF.

ENDLOOP.

ELSE.

• Process the batch-input session in series

LOOP AT T_OPEN_JOBS.

• We don't kick the first job off until last, this

• ensures that all dependant jobs exist before

• processing really starts

IF SY-TABIX NE 1.

• Close the remaining open jobs and have them

• start after previous

CALL FUNCTION 'JOB_CLOSE'

EXPORTING

JOBCOUNT = T_OPEN_JOBS-JOB_ID

JOBNAME = T_OPEN_JOBS-JOB_NAME

EVENT_ID = C_JOB_EVENT

EVENT_PARAM = V_JOB_EVENT_PARAM

EXCEPTIONS

OTHERS = 4.

IF SY-SUBRC NE 0.

RAISE-EXCEPTION UNABLE_TO_CLOSE_JOB_A.

ENDIF.

ENDIF.

• Set next job (session) to run after the current one

V_JOB_EVENT_PARAM = T_OPEN_JOBS-JOB_NAME.

V_JOB_EVENT_PARAM+32 = T_OPEN_JOBS-JOB_ID.

ENDLOOP.

• Read the very first job which will kick off the

• entire processing chain

READ TABLE T_OPEN_JOBS INDEX 1.

• Close the first job and have it start immediately

CALL FUNCTION 'JOB_CLOSE'

EXPORTING

JOBCOUNT = T_OPEN_JOBS-JOB_ID

JOBNAME = T_OPEN_JOBS-JOB_NAME

STRTIMMED = 'X'

EXCEPTIONS

OTHERS = 4.

IF SY-SUBRC NE 0.

RAISE-EXCEPTION UNABLE_TO_CLOSE_JOB_A.

ENDIF.

ENDIF.

COMMIT WORK.

Cheers,

Scott

[Former Member]

Sorry for the formatting of the code. It was nicely indented until the forum got hold of it!

Scott

[thomas_jung]

I guess I will play <i>devil's advocate</i> and ask why create so many Batch Input Sessions. You know that creating 100 or more session overloads the system. This is a custom program that is creating the sessions, correct? Why not take the total number of transactions and divide it into only 10 or so sessions (or whatever number is manageable for your system) using functions BDC_CLOSE_GROUP and BDC_OPEN_GROUP triggered by a counter. You will still get parallel activity, but only enough parallelism as so not to overwhelm your system.