Package size is a vexing issue. For example, if you use a big package, a single faulty record could result in the whole package being dropped. You can choose smaller packages in the hope that you can run several work processes in parallel. This isn’t a bad idea, except that you may not have enough work processes available to handle the load.

I have come across a lot of misconceptions and confusion on this topic. I have often seen parameters related to package size set in a whimsical manner without a complete understanding of its implications. This leads to adverse effects on data extraction jobs into BW and overall performance in the source system.

I’ll explain the role of data packages in BW, the control parameters that influence the size of a data package, and how and where these parameters are set in the IMG. You’ll also see the considerations involved in setting the relevant parameters and how some of these parameters may be overridden in the target BW system. First I’ll provide a few basics about packages.

Package Settings

SAP package settings are maintained in table ROIDOCPRMS. Since a BW system can be a source, you can have the same table (and therefore maintenance/configuration activity) in both the SAP source and the BW systems. Your settings in the SAP source system control the data packages that you extract to the BW logical system to which the SAP source system is connected. Similarly, your settings in table ROIDOCPRMS in your BW system control the extraction of data packages from your BW system to some other target system.

You access this table via transaction SE11 or SE16. However, configurers might want to run transaction SBIW to access the BW-specific customization options in the IMG. Then you follow menu path Data Transfer to the SAP Business Information Warehouse>General Settings>Maintain control parameters for data transfer. Different organizations have different policies on allowing access to this maintenance activity. If you are a Basis administrator or a configuration specialist in the source system, you are more likely to have authorization. Figure 1 shows this maintenance screen.

Figure 1

Maintenance screen for data transfer (control) parameters

These parameters have a significant impact on not only your data extraction jobs, but also on overall system performance. Therefore, be cautious in setting them. It is important that you understand each of these parameters and the implications of setting them:

• Source system: Here, you enter the logical system name of the source system. Every client is a different logical system. The convention for the names of logical systems is that they are a combination of their system name and client number, so it’s easy to figure out. (This is an activity for your Basis administrator). Press the F4 key for a list of logical names.
  
  
• Max (kB) or MAXSIZE: This is the number that you believe represents a certain maximum size of your data extracts. This is not something that you would know or calculate beforehand; it is an estimate, which is why SAP gives you a default value for this parameter. The maximum data package size is not the same as the actual package size. By setting this parameter in the IMG or using the SAP-supplied default, you are not instructing the system to create packages of MAXSIZE. The actual data package size is computed during extraction from the source system using this formula:

(MAXSIZE * 1000) / width of transfer structure

If MAXLINES > the result of the formula, package size is the result of the formula. I’ll explain MAXLINES later.

If MAXLINES < the result of the formula, package size is set to MAXLINES.

Most people instinctively question this formula when they see it the first time. Since the maximum package size (MAXSIZE) is in kilobytes and the size of the transfer structure is in bytes, you need the right units. The formula does not make this explicit, hence the confusion. If ROIDOCPRMS does not have any parameters, packages are transferred to BW in sizes of 10 megabytes or 10,000 kilobytes. In other words, 10,000 (kilobytes) is the default value for MAXSIZE.

Now, click on the Display button, press Enter again after the warning message, and you are taken to the screen shown in Figure 2. Click on the icon to the left of the Generic Delta button. It displays details of the DataSource, including the name of the structure and the fields in the extract structure, as shown in Figure 3.

Figure 2

DataSource display/maintenance screen

Figure 3

Name of extract structure and fields in the extract structure

In this screen, place your cursor on the name of the extract structure (BIW_MARA_S in this case) and double-click. You are taken to the table/structure maintenance screen. Go to Extras>Structure width to find the width of the structure in bytes. If you know the name of the extract structure, run transaction SE11, type in the name of the structure, press Enter, and then go to Extras>Structure width from the menu.

• Max. Lines or MAXLINES: As the name suggests, this parameter is used to control the maximum number of records in a data package. Some analysis is required to arrive at this number. When nothing is specified in the settings table, each data package contains no more than 100,000 records. The size of a data package is inversely proportional to the width of the transfer structure. The width of the transfer structure is the total of the maximum length of each field. Therefore, the individual size of each record does not matter.
  
  
• Frequency: This parameter refers to the frequency with which an Info IDoc is sent after a Data IDoc. An Info IDoc contains the upload status of the Data IDoc that immediately preceded it. The key question here is how frequently you want this information. For example, it is useful when troubleshooting extraction errors. Setting this parameter is a matter of common sense. The default value is 1. If you feel uncomfortable about changing it, experiment by fine-tuning this parameter in your sandbox environment.
  
  Here's a rule of thumb based on my experience. If your data (package/packet) IDoc size is small, you want the frequency of Info IDocs to be a large number (in the vicinity of 10 to 15). Similarly, if your data (package/packet) IDoc size is large, you would want the frequency of Info IDocs to be small. This ensures more efficient monitoring and management of your loads. How small is a judgment call you make when you fine-tune your extraction strategy. For larger data IDocs, I avoid going over five Info IDocs per data IDoc. SAP recommends that you set this parameter to no greater than 20.
  
  
• Max Proc: This is the maximum number of parallel (work) processes for data extraction. The kind of work process relevant here is a dialog process — one of the various types of SAP work processes such as batch, update, enqueue, gateway, and spool. The capability of specifying this parameter was not available before standard R/3 Release 3.1I. The greater the number of parallel processes, the better the performance. The caveat is that this number is constrained by the number of processes available during extraction. In other words, you might put in 10 hoping to get good performance while in reality very little parallelism occurs because few dialog processes are available. Talk to your Basis administrator or performance-tuning specialist to learn the number of dialog processes available.
  
  
• Target system for batch job: This is the host system or the application server on which the extraction job is to be run.

Now I'll give you two examples of package size calculations:

Example 1:

MAXSIZE = 15000 (kB)
MAXLINES = 40000
Size (width) of transfer structure =
400 (bytes)
Calculated data package size =
(15000 * 1000) / 400
= 37,500 (bytes)

Since actual data package size is less than MAXLINES, data is transferred in packages of 37,500 bytes.

Example 2:

MAXSIZE = 18000 (kB)
MAXLINES = 40000
Size (width) of transfer structure =
400 (bytes)
Calculated data package size =
(18000 * 1000) / 400
= 45,000 (bytes)

Since actual data package size is greater than MAXLINES, data is transferred in packages of size MAXLINES or 40,000 bytes.

Override the BW Settings

The source system settings apply to all InfoSources/InfoPackages. Often the extraction requirements for one or more InfoPackages are such that you need to modify these parameters on an individual basis. For example, you might want to extract your FI data in small packages and your HR data in big packages. Or within the same application (say, logistics), you expect a light volume of purchasing data but a heavy volume of sales data. It may not make sense to use the same package size for both your purchasing and sales DataSources.

So guess what? In your SAP BW system, you can override your across-the-board source system parameters on a limited basis. You can change the MAXSIZE parameter only to a value lower than the setting in the source system. You can also change the frequency parameter — again only to a value lower than the setting in the source system.

Go to the InfoPackage maintenance screen of the InfoPackage in question (Figure 4). Select the DataS. Default Data Transfer menu item on the Scheduler menu.

Figure 4

Data transfer menu item on the InfoPackage maintenance screen

A pop-up opens (Figure 5).

Figure 5

Areas where you can override source system settings on an InfoPackage level

You can override the relevant source system parameters (maximum size and frequency) in the two boxes ready for input as indicated in Figure 5. The pop-up has three rows, one for each update type: Full Upload, Delta Upload, and Initializing Delta. This provides you with a means to control the two parameters for each type of update.

Anurag Barua

Anurag Barua is an independent SAP advisor. He has 23 years of experience in conceiving, designing, managing, and implementing complex software solutions, including more than 17 years of experience with SAP applications. He has been associated with several SAP implementations in various capacities. His core SAP competencies include FI and Controlling FI/CO, logistics, SAP BW, SAP BusinessObjects, Enterprise Performance Management, SAP Solution Manager, Governance, Risk, and Compliance (GRC), and project management. He is a frequent speaker at SAPinsider conferences and contributes to several publications. He holds a BS in computer science and an MBA in finance. He is a PMI-certified PMP, a Certified Scrum Master (CSM), and is ITIL V3F certified.

You may contact the author at Anurag.barua@gmail.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.