Things you should know about LO
Sap has provided us the standard Logical Extractor which are used to extract data related to application Purchasing, Inventory Controlling, Shop Floor Control, Sales data, Delivery data etc. The Transaction LBWE is used to direct to LO Cockpit where all the data sources belongs to Logical Extractor are listed there. PFB the screen shot of LO Cockpit. In this Document we will try to give info on each of the objects listed in screen shot. I will try to give some info on the numbers below, Update Mode Job Control, Queued Delta and many more.
When we create some sales order or create some Purchase order and press save then we get some successful message that your sales order has been successfully created or it may result in error or sales order may not create at all.
Let’s say you are creating the sales order now when you press the commit button or save button then Dialogue process completes the VBHDR entry and also the VBMOD, VBDATA entry. The above listed table are actually called the update table they each transaction which is happening in system and also track if there is any error. Find below the information /data this table contains.
VBHDR : Contains the Header information of the request/transaction.
VBMOD : take care of module information.
VBDATA : Contains the data which needs to be transfer to tables.
VBERROR : Contains information about error if some occurs.
Now we have understood the concept of update tables now let’s concentrate on V1 Updates
V1 Update: Processing the V1 modules basically involves transferring of update tables content VBMOD and VBDATA to base application tables. For example you are creating the sales order as soon as you press Commit/Save button then internal system execute the V1 update which write this information to base application tables. Once this information is written to base table then only you will see the message “Sales Order Successfully created” So you can say that V1 update is time critical update and it describe the Primary Changes which should be carried out in Single Unit of work either in full or null. It can never have some intermediate stage.
So this Conclude us with V1 update and let’s talk about V2 update.
V2 Updates: As soon as the V1 updates get over then system start searching for V2 update for updating the statistic tables. The same data is written to Statistic table. This is the tables which can capture data for reporting. For example the LIS table S*** Store sales data it will contains the same data as VBAK and VBAP but in different structure to optimize the reporting.
V2 update does not define the critical changes these changes can happen after few seconds once the V1 updates get over depending upon the system processes.
We can see the status of V1 and V2 updates through transaction SM13. PFB the screen shot below. We can check the status of V1 or V2 updates from here.
NOTE: Make sure update is Active. It can be visible at lower text of screen shot below.
Data Source for LO: Data Source for LO are provided by sap only in standard form. If we wish to add some new fields in extractor then we can enhance it.
Naming Convention of LO Data Source:
Example : 2LIS_11_VAHDR
Let’s concentrate on each parameter individually:
Application Component: This will two digit number giving information about the application to which it belongs like 11 specify sales 12 specify Shipping etc.
Event: It provides the transaction name which provides the data for that data source. It can be four types –
VA: Creating, Changing and deletion Orders.
VB: Creating, Changing and deletion Quotations.
VC: Creating, Changing and deletion Deliveries.
VD: Creating, Changing and deletion Billing Documents.
Suffix: It specifies the level at which the information is available. It can be again of four types:
HDR: header Information.
ITM: Item level Information.
KON: Information related to condition.
SCL: Data related Schedule Line.
Extraction Structure: Naming Convention for Extract structure for LO Data source will be
MC<Application><Event/Group of Event>0<Suffix>
For example: MC11VA0ITM is extract structure of data source 2LIS_11_VAITM.
You can see the extract structure from here as well.
Important table for LO Data Sources:
TMCEXCFS: This table signifies that which all the fields from communication structure is chosen or active in extract structure of data source. PFB the screen shot below I have selected the extract structure as MC11VA0HDR as extract structure which is extract structure for Data Source 2lis_11_VAHDR. The third screen shot below shows the fields which are active or chosen for extract Structure.
TMCEXCFZ: This table is similar to above but it signifies the fields which we have added to delivered version extract structure during its enhancement. It also tracks if we have added any ZZ fields in extract structure. PFB the screen shot for MC11VA0HDR extract structure.
TMCEXACT: The Extract Structure are assigned to Data Source using this table by system.
PFB the screen shot for communication between extract structures. PFB the screen shot for details.
Now let’s try to connect the Dots the data flow will be like from Application Table à Communication Structure àExtract Structure à Data Sources. PFB the flow below.
Now until now it’s all about ECC now we shall see how the data is fetched to BW, How the delta work its functionality etc.
If you go to LO Cockpit through LBWE transaction code then you can see many update method as shown below. This signifies how you should fetch the delta for data Sources.
As shown above the update method can be Direct Delta, Queues Delta and Unserialized V3 updates.
Now we shall see how this update process work, their significance and when to use them.
Let’s discuss them all one by one:
Direct Delta: With this update, Data is transferred directly to BW delta queue with each document posted in same LUW with V1 updates. Now when there is any delta request from BW this directly hit the BW delta queue and delta data is fetched.
This is not good to use as the number of LUWs get increase lot which result in jamming of system of low performance of system.
Unserialized V3 Updates: We rarely used direct delta method due to performance issue most of the time we use V3 update and Queue Delta. Now in this method Data is transferred to Update Queue with V3 call and is kept there until the collective Job is run to fetch data from update Queue to Delta queue. This method does not ensure serialization of document data. Update to DSO object is not recommended if serialization is desired.
Queued Delta: The Queue delta is somewhat similar to V3 Unserialized update the mail difference is that this queued delta update ensures the Serialization that’s the main reason why we have the queued delta in most of Production system. As in BW we have DSO in staging layer where it’s must to have serialized data for correct working of change log table. Up to 10,000 Document can be processed in single LUW.