At one of my clients they had a requirement to run a batch job every 5 minutes.  Sometimes the batch job would take longer than 5 minutes to complete.  Thus, the same program would start in a new batch job before the previous batch job had time to finish.  The same program would collide with itself and cause issues.

It seems that SAP’s built-in job scheduler does not have a standard way of preventing overlapping job executions.  I was hoping to find a checkbox that would deny an execution of a job if it finds the same active job running, but that would be too easy.  However, SAP does have some different options in its toolbelt to satisfy this requirement.  The approach that I will demonstrate will use an event-driven approach to execute a SAP batch job.

First I will detail the High level overview of what needs to happen.  Then, after you understand the big picture, then I will go into more detail about how to code and configure this scenario.

High level Overview

Basically 2 SAP batch jobs are needed:

1) SAP Job #1

• This job will execute every 5min or so depending on your requirment and execute a simple custom program that will check the status of Job #2.
  • If the status of job Job #2 is not running, then the custom program will raise an event
  • If the status of Job #2 is running, then the custom program will do nothing

2) SAP Job #2

• This job is setup to start only when an event is raised
  • If an event is Raised from Job #1 then Job #2 will start.  Job #2 will contain the actual programs that you need to execute.

Sound easy enough?

Step-By-Step Instructions

Now let’s get to business and see what configuration and coding we need to do.

1)      First let’s define an Event.

Transaction SM64 – I defined my event as Z_JOB_START_XXXXX

2)     Next,  Create simple Custom program ZJOB_CREATE_EVENT to Raise the Event.   This program will basically check if the specified job is currently running.  If it is not running then Raise an event which was created in the previous step above.   In my case, I will  raise event ‘Z_JOB_START_XXXXX’.   Create a variant here with the Event Name(Z_JOB_START_XXXXX) and the Job #2 name (ZJOB_XXXXX).

3)      For Job #1.  Basically set this job as Periodic Time driven job to run every 5 minutes or so with the custom program ZJOB_CREATE_EVENT.  Also make sure you include the variant with the Job #2 name and Event.

4)      For Job #2.  Define this job as an Event Driven batch job and define the actual program (I used test program ZSPTEST) that needs to be executed.  Specify the event Z_JOB_START_XXXXX that this job will be waiting for.  Also checkbox ‘Periodic job’ to schedule another event job.

That’s it…Now the batch job will only execute if the same batch job is not running.

Testing

For testing purposes, I will demonstrate by manually execute program ZJOB_CREATE_EVENT to show that how this all works.

The event ZJOB_START_XXXXX has been raised by program ZJOB_CREATE_EVENT.  Now you can see the ZJOB_XXXXX is Active/Running

During the time the job is active, I attempted to execute program ZJOB_CREATE_EVENT again.   This time, the program knows that the job is still active and, therefore, it does not raise the event.  The only time the event will be raised again is once the job is finished .

This is only one scenario in where an event driven batch job is needed.  Now you can see how you can utilize an event driven batch job to put some control around how some programs are executed.

Sometimes, a special business or security requirement does not permit the “business as usual” scenario.  It is these situations which nudge me down the path which I have never explored.

Take, for example, a simple flat file interface outbound from SAP to an external system.  In the typical scenario, at the 50,000 foot level, it works like this:

In a scheduled batch job step, an SAP ABAP program extracts data and creates a flat file in a folder somewhere on the network that is commonly visible to both SAP and the external system.

The external system acquires the flat file, processes the data and then archives the file, just in case we need to play “where is my data” or “I sent it, why didn’t you get it”.

Here is the process diagram:

In this scenario, OS administrators on both sides of the interface have agreed to grant to the common folder all of the permissions needed so that each side of the interface can perform its tasks.

But what if that is not the case?  What if the external system administrator cannot permit a common SAP/external system mount; but will permit receiving the file via ftp?

Let’s redraw the process diagram:

In this scenario, SAP drops the output file into its own outbound network OS folder. The file is then moved to an inbound network folder on the external system via an ftp script.

The question now becomes, how do we execute the ftp script after the first step of the batch job which creates the outbound data file?

It turns out that SAP provides a facility to do just that.  Effectively, SAP will allow the ftp script to be entered as a step in a batch job.

We begin to assemble our batch job with SM36 as usual.

As shown here, the batch job is named Z_OUT_INTERFACE_2_EXTERNAL_SYST.

The first step of the batch job executes ABAP program Z_OUT_MATERIAL_EXTRACT with variant PRODUCTION_VAR.

This is the step which creates the outbound data file.

Once the file is created by the ABAP program in step 1, we would like an ftp script to execute, and copy the file to a folder on the remote system. SAP allows an external program (e.g. our ftp script) to be executed as a batch job step.  We are going to  make this step 2 in our job. (This is the section of batch job land which I had never before explored.) To set up an external program as an SAP batch job step, click the External Program button. The External program block is now open for input.

In the Name box, enter the complete path name of the location of the external program. In this case, our external program is an ftp script which takes two input parameters: 1) The complete pathname of the data file. In this example, the complete pathname is /data/dx1/ftpscript.ksh. 2) The path name and the name of the outbound data file. In this example, the path name of the outbound data file is /data/dx1/interfaces/materials/outbound, and the name of the outbound data file is materials.txt. Both of these parameters are entered in the Parameter box.

SAP also allows for the external program standard output or error output to be displayed in the SAP job log. These are turned on/off using control flags.

In this example, I have turned on the control flags which allow any standard output and error output from the external program to be displayed in the SAP job log.  I have also set the control flag which requires that the external program complete before the SAP job ends.  If this control flag is not set and there are no further job steps, the SAP job will complete without waiting for the external program.

Here is the entire SAP batch job with two job steps. The first step is the ABAP program which creates the outbound data file. The second step is the ftp script which will ftp the file to the external system. This is the result that we want.

And, for all of you SAP documentation fans, yes, this is documented in SAP.  This documentation describes the external command and external program facilities, as well as the authorizations needed to utilize them.

SAP Documentation about using External Commands and External Programs as batch job steps can be found at: http://help.sap.com/saphelp_nw70/helpdata/EN/c4/3a7f2c505211d189550000e829fbbd/content.htm