Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member

Full Repair Requests for LO Extractors

Full Repair Requests: Full Repair extraction request is a data request for data that has previously been extracted and loaded to a target InfoProvider. These types of requests can be updated in every target InfoProvider, even if that target already has the data from an initialization or Init w/o Data Transfer for this DataSource.

Need of Full Repair Requests: Sometimes, delta extractions don’t extract all the delta records or the process failed and can’t be restarted and to fill this gap we need Full Repair Requests. Even we might need to re-synchronize the data between BW and the source system. These types of requests are also useful for the times when we are initially extracting large volumes of data and execute an Init w/o Data Transfer and execute multiple parallel Infopackages that are Full Repair requests with specific selection criteria.

Before moving ahead let us have a brief overview on LO Extractors.

LO Extractors

Logistics involves movement/flow of material, people, money, energy and information from a point of origin to a point of consumption so as to meet the customer requirements for goods and services.SAP ERP has a number of Logistics (LO) applications, so SAP provides a number of DataSources that are related to Logistics. The extraction for these DataSources follows a well-defined process that uses a special framework – the Logistics Cockpit.

LO Cockpit:

                                                 

DataSource: A DataSource is a structure in the source system that specifies the method for transferring data out of the source system. It is created in the source system and replicated to the BW system. With SAP ERP and other SAP systems as source, we have a large number of DataSources that are offered by SAP which support a wide range of analysis requirements.But when our requirements are not met by using SAP Business Content, we can create a DataSource based on our own logic. Such a DataSource is known as Generic DataSource.

All the DataSources belonging to logistics can be found in LO Cockpit grouped by their respective application areas. Also, if the datasource is provided in the LO Cockpit, changes can be made there too depending on how the extraction of data is made for that datasource.

                                                      

Datasource for LO extraction is delivered by SAP as a part of business content. It has the naming convention: 2LIS_<Application_Component>_<Event>_<Suffix>

Application Component: Application Components are sets of DataSources grouped logically. Here, these are 2 digit numbers. These can be checked in LO cockpit. e.g.: application 11 refers to SD Sales.

Event: specifies the transaction that provides the data for the application specified, and is optional in the naming convention.

  1. E.g.:

VA: creating, changing or deleting sales orders

VB: creating, changing or deleting quotations

VC: creating, changing or deleting deliveries

VD: creating, changing or deleting billing doc

Suffix = It details the DataSource, what level of data is extracted etc.

HDR represents Header data

ITM represents Item data

SCL represents Schedule line data

KON represents Conditions data

So, 2LIS_11_VASCL will extract Sales Order Schedule Line data from SAP ECC system.

DataSource can be activated at RSA5 (T-code) and the activated datasources can be viewed in transaction RSA6. Upon activation of the business content datasources, all components like the extract structure, extractor program etc. also gets activated in the system.

An extract structure generated will have the naming convention:

MC <Application><Event/group of events>0<Suffix>, where suffix is optional.

Thus, MC11VA0SCL: Extraction structure for the DataSource 2LIS_11_VASCL.

Initial and Delta Data Extraction for Logistics Transaction DataSources

Initialization/Full Upload: To differentiate the new data from the historical data, the process of initialization is used which sets a point of reference for the historical data and also provides the option to load the historical data to SAP NetWeaver BW. Also, to use the delta capability of the DataSource, the process of initialization must be carried out. The new data generated after initialization is identified as delta data.

Setup Tables: For loading data first time into the BW system, the set up tables have to be filled. The restructuring/set up tables are cluster tables that hold the respective application data, and the BI system extracts the data as a onetime activity during the initialization process or during the full update mode, and the data can be deleted from the set up tables after successful data extraction into BW to avoid redundant storage. The setup tables are filled for the entire application component and not for the individual DataSources.

Naming Convention for Setup Tables : <Extraction structure>SETUP

Thus, the DataSource 2LIS_11_VASCL having extract structure MC11VA0SCL has the set up table MC11VA0SCLSETUP.

Once the initialization is completed successfully, we don’t need the data in the setup table. It can be deleted using transaction LBWG.

Delta Loads: After the successful initialization, delta records get captured and are passed to an area known as delta queue, which stores records that are ready to be extracted by the BW system.

There are three different methods for processing this data but before proceeding its necessary to understand the various update modes.

Update Modes: While carrying out a transaction, for e.g. the creation of a sales order, the user enters data and saves the transaction. The data entered by the user from a logistics application perspective is directly used for creating the orders and also indirectly forms a part of the information for management information reporting. The data entered by the user is used by the logistic application for achieving both the above aspects, but the former, i.e. the creation of the order takes a higher priority than result calculations triggered by the entry. The latter is often termed as statistical updates. The SAP system treats both these events generated by the creation of order with different priorities by using different update modes to achieve the same.

V1 Update: A V1 update is carried out for critical or primary changes and these affect objects that has a controlling function in the SAP System, for example the creation of an sales order in the system. These updates are time critical and are synchronous updates.

V2 Update: A V2 update, in contrast with V1 is executed for less critical secondary changes and are pure statistical updates resulting from the transaction.

V3 Update: V3 update which consists of collective run function modules. Compared to the V1 and V2 updates, the V3 update is a batch asynchronous update, which is carried out when a report (RSM13005) starts the update (in background mode). The V3 update does not happen automatically unlike the V1 and V2 updates.

Delta Load Methods: SAP provides us with different mechanisms for pushing the data into the delta queue and is called update mode. In transaction LBWE, we can see the various update modes available.

                                                      

Direct Delta: This method stores the posted documents in the delta queue using V1 update. V1 update accords the highest priority to this process over others and is generally used for most critical updates. It is recommended only when a small number of documents are being posted.

Queued Delta: This method stores the posted document data in an extraction queue using the V1 update. A collective run is required to read the data from the extraction queue and transfer it to the delta queue. This method can be used when the number of documents posted is large, and serialization is also required.

Unserialized V3: This method stores posted documents in an update table using the V3 collective run, which happens before the data is written to the delta queue. Another V3 collective run than reads the data from the update table without considering the sequence, and transfers the data to the delta queue. Since this doesn’t retain the sequence in which records were generated, we should not load data with this update type directly into a DSO. This is used when serialization of data isn’t required.

Full Repair For DataSources in LO

If there is an issue in the data being extracted through delta load from LO DataSource and it is required to reload the data into BW from R/3, then full repair has to be used. To use full repair option for LO datasources, setup tables need to be filled from the source tables present in SAP R/3. It is required because delta load data moves directly into delta queue only and not into the setup tables.

In case it is required to do a full repair for a LO data source:

·          1) Identify the extract structure corresponding to the LO data source using transaction code LBWE.

·          2) Identify the corresponding Set-up table (Set-up table is Extract structure name suffixed by SETUP).

·          3) Identify the transaction to fill up Set-up table (depends on Set-up table).

·          4) Identify the selection criteria for filling Set-up table and the selection options available in Full repair Infopackage.

·          5) Delete the Set-up table using transaction code LBWG and fill it based on the decided selection criteria.

·          6) Reload the required data from setup table by executing a Full Repair Infopackage.

To explain this process, let us consider an example to reload the data for 2LIS_11_VASCL datasource which uses LO Extractor.

We can check all the active extract structures in transaction LBWE (LO Data Extraction: Customizing Cockpit).

                                            

Now, the name of the setup table as explained before will be MC11VA0SCLSETUP for the corresponding datasource.

To move ahead with the reload, first we need to identify the selection criteria to fill the setup table.

Transaction to fill the setup table is OLI*BW, where “*” depends upon the application area. Some examples are given below:

OLI1BW: Article Movements

OLI2BW: Stocks

OLI3BW: Purchasing documents

OLI7BW: Order

OLI8BW: Deliveries

OLI9BW: Billing documents

In our case it will be OLI7BW.

So the selection screen has Sales Organization, Company code and SD Document (Sales Document Number) which means data based on the above selection can only be filled in the setup tables. In case we have other fields for selection, then we need to find the corresponding values for these columns from the application tables to proceed.

Before filling the setup tables, it’s a good practice to delete the setup table. We can use the transaction LBWG to delete the contents of setup tables. It is not mandatory to delete the setup table but we follow this practice to maintain consistency as setup table has an additive property.

                                            

In our case we delete the setup table for application component 11 i.e. SD Sales BW.

Before filling the setup table, we must ensure that our system is locked to avoid loss of the new records posted.

Now we enter the desired selection criteria and the details in the other fields where date and time of termination is the estimated time to fill the setup table with desired data and then execute. On clicking continue, the selected records are transferred to the setup table.

                                            

Once we have filled the setup table, we can go to transaction RSA3 and check the number of records in 2LIS_11_VASCL. It should be equal to the number of records we have loaded.

Now, we need to execute a Full Repair Infopackage to load the data from setup table. Below steps define the complete procedure to execute the Infopackage:

1) 

        1)  Create/Find a Full Repair Infopackage in 2LIS_11_VASCL datasource in BW system.

         

                                                       

          2) From the Scheduler dropdown, select the Repair Full Request Option.

                                                   

          3) Check the Indicate Request as Repair request option.

                                                      

          4) Make sure to check the Full Update mode in the Update tab.

                                                      

          5) Execute the Infopackage by clicking Start. We can execute the Infopackage immediately or schedule it to a future date as per our requirements.

                                                      

Once the load completes successfully, check the data in the InfoProvider.

Thanks!!

2_

         

17 Comments
Labels in this area