Running a batch input session executes the transactions in the session and
enters data into an R/3 System.
Usually, the system will run batch input sessions automatically. However, you
can also start batch input sessions by hand. You may wish to do this for these
and other reasons:
To correct transactions that had errors
To check that the transactions in a session have been generated
correctly by running the first several transactions
To start a session on special request (the session would not be started
automatically or must be started right away).
Prerequisites
Start the batch input management tool: Select
System �
Service �
Batch input
� Sessions.
Alternate: Enter transaction SM35. Both paths take you to the session overview
of the batch input system. transaction SM35.
Procedure
To start a session, mark the session and choose Process from the tool
bar. You can then choose how to run a session and with what logging and display
options.
You can start any session in new status that is not locked. With
Process/foreground or Displayerrors only mode, you can also
re-start transactions that have the status Incorrect. Sessions with the
status Processed cannot be run again.
Run Modes
There are three ways to run a session:
Process/foreground: You can interactively correct transactions
that contained errors and step through transactions that have not yet been
executed.
Display errors only: This mode is like Process/foreground
except that transactions that have not yet been run and which do not contain
errors are run non-interactively.
If an error occurs, processing stops and the
screen upon which the error occurred is displayed.
Background: Use this mode to schedule a session for immediate
processing in the background processing facility.
You receive control of your terminal again as
soon as the session has been passed to the background processing system.
Note that your session is automatically
released for processing in the background processing system. You need not
explicitly release the session for processing.
A completed session is handled in one of
three ways:
The system deletes a session from the queue when it has been
successfully completed. You can check on the outcome of the session by
displaying the session log file.
If the KEEP option was set when the session was generated, then the
system leaves a session in the queue, even if it was run successfully.
The status is changed to Processed.
You cannot run a processed session a
second time. You must manually delete it when you no longer need it.
If a transaction in the session contained an error, the incorrect
transaction is aborted. All other transactions are completed. The
session remains in the queue and is held in the Errors section of
the list. You can correct the session in one of the interactive modes
and run it to completion.
A transaction contains an error if it
issues a message of type E (error) or type A (abnormal termination).
Other messages are ignored and do not affect the execution of a
session..
A session also is held in the queue in
the Errors list if the session was ended with the /bend OK code.
