VENKI

Useful SAP Links

SAP HANA

http://www.biportal.org/Resources/Documents/cool%20features%207.4.pdf
http://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/7018dff1-187c-2f10-ef86-c6cde2cef5e4?QuickLink=index&overridelayout=true&54863912240010
http://scn.sap.com/docs/DOC-51568

SAP BW 

Data modelling

ETL


Reporting






Database Joins


"Creating Access Relationships creates a family of data information harmonising the use of queries and reports..."

Access Relationships enable data in one table to be joined to data in another table which generally serves as the basis for your reports (typically via a query).
Without relationships in place, you are restricted to how data is managed from the reporting point of view and each table sits as a 'stand-alone' file.
As part of the database normalisation process , setting Access relationships keeps to the rules and general good practice of RDBMS Relational Database Management System.
Joining tables together can be set in one of three ways:
  1. Table level via the 'Relationship' Window
  2. Query level via the 'Query' Window
  3. Both Table and Query levels
In order to join two tables together, there are rules that must be observed which are:
1. Field Data Types - the fields which are to be joined across two tables must be the same data type. Therefore a 'Text' data type cannot join to a'Number' data type field.
The exception to the above is a 'Number' data type can join to a'AutoNumber' data type providing both are set to same size (i.e. Long Integer).
2. Field Sizes - applies to only the 'Text''Number' and 'AutoNumber' data types where the size or length of a field can be modified. For the numeric data types, the size must be the same and therefore a 'Number' data type field size in one table which is set to 'Double' cannot join to a field whose size is set for example to 'Integer'.
The 'Text' data type is a little more relaxed as the joining field must be at least the same length (or greater) of characters (bytes)
Note: It is possible to join different field sizes with 'Number' data types provided the field can be cast and fit into the larger size. This is not good practice and in any event shouldn't the data type be the same across tables for the same data value?
3. Field Names? - this is not essential as field names are not checked when joining tables together. But for user-friendliness, having the same field name makes life just a little bit easier!
As a reminder, you may want to review data types and sizes before setting any primary or foreign key indexes.

Setting the correct keys (primary and foreign) must be considered and applied before joining tables together.
The type of key applied will lead to the type of Access relationship you can have and in essence there are four:
  1. One-to-one
  2. One-to-many
  3. Many-to-one
  4. Many-to-many
The 'one' side is associated to a unique value for a field and is referred as the primary key. The 'many' side is an indexed field which allow for duplicate values in a field and is known as the foreign or secondary key.
To get a better understanding of these keys, please review primary and foreign keys.
One-to-One This type of Access relationship is seldom used but it allows you to join two tables together whereby each row (record) in table A has a related row (only one record) in table B.
Types of uses for this setup could be a way to overcome some management, performance or sensitive data issues. For example, if you had two tables dealing with employee information where one table Personnelstores general profile information including surname, ID and contact information and the other table Payroll containing salary and other sensitive data, then there would only be one record per individual in each table(joined by a common unique value - 'Employee ID').
Other times, this type of Access relationship may be used is when overcoming limitations and performance problems. For example, for a table to hold over 100 fields (maximum is 255) will require a lot more memory than a table with far less. If you had a client table which held a lot more profile information than the normal, consider splitting into two tables; table A to hold the main essential fields and table B holding the less frequently used data (especially when using 'Memo' and 'OLE Object' data types). The common field would be unique in both (i.e. Customer ID).
One-to-One
One-to-Many / Many-to-One This is the most common type of Access relationship where a single record in one table is joined to one or more records in another table with the same matching data value from the unique value of the first table.
There are many examples to highlight but imagine if you have a table calledCustomers which contains the client's details including name, address and contact and another table of transactions called Orders where a customer can place more than one order over a period of time. The common field between the two is the Customer ID and is unique from Customers but duplicated in the Orders table for each instance an order was placed for the same customer.
This type of Access relationship is sometimes referred as parent-child ormaster-detail. Terminology sometimes used when talking about a customerhaving never placed an order is referred as a widow record (a parent with no children). The other way around where an order does not have a knowncustomer is referred as an orphan record.
One-to-Many
Many-to-Many This type of Access relationship cannot be created directly in Access and therefore will require three tables. It is where in table A, a record can refer to one or more records in table B and table B can be linked to one or more records in table A (a two-way 'one-to-many/many-to-one' link) but requires a third interim table C!
This relationship happens by default if you have created multiple tables using the database normalisation techniques and have joined tables together using the 'one-to-many' relationships.
For example, for each order stored in the Orders table which holds the header information including date, customer ID and shipping information has a second table which stores the item details that make up the order calledOrder Details where the Order ID field is common to both tables causing a'one-to-many' relationship. For each item in the Order Details table, a product is held identifying the item and its product information which in turn is held in a separate table called Products containing name, stock levels and price. The relationship between Order Details and Products is a 'many-to-one' where the common field is Product ID.
So we have three tables; Orders linked to Order Details linked to Productsand therefore we have an indirect relationship between Orders and Products (the Order Details table sitting between the two).
In the 'real world', this would be a typical relationship because you have one order with many products (items) and the product is sold across many orders. The middle table Order Details handles the two way relationship.
Many-to-Many

In addition to Access relationships, you also have three different join types to choose from:
  1. Equi-Join (Inner Join)
  2. Left-Join (Outer Join)
  3. Right-Join (Outer Join)
Equi-Join By default, when you join two tables together, it sets it as anEqui-Join also referred to as the Inner Join.
It tells Access to show only records from the two tables where they both have the matching values. Any record in either table that does not have a corresponding record in the other table is simply suppressed from view.
For example, if we continue to use our Customers and Orders table relationship scenario of a 'one-to-many', it would only return records where the matching Customer ID field existed across the two tables. Therefore, it will display all customers that have placed at least one order and only display orders that have a known customer account.
Any orders that do not have a matching Customer ID will be suppressed and in the 'real world' this would be unusual due to the fact you first would choose and assign a customer before placing the order!
However, it is possible to have a customer as a new prospect that has yet to place their first order and therefore would also be suppressed with this type of join.
Note: Access relationships cause and effect - Before adding any criteria, you will find records have been filtered because of this type of join. If you had 99 out 100 records in table A each having 3 records from table B with the remaining 1 record not having any records from table B, then the result recordset would be 297 (99 X 3) suppressing the 1 record.
Inner Join Diagram
Left/Right-Joins which are also known as Outer Joins change the relationship link. Access will force records to be displayed whether there is a matching value or not.
In Access, you can only set one direction of outer join (left or right) at time and it tells the system from which direction to force the records to be all shown.
For example, using our Customers and Orders table scenario, creating aRight-Join (pointing from Customers to Orders) will show all customers whether they have orders related or not.
Where there are records from Customers which do not have any related orders are said to be Widow Records (parent with no children).
Right Outer Join Diagram
Right Outer Join Diagram
Using the Left-Join example for the above tables will force all orders to be displayed and only related customers.
This type of example may not be different from an Equi-Join if the relational database has been designed with care as in the 'real world' you wouldn't really have an order issue without first choosing a customer!
This type of join will be driven towards data that may have been imported from an external system where Access cannot deal with those orphanrecords (records without a parent).
Left Outer Join
Left Outer Join Diagram

There it is, Access relationships understood!
Don't get too wrapped with up different joins, keep it simple and as you develop the database you will learn to modify the rules.
The next step is to create the joins which is covered under how to apply the joins and create a relational database.

Activating BW objects


Info Objects:
RSDG_IOBJ_ACTIVATE                           Activation of InfoObject (without automatic transport connection)
Info Cube:
RSDG_CUBE_ACTIVATE                          Activation of Info Cubes
Multiprovider:
RSDG_MPRO_ACTIVATE                         Activating Multiprovider
ODS:
RSDG_ODSO_ACTIVATE                         Activating/Repairing Data Store Objects (Without Automatic Transport Connection)
Transfer Structure:
RS_TRANSTRU_ACTIVATE_ALL              Activate all active transfer structures for a source system
Data Source:
RSDS_DATASOURCE_ACTIVATE_ALL      Activate All DataSources of a Log System
Communication Structure:
RS_COMSTRU_ACTIVATE_ALL               Activate all inactive communication structures
Update Rule:
RSAU_UPDR_REACTIVATE_ALL               Report RSAU_UPDR_REACTIVATE_ALL

Labels


How to transfer the Data from SAP-System to Non-SAP system without additional Cost/License
Can we Transfer the Reports/Data from SAP-System to Non-SAP system without additional Cost/License?.
Yes, we can transfer using with simple FTP/SFTP.
Is it required any additional License or additional Cost?
No.
Is there any complex Coding or Configuration required?.
No, it is very simple.
How Can I transfer the Report/Data?.
Here I'm considering SAP-BW system running in UNIX operating system and Windows XP as Non-SAP System.
Source          : SAP-BW System running on UNIX.
Destination : SQL-Server running on Windows XP.
Scenario:
I have data in SAP-BW System, e.g. InfoCube 0SD_C03. And 0SD_C03 is having some reports and want to transfer the reports data to SQL-Server running on Windows XP.
Else
You may need to transfer ECC Data to SQL-Server running on Windows XP. For this also you can use the same logic.
Here are the steps...
  1. Set the Variable values using fixed restrictions or Using SAP/Customer Exits variables in BW Report. (If you have any variables.)
  2. Using RSCRM_BAPI TCode schedule the report based on your requirement i.e. daily, weekly...etc. And then dump the report result into one path (Directory) in Application Server.                                                                                                      E.g.:  Directory:  /usr/sap/BP1/DVEBMGS00/work/
    You can see this path in AL11 Tcode.
  3. Open the port in BW Application server.
  4. Create FTP/SFTP User ID in Application server level in BW System.
  5. Using Windows Script you call the Report in /usr/sap/BP1/DVEBMGS00/work/ path in BW system to SQL-Server running on Windows XP. This script you can save as a batch file and schedule it based on your requirement in Windows Server.
        Sample Windows script:
image
Note: For better understanding or Changing of the above code, please contact your Windows system Administrator. This is just sample code only.
Here I’m using RSCRM_BAPI Tcode to dump the report result into Application Server. You can use your own method also. Our intension is how to transfer the data from SAP to Non-SAP System.

Inflow/Outflow


The Business Information Warehouse (SAP BW) key figures are either about cumulative values (for example sales, number of pieces sold) or non-cumulative values (for example number of employees, warehouse stock). Key figures that are defined as non-cumulative values form a key figure group with further key figures that contain the values for the non-cumulative value changes (inflows and outflows). In order to be able to plan non-cumulative values, all key figures that belong to such a key figure group must therefore be compared with each other, so that no inconsistencies occur.
The function to accumulate balances offers you an alternative approach for this comparison, by determining values for the respective missing key figure, for the updating of balances over time. You determine the key figures, from which the key figure group is made up, here within SEM-BPS (and not with the key figure definition in SAP BW). Either the closing balance or the non-cumulative value change (applied to the period) can be calculated. Here is the following general formula that it is based on:

Closing balance = opening balance + inflows – outflows
as well as
Opening balance (current period) = closing balance (current period – 1)
The time period for which the update of balances is executed, results from the value restriction of the time characteristic you selected in the planning package or level.
The general use of this function is that you receive direct access to all balance-relevant values for a given key figure for every desired period. This occurs without time-intensive translations having to be carried out beforehand, as would be necessary for the query of values direct from the data basis.
Only apply the function to accumulate balances for those key figures that are not defined as non-cumulative values in the Business Information Warehouse. The reason for this is that the additional key figures (for non-cumulative value changes or inflows and outflows) compounded to a non-cumulative value defined in SAP BW are not included in InfoCubes, which contain a non-cumulative value. As a result no access possibilities would exist for the additional key figures from SEM-BPS. You can determine the exact key figure definition with the help of the SAP BW Administrator Workbench.
Features : When creating a planning function to accumulate balances, only select the characteristic that contains the time dimension. The value restriction of this characteristic determines the time period in the planning package or level, for which the update of balances takes place.
In the parameter groups for the function to accumulate balances, you define which balances should be planned. For this you can choose four key figures at most for the opening balance, the closing balance as well as the inflows and outflows in the balance.
It is not absolutely necessary to enter a key figure name for all fields. By omitting a key figure you can use the function in various ways:
If no key figure name is entered for the outflows in the balance, then the function interprets the key figure for the inflows as the non-cumulative value change that can also have a negative value. Therefore the value of the key figure that you enter under inflows corresponds in this case to the balance of the outflows and inflows. A detailed conclusion about the real outflows and inflows is not possible with this type of data retention.
If no key figure name is entered for the opening balance, then no closing balance can be determined for the first period of the package. On the contrary it is assumed that the closing balance has already been determined in the first period of the planning package and can serve as the starting point for the update of balances in the following periods.
In addition in the parameter groups you can define whether the closing balance should be calculated according to the formula mentioned above, or whether inversely the non-cumulative value change is to be calculated on the basis of planned closing balances according to the following formula:
Balance change (current period) = closing balance (current period) – closing balance (current period – 1)
Example 1: Calculating the Closing Balance
Period Opening Balance Inflow Outflow Closing Balance
001.2000 100 80 20 160
002.2000 160 50 70 140
003.2000 140 120 30 230
Example 2: Calculating the Non-Cumulative Value Change on the Basis of the Closing Balance
Period Opening Balance Inflow Outflow Closing Balance
001.2000 100 60 160
002.2000 160 -20 140
003.2000 140 90 230


Date                     Amount    Open_Bal     Close_Bal
1/01/2012             100                0                100
3/01/2012              -20            100                 80
4/01/2012              200             80               280
4/01/2012                10           280                290
5/01/2012                10           290                300

Variable Selection : From Date and To Date.
Create Customer Exit Variable on Calendar Day (0CALDAY) 
Create ZC_FYFD variable on 0CALDAY, the properties are.. 
Type of Variable  = Characteristic 
Variable Name  = ZC_FYFD
Processing by  = Customer Exit 
Characteristic  = Calendar Day 
Variable Represents  = Interval 
Variable Entry  = Mandatory 
Check ready for input

********************Begin of Data Type Declaration*********************************
DATA: L_S_RANGE TYPE RSR_S_RANGESID, 
                          LOC_VAR_RANGE LIKE RRRANGEEXIT, 
                     zbuper LIKE t009b-poper,
       zbdatj LIKE t009b-bdatj,
ZDT1 TYPE SY-DATUM,
ZFDT TYPE SY-DATUM,
ZLDT TYPE SY-DATUM.
********************End of Data Type Declaration************************************
****************************************Begin***************************************
********To get the Financial Year From and To dates based on System/Current Date****

CASE i_vnam. 
WHEN 'ZC_FYFD'.
   IF i_step = 1.
    ZDT1 = SY-DATUM.
     CALL FUNCTION 'DATE_TO_PERIOD_CONVERT'
        EXPORTING
          I_DATE               = ZDT1
*         I_MONMIT             = 00
          I_PERIV              = 'V3'
       IMPORTING
         E_BUPER              = zbuper
E_GJAHR              = zbdatj
       EXCEPTIONS
         INPUT_FALSE          = 1
T009_NOTFOUND        = 2
T009B_NOTFOUND       = 3
OTHERS               = 4
                .
      IF SY-SUBRC <> 0.
         MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
         WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
      ENDIF.
       CALL FUNCTION 'FIRST_AND_LAST_DAY_IN_YEAR_GET'
        EXPORTING
          I_GJAHR              = zbdatj
I_PERIV              = 'V3'
       IMPORTING
         E_FIRST_DAY          = ZFDT
E_LAST_DAY           = ZLDT
       EXCEPTIONS
         INPUT_FALSE          = 1
         T009_NOTFOUND        = 2
T009B_NOTFOUND       = 3
OTHERS               = 4
                .
      IF SY-SUBRC <> 0.
         MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
         WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
      ENDIF.
l_s_range-low = ZFDT.
      l_s_range-high = ZLDT.
      l_s_range-sign = 'I'.
l_s_range-opt = 'BT'.
      APPEND l_s_range TO e_t_range.
    ENDIF.
     ENDCASE. 
*****************************************End*****************************************
****
Save and Activate the above code and project.

Code Example: 
DATA: L_S_RANGE TYPE RSR_S_RANGESID. 
* Current month to date variable ZCMTD example. 
WHEN 'ZCMTD'. 
* you variable name 
data:   ZCMTD_LOW like sy-datum. 
*defining variable for using as a starting date of the interval 
ZCMTD_LOW = sy-datum.  *initializing it with the current date 
ZCMTD_LOW+6(2) = '01'.  
*replacing last two symbols (day) in the current date with '01'(see ref.1) 
CLEAR L_S_RANGE. 
L_S_RANGE-LOW = ZCMTD_LOW.  
*initializing low interval limit 
L_S_RANGE-HIGH = SY-DATUM.  
*initializing high interval limit 
L_S_RANGE-SIGN = 'I'.  
*defining interval as inclusive 
L_S_RANGE-OPT = 'BT'. 
APPEND L_S_RANGE TO E_T_RANGE. 
* Current month to date variable ZCMTD example end. 
ENDCASE.

The result of this will be an interval from the first day of the current month till 
the current system date.

SAP V1, V2 and V3 Updates


SAP V1, V2 and V3 Updates
Document update is where the transaction (documents) are updated in the application tables. This update is normally a synchronous update, i.e. if the update does not go through for whaterever reason, the complete transaction is rolled back.


Statistical update is the update of statistics for the transaction – like LIS or extractors for BW.


V1 – synchronous update. If the update is set to V1, then all tables are update and if any one fails, all are rolled back. Done for all transaction plus critical statistics like credit management, etc.


V2 – asynchronous update – transactions are updated and statistical updates are done when the processesor has free resources. If the statistical update fails, the transaction would have still gone through and these failures have to be addressed separately.


V3 – batch update – statistics are updated using a batch (periodic) job like every hour or end of the day. Failure behaviour is same as V2 updates.
Statistical update is also used as to describe the initial setup of the statistical tables for LO/LIS. When old transactions are updated in LO/LIS as a one time exercise, then it is called a statistical update also. Once these tables are upto date will all transactions, then every transaction is updated in them using V1, V2 or V3.