B.MANAGING BATCH-INPUT SESSION.
Batch input sessions enter data non-interactively into an R/3 System. Batch input is typically used to transfer data from non-R/3 Systems to R/3 Systems or to transfer data between R/3 Systems.
This section describes how to manage batch input sessions.
To reach the main menu of the batch input system, select System --> Services --> Batch input.
Overview and Concepts
a) Task Overview: Batch Input
b) Batch Input: Concepts
Working with Batch Input Sessions
c) Processing Sessions Automatically
d) Selecting Sessions
e) Running Sessions
f) Correcting a Session
g) Deleting Sessions
h) Locking and Unlocking Sessions
i) Releasing and Restarting an Interrupted Session
Information and Analysis
j) Displaying Queue Management Information
k) Displaying Session Logs
l) Reorganizing the Log File
m) Analyzing Sessions
a) Task Overview: Batch Input.
With the functions of the batch input management system, you can do the following:
Start batch input sessions to enter data into an R/3 System.
For debugging sessions that contain errors, the batch input system offers two modes for running sessions interactively.
Schedule the background program that automatically submits sessions for processing in
the background.
Lock a session until a specified date.
Locking a session prevents it from being run.
Delete batch input sessions.
Release a session for re-execution if it has been aborted by a system failure or
shutdown while being created or executed.
Analyze a batch input session before or after it has run.
The analysis function lets you display data entered in the transactions in a session. You can:
display the screens called by the session with the session data filled in.
display listings of input fields by field name, with the session data for each field.
Display the log produced by a batch input session.
Functionally:
For help in generating sessions, please see the Basis Programming Interfaces manual.
b) Batch Input: Concepts:
Processing Sessions
A batch input session is a set of one or more calls to transactions along with the data to be processed by the transactions. The system normally executes the transactions in a session non-interactively, allowing rapid entry of bulk data into an R/3 System.
A session simulates on-line entry of transactions and data. It calls transactions and enters data using most of the facilities that are available to interactive users.
For example, the data that a session enters into transaction screens is subject to the same consistency checking as in normal interactive operation. Further, batch input sessions are subject to the user-based authorization checking that is performed by the system.
Generating Sessions
To transfer data with batch-input, the system that is sending the data uses a data transfer interface provided by an R/3 application program in the receiving system. The interface program in the application then produces a batch input session.
The interface program in an application is an ABAP/4 program that sets up the transaction calls and data that make up a session. If the batch input session contains data from an external source, the program also reformats the data to meet the requirements of the input fields in which the data is to be entered. Usually, such programs are provided by the R/3 applications. For more information, please see the documentation of the R/3 applications.
Authorizations
When a session is generated, a client and user are associated with it. If the session is run in background-processing mode, the system uses this user for authorization checking as the session runs. This authorization testing applies whether you sent the job for batch execution or the session was started by a background job.
Sessions that you process in one of the interactive modes are run with your authorizations. The interactive modes are described later in this section.
c) Processing Sessions Automatically:
In most systems, sessions are started non-interactively with a background job that periodically checks for and starts any sessions that have not yet been run. Running sessions interactively is usually reserved for testing sessions or correcting sessions.
To start batch input sessions automatically, schedule the ABAP/4 program RSBDCSUB for repeated execution. The program schedules sessions for immediate execution in the background processing system.
With RSBDCSUB, you can use all of the selection criteria offered on the batch input main menu to select sessions to run:
session name
date and time of generation
status: ready to run or held in the queue because of errors
d) Selecting Sessions:
To reach the main menu for managing batch input sessions, select System --> Service -->
Batch input. On the main menu, you can select sessions using any or all of the following criteria:
session name
date on which the session was generated (entered into the session queue)
session status
You can also select from one of two actions:
To display the session queue, select Session --> Overview.
You can start, analyze, or delete sessions in the queue.
To display session log files, select Session --> Logs.
All sessions generate a log when they are run. From the list of session logs, you can take further actions, such as analyzing a session.
The Session Queue
The information in the session queue includes the following:
Date and Time: The date and time when a session was generated (entered in the
session queue).
Locked: If a session is locked, this column shows the date upon which the system
releases the session. A locked session cannot be started.
Created by: The user who generated the session.
Tran. and Screen: The number of transactions and screens, respectively, that remain to be processed in a session.
Auth. user: The user under whose authorizations the session will be run if it is submitted for batch execution.
You can display statistics on the transactions in any session by marking the session and using the Statistics function.
Session Sorting and Status
Sessions in the session queue are sorted by date and time of generation and are grouped in different lists according to their status.
possible statuses are as follows:
not yet processed
The Tran. and Screen fields in the display show how many transactions and screens,
respectively, the session contains.
held in the session queue because of errors in transactions (Errors in sessions)
Transactions that contained errors are aborted; all correct transactions are processed.
The Tran. and Screen fields in the session display show how many incorrect
transactions were found in the session.
You can restart a session and correct the erroneous transactions with one of the interactive execution modes offered by the batch input system. For more information, please see Correcting a Session(f).
processed
For further information on a session that has been successfully run, you can display the log generated by the session. All completed sessions generate a log. You cannot run a completed session a second time.
Only sessions that were generated with the KEEP option are held in the queue after
processing. Other sessions are deleted after they are successfully completed.
in generation
You will usually see this status only if you happen to display the queue while a session is being generated (entered into the session queue).
You can also encounter this status if a system failure has interrupted the generation of a session. If you suspect that a session has been interrupted, please see Releasing and Restarting an Interrupted Session(i) for more information.
in process
You will usually see this status only if you happen to display the queue while a session is being run.
You can also encounter this status if a system failure has interrupted the execution of a session. If you suspect that a session has been interrupted, please see Releasing and Restarting an Interrupted Session(i) for more information.
e) Running Sessions:
Running a batch input session executes the transactions in the session and enters data into an R/3 System.
To start a session, select Session ® Overview from the main batch input screen. Then mark the session(s) that you wish to start and select Session ® Process or ® Process in batch.
You can start any session in the not yet processed list that is not locked. With Process/foreground or 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.
Process in Batch: Use batch mode to schedule a session for immediate processing in the batch facility.
You receive control of your terminal again as soon as the session has been passed to the batch 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 the 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. Please see Correcting a Session(f).
For more information on correcting sessions with the display-all or error-display mode, please see Correcting a Session(f).
f) Correcting a Session:
When a session is run in background-processing mode, the system marks transactions that contain errors as incorrect. All other transactions in the session are completed. The session itself is kept in the session queue in the Errors section of the list.
A transaction contains an error if it generates an error message of type E (error) or type A (abnormal termination). Messages of other types are ignored and do not affect the execution of a session.
You can correct and re-execute the incorrect transactions in an "Errors" session. There are two ways to do so:
1. Re-run the session in display-all or error-display mode. These modes offer the following advantages:
The system skips transactions that were successfully completed. Only incorrect transactions or transactions that have not been executed are run.
You can change inputs and add missing screens interactively as incorrect transactions run.
The following topic provides more information on using display-all mode or error-display mode to correct a transaction.
2. As an alternative, you can analyze the session to determine what the error was. With the analysis displays, you can check the screen that contained the error and the values that were entered in it. You can then correct the program that generated the session and regenerate the session.
You must ensure that the new session does not include transactions that were successfully completed. Otherwise, the updates made by the transactions will be performed again.
Using Display-All Mode
When you use display-all mode to re-start a session that contains an incorrect transaction, the system skips to the first screen of the incorrect transaction. Completed transactions are not re-executed.
options when you run a session interactively.
To correct a transaction, you can:
use the ENTER key to step through the screens recorded in the session
As in normal operation, pressing the ENTER key starts a dialog step. As long as you simply press ENTER, the system processes the screens and data recorded in the session.
change or add values in any screen
When you press ENTER, the system processes the data as altered by you.
branch off from the transaction flow recorded in the session
You can use any function that you wish within the transaction that is currently running. You can, for example, branch off to enter data on a screen that was omitted from the session.
To resume executing the session, return to the screen that was expected by the session.
It holds the data for the screen recorded in the session until you have returned to that screen. It then resumes normal execution of the session.
Interrupting a Session
You can interrupt the interactive execution of a session by entering the /bend OK code on any screen. /bend terminates the transaction currently being executed in the session and marks the transaction with the status Incorrect. The session is kept in the queue and is displayed in the Errors in sessions section of the list.
You can use /bend when testing sessions. For example, you may wish to run the first two transactions of a large session in display-all mode to make sure that the session has been generated correctly.
If the transactions are correct, you can then terminate the run with /bend and then submit the session for background execution. The transactions that have already been run will not be run again.
Deleting a Transaction
You can delete a transaction from a session during interactive execution by entering the /bdel OK code. The transaction is removed from the session. The deleted transaction cannot be run even if you restart the session, and you cannot take back the deletion.
The transaction is, however, available for analysis if the session was generated with the KEEP option set. The transaction is marked with the status Deleted in the analysis display. The deletion also is recorded in the log generated by the session.
g) Deleting Sessions:
You can delete any session from the session queue. Deleting a session discards the session. If the session has already been run, you also delete the session log.
Normally, sessions are deleted from the session queue automatically when they are completed. However, if a session was generated with the KEEP option, it is kept in the session queue. You must explicitly delete the session when you no longer need it.
A session is also kept in the queue if it contained an error or was broken off with the /bend OK code. Such a session is deleted when you finish processing it, unless it was generated with the KEEP option.
To delete a session from the session queue, mark the sessions to be deleted and select Edit --> Delete.
h) Locking and Unlocking Sessions:
You can lock sessions in the session queue by marking the sessions and selecting Edit ® Lock.
Locking a session prevents a session from being started until after the date recorded in the lock. For example, a session locked until the eleventh of November can be started only after that date.
You may wish to lock a session for such reasons as
holding a session until a specified date
preventing a session that contains errors from being re-started
preventing a session that requires a special resource, such as printer forms or a specific tape, from being started unintentionally.
You can unlock a session by changing the lock date to the present date or by entering a space as the lock date.
i) Releasing and Restarting an Interrupted Session:
If a system problem occurs while a session is being generated or is being run, the session is terminated abnormally. Typical causes of an abnormal termination might include shutdown of the R/3 System while a session is running or termination of a SAPGUI presentation process while a session is being run interactively.
In the session queue, a session that was terminated while it was being generated remains in the Being generated section of the list. A session that was terminated while it was running remains in the Active list.
You can recognize that a session has terminated abnormally because the status of the session does not change. If, for example, you find a session that was run the previous night still in the Active list, then it is likely that the session was interrupted.
If a session was to run in the background, you can check the status of the session's job in the background processing system. If the session was aborted, then the background job log contains the reason for the abnormal termination.
Before you can restart (or start) a session that terminated abnormally, you must release it. Releasing the aborted session sets its status to Being processed. Reset the status by marking the session or sessions and selecting Edit --> Release.
You can safely restart a session that was interrupted while it was being run. When you restart the session, all transactions that were successfully completed before the problem occurred will be skipped. The transaction that was executing when the problem occurred will be re-executed.
caution
Release an active session only if you are sure that it has been interrupted and is no longer running.. Sessions also have the status Active while they are running.
caution
Restarting after abnormal termination during generation: You can start a session that was interrupted while it was being generated. The session is guaranteed to contain only complete transactions and to be runnable.
However, there is no guarantee that the session contains all of the transactions that were to be included in it. You may therefore wish to delete and regenerate such a session.
j) Displaying Queue Management Information:
Should you ever need to review the internal queue-management information on a particular entry, you can display this information by marking an entry and selecting Analysis --> Queue.
Not all of the queue management fields displayed are used by the batch input system; the queue management functions are used by other queues in the system as well. The fields that are used by the batch input system are as follows:
Client: The client in which a session is to run.
Groupid: The session name.
QID: The internal ID of a session. The ID is used for queue management with System -> Services --> Queue.
QSTATE: A character indicating the status of the batch input session.
QERASE: If marked, indicates that the KEEP option is set. If KEEP is set, the system does not delete the session after it is successfully run.
USERID: User to be used for authorization testing if a session is submitted for background execution.
displaying Session Logs:
Every batch input session generates a log when it runs. To display a log, you can either:
select Session --> Logs from the batch input main menu; or
put the cursor on a particular session in the session queue and select Goto --> Log.
A session log contains any error messages issued by transactions in the session. It also includes batch input error messages reporting any problems in running transactions, together with the transaction and screen at which the problem occurred. Finally, a log contains a set of summary statistics.
l) Reorganizing the Log File:
You should periodically use the ABAP/4 program RSBDCREO to reorganize the batch input log file. You can run RSBDCREO in the background or interactively.
Running the program reduces the size of the log file, BI
Subscribe to:
Post Comments (Atom)
0 comments
Post a Comment