BATCH DATA COMMUNICATION

Editor's Notes

• #3: Programs can execute in the background of the SAP system while online operation is occurring. SAP’s background processing system is easy to use and completely integrated within the system. Suppose a manager wants an accounting report every Monday morning. Rather than having the manager execute this program online every Monday morning, it could be scheduled to run every Sunday night so that the report would already be printed for the manager when she arrived to work. This scheduling of a report program is accomplished with SAP’s background processing system. In this chapter, we will focus on three areas of background processing: Phases of background processing Passing data to subsequent job steps Scheduling a background job within an ABAP/4 program
• #4: The SAP R/3 Dispatcher and it’s work processes constitute the R/3 Runtime System. From the perspective of the host operating system, the R/3 Runtime System appears as a collection of parallel processes. On each application server, these parallel processes include a dispatcher and work processes, the exact number of work processes is variable and depends on the specific configuration. There are five types of work processes: Online: (or dialog) work process for executing sequential steps in business transactions Update: work process updates the database Enqueue: work process for setting and releasing locks on SAP objects Spool: work process for spool formatting Background: (or batch) work process for executing background jobs Here we will examine background processing (also called batch processing).
• #5: Background processing enables you to plan the start of ABAP/4 programs. Then, at the specified time, they are executed by special work processes called background (batch) work processes. Background processing runs are composed of jobs. A job is a sequential series of steps that can be scheduled. A step is a program for background processing.
• #6: The three phases of background processing are: Job Scheduling, Job Processing, and Job Overview. Before we cover these phases, it is important to mention that authorization objects exist for background (batch) processing: S_BTCH_ADM, S_BTCH_JOB, S_BTCH_NAM, and S_PROGRAM. Not all users will have the authority to release or manage background jobs. First, we are going to cover the Job Scheduling phase.
• #7: To schedule/create a background job, use the Define Background Job function - menu path “System Services Jobs Define Job” (or transaction “SM36”). When creating a background job, you must specify a job name. The only restriction on the name of the job is the maximum length (32 characters). You should give your job a meaningful name. For example, you can name a background job ‘Weekly Accounting Report’ if it will execute an accounting report program every week. When creating a background job, you must also specify a job class. This job class indicates the priority level of the background job (priority level A, B, or C with A being the highest priority). This priority level determines the processing order of jobs with the same start criteria. The Exec. Target is not required. Normally, you will just leave this field blank. However, if you are using an SAP system that has multiple application servers (and each of these servers has background work processes), you can specify the specific application server on which the background job should be processed. Next, you should enter the steps (i.e., programs) to be included in the background job (see next slide). To indicate these steps, click on the ‘Step’ pushbutton.
• #8: To include an ABAP/4 program in a background job, you must specify the program name and, if necessary, its variant. A variant is a set of parameter values needed for the execution of a particular program. If a program has a selection screen, it will need a variant for background processing. To create a variant, you need to execute the program and enter the appropriate values on the selection screen. Instead of executing the program, you will save these values as a variant by using the menu path “GoToVariants” in transaction se38 or create a variant through transaction se38. You need to give the variant a name and a description. This description should describe the parameter values of the variant. You will also want to change the print specifications so that the report is not sent to the printer immediately, but instead is placed in the print spool. After adding all the steps to the background job, you can indicate the start criteria for the job (see next slide).
• #9: From the initial define background job screen, click on the ‘Start condition’ pushbutton to indicate the start criteria for the background job. The options available for scheduling jobs are: Immediate - allows you to start a job immediately. Date/Time - allows you to start a job at a specific date/time. After Job - allows you to start a job provided that another job has completed. After Event - allows you to specify the event when you want your job to run. At Operation Mode - allows you to start a job when the system switches to a particular operation mode. You can schedule jobs to run at regular intervals, not just one time, by specifying a frequency.
• #11: If you specify Immediate or a specific Date/Time, a job can run at regular intervals by checking the Periodic Job option. The ‘Period Values’ pushbutton allows you to specify how often you want the job to run (e.g., daily, weekly, monthly, etc.).
• #12: The ‘After Job’ pushbutton allows you to start a job provided that another job has been completed. With this option, you must specify the name of the job that must be completed for the current job to run. If the Start status-depend. option is checked, the current job will only run if the specified job ends successfully. This option is useful in cases where the current job depends on the outcome of the specified job.
• #13: The ‘After Event’ pushbutton allows you to specify the event when you want your job to run (i.e., your job will run only when the specified event is raised/triggered). With this option, you must specify the name of the event that must be triggered. You can distinguish between different occurrences of a particular event by specifying an event parameter (this concept is covered in a later slide). If you check the Periodic Job option, a new job will run each time the specified event is raised, not just the first time. Note: Before you can schedule a job to run after an event, the appropriate event must already exist (you can use the drop-down arrow to see existing events). There are two types of events: System Events - events that are defined by SAP and triggered automatically when the system changes (e.g., SAP-defined event ‘SAP_OPMODE_SWITCH’ is triggered when the system’s operation mode changes). User Events - events that you define and trigger yourself. Create a user event with transaction “SM62”. These types of events can only be used to trigger background jobs.
• #16: System events are triggered automatically by the system; therefore, you have no control over when a job that is scheduled to run after a system event will occur. User events are not triggered automatically by the system; therefore, you control when a job that is scheduled to run after a user event will occur by raising/triggering the user event. User events can be triggered from: ABAP/4 program - use the function module ‘BP_EVENT_RAISE’ (see code above). external program - use the program SAPEVT. By “calling” the function module “BP_EVENT_RAISE” in an ABAP/4 program, you trigger an event in the background processing system and all jobs that were based upon that event are started. The only required exporting parameter is the eventid (name) of the event to raise. A job can be scheduled to wait for just a specific event to be triggered, or it can be scheduled to wait for a combination of an event and a specific event parameter. The optional eventparm exporting parameter is used for this event parameter.
• #17: Now that we have covered Job Scheduling, let’s move on to the Job Processing phase.
• #18: The Batch Scheduler initiates the start of background jobs at the specified starting time. The Dispatcher dispatches this request to the appropriate background (batch) work process. Remember: The actual processing of the job steps takes place in the work process.
• #19: To display the work processes for a particular application server, use the menu path “ Tools Administration Monitoring System Monitoring Process Overview ” (or transaction “SM50”). Notice that the application server in the above example contains one Spool (SPO), eight Online (DIA - dialog), and three Background (BTC - batch) work processes. You can see that the program SAPLTHFB is being processed in a background work process.
• #20: After a background job has been initiated, start and end modules are automatically generated. Each of these modules puts an entry into the job log. During the execution of each step in a background job, entries are made to the job log with any “MESSAGE” statements in the job’s programs or with any job-progress messages from the system. Also, “WRITE” statements within a program will create a list. Printing specifications can be determined when scheduling each job step (e.g., print list immediately or put list in print spool). Only one list is possible for each job step.
• #21: Finally, we will cover the Job Overview phase of background processing.
• #22: To get an overview of background jobs, use the Job Overview function - menu path “SystemServicesJobsJob Overview” or “GoToJob Overview” from the Job Definition screen (transaction “SM37”). In the Job Overview, you can see the status of background jobs: Scheduled - The job has been created, but it has not yet been assigned a starting date. Released - The job has been created and it has been assigned a starting date. Ready - The job is ready to be processed. Active - The job is being processed. Finished - The job has finished successfully. Cancelled - The job did not finish successfully. A job will be “cancelled” if any warning, error, or abend messages occur within one of the programs or within the system. From this Job Overview, you can manage background jobs (i.e., release, change, delete, display, etc.). You can also display the job log for a particular background job (see next slide) and view or print its spool list.
• #23: The job log of a background job will indicate when the job started, when each of the job steps started, and when the job finished. Along with the system messages indicating the progress of the job, any program messages will be displayed in the job log. In the example above: System messages: Job started Step 001 started (program....) Step 002 started (program....) Job finished Program messages: Mapping complete. 000000 records rejected … This job log is particularly useful when a background job is cancelled (see previous slide). In this case, you can find out what error caused the cancellation by examining the entries in the job log. You can determine the message class and number by looking at the Msg. ID column. For example, the “Mapping complete … ” program message is number 069 from message class ZS. With this information, you can debug the program to find out where this message is issued within the program.
• #24: Now that we have learned about the three phases of background processing, there are two other topics of importance: Passing data to subsequent job steps Scheduling a background job within an ABAP/4 program
• #25: Global ABAP/4 memory is used to pass data to subsequent job steps. Suppose the step #1 program retrieves customer information from the appropriate databases to produce a report. The step #2 program creates a sequential file with this same information. Instead of selecting off the databases again in the second program, the data can be passed from the first step to the global ABAP/4 memory and retrieved by the second program. The “EXPORT” statement is used to transfer data to global ABAP/4 memory. EXPORTing will overwrite any data that is currently in this memory. The “IMPORT” statement is used to retrieve data from global ABAP/4 memory. The global ABAP/4 memory used when EXPORTing and IMPORTing is user and session dependent. You can pass any program data objects to global ABAP/4 memory: fields, field strings, and internal tables.
• #26: The basic syntax of the “EXPORT” and “IMPORT” statements is: EXPORT <data1> … <datan> TO MEMORY [ID <id>]. IMPORT <data1> … <datan> FROM MEMORY [ID <id>]. The <data> can be any field, field string, or internal table in the program. To specify multiple <data> objects, separate them by spaces. You can use the “ID <id>” addition to specify distinct memory addresses. In this way, you can avoid overwriting data already in memory. The <id> name can be up to 32 characters The <data> objects must have the same structure (data type and length) when EXPORTing and IMPORTing. The return code (SY-SUBRC) is set to zero if the IMPORT is successful (i.e., data is found). If no data is found, SY-SUBRC will be set to a non-zero number after the IMPORT is attempted.
• #27: Background jobs can be generated within an ABAP/4 program. An ABAP/4 program generates a background job by opening a job, inserting job steps, and closing the job. These steps are accomplished by using three function modules: “JOB_OPEN”, “JOB_SUBMIT”, and “JOB_CLOSE”. In the next three slides, these function modules will be covered. Not all of their exporting and importing parameters are described. For a complete list, go to the function library (“SE37”) and display the specific function module’s import/export parameter interface. Other function modules exist for background processing: “BP_EVENT_RAISE” (trigger event), “BP_EVENT_CHECK” (check event name), “BP_JOB_COPY” (copy job), “BP_JOB_DELETE” (delete job), “BP_JOBLOG_SHOW” (display job log), “BP_LOG_READ” (read job log), and more (see SAP’s Online Help).
• #28: The “JOB_OPEN” function module opens a background job. The main exporting parameter is: Job name (jobname). To create a background job, you must give it a name. This parameter is always required. The only importing parameter is: Job number (jobcount). After the function module has executed, it returns a job number. You will need to use both the job name and the job number when calling the other two function modules (“JOB_SUBMIT” and “JOB_CLOSE”).
• #29: The “JOB_SUBMIT” function module inserts a step (i.e., program) into the job. The main exporting parameters are: User (authcknam) - User whose authorizations will be checked throughout the program. This parameter is always required. Job number (jobcount) - Job number that was returned from the “JOB_OPEN” function module. This parameter is always required. Job name (jobname) - Job name that you sent to the “JOB_OPEN” function module. This parameter is always required. Report (report) - Name of ABAP/4 report program to be executed. This parameter is required if you are adding an ABAP/4 program, not an external program, to the job. Variant (variant) - Name of variant to use with program. This parameter is required if the ABAP/4 report program has a selection screen. The “JOB_SUBMIT” function module is called for each step that is to be added to the background job. In the above example, the “JOB_SUBMIT” function module would be called twice to insert the two steps into the job. An alternative to the “JOB_SUBMIT” function module is the “SUBMIT” statement with the “VIA JOB” addition (and the “WITH” addition if there is a selection screen). For more information, see SAP’s ABAP/4 Programming Language Help for “SUBMIT”.
• #30: The “JOB_CLOSE” function module closes the job. Once you close a background job, you cannot add any more steps to it with the “JOB_SUBMIT” function module or the “SUBMIT” statement. The main exporting parameters are: Job number (jobcount) - Job number that was returned from the “JOB_OPEN” function module. This parameter is always required. Job name (jobname) - Job name that you sent to the “JOB_OPEN” and “JOB_SUBMIT” function modules. This parameter is always required. Start date (sdlstrtdt) and Start time (sdlstrttm) - Start date/time for job. These parameters are required if you want the job to execute on a particular date and time Start immediately (strtimmed) - Start immediately flag. This parameter is required if you want the job to be processed immediately (strtimmed = ‘X’). Other exporting parameters exist to start the job after another job or after an event. Also, you can indicate the frequency of a job. The only importing parameter is: Job released (job_was_released) - Job released flag. After the function module has executed, it returns a flag indicating whether the job was released. If it was, the parameter returned is an ‘X’.
• #31: This example shows how a background job can be generated within an ABAP/4 program. The job name, program, variant, and user are entered as parameters. When the above program is executed, a background job is created without a start date/time (i.e., the job has been scheduled but not released). Notice the data declaration section in the example program: The job number variable is like the structure field TBTCJOB-JOBCOUNT. The job name variable is like the structure field TBTCJOB-JOBNAME. The report variable is like the structure field SY-REPID. The variant variable is like the structure field RALDB-VARIANT. The user variable is like the structure field SY-UNAME (it could also be like the structure field TBTCJOB-AUTHCKNAM).
• #32: The three phases of background processing are: Job Scheduling, Job Processing, and Job Overview. In Job Scheduling, you indicate which steps (programs) make up the job. Also, you can specify the job’s starting criteria. You can schedule a job with the Define Background Job function (“SM36”) or within an ABAP/4 program using “JOB_OPEN”, “JOB_SUBMIT”, and “JOB_CLOSE”. In Job Processing, the background job is processed by the system. The Batch Scheduler initiates the start of background jobs and the Dispatcher dispatches the request to the appropriate background work process. In Job Overview, you can see the status of background jobs, manage jobs, and display the job log and spool list. You can review a job with the Job Overview function (“SM37”). For more information on background processing, see SAP’s Online Help (HelpR/3 LibraryContentsBasis ComponentsBasis Programming InterfacesProgramming with the Background Processing System).
• #34: The SAP system is comprised of three distinct layers: Database - The database system resides on this layer. Application (operating system) - The main processing takes place on this layer (e.g., ABAP/4 programs run on this layer). Presentation - The “front end” to the SAP system (i.e., SAPGUI) resides on this layer. These three layers can be arranged in many technical architectures. For the remainder of this section, we will assume that these three layers reside on separate computers (called “servers”). Here we will learn how to process sequential files on an application server. These files are called “datasets”. The concept of processing sequential files is important because these files are used to transfer data between an SAP system and an external system.
• #35: “Processing” a file refers to either creating a file or reading a file. Before a sequential file can be processed, it must be opened. At most, six files can be open at the same time in each session. After a sequential file has been processed, it must be closed. In the following slides, we will learn the ABAP/4 statements dealing with sequential files on the application server. Each of these statements needs to have a file name specified. This file name includes the full directory path and file name. In many operating systems, this file name is case sensitive (e.g., UNIX). An example file name in UNIX is ‘/tmp/bc180_file1’.
• #36: To open a sequential file on the application server, use the “OPEN DATASET” statement. The basic syntax of this statement is: OPEN DATASET <file name> [options]. Many options exist when opening a file: Use the “FOR” options to specify the access mode: FOR INPUT (default) opens an existing file for reading. FOR OUTPUT opens a file for writing. If the file does not exist, it is created. If the file already exists, its contents are deleted. FOR APPENDING opens a file for writing. If the file does not exist, it is created. If the file already exists, the system goes to the end of the file to add to it. Use the “IN” options to specify the structure of the file: IN BINARY MODE (default) indicates that the file is not structured in lines (i.e., it is set up byte-by-byte). IN TEXT MODE indicates that the file is structured in lines. The last page of this chapter details these two modes and their effect on processing sequential files. If you use the “MESSAGE <field>” addition, a system message issued when opening the file will be placed in the character-type <field>. The “AT POSITION <position>” addition opens the file at a specific <position>, indicated in bytes from the beginning of the file. If a file is opened successfully, SY-SUBRC will be 0; otherwise, it will be 8.
• #37: To close a sequential file on the application server, use the “CLOSE DATASET” statement. The basic syntax of this statement is: CLOSE DATASET <file name>. A file is implicitly closed: at the end of a program when a screen changes To delete a sequential file on the application server, use the “DELETE DATASET” statement. The basic syntax of this statement is: DELETE DATASET <file name>. If a file is successfully deleted, SY-SUBRC will be 0.
• #38: To write to a sequential file on the application server, use the “TRANSFER” statement. The basic syntax of this statement is: TRANSFER <field string> TO <file name>. The <field string> is the structure that is transferred to the file, either as a record or character-by-character. An error on the transfer results in an abnormal termination of the program. To read a sequential file on the application server, use the “READ DATASET” statement. The basic syntax of this statement is: READ DATASET <file name> INTO <field string>. If the file is set up in lines, a record of the file is read into the <field string>. If the record is longer than the <field string>, the record is truncated. If the record is shorter than the <field string>, the <field string> is padded with spaces. On the next read, the next record is read into the <field string>. If the file is not set up in lines, the length of the <field string> determines how many characters are read from the file. On the next read, the system starts with the next character and again reads as many characters as can fill the <field string>. If a record (or character) is found, SY-SUBRC is set to 0. If a record (or character) is not found (i.e., the end of the file was reached on the last read), SY-SUBRC is set to 4.
• #39: To create a new sequential file on the application server, perform the following steps in an ABAP/4 program: Step #1:Define the field string to be transferred to the file. Step #2:Open the file “FOR OUTPUT”. If the file already exists, its contents will be deleted. Step #3:Populate the field string. Step #4:Transfer the contents of the field string to the file. Step #5:Close the file. In the example above, we are creating a file with customer information. Specifically, we are transferring the customer number, state, and telephone number (for all customers in a particular state) from the KNA1 table to the ‘/tmp/bc180_file1’ file on the application server. The file name is entered as a parameter. By default, all parameter values are capitalized by the system. Because this file name may be case sensitive, we do want the file name capitalized. The “LOWER CASE” addition to the “PARAMETERS” statement will “turn off” this automatic capitalization. This addition does not mean that all characters will be converted to lower case; instead, it means that the characters will remain as typed by the user.
• #40: To extend an existing sequential file on the application server, the only difference to the previous example is in step #2. Instead of opening the file “FOR OUTPUT”, open it “FOR APPENDING”. If the file does not exist, the “FOR APPENDING” option acts like the “FOR OUTPUT” option and a new file is created.
• #41: To read an existing sequential file on the application server, perform the following steps in an ABAP/4 program: Step #1:Define the field string in which the file’s records will be read. The structure of the field string should match the structure of the file’s records. Step #2:Open the file “FOR INPUT”. If the file does not exist, an error will occur. Step #3:Read a record from the file into the field string. To read the complete file, you must code the “READ DATASET” statement in a DO loop. Step #4:Code a way out (EXIT) of the DO loop. If SY-SUBRC is not 0, the end of the file has already been reached. Step #5:Close the file. In the example above, we are reading the file ‘/tmp/bc180_file1’ we created in the previous two examples. This particular example creates a report with the contents of the file.
• #42: To determine whether to open a file “IN TEXT MODE” or “IN BINARY MODE”, you need to know how the file is structured. If the file is structured in lines (or records), open it “IN TEXT MODE”. If the file is structured byte-by-byte, open it “IN BINARY MODE”. These two structure modes affect the processing of sequential files. With the “TRANSFER” statement: If you transfer a field string to a file opened “IN TEXT MODE”, the whole field string will be transferred and the system will “mark” the end of the line. On the next transfer, the system will start at the next line. If you transfer a field string to a file opened “IN BINARY MODE”, the whole field string will be transferred. On the next transfer, the system will start at the next character position. With the “READ DATASET” statement (see example above): If you read from a file opened “IN TEXT MODE”, one record of the file will be read into the field string. If the record is shorter than the field string, the field string is padded with spaces. If the record is longer than the field string, the record is truncated. On the next read, the next record is read into the field string. If you read from a file opened “IN BINARY MODE”, the length of the field string determines how many characters are read. On the next read, the system starts with the next character and again reads as many characters as can fill the field string.
• #44: In the previous chapter, we learned how to process sequential files on an application server with the “OPEN DATASET”, “TRANSFER”, “READ DATASET”, “CLOSE DATASET”, and “DELETE DATASET” statements. In this chapter, we will learn how to process sequential files on a presentation server. These files are called “local files”.
• #45: To create a local file, the contents of an internal table are transferred to the file. To read a local file, the contents of the file are read into an internal table.
• #46: To create a local file, use the “DOWNLOAD” function module. The only required parameter in the “DOWNLOAD” function module is the “DATA_TAB” internal table whose contents will be transferred to the local file. When this function module is executed, the system displays a dialog box requesting the file name and the file type (or format). To have values defaulted in these two fields, use the “FILENAME” and “FILETYPE” exporting parameters. If you do not want the user to be able to enter the file name or file type (i.e., you do not want the dialog box displayed), use the “WS_DOWNLOAD” function module. With this function module, the “FILENAME” parameter is required, along with the “DATA_TAB” internal table parameter. The following file types are available: ASC - ASCII files BIN - Binary files DAT - Excel spreadsheet files WK1 - Lotus and Excel spreadsheet files The “MODE” exporting parameter can be used to specify the write mode: ‘ ’ (blank) for overwrite mode (i.e., create a new local file). This is the default. ‘A’ for appending mode (i.e., extend an existing local file). The list of exporting and importing parameters above is not a complete list. See SAP’s online help for all of these parameters.
• #47: To create a local file, perform the following steps in an ABAP/4 program: Step #1:Define the internal table to be transferred to the file. Step #2:Populate the internal table. Step #3:Call the “DOWNLOAD” function module. In the example above, we are creating a file with customer information. Specifically, we are transferring the customer number, state, and telephone number (for all customers in a particular state) from the KNA1 table to the ‘c:c180_file2’ file on the presentation server.
• #48: To read a local file, use the “UPLOAD” function module. The only required parameter in the “UPLOAD” function module is the “DATA_TAB” internal table. The contents of the file will be uploaded into this internal table. When this function module is executed, the system displays a dialog box requesting the file name and the file type. To have values defaulted in these two fields, use the “FILENAME” and “FILETYPE” exporting parameters. If you do not want the user to be able to enter the file name or file type (i.e., you do not want the dialog box displayed), use the “WS_UPLOAD” function module. With this function module, the “FILENAME” parameter is required, along with the “DATA_TAB” internal table parameter. The file types available for uploading are the same as those available for downloading: ASC, BIN, DAT, and WK1. The list of exporting and importing parameters above is not a complete list. See SAP’s online help for all of these parameters.
• #49: To create a local file, perform the following steps in an ABAP/4 program: Step #1:Define the internal table to be transferred to the file. The structure of the internal table should match the structure of the file’s records. Step #2:Call the “UPLOAD” function module. Step #3:Process the internal table. In the example above, we are reading the file ‘c:c180_file2’ we created in the previous example. This particular example creates a report with the contents of the local file.
• #50: SAP has provided an easy way to download and upload ABAP/4 source code to/from a local file. To download an ABAP/4 program to a local file, use the “Utilities  More Utilities  Upload/Download  Download” menu path when you are displaying or editing a program in the ABAP/4 Editor. A dialog box will request the name of the local file you wish to create and the file format. To upload a local file into an ABAP/4 program, use the “Utilities More Utilities  Upload/Download  Upload” menu path when you are editing a program in the ABAP/4 Editor. A dialog box will request the name of the local file to upload and thefile format. Be careful using this function because uploading a local file into an ABAP/4 program will overwrite any existing code.
• #52: In the remaining chapters, we will learn the batch input procedure. Batch input is used to transfer large amounts of data into the SAP system. In this chapter, we will learn the basics of batch input. When transferring data into the SAP system, we can refer to two types of transfers: Conversions - This type of transfer refers to a one-time transfer from a legacy system to the SAP system. In this case, the “legacy” system is the old system that is being replaced by the SAP system. For example, the old system being replaced has data for 2,000 vendors that must be transferred to the SAP system. Interfaces - This type of transfer refers to an ongoing transfer from a complimentary system to the SAP system. In this case, the “complimentary” system is a system that will run along side the SAP system. For example, customer orders may be taken in another system. For the SAP system to reflect accurate information, these orders must be transferred to the SAP system every night. Batch input is also referred to as BDC (Batch Data Communication).
• #53: Batch input is used to transfer large amounts of data into the SAP system. The external data should not be transferred directly into the SAP database tables; instead the data should be checked and validated before being transferred into the SAP system.
• #54: Data passes through checks and validations when a user enters the data online through a transaction (i.e., an online program). Automatic checks are performed on each screen of an online program: Required fields Proper formats Foreign key values Valid values The checks programmed into the online program are also performed on the data as the transaction progresses. To ensure that data passes through these checks during batch input, you must simulate the user dialog by passing the data through an online program.
• #55: To simulate user dialog (i.e., to pass data through an online program), you must know the following information: Online program name Screen numbers Field names Field values When you code a batch input program, the “BDCDATA” ABAP/4 Dictionary structure is used to collect this information. The “BDCDATA” structure includes the following fields: PROGRAM [CHAR 8] - Online program name. DYNPRO [NUMC 4] - Screen number. DYNBEGIN [CHAR 1] - Flag to indicate the start of a new screen. FNAM [CHAR 35] - Field name of a screen field to be filled with data. FVAL [CHAR 80] - The actual value to be filled into the specified screen field. To collect this information for an entire transaction, the “BDCDATA” structure will be used to create an internal table in the batch input program.
• #56: To demonstrate the use of the “BDCDATA” structure, we will work through a “change vendor” example. Ultimately, we want to perform batch input to change already existing vendor records. Specifically, we will add a street address to each vendor. Before coding a batch input program, you must research the appropriate transaction. This research consists of determining the online program name, screen numbers, and field names for the entire transaction. In our example, this transaction would be the “Change Vendor” transaction. This transaction can be accessed via the menu path “Accounting Financial Accounting Accounts Payable Master records Change” (or transaction code “FK02”).
• #57: When you come to the first screen of the transaction to research, perform the following steps: Step #1: Use the “System Status” menu path to determine the online program name, the screen number, and, if unknown, the transaction code. In our example, the online program name is “SAPMF02K”, the screen number is “0106”, and the transaction code is “FK02”. Step #2: In each screen field that you want to fill with data, determine the field name by placing the cursor in the field and pressing the ‘F1’ key. When the ‘Help’ dialog box pops up, click on the “Technical info” pushbutton. On the ‘Technical Info’ dialog box, the field labeled “Field description for batch input” will give the appropriate field name. In our example, we will need to fill the vendor number field with an already existing vendor. This field name is “RF02K-LIFNR”. We will also have to check the address check box. This field name is “RF02K-D0110”. Step #3: Determine how to proceed in the transaction. The “command field” of each screen is used to capture the user’s actions (e.g., clicking on a pushbutton or pressing a function key). The field name for this “command field” is “BDC_OKCODE”. In our example, we can press the ‘Enter’ key to move on to the next screen. This action does not require a value in the “command field”. We could use a “/00” value in the “BDC_OKCODE” field, but it is not necessary.
• #58: When you come to the next screen of the transaction, perform the following steps: Step #1: Use the “System > Status” menu path to determine the online program name and the screen number. The online program name will not always be the same throughout a transaction. In our example, the online program name is “SAPMF02K” again and the screen number is “0110”. Step #2: In each screen field that you want to fill with data, determine the field name by placing the cursor in the field and pressing the ‘F1’ key. When the ‘Help’ dialog box pops up, click on the “Technical info” pushbutton. On the ‘Technical Info’ dialog box, the field labeled “Field description for batch input” will give the appropriate field name. In our example, we will need to fill the street field. This field name is “LFA1-STRAS”. Step #3: Determine how to proceed in the transaction. In our example, we want to save the record. We can click on the ‘Save’ pushbutton or press the ‘F11’ key to save the record. In the “command field” of a screen, we can use a forward slash (“/”) followed by the function key number to mimic pressing a function key. In our example, we will use a “/11” in the “command field” to save the record. Remember that this command field is referenced with the “BDC_OKCODE” field name.
• #59: Once you have researched the transaction completely, you can determine the contents of the “BDC table”. This BDC table is an internal table created in a batch input program to collect the relevant screen information for an entire transaction. It must be created “LIKE BDCDATA”. The BDC table is filled using the following rules: For each new screen encountered in a transaction, you must indicate the online program name, screen number, and new screen flag (i.e., an ‘X’ in DYNBEGIN). This information is one entry in the internal table. Even if no fields will be filled on the screen, it must be referenced. On each screen, you list the field names to be filled and their appropriate values. In this case, DYNBEGIN cannot be an ‘X’. Each field’s information is one entry in the internal table. The graphic above shows the contents of the BDC table for our example: For our simple example, we will only change one vendor. This vendor’s number is “TEST1” and it will be placed in the “RF02K-LIFNR” field on screen “0106”. On screen “0106”, we also have to check the address check box. We check this box by placing an “X” in the check box field “RF02K-D0110”. On screen “0110”, we will place the address “123 Main St.” in the address field “LFA1-STRAS”. Because pressing the ‘F11’ key on screen “0110” can be used to save the record, we will place a “/11” value in the “BDC_OKCODE” field.
• #60: Once you have determined the contents of the BDC table, you can begin coding the batch input program. In a batch input program, you must declare the BDC table as an internal table with the following statement: DATA: <bdc table> LIKE BDCDATA OCCURS <n> [WITH HEADER LINE]. The <bdc table> must be declared “LIKE BDCDATA”. After determining the contents of the <bdc table> (see previous page), you can determine the number <n> in the “OCCURS” clause. This internal table does not have to be created with a header line. However, all of our examples and solutions will use a header line with the BDC table. Once you have declared the BDC table, you can fill it with the appropriate values for one transaction at a time. In the next two slides, we will cover two methods that can be used to fill the BDC table.
• #61: To fill the BDC table, perform the following steps: Step #1: Delete all table entries with the “REFRESH” statement. This statement becomes important when we use the BDC table for multiple records. The BDC table can only hold information for one transaction at a time; therefore, it must be cleared out before a new transaction is being entered into it. Step #2: Initialize the header line (or staging area) with the “CLEAR” statement. This statement is important because you do not want an old entry’s information carried over to the next entry. Specifically, you do not want the “X” in DYNBEGIN carried over to other entries. Step #3: Fill the header line (or staging area) with the appropriate information. For a “new screen” entry, fill the PROGRAM, DYNPRO, and DYNBEGIN fields. For a “field” entry, fill the FNAM and FVAL fields. Step #4: Append the header line (or staging area) to the internal table with the “APPEND” statement. Step #5: Repeat steps 2 through 4 for each entry entered into the BDC table. The subroutine above performs these steps for our example (assume that this subroutine is “called” from the “START-OF-SELECTION” event).
• #62: The previous page shows the one-subroutine method for filling the BDC table. The two-subroutine method shown above is preferable because the second subroutine is reusable throughout all batch input programs. The two-subroutine method uses the same steps listed on the previous page. The first subroutine deletes all table entries. Then, this first subroutine “calls” the second subroutine for each entry to be entered into the BDC table. Each time this second subroutine is “called”, it is sent three variables. The first one (FLAG) indicates whether the entry is for a new screen (FLAG = ‘1’) or new field (FLAG = ‘ ’). If the entry is for a new screen, the other two variables will be the online program name (VAR1) and screen number (VAR2). If the entry is for a new field, the other two variables will be the field name (VAR1) and field value (VAR2). In the second subroutine, the first line of code clears out the header line (or staging area). The “IF” statement in the second subroutine fills the appropriate header line (or staging area) fields based on the flag. The last line of code in the second subroutine appends the header line (or staging area) to the internal table. In the example above, how many times will the “POPULATE_BDC_TAB” subroutine be executed? __________
• #63: So far, we have only filled the BDC table. We have not actually performed batch input to update an SAP database. In a batch input program, the contents of the BDC table can be used three ways to perform batch input: Use the BDC table to create a batch input session. In this case, the batch input program is often called a BDC program. Use the BDC table in a “CALL TRANSACTION USING” statement. Use the BDC table in a “CALL DIALOG” statement. In the next two chapters, we will cover the method of creating a batch input session. In Chapter 7, we will cover the other two batch input methods.
• #65: In this chapter, we will cover the batch input method to create a batch input session. In this case, the batch input program is often called a BDC program. With this method, the execution of the batch input program only creates a batch input session; it does not update the SAP database. The transaction data entered into the BDC table is inserted in the batch input session. Processing (or executing) this batch input session updates the SAP database. Batch input sessions are collected and maintained by the system in the “batch input queue” (also called the “queue file”).
• #66: In a BDC program, you create a batch input session. To create a batch input session, you must: Open the batch input session with the “BDC_OPEN_GROUP” function module. Insert transaction data (collected in the BDC table) into the batch input session with the “BDC_INSERT” function module. This subroutine is “called” for each transaction entered into the batch input session. Close the batch input session with the “BDC_CLOSE_GROUP” function module. The next three slides cover these function modules in detail.
• #67: The “BDC_OPEN_GROUP” function module opens a batch input session. The main exporting parameters are: Client - The client in which the batch input session is to be processed. The default is the client in which the BDC program was executed. Group (required) - The name of the batch input session. This name does not have to be unique. Holddate - The batch input session cannot be processed until this “lock date”. The default is no date, so the batch input session can be processed immediately. Keep - Flag to indicate whether the batch input session should be kept (‘X’) or deleted (‘ ’) after successful processing. The default is to delete the batch input session. User (required) - User whose authorizations will be checked if the batch input session is processed in the background.
• #68: The “BDC_INSERT” function module inserts transaction data into a batch input session. The only exporting parameter is: Tcode (required) - The transaction code that is to be executed. In other words, the information in the BDC table refers to this transaction. The only tables parameter is: Dynprotab (required) - The BDC table with the transaction data. The “BDC_INSERT” function module is “called” for each transaction entered into the batch input session. In our simple example where we update one vendor, we will only “call” this function module once. In a more realistic example where we will read multiple records from a sequential file, we will “call” this function module for each record. A batch input session can include data for different transactions. The “TCODE” parameter indicates the appropriate transaction code. The BDC table contents must mimic the transaction code specified or an error will occur when the batch input session is processed. For example, if you read vendor information from a sequential file, you will use the “Change Vendor” transaction (“FK02”) if the vendor already exists or the “Create Vendor” transaction (“FK01”) if the vendor does not exist. The BDC table for each of these transactions will be different because different screens are encountered and different fields must be filled.
• #69: The “BDC_CLOSE_GROUP” function module closes a batch input session. There are no parameters for this function module, only exceptions. In both the “BDC_CLOSE_GROUP” and “BDC_INSERT” function modules, the batch input session name is not specified. This fact indicates that only one batch input session can be open at any given time. Depending on the number of records to be processed, you may want to split the records into multiple batch input sessions. In this case, you would close one batch input session and then open a new one before entering more transaction data.
• #70: A batch input session is comprised of two sections: The heading section consists of general information about the batch input session. This information is contained in the APQI table. This general information includes: The creator of the batch input session The creation date Parameters specified in the “BDC_OPEN_GROUP” function module: Client Session name Authorization user Hold date Keep or delete flag The data section consists of the transaction data. Information about this transaction data is contained in the APQD table.
• #71: We will continue our example from the previous chapter to create a batch input session. Recall that we are using the “Change Vendor” transaction (“FK02”) to update one vendor’s record (“TEST1”) by adding a street address (“123 Main St.”).
• #72: To create a batch input session, perform the following steps in a BDC program: Step #1: Create the BDC table. This internal table must be declared “LIKE BDCDATA”. These steps are continued on the next page. If you create a variable or constant for the batch input session name, it must be declared “LIKE APQI-GROUPID”; otherwise, you will encounter an error when the “BDC_OPEN_GROUP” function module is executed. Executing the program creates a batch input session. We have to process the session to update the SAP database. Use the “SystemServices Batch input Sessions” menu path to process batch input sessions (we will cover this topic in greater detail in the next chapter).
• #73: Steps to create a batch input session (continued from previous page): Step #2: Open the batch input session by calling the “BDC_OPEN_GROUP” function module. Step #3: Fill the BDC table with the appropriate data for the transaction (see next page). We learned how to fill the BDC table in the previous chapter. Step #4: Insert a transaction’s data (from the BDC table) into the batch input session by calling the “BDC_INSERT” function module. Step #5: Close the batch input session by calling the “BDC_CLOSE_GROUP” function module.
• #74: The two subroutines above are used to fill the BDC table. These two subroutines are executed just before the BDC table’s contents are inserted into the batch input session. You should get in the habit of using this two-subroutine method of filling the BDC table. For this simple example and others we will cover, it might seem harder and longer to use this two-subroutine method. However, when you code a more complicated batch input program (i.e., one that involves many screens and many fields), you will notice a time savings and increased maintainability by using the two-subroutine method. It is also a good habit to put comments on each entry entered into the BDC table. For example: PERFORM POPULATE_BDC_TAB USING: ‘1’‘SAPMF02K’‘0106’“initial screen of change vendor ‘ ’‘RF02K-LIFNR’‘TEST1’“vendor number field ‘ ’‘RF02K-D0110’‘X’“address check box ‘1’‘SAPMF02K’‘0110’“address screen of change vendor ‘ ’‘LFA1-STRAS’‘123…’“street address field ‘ ’‘BDC_OKCODE’‘/11’“save the record
• #75: The next example we will cover is more realistic to what you will be doing in the “real world”. You would never code a BDC program to update one record – it would be faster to manually go through the transaction online. In this example, we will read vendor records from a sequential file on the application server. Let’s assume that we are on an SAP project. ABC Inc. is the client installing SAP. Our project manager has just informed us that ABC Inc. has a sequential file with vendor information that must be updated in the new SAP system (we have already inserted vendors into the system via batch input). This sequential file is located on the application server. We must determine the format of the sequential file (see next page).
• #76: The sequential file on the application server (‘/tmp/bc180_file3’) is set up in lines (or records). This fact determines that we will open the file “IN TEXT MODE”. Each record on the file has two fields. These two fields have the following formats: <Field1> LIKE LFA1-LIFNR <Field2> LIKE LFA1-STRAS Once we determine the fields coming from the file, we can research the appropriate transaction. We have already performed this research in the previous chapter, so we’ll skip ahead to coding the BDC program (see next page).
• #77: To create a batch input session with multiple records from a sequential file on the application server, perform the following steps in a BDC program: Step #1: Create the BDC table. This internal table must be declared “LIKE BDCDATA”. Step #2: Define the field string in which the file’s records will be read. The structure of the field string should match the structure of the file’s records. These steps are continued on the next page. If you create a variable or constant for the batch input session name, it must be declared “LIKE APQI-GROUPID”; otherwise, you will encounter an error when the “BDC_OPEN_GROUP” function module is executed. Executing this program creates a batch input session. We have to process the session to update the SAP database. Use the “System Services Batch input Sessions” menu path to process batch input sessions (we will cover this topic in greater detail in the next chapter).
• #78: Steps to create a batch input session with multiple records from a sequential file on the application server (continued from previous page): Step #3: Open the file “FOR INPUT”. Step #4: Open the batch input session by calling the “BDC_OPEN_GROUP” function module. Step #5: Read a record from the file into the field string. To read the complete file, you must code the “READ DATASET” statement in a DO loop. Step #6: Code a way out (EXIT) of the DO loop. If SY-SUBRC is not 0, the end of the file has already been reached. Step #7: Fill the BDC table with the appropriate data for the transaction (see next page). This step will be executed for each record in the sequential file. We learned how to fill the BDC table in the previous chapter. Step #8: Insert a transaction’s data (from the BDC table) into the batch input session by calling the “BDC_INSERT” function module. This step will be executed for each record in the sequential file. Step #9: Close the batch input session by calling the “BDC_CLOSE_GROUP” function module. Step #10: Close the file.
• #79: The two subroutines above are used to fill the BDC table. These two subroutines are executed just before the BDC table’s contents are inserted into the batchinput session. The main difference in this example and our previous one-vendor example is the values used to fill the vendor number and street address fields. In our previous example, these values were hard-coded as ‘TEST1’ and ‘123 Main St.’. Because we are now reading this information from a sequential file, the values change for each vendor and cannot be hard-coded. In this case, we will use the values read into the “INREC” field string for each record. When we learned how to fill the BDC table, the first step was to delete all table entries with the “REFRESH” statement. This action is important now because the “FILL_BDC_TAB” subroutine will be executed for each record. Without the “REFRESH” statement, the BDC table contents would be accumulating with each new record and the same transaction data would be inserted into the batch input session multiple times. There is no difference in the second subroutine.
• #80: Throughout the last two chapters we have learned the basics of batch input and one batch input method – to create a batch input session. In the last chapter, we learned how to research a transaction and fill the BDC table. This process will be used for all batch input methods. In this chapter, we learned how to code a BDC program to create a batch input session. An important point to remember is that executing a BDC program does not update the SAP database; instead, it creates a batch input session. The SAP database is updated when the batch input session is processed. We will cover the topic of processing batch input sessions in the next chapter.
• #82: In the previous chapter, we learned how to create a batch input session using the “BDC_OPEN_GROUP”, “BDC_INSERT”, and “BDC_CLOSE_GROUP” function modules within a BDC program. The execution of this BDC program does not update the SAP database. In this chapter, we will learn how to update the SAP database by processing the batch input session. You can use two methods to process batch input sessions: Manually process batch input sessions in the Session Overview Execute program “RSBDCSUB”
• #83: One way to process a batch input session is to go to the Session Overview function with: “ System Services Batch input Sessions” menu path Transaction code “SM35” On the initial screen of the Session Overview, you can specify search criteria for the batch input sessions to find. On the main screen of the Session Overview (shown above), you will see a display of the batch input sessions that meet the search criteria. From this screen, you can process a batch input session by selecting it and clicking on the ‘Process’ pushbutton (or double-clicking on the batch input session).
• #84: To process a batch input session, you must choose one of three processing modes: In the “foreground” processing mode, all the screens will be displayed with the appropriate fields filled in as if you are executing the transactions online. In this mode, you can edit the fields on each screen. This mode is the best for initial testing. The authorizations of the user processing the session are checked. In the “display errors only” processing mode, a screen is only displayed if an error or abend message is issued on the screen. In this mode, you can edit the fields on each screen that is displayed. The authorizations of the user processing the session are checked. In the “background” processing mode, the session is sent to be processed in the background processing system (i.e., no screens are displayed). In this mode, a background job is created with the name of the session. The authorizations of the user specified in the “BDC_OPEN_GROUP” function module are checked. The “foreground” and “display errors only” modes are considered “interactive” processing modes. The update mode when processing batch input sessions is synchronous, no matter what processing mode is used. Synchronous updating means that an update is completed for one transaction before processing continues to the next transaction in the batch input session.
• #86: If you process a batch input session with one of the interactive processing modes (“foreground” or “display errors only”), you have many processing options when stopped on a screen. To access these options, you can: Use the “System Services Batch input” menu path options Enter the appropriate code in the “command field” of the standard toolbar These menu path options (and codes) include: Delete transaction (/bdel) - This option deletes the current transaction from the batch input session. Next transaction (/n) - This option skips the current transaction and moves on to the next one in the batch input session. The current transaction is not deleted from the batch input session. Process/foreground (/bda) - This option switches from the “display errors only” to the “foreground” processing mode. You must be stopped on a screen to use this option in the “display errors only” mode. Display errors only (/bde) - This options switches from the “foreground” to the “display errors only” processing mode. Cancel (/bend) - This option cancels the batch input session (i.e., skips all the transactions without deleting them). At the conclusion of all batch input sessions, you will always see the same information message: “Batch input processing terminated”.
• #87: In the Session Overview, you can use any of the following pushbuttons: Process This pushbutton allows you to process the selected batch input session in any one of the three modes listed on page 3. Delete This pushbutton allows you to delete a batch input session (or block). Session This pushbutton allows you to display transaction information for a batch input session. Statistics This pushbutton allows you to display the general statistics (e.g., number of transactions processed, deleted, in error, or still to be processed) of a batch input session. Log This pushbutton allows you to display the log generated after a batch input session has been processed, either successfully or with errors. In the Session Overview, you can also print batch input session contents, record batch input sessions and lock/unlock batch input sessions.
• #88: A batch input session can have any one of the following six statuses : Sessions still to be processed These sessions can be processed in any one of the three methods listed on page 3. Incorrect (sessions processed with errors) An error or abend message issued on any screen of any transaction in the batch input session will cause the session to be marked as incorrect. Using the “next transaction” (/n) or “cancel” (/bend) options when processing a session will also result in a session with errors. These sessions can be processed in any one of the three methods listed on page 3. Sessions processed successfully These sessions have been processed completely without any errors and the “keep” parameter of the “BDC_OPEN_GROUP” function module was flagged (KEEP = ‘X’). Background (batch) sessions These sessions processed in the background processing system. A background job is created with the name of the session. Sessions being processed These sessions are currently being processed. Sessions being created These sessions are currently being created.
• #89: A log exists for sessions processed successfully or sessions with errors. Select a batch input session with one of these statuses and click on the ‘Log’ pushbutton to display the session’s log. The Session Log will display all messages issued during each transaction. Also, the log’s messages will indicate the start of session processing, the end of session processing, and the session statistics. The message section of the log indicates the message type, message class, message number, and message text. A batch input session’s log can be used to analyze a session and determine why and where errors occurred in processing the session. Another area that can be used to analyze a batch input session is the Session Analysis section (see next page).
• #90: Sessions with any status contain a Session Analysis section. Select a batch input session and click on the ‘Session’ pushbutton to go to this section: Transactions Status of transactions A blank indicates that the transaction is still to be processed. Processed indicates that the transaction has been processed successfully. Incorrect indicates that an error or abend message was issued during the transaction. A transaction will also be incorrect if the “next transaction” (/n) or “cancel” (/bend) options were used when the transaction was processed. Deleted indicates that the transaction was deleted during the processing of the batch input session with “delete transaction” (/bdel). Screens of each transaction You can select a screen and click on the ‘Data’ pushbutton to view the details of each field and value. Double-clicking on a screen will take you to a graphical representation of the screen with the appropriate fields filled. Use the ‘Log’ pushbutton to display the session’s log. To correct a batch input session, you can correct the BDC program and re-execute it or process the error session interactively and make the changes online. Your decision may depend on how many transactions had errors.
• #91: When dealing with batch input sessions, there is a timing issue involving the creation of a batch input session and the processing of a batch input session. The “creation” and “processing” of batch input sessions are distinct actions; therefore, they occur at different times. Between the time a batch input session is created and the time it is processed, changes may have been made to the SAP database. These changes may result in errors when processing the batch input session. For example, a BDC program creates a batch input session to insert 1000 customers into the SAP database. Before the session is processed, an online user inserts 50 of these customers. When the batch input session is finally processed, these 50 customers will result in errors because they cannot be inserted into the SAP database more than once.
• #92: Using the Session Overview is one method to processing batch input sessions. Another method is to execute the program “RSBDCSUB”. Program “RSBDCSUB” schedules a session to be processed in the background. When this program is executed, a parameter screen prompts you for the session name. Remember that batch input sessions can have the same name. This program schedules all sessions with the specified name to be processed in the background. On the parameter screen, you can also determine which types of sessions with the specified name should be executed: sessions still to be processed, sessions with errors, or both. You can schedule this program to be executed in the background (a variant will be needed for the parameter screen) or you can execute this program from within another program with the “SUBMIT” statement. For example, this program could be executed at the end of a successful BDC program using the “SUBMIT” statement. This execution would minimize the timing issue described on the previous page. See online help for details on the “SUBMIT” statement.
• #96: In a batch input program, the contents of the BDC table can be used three ways to perform the data transfer to the SAP system: Use the BDC table to create a batch input session. In this case, the batch input program is often called a BDC program. Use the BDC table in a “CALL TRANSACTION USING” statement. Use the BDC table in a “CALL DIALOG” statement. In chapter 5, we covered the first method – creating a batch input session with the contents of the BDC table. In this chapter, we will cover the other two batch input methods – using the BDC table in the “CALL TRANSACTION USING” and “CALL DIALOG” statements. When you perform batch input, you will generally be deciding between the first two methods – creating a batch input session or using the “CALL TRANSACTION USING” statement. However, we will also cover the third method so you are familiar with this “CALL DIALOG” alternative.
• #97: Two questions illustrate the main differences between creating a batch input session and using the “CALL TRANSACTION/DIALOG”: When is the SAP database updated? How are errors handled? When is the SAP database updated? If you create a batch input session in a BDC program, the SAP database is updated during the processing of the batch input session, not the execution of the BDC program. If you use the “CALL TRANSACTION” or “CALL DIALOG” statement, the SAP database is updated during the execution of the batch input program. In other words, the timing issue we covered in the previous chapter is not an issue with these two alternatives because the database is updated during the execution of the batch input program. How are errors handled? If you create a batch input session in a BDC program, errors are handled automatically by the system during the processing of the batch input session. Errors are recorded in a log and the batch input session in error is kept. If you use the “CALL TRANSACTION” or “CALL DIALOG” statement, errors are not handled automatically by the system. Errors must be handled in the batch input program.
• #98: To illustrate the “CALL TRANSACTION” and “CALL DIALOG” methods, we will use the example to change vendors coming from a sequential file on the application server. In chapter 5, we used this example to create a batch input session. In this chapter, we will first use this example with the “CALL TRANSACTION” method. Then, we will use it with the “CALL DIALOG” method.
• #99: The “CALL TRANSACTION” statement executes an online program. When this transaction is completed, processing returns to the “calling” program. To perform batch input with the “CALL TRANSACTION” statement, the “USING” addition is required to send the contents of the BDC table to the transaction: CALL TRANSACTION <transaction code> USING<bdc table> [MODE<display mode>] [UPDATE<update mode>] [MESSAGES INTO <mssg int. table>] . The <bdc table> must be declared “LIKE BDCDATA”. The only required addition for batch input is “USING”. The other additions are only valid in conjunction with the “USING” addition. The <display mode> determines how the transaction will be processed: ‘A’ (display all), ‘E’ (display errors only), or ‘N’ (no display). The default is ‘A’. The <update mode> determines how updating will occur: ‘S’ (synchronous) or ‘A’ (asynchronous). The default is ‘A’. Synchronous updating indicates that an update is completed for the transaction before processing returns to the “calling” program. Asynchronous updating indicates that processing returns to the “calling” program immediately after the transaction is completed, even before the update is completed. System messages issued during the transaction can be stored in the <mssg int. table>. This internal table must be declared “LIKE BDCMSGCOLL”.
• #100: To perform batch input using the “CALL TRANSACTION USING” statement with multiple records from a sequential file on the application server, perform the following steps in a batch input program: Step #1: Create the BDC table. This internal table must be declared “LIKE BDCDATA”. Step #2: Define the field string in which the file’s records will be read. The structure of the field string should match the structure of the file’s records. The sequential file we are reading has the same format as the one from chapter 5 (see page 12 of chapter 5). It is structured in lines, so we will open it “IN TEXT MODE”. These steps are continued on the next page.
• #101: Steps to perform batch input using the “CALL TRANSACTION USING” statement (continued from previous page): Step #3: Open the file “FOR INPUT”. Step #4: Read a record from the file into the field string. To read the complete file, you must code the “READ DATASET” statement in a DO loop. Step #5: Code a way out (EXIT) of the DO loop. If SY-SUBRC is not 0, the end of the file has already been reached. Step #6: Fill the BDC table with the appropriate data for the transaction (see next page). This step will be executed for each record in the sequential file. Step #7: Insert a transaction’s data (from the BDC table) into the transaction directly by using the “CALL TRANSACTION USING” statement. This step will be executed for each record in the sequential file. The display mode determines how this transaction is processed (i.e., will you see the transaction’s screens or not). Step #8: Check SY-SUBRC to determine if an error occurred during the transaction (SY-SUBRC <> 0). The system does not automatically handle these errors like it does during the processing of a batch input session. You must handle these errors in the program (see page 8). Step #9: Close the file.
• #102: The two subroutines above are used to fill the BDC table. These two subroutines are executed just before the BDC table’s contents are passed to the transaction with the “CALL TRANSACTION USING” statement.
• #103: With the “CALL TRANSACTION USING” statement (and the “CALL DIALOG” statement), errors are not handled automatically by the system. Therefore, you must handle these errors in the batch input program. After a “CALL TRANSACTION USING” statement (or a “CALL DIALOG” statement), the value of SY-SUBRC indicates the success or failure of the transaction: If SY-SUBRC is zero, the transaction (or dialog module) was successful. If SY-SUBRC is not zero, the transaction (or dialog module) was not successful. You can handle an error in many ways: Write an error report. Send the record(s) in error to an error file. Create a batch input session with the record(s) in error. This list of error handling methods is not complete. The exact method chosen will depend on your specific requirements. Also, these methods can be combined (e.g., you can create an error report and send the records in error to an error file).
• #104: In the “CALL TRANSACTION USING” statement, you can specify the update mode as synchronous or asynchronous. To restate the difference: Synchronous updating indicates that an update is completed for the transaction before processing returns to the “calling” program. Asynchronous updating indicates that processing returns to the “calling” program immediately after the transaction is completed, even before the update is completed. The difference in these update modes creates a tradeoff between the execution speed and the meaning of the return code. With respect to the execution speed: Synchronous updating is slower than asynchronous updating because processing does not return to the “calling” program until the update is complete. Remember that the update mode when processing batch input sessions is always synchronous. With respect to the meaning of the return code: The return code (SY-SUBRC) after synchronous updating indicates the success or failure of the actual update. The return code after asynchronous updating only indicates the success or failure of the transaction, not the update.
• #105: The final batch input alternative we will cover is the “CALL DIALOG” method. This alternative is not used often. In fact, SAP’s online help states that this batch input method is “outmoded”. Typically, you will be deciding between creating a batch input session and using the “CALL TRANSACTION USING” statement. The “CALL DIALOG” statement executes a dialog module. When this dialog is completed, processing returns to the “calling” program. To perform batch input with the “CALL DIALOG” statement, the “USING” addition is required to send the contents of the BDC table to the dialog module: CALL DIALOG <dialog module> USING<bdc table> [MODE<display mode>] . The <bdc table> must be declared “LIKE BDCDATA”. The only required addition for batch input is “USING”. The “MODE” addition is only valid in conjunction with the “USING” addition. The <display mode> determines how the dialog module will be processed: ‘A’ (display all), ‘E’ (display errors only), or ‘N’ (no display). The default is ‘A’. Notice that an update mode is not specified with the “CALL DIALOG” statement. The update is not handled by the dialog module, but instead by the “calling” program. The “COMMIT WORK” statement is required in the “calling” program to update the database.
• #106: To perform batch input using the “CALL DIALOG” statement with multiple records from a sequential file on the application server, perform the following steps in a batch input program: Step #1: Create the BDC table. This internal table must be declared “LIKE BDCDATA”. Step #2: Define the field string in which the file’s records will be read. The structure of the field string should match the structure of the file’s records. The sequential file we are reading has the same format as the one from chapter 5 (see page 12 of chapter 5). It is structured in lines, so we will open it “IN TEXT MODE”. These steps are continued on the next page.
• #107: Steps to perform batch input using the “CALL DIALOG” statement (continued from previous page): Step #3: Open the file “FOR INPUT”. Step #4: Read a record from the file into the field string. To read the complete file, you must code the “READ DATASET” statement in a DO loop. Step #5: Code a way out (EXIT) of the DO loop. If SY-SUBRC is not 0, the end of the file has already been reached. Step #6: Fill the BDC table with the appropriate data for the dialog module (see next page). This step will be executed for each record in the sequential file. Step #7: Insert a transaction’s data (from the BDC table) into the dialog module by using the “CALL DIALOG” statement. This step will be executed for each record in the sequential file. The display mode determines how this dialog module is processed (i.e., will you see the dialog’s screens or not). Step #8: Check SY-SUBRC to determine if an error occurred during the transaction (SY-SUBRC <> 0). The system does not automatically handle these errors like it does during the processing of a batch input session. You must handle these errors in the program (see page 8). Step #9: Confirm the update to the database with “COMMIT WORK”. Step #10: Close the file.
• #108: The two subroutines above are used to fill the BDC table. These two subroutines are executed just before the BDC table’s contents are passed to the dialog module with the “CALL DIALOG” statement.
• #109: The main difference between the “CALL TRANSACTION USING” method and the “CALL DIALOG” method is the timing of the update to the SAP database. With the “CALL TRANSACTION USING” batch input method, an update occurs after each transaction is completed. With the “CALL DIALOG” batch input method, an update only occurs on the “COMMIT WORK” statement. In our “CALL DIALOG” example, the commit to the database occurred after all the records were processed (i.e., after the end of the DO loop). We could have coded this “COMMIT WORK” inside the DO loop so that an update would occur after each record was processed.