Special Techniques: Starting External Programs (SAP Library

Special Techniques: Starting External Programs

This section describes special procedures to use for starting:

service programs or daemons that are to remain active in the target system
multiple programs in cascade fashion

Starting Service Programs and Daemons

You can use the R/3 background processing system to start service programs, such as daemons in UNIX systems.

These programs are intended to remain active after they have been started. They do not terminate and return to the R/3 background control program like normal programs.

When you start a service program, you should use the following Control flag setting when you schedule the job:

Termination: don't wait: Since the external program should not immediately terminate, you should change the default Wait setting. The R/3 control program will then terminate as soon as it has started the external program.

You can still get trace data back from the control program up until the time that it starts the external program.

Starting Cascades of Programs

Often, an external program started by the background processing system in turn starts one or more other external programs. This cascading of programs presents a problem: often, you will not be able to obtain useful feedback from the initial external program. If the external program terminates without waiting for the other programs to complete, then the return code in the job log provides no useful information on the additional processing done in the target system.

You can avoid this problem in two ways:

If you can modify the first external program, then have it issue an event to the R/3 background processing system rather than starting the additional programs.

In the background processing system, you can then schedule individual jobs for each of the "cascaded" programs that are to be started. When the initial program issues the event, the background processing system starts each of the jobs that is waiting for the event.

Advantage: you can receive return codes, output, and/or trace data from each of the external programs in the job logs.

If you cannot modify a "master program," then modify the "cascaded" programs to signal their outcomes to the R/3 system with events. You can use the event to have the R/3 background processing system start additional processing.

Example: during data transfer into your R/3 System, you could start each external data transfer program from a script or small control program that waits for the transfer program to terminate.

Upon termination of the transfer program, the control program checks the return code and issues the appropriate event to the R/3 system with the R/3 program SAPEVT. You can have the R/3 background processing system use the event to start the ABAP program that processes the transferred data.