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.

Update Process

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:

2LIS_<APPLICATION COMPONENT>_<EVENT><SUFFIX>

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.

Modelling in LSA++

Transform classic LSA Data Models in LSA++ 

Data Models for BW/4HANA

With BW/4HANA the number of modelling object types was reduced from 10 to 4. That means common objects like the InfoCube, MultiProvider or PSA table are not available any more. Complex data structures like the star schema are obsolete with HANA’s row based in-memory technology.

For modelling data flows SAP raises the new Layered Scalable Architecture++ (LSA++) into orbit as extension to the classic LSA. The LSA defines an implementation standard for separation of data of different maturity level. It offers best practice guidelines for so called layers as well as services provided by them.

The LSA++ is an extension of the classic LSA specific for SAP BW on HANA systems. The three most important advantages of LSA++ are:

1. The number of redundant objects is reduced means less memory consumption.
2. The administration effort is reduced.
3. Data models are more flexible.

For global BW system landscapes following the classic LSA principles the transformation to LSA++ in combination with a HANA DB can be done in two steps:

1. Mapping of existing objects
2. Simplify the data flow

1. Mapping of existing objects

The mapping of old objects to a BW/4HANA objects is provided by SAP. It offers a migration tool to transfer an existing data flow to a HANA data flow. The t-code is RSB4HTRF.

© 2016 SAP AG. All rights reserved.

2. Simplify the data flow

The second step is the more interesting step. Here the real simplification takes place. I give you a bunch of transformation mappings to use.

Mapping 1:

The starting situation is a 1:1 transformation to the Architected Data Mart layer from the Business Transformation Layer. In LSA++ the Business Transformation Layer can be omitted. The reporting-optimized InfoCubes are no longer supported in the BW/4HANA architecture.

Mapping 2:

This is similar to Mapping 1. For a 1:1 transformation in the business transformation layer, the Architected Data Mart layer can be omitted. The ADSOs are directly consumed by the CompositeProvider.

Mapping 3:

In the case of simple merging scenarios in the business transformation layer (for example, fields from Status are required in the Order Item), the business transformation layer and the architected data mart can be omitted. Merging scenarios can be represented by a JOIN in the CompositeProvider.

Mapping 4:

The PSA as an input object is no longer supported with a BW/4HANA architecture. The input data can be loaded into a write-optimized ADSO. The field-based structure allows the ADSO to be generated automatically according to the structure of the data source. The write-optimized ADSO also serves as a corporate memory.

LSA++ Architecture

Layer Architecture of a Data Warehouses with SAP HANA Database (LSA++)

Concept

By using an SAP HANA database as your database for SAP NetWeaver Business Warehouse (BW), you have greater flexibility and more possibilities to achieve your requirements. A new, integrated layer architecture (LSA++) is required to depict a system with different approaches in BI, their persistency layers and virtual data marts.

The flexible, consistent core of the EDW remains in place. In the LSA++, special services for operational, flexible data are added to the core. The main differences to the LSA are:

• Queries on DataStore objects are just as fast as on InfoCubes. Therefore queries can be directly defined on the data propagation layer. You do not need an explicit reporting layer.
• You can define virtual data marts by using CompositeProviders that combine InfoProviders.
• Using special VirtualProviders and TransientProviders, you can access data directly in the SAP HANA database, to allow queries on the data.

LSA Architecture

Layer Architecture of Data Warehouse (LSA)

Use

The structure and running of a data warehouse in general, and an enterprise data warehouse in particular, is highly complex and cannot be tackled without the support of suitable tools. The SAP NetWeaver Business Warehouse provides you with an integrated solution:

The concept of layered scalable architecture (LSA) assists you in designing and implementing various layers in the BW system for data acquisition, Corporate Memory, data distribution and data analysis. We differentiate between two main layers here: The Enterprise Data Warehouse layer and the Architected Data Mart layer.

The following graphic illustrates the structure of the different layers:

Depending on your requirements, the system might also contain further layers. The data in a layer does not necessarily have to be saved in persistent format.

Note that the LSA has fixed rules regarding where necessary transformations are performed:

• Only transformations independent of the business process are performed between data acquisition layer and data propagation layer (usually in the Quality & Harmonization layer). These transformations create a Data Warehouse data model from data. This data model can be reused for different data marts.
• Transformations that relate to a specific business process are only performed after the Enterprise Data Warehouse layer (in other words, in the Business Transformation layer).

If you are using an SAP HANA database for your BW system, you should base your system on the new layer architecture (LSA++). More information:

BW REPORTING

Types of SAP BW Variables

The following types of variables can be created in SAP BW and will be discussed in detail:

• Characteristic Value Variables
• Hierarchy Node Variables
• Text Variables
• Formula Variables
• Hierarchy Variables

Characteristic Value Variables

These types of SAP BW variables act as placeholders for characteristic values. You can select not just single values for variables but also multiple single values, intervals, ranges, or selection options based on how the variable is defined. For instance, you can replace fiscal period with a variable reference:

Fiscal Period = 0062017 ➔ Fiscal Period = FISCPER_V01

Hierarchy Node Variables

If you want to select hierarchy nodes, you must use hierarchy node variables.

Text Variables

These types of variables act as placeholders for text. You can use these variables in calculated key figures, structures, and query descriptions. These variables appear as technical name surrounded by ampersands (&). For example:

Prior Year Revenue Period = 0062016 ➔ Prior Year Revenue Period = &FISCPER_T01&

Formula Variables

These types of variables represent numerical values. You can use these variables in formulas for computing conditions and exceptions.

Hierarchy Variables

These types of variables act as placeholders for hierarchies. You can use these types of variables when you want to select hierarchies.

Processing Types of SAP BW Variables

The variable processing type governs the way in which a variable gets filled with values during runtime of the query. The following are the various processing types:

• Replacement Path
• Customer Exit
• SAP Exit
• User Entry/Default Value
• Authorization

We will discuss these processing types and their valid variable types in the following sections.

Replacement Path

The replacement path processing type needs to be chosen when the value of a variable needs to be automatically replaced on execution of the query. Through the replacement path, we can create hidden variables and later fill them with another variable. For instance, consider a scenario where we have Plant and Year in the variable screen. Plant gets filled from the hidden variable Plant_Var. On the variable screen, you will not see Plant_Var. Based on user selections, the hidden variable is leveraged to collect the proper data from the database as outlined below:

Replacement Path Processing Type Example

Customer Exit

Function module EXIT_SAPLRRS0_001 is leveraged via enhancement RSR00001 when you select the customer exit processing type for a variable. Using this processing type, variables can be filled in the reporting at various points of time, but the code should always be within enhancement RSR00001. This exit primarily functions with hidden variables but can be written with greater complexity than the replacement path processing type. For instance, if you need to join multiple database tables to identify hidden variables, it will require ABAP code to derive the logic. Based on user selections, the custom logic is run to collect the proper data from the database as outlined below:

Customer Exit Processing Type Example

SAP Exit

Function module RREX_VARIABLE_EXIT is leveraged when the SAP exit processing type is used for a variable. When using this exit, make sure that the variable is filled properly and restrictions are considered in FILL_SP_1.

User Entry/Default Value

If you want an additional screen to pop up for user entry, select this processing type. For example, Sales Organization and Division are available for user entry in the variable selection screen below:

User Entry Processing Type Example

With the user entry processing type, you can specify the variables that will be available for user entry, or you can specify default values based on your requirement. Based on user entry or default values, the proper data is selected from the database.

Authorization

Leverage the authorization processing type if you want to fill the variables automatically based on the authorization of a user. For instance, let’s assume you have a variable screen with Country and Year. The Country variable is derived automatically from the authorizations of the user executing the query.

Applicable Processing Types by Variable Type

Please note that not all variable types can leverage all processing types. There are certain restrictions. Let’s now understand the applicable processing types for each of the different types of SAP BW variables.

CHARACTERISTIC VALUE VARIABLES

Characteristic value variables can have the following processing types:

• User Entry/Default Value
• Replacement Path
• Customer Exit
• SAP Exit
• Authorization

HIERARCHY NODE VARIABLES

Hierarchy node variables can have the following processing types:

• User Entry/Default Value
• Customer Exit
• SAP Exit
• Authorization

TEXT VARIABLES

Text variables can have the following processing types:

• User Entry/Default Value
• Replacement Path
• Customer Exit
• SAP Exit

FORMULA VARIABLES

Formula variables can have the following processing types:

• User Entry/Default Value
• Replacement Path
• Customer Exit
• SAP Exit

HIERARCHY VARIABLES

Hierarchy variables can have the following processing types:

• User Entry/Default Value
• Customer Exit
• SAP Exit

Below is the summary table of the applicable processing types for each of the variable types:

	Variable Type
Processing Type	Characteristic Value Variables	Hierarchy Node Variables	Text Variables	Formula Variables	Hierarchy Variables
User Entry/Default Value	X	X	X	X	X
Replacement Path	X		X	X
Customer Exit	X	X	X	X	X
SAP Exit	X	X	X	X	X
Authorization	X	X

—

Did you like this tutorial? Have any questions or comments? We would love to hear your feedback in the comments section below. It’d be a big help for us, and hopefully it’s something we can address for you in improvement of our free SAP BW tutorials.

SAP BW

Welcome to zero gravity

Hai,

Intelligence is not personal, is not the outcome of argument, belief, opinion or reason. Intelligence comes into being when the brain discovers its fallibility, when it discovers what it is capable of, and what it is not.... When (thought) sees that it is incapable of discovering something new, that very perception is the seed of intelligence.