HOW TO SAP

Step by step manual guide with screenshot for Basis, Security Authorization & Abap

Popular Posts

  • HOW TO SAP - Create RFC TCPIP connection and Register Server Program with RFCEXEC
    Execute SM59 Expand TCP/IP connections > Click Create Enter the following details. Ensure connection type is 'T' Save a...
  • HOW TO SAP - SAP Web dispatcher Installation
    Login with adm. Create folder SAPWEBDISP in usr\sap\ Download latest web dispatcher from services.sap.com and save it to above folder...
  • HOW TO SAP - STMS transport hang with truck icon
    At times transport will hang with status Truck icon Check https://forums.sdn.sap.com/thread.jspa?threadID=972797&tstart=100 Logi...

Blog Archive

  • ►  2019 (14)
    • ►  July (4)
    • ►  June (8)
    • ►  May (2)
  • ►  2018 (1)
    • ►  January (1)
  • ▼  2017 (65)
    • ►  December (16)
    • ►  November (18)
    • ▼  October (26)
      • GRC 10 - Firefighter tcode
      • SPRO missing entry - launch with tcode SIMGH
      • How to Created Background Jobs in SAP - SM36
      • SSO Parameter value
      • Frequently used SE16 Tables for SAP security autho...
      • Creating a Trusted RFC between SAP ECC and HANA
      • SAP Query using tcode SQVI with username and email...
      • BW on HANA migration handbook for SAP Basis team
      • Why is SAP authorization profile red or yellow?
      • SAP BASIS - Hana Cockpit explain
      • What is SU24 and how to maintain authorization object
      • How to Assigning Authorization objects to Users in...
      • Alternative to ST01 system trace using Tcode STAUT...
      • Introduction to SAP basis
      • SAP Router configuration and renew of the SAP rout...
      • Maintain/Restore Authorization Groups
      • How to check Active Directory account is locked or...
      • Useful SAP Security Tcodes
      • Excel - remove duplicate and replace it with blanks
      • Extracting Text Between Brackets with Excel Sheet
      • How to get a list of userID from LDAP distribution...
      • Top 10 SAP security implementation steps
      • How to create SAP gateway service (Employee Infor...
      • How to Download/Upload SAP Note in SNOTE
      • SAP SECURITY INTERVIEW - BEST PRACTISES
      • How to Implement SAP note in SNOTE
    • ►  September (1)
    • ►  August (3)
    • ►  June (1)
  • ►  2014 (1)
    • ►  August (1)
  • ►  2013 (2)
    • ►  December (1)
    • ►  March (1)
  • ►  2012 (5)
    • ►  June (3)
    • ►  February (2)
  • ►  2011 (88)
    • ►  October (3)
    • ►  September (8)
    • ►  August (8)
    • ►  July (4)
    • ►  June (14)
    • ►  May (22)
    • ►  April (11)
    • ►  March (14)
    • ►  February (2)
    • ►  January (2)
  • ►  2010 (1)
    • ►  October (1)
  • ►  2009 (17)
    • ►  October (12)
    • ►  September (1)
    • ►  August (3)
    • ►  June (1)
  • ►  2008 (20)
    • ►  January (20)
2013-2017. Powered by Blogger.
HOW TO SAP

GRC 10 - Firefighter tcode

October 30, 2017   ffid, firefighter, grc 10, tcode,
Child system/GRCPI/GRIA_EAM
CentralizedGRAC_SPM
Continue Reading

SPRO missing entry - launch with tcode SIMGH

October 27, 2017   Authorization, missing entry, security, SIMGH, spro,

  • Launch SIMGH
  • Find structure under IMG structure
  • Then click display
  • Continue Reading

    How to Created Background Jobs in SAP - SM36

    October 26, 2017   background job, sm36,
    Background jobs in SAP system run in the background without affecting normal operations in the system. These jobs are used to reduce manual effort and to automate the process. They can run in the background without any user input and can be scheduled to run when the system load is low.
    Background jobs can be divided into three categories −

    Class A (High Priority)

    This is used for urgent or critical tasks and must be scheduled with class A priority job. Class A job reserves one or more background work processes.

    Class B (Medium Priority)

    These jobs are executed after the completion of high priority jobs of Class A.

    Class C (Low Priority)

    The jobs in this category run once class A and class B jobs are completed.
    Transaction Code SM36
    SAP SM36

    General Data

    Enter the Job Name and its Priority.
    Select the target server on which you want to execute the job. This is used for load balancing; you can define the target server on which you want to run the job.
    Define Background
    Using Spool List Recipient, enter the email id if you want to get the results in email.
    Recipient
    To define the steps for execution, go to the Step Tab. Enter program name, variant name in the field. If you have not created variant as per your requirement, then leave it blank. Click on the save button at the bottom.
    Create Step 1List Overview
    To pass the start condition, enter the start date, end date, frequency, etc. In case the start condition is not specified, then the job will remain in scheduled state and will not run. Various options can be used to define the start condition. To create a periodic job, select the box at the bottom.
    Background Job
    Once the schedule is defined, click on Save.
    Schedule is Defined

    Continue Reading

    SSO Parameter value

    October 25, 2017   Authorization, parameter, security, sso,


    login/password_change_for_SSO
    Handling of password change enforcements in Single Sign-On situations

    Valid Input, Formats, Areas:

     0 =  Ignore requirement for password change(=> backward compatible)
     1 = Popup with selection 2 or 3 (User decides, default)
     2 = Password change dialog only (Entry: Old and new password)
     3 = Deactivation of password (automatic, no popup)
    Continue Reading

    Frequently used SE16 Tables for SAP security authorization

    October 25, 2017   Authorization, se16, security, tables,

    • AGR_USERS : Assignment of roles to users  Basis - ABAP Authorization and Role Management
    • AGR_TCODES : Assignment of roles to Tcodes  Basis - ABAP Authorization and Role Management
    • BUT100 : BP: Roles  Basis - Use AP-MD-BP* Components
    • SRRELROLES : Object Relationship Service: Roles  Basis - General Object Relations
    • EKPA : Partner Roles in Purchasing  MM - Purchasing
    • AGR_AGRS : Roles in Composite Roles  Basis - ABAP Authorization and Role Management
    • AGR_DATEU : Personal settings for roles  Basis - ABAP Authorization and Role Management
    • AGR_USERT : Assignment of roles to users  Basis - ABAP Authorization and Role Management
    • AAA_ROLES2 : SAP Authorization Assistant - Roles no longer Managed  Basis - ABAP Authorization and Role Management
    • AAA_ROLES : SAP Authorization Assistant - Roles Managed by Tool  Basis - ABAP Authorization and Role Management
    • AGR_TCDTXT : Assignment of roles to Tcodes  Basis - ABAP Authorization and Role Management
    • EHSWAT100 : MD (BDT): Business Partner Roles  Environment, Health and Safety - Waste Management
    • CACS_AGRROL : Participant Roles in Participation Agreement  ICM - Incentive and Commission Management (ICM)
    • AGR_SELECT : Assignment of roles to Tcodes  Basis - ABAP Authorization and Role Management
    • AGR_TCODE3 : Assignment of roles to Tcodes  Basis - ABAP Authorization and Role Management
    • BPFRG : OBSOLETE TABLE: Business Partner: Roles for Release  Fi Services - Business Partner
    • USLA04 : CUA: Assignment of Users to Roles  Basis - User and Authorization Management
    • USRSYSACT : CUA: Roles in Distributed Systems  Basis - User and Authorization Management
    • TB003T : BP Roles: Texts  Basis - Use AP-MD-BP* Components
    • USRSYSACTT : CUA: Roles in Distributed Systems  Basis - User and Authorization Management
    • TB003E : BP Role Exclusion Groups -> BP Roles  Basis - Use AP-MD-BP* Components
    • DPR_RATES : Customizing: Cost/Revenue Rates for Project Roles  PPM - cProjects Accounting Integration
    • TDLOAN_CPPART : Default Sttng of Permitted Roles and Roles for Partner Copy  Fi Services - Loans Management
    • TE673 : Installation Roles in an Installation Group  IS - Contract Billing
    • TE673T : Names of Installation Roles  IS - Contract Billing
    • AGR_USERS - Assignment of roles to users  Basis - ABAP Authorization and Role Management
    • AGR_1251 - Authorization data for the activity group  Basis - ABAP Authorization and Role Management
    • AGR_DEFINE - Role definition  Basis - ABAP Authorization and Role Management
    • AGR_TCODES - Assignment of roles to Tcodes  Basis - ABAP Authorization and Role Management
    • AGR_1252 - Organizational elements for authorizations  Basis - ABAP Authorization and Role Management
    • AGR_HIER - Table for Structure Information for Menu  Basis - ABAP Authorization and Role Management
    • AGR_AGRS - Roles in Composite Roles  Basis - ABAP Authorization and Role Management
    • UST12 - User master: Authorizations  Basis - User and Authorization Management
    • AGR_PROF - Profile name for role  Basis - ABAP Authorization and Role Management
    • PRGN_CUST - Customizing settings for authorization process  Basis - ABAP Authorization and Role Management
    • USR10 - User master authorization profiles  Basis - User and Authorization Management
    • BUT100 - BP: Roles  Basis - Use AP-MD-BP* Components
    • AGR_TEXTS - File Structure for Hierarchical Menu - Customer  Basis - ABAP Authorization and Role Management
    • SSM_CUST - Set Values for the Session Manager / Profile Generator  Basis - Session Manager
    • USR12 - User Master Authorization Values  Basis - User and Authorization Management
    Continue Reading

    Creating a Trusted RFC between SAP ECC and HANA

    October 25, 2017   hana, rdc,
    Suppose, you want to set up a trusted RFC towards target system BB1 on your source SAP system AA1. With the completion of the setup, you would be logged onto AA1 and your user would have enough authorization in BB1; you can use the RFC connection and logon to BB1 without having to re-enter username and password.
    Using RFC trusted/trusting relationship between two SAP systems, RFC from a trusted system to a trusting system, password is not required for logging on to the trusting system.
    Open SAP ECC system using SAP logon. Enter transaction code SM59 → this is the transaction code to create a new Trusted RFC connection → Click on the 3rd icon to open a new connection wizard → click on Create and a new window will open.

    SAP ECCConfiguration
    RFC Destination ECCHANA (Enter name of RFC destination) Connection Type — 3 (for ABAP system)
    Go to Technical Setting.
    Enter target host — ECC system name, IP and enter system number.
    /connection Type
    Go to Logon & Security Tab, Enter Language, Client, ECC system username and password.
    Test RFC SAP
    Click on the Save option at the top.
    Destination
    Click on Test Connection to successfully test the connection.
    RFC Connection Test

    Configuring RFC Connection

    Follow these steps to configure RFC connection −
    Step 1 − Run transaction — ltr (to configure RFC connection) → New browser will open→ Enter ECC system username and password and logon.
    Monitoring
    Step 2 − Click on New → New Window will open → Enter configuration name → Click Next → Enter RFC Destination (connection name created earlier), Use search option, Choose name and click Next.
    Create Configuration
    Step 3 − In Specify Target system, Enter HANA system admin username & password, host name, Instance number and click Next. Enter number of data transfer jobs like 007 (it can’t be 000) → Next → Create Configuration.

    Testing Trusted RFC

    Click on Test Connection to successfully test a connection.
    Trusted RFCConnection Test

    Continue Reading

    SAP Query using tcode SQVI with username and email as the result

    October 23, 2017   Authorization, query, security, sqvi, user email,

  • SQVI
  • Quickview: Email
  • Click Create
  • Datasource: Table Join
  • Ok
  • Edit > Insert Table (both tables)
    ADRP
    ADR6
    USR21
  • Click Check. If defined joined condition is correct, click back
  • Expend and select the field you would like to see in the result

    eg: First Name, Last Name, E-Mail Address and User Name in User Master Record
  • Click on selection field tab. Select user name in master data. Add to the left column.
  • Click check for errors. If none, then proceed to execute
  • Now you can search using username and it will show your the first name, last name and email address
  • Continue Reading

    BW on HANA migration handbook for SAP Basis team

    October 23, 2017   BASIS, bw, hana,
    Source: https://blogs.sap.com/2016/10/12/bw-hana-migration-handbook-sap-basis-team/

    BW on HANA migration handbook for SAP Basis team
    I would like to share my experience with migrating large SAP BW system running on traditional database (Oracle, DB2, MSSQL) to BW on HANA. Even though there are many blogs available, it’s difficult to get an end-to-end BW HANA migration document with detail step-by-step  procedure. So I would like share my approach and best possible pre/post SAP Basis steps  involved in BW HANA migration project. First of all those who are new to HANA and SAP OS/DB migration process I would like to give some overview about BW on HANA migration Process.
    Table of Content
    1. Overview of BW on HANA Migration Process
    2. Step-by-step BW on HANA Migration process
    2.1 Check PAM, read all relevant OSS notes, upgrade/migration documents
    2.2 BW HANA Migration cockpit
    2.2.1 BW HANA migration readiness check
    2.2.1.1 Generic Checklist Tools
    2.2.1.2 BW object check
    2.2.2 Sizing Overview
    2.2.3 Essential Housekeeping tasks
    2.2.4 Optional Housekeeping tasks
    2.2.5 Checks for BEx query
    2.2.6 Security specific checks
    2.2.7 ABAP specific checks
    2.3 Migration export/import
    2.3.1 Classical Migration approach
    2.3.1.1 Split JAVA stack ( in case of dual stack system ).
    2.3.1.2 Export Preparation run
    2.3.1.3 Table splitting
    2.3.1.4 Determine the customize order of export/import
    2.3.1.5 Run the report SMIG_CREATE_DDL
    2.3.1.6 Migration export
    2.3.1.7 Target system build and HANA import
    2.3.1.7.1 HANA Appliance check
    2.3.1.7.2 Perform Import
    2.3.2 DMO approach
    2.4 Post migration tasks
    3. Best practice in place

    1. Overview of BW on HANA Migration Process
    I would like to share my experience with migrating large SAP BW system running on traditional database (Oracle, DB2, MSSQL) to BW on HANA. Even though there are many blogs available, it’s difficult to get an end-to-end BW HANA migration document with detail step-by-step  procedure. So I would like share my approach and best possible pre/post SAP Basis steps  involved in BW HANA migration project. First of all those who are new to HANA and SAP OS/DB migration process I would like to give some overview about BW on HANA migration Process.
    • Overview of BW on HANA Migration Process
    • Step-by-step BW on HANA Migration process
    • Best practice in place
    Technically BW on HANA Migration process consisting of database level export of SAP data from traditional database and import into HANA database.

    Fig -1 : BW on HANA migration high level overview
    There are multiple ways you can migrate SAP BW system running with any database to BW running on HANA. It could be combine upgrade and migration approach (using SUM with DMO) or it could be two steps approach first upgrade to minimum level of BW 7.3/BW7.31/BW7.4 which is require for HANA migration than migrate to BW on HANA using SWPM (Software Provisioning Manager). In a situation where you have already upgraded your SAP BW system to BW 7.3/BW7.31/BW7.4 release with the latest patch level, in that case you can migrate to BW on HANA easily using classical approach.
    For Basis folks – it’s another type of OS/DB migration however there are few differences in terms of tools involved and HANA specific pre and post steps. When you talk about tools, till now “Distribution Monitor” cannot be used for BW on HANA migration. There is a special tool “SUM with DMO” specifically design for HANA migration as ‘one-step-approach’ tool – which support combine approach of upgrade and migration (+ Unicode conversion).
    In nutshell BW on HANA migration consisting of an export run – which will export any database data into a common location (file system or memory pipe ) and an import run will write data from common location to HANA database ( as show in fig-1). So it’s similar to any other SAP OS/DB migration steps. In the following section I will explain you detail steps/processes involve in BW on HANA migration project.
    1. Step-by-step BW on HANA Migration process
     When you start BW on HANA migration project, being a SAP Basis technical folk, there will be number of questions come to your mind about tools, technology, new database, migration methods etc. A typical question is what to do first? Where to start? Sizing and vendor selection should be first or BW system evaluation should be first? To address these questions, based on my experience I came up with the following solution approach. There are certain steps you have to perform in parallel. I would like to highlight all major steps those will cover most of your BW on HANA migration activities. To begin with please follow the sequence as
    • Check PAM, read all relevant OSS notes, upgrade/migration documents
    • BW HANA Migration cockpit (pre/post tasks )
    • Migration export/import
    • Post migration tasks
    Please see the below high level steps:
    Fig-2 : BW on HANA Migration High level steps 
    2.1 Check PAM, read all relevant OSS notes, upgrade/migration documents
    This is one of the areas where SAP Basis folks spent large amount of time to figure out compatibility, dependency of SAP products during any upgrade/migration. Like any other SAP upgrade/migration, first check the dependency of target SAP BW release with other SAP products (ECC, CRM, SRM etc). Figure out all restrictions and best practice for source and target BW release.
    Validate patch dependency from generic release note. Please find the following useful OSS notes to figure out any restriction and patch dependency ( I have assumed your target SAP BW release is BW 7.4 ).
    – 1751237 – Add. info about the update/upgrade to SAP NetWeaver 7.4 (incl. SPs and SRs)
    – 1850327 – SP Equivalence for update/upgrade to SAP NW 7.4
    – 1730102 – Release Restrictions for SAP NetWeaver 7.4
    – 1826531 – Add-on compatibility of SAP NetWeaver 7.4 – ABAP
    For each support pack level of HANA, there is a release note. Make sure you have read that OSS note atleast once ( Please find the SPS 11 and SPS 10 release notes ).
    – 2227464 – SAP HANA Platform SPS 11 Release Note
    – 2165826 – SAP HANA Platform SPS 10 Release Note
    Apart from dependency analysis, please check the following BW on HANA specific OSS notes:
    – 1736976 – Sizing Report for BW on HANA
    – 1650394 – SAP HANA DB: Partitioning and Distribution of Large Tables
    – 1909597 – SAP NetWeaver BW Migration Cockpit for SAP HANA
    – 1855041 Sizing Recommendation for Master Node in BW-on-HANA
    – 1829728  BW Housekeeping Task List
    – 1777465 SAP HANA Feasibility Check for Netweaver BW on HANA
    – 1637145  SAP BW on HANA: Sizing SAP In-Memory Database
    – 706478   Preventing Basis tables from increasing considerably
    – 1847431    SAP NetWeaver BW ABAP Routine Analyzer
    – 1729988    SAP BW powered by SAP HANA – Checklist Tool
    Please make sure you know about association between HANA Support pack level and HANA revision number range. Please check the following matrix :
    HANA 1.0 SPSStarting revision number
    SPS 0660
    SPS 0770
    SPS 0880
    SPS 0990
    SPS 10100
    SPS 11110 
    2.2 BW HANA Migration cockpit
    Once you gather all information by reading various OSS notes and upgrade/migration documents, there will be many questions in your mind – what is the best tool to use for pre/post migration work? Which one should you start first ? What is the best way to organize all pre/post work so that you should not miss any important step? You are almost certain that you have to perform many pre and post migration activities and it’s a tedious process to maintain the entire list of tasks. So question is how to track each activity. To overcome all these issue and streamline execution of all essential pre & post migration steps SAP comes up with a tool called – “BW HANA Migration cockpit”. Using this migration cockpit tool Basis and BW team can manage and execute all essential pre and post migration steps from a single window. Please note that, this is a combined effort of both SAP Basis and SAP BW team – both the team must work together to perform all pre/post-migration activities.
    To access BW HANA migration cockpit run the ABAP program : ZBW_HANA_MIGRATION_COCKPITand this program is part of
    SAP OSS note : 1909597 – SAP NetWeaver BW Migration Cockpit for SAP HANA
    If this ABAP program : ZBW_HANA_MIGRATION_COCKPIT does not exist in your system, please implement the OSS note : 1909597.
    When run the ABAP program: ZBW_HANA_MIGRATION_COCKPIT, BW HANA, migration cockpit will invoke and it looks like the following:
    Fig-3 : BW on HANA Migration cockpit
    Each ‘Tab’ represents a specific set of activities. Particularly tasks under –  Check, Size, Housekeepingand Migrate tabs are important pre-migration tasks for Basis folks and SAP always advice to complete all these tasks. I will cover all four essential tabs and underlying (important) activities.
    2.2.1 Check ( BW HANA migration readiness check )

    Fig-4 : BW on HANA Migration readiness checks
    “Check” tab contains all essential pre-migration checks. Execute each “check’ run as background job and fix all issues reported by each check run.
    The most important checks are :
    • Checklist tool ( all generic SAP, Database and OS specific checks )
    • Table consistency check
    • PSA consistency check
    • BW objects checks. 
    2.2.1.1 Generic Checklist tools
    One of the initial tasks for BW on HANA migration project is to execute “migration checklist’ or “HANA migration readiness check”. This will validate whether your current SAP BW system is full filling all conditions /restrictions for BW on HANA migration requirements? This involves – database consistency check, Generic SAP release and patch checks, OS specific checks and BW objects checks.

    Fig-5 : BW on HANA Migration cockpit – checklist tool
    An alternative approach to execute the migration checklist is to run the following ABAP-program (as per your current SAP BW release. )
    ZBW_HANA_CHECKLIST ( for BW 7.x and higher )
    ZBW_HANA_CHECKLIST  (for lower BW release)
    If this ABAP-program is not available in your system, please implement the following OSS note :
    SAP OSS note “1729988 – SAP NetWeaver BW powered by SAP HANA – Checklist Tool”
    Before executing this check run please make sure you have selected the correct SAP BW release in “Option” tab.
    Select target release for SAP BW :
    • 730 or 7.31
    • 740
    However I would strongly recommend to run the checklist utility through “BW HANA Migration cockpit” rather than an individual program.
    Migration checklist comes with the following type of results set.
    Fig-6 : BW on HANA Migration cockpit – checklist result.
    SAP always recommends to address each and every issue (error flag with ‘red’ error sign)  as a pre-migration steps before actual migration. Both SAP Basis and BW team need to work together to address all these issues.
    2.2.1.2 BW objects check.
    After Basis specific system check nest step is to check the consistency of BW objects. Normally “BW team” is responsible for this check and corresponding fixes.
     Fig-7 : BW on HANA Migration cockpit – BW object checks
     Fig -8 : BW object checks
    2.2.2 Sizing Overview
    Sizing is one of the complex areas where you need to put lots of effort. It may runs for weeks or months and it will go throw multiple iterations. It involves multiple team, vendor etc. In general sizing is the first project task that needs to be completed before project kick off. I am not going to cover entire sizing exercise details for BW on HANA; rather I will explain you about few important sizing parameters and how to go about BW on HANA sizing exercise. It should be combination of SAP Quicksizer tool and SAP provided scripts/report for estimating HANA sizing.
    Important parametersSizing inputs :
    MemoryDatabase footprint, compression factor
    CPUUser activity, query complexity and data volume
    DiskData volume, Log Volume, executables and backups
    Next question is how to go about sizing estimation for BW on HANA? Shall I start with SAP Quicksizer tool or directly involve hardware vendor. As a first step I would recommend to start with sizing report inside “BW HANA Migration cockpit” as follows:

    Fig -9
    This sizing report requires few inputs (both Basis and BW specific), so Basis folks need to work with BW team. Please note that, this is an estimation – so I would recommend to run the sizing report multiple times with different input combinations.

    Fig -10 : Sizing report input
    For parameter details please download the sizing guide line from the following OSS note :
    OSS note : 1736976 – Sizing Report for BW on HANA
    An alternative approach is to run the sizing report /SDF/HANA_BW_SIZING  directly (if “BW HANA Migration cockpit” is not available in your system ). If this report is not available in your system, please implement the following OSS note.
    OSS note : 1736976 – Sizing Report for BW on HANA
    After running this report with appropriate inputs, you will get the sizing report (HANA_sizing.txt) file), you can estimate your target sizing configuration. You can share this file with your hardware vendor as per of your HANA appliance procurement process.
    Next step is to run the SAP Quicksizer tool with appropriate parameters input. So my recommendation is to run both “Sizing Report” and SAP Quicksizer tool.
    2.2.3 Essential Housekeeping tasks
    SAP always recommends that delete all unwanted old logs, trace etc from the system on a regular basis so that it prevent un-expected growth of logs and trace tables. From export/import optimization point of view you should delete old logs, trace and audit information from database tables (as much as possible)  so that it will contribute to optimization / time reduction for export/import. For application specific logs deletion discuss with BW team. I would recommend to use “House keeping” option from “BW HANA Migration” work bench to perform mandatory cleanup tasks. If you are using SUM with DMO – it enforced to cleanup few BW specific old logs/traces during check phase.
    Fig-11 : BW on HANA Migration cockpit – Housekeeping tasks
    If you are performing upgrade and migration together (using SUM with DMO)  use “Before upgrade housekeeping tasks” list :
     Fig-12 :
    Perform all steps in sequential manner and consultant with SAP BW team for BW specific activities.If you are not performing combine upgrade and migration use “BW housekeeping tasks” as part of migration cleanup tasks.
     Fig-13
    Perform all steps in sequential manner and consultant with SAP BW team for BW specific activities.
    2.2.4 Optional House Keeping tasks
    I believe most of the Basis folks are familiar with the following housekeeping related OSS note
    706478 – Preventing Basis tables from increasing considerably.
    Perform cleanup / reorg of SAP Basis specific tables. Cleanup all unwanted old logs.
    Apart from Basis specific steps, perform all BW specific cleanup steps (starts from item #35) as per the OSS note: 706478; primarily
    • All BW statistics tables name starts with : RSDDSTATxxxxxx
    • BW authorization logs table: RSECLOG.
    • BW PSA tables and DSO change logs: tables /BIC/B*.
    • DTP and PSA Log : RSBERRORLOG, RSERRORHEAD, RSERRORLOG
    • BW process Chain Run Logs: RSPCPROCESSLOG
    I would like to recommend to delete/cleanup old logs/trace data as much as possible – as per your organization’s retention policies.          
    Apart from the above mentioned cleanup activities – please perform following additional tasks: 
    1. Delete invalid temp (QCM) tables (SE14).
    2. Check the DDIC consistency (Run program RSUPGRCHECK ).
    3. Split Java stack ( in case of dual stack BW system )
    4. Use RSECADMIN to cleanup RSECLOG ( BW Authorization )
    5. Validate Export/Import file system ( space & permission )
    6. In case of Oracle or DB2 set a large temporary tablespace in source system
    7. Prepare a list of large tables ( for splitting)
    8. Update Database statistics.
    9. Delete BW temporary tables (SAP_DROP_TMPTABLES)
    10. Delete old PSA data (RSAR_PSA_CLEANUP_DEFINITION).
    11. Repair Inconsistent Info Packages with transaction RSBATCH
    12. Perform Delta Q cleanup (RSA7).
    SAP_DROP_TMPTABLES :
     Fig-14
    Report : RSBATCH
    Fig-15
    2.2.5 Check for BEx issue
    SAP BW team needs to perform this step. As part of BW on HANA migration if you migrate from your lower BW release ( BX 3.x or BW 7.x ) you have to migrate/adjust your BEx queries.

    Fig-16
    So BW team need to covert/migrate lower release BEx queries to higher release of SAP using “BEx” tab in BW migration Workbench.
    2.2.6 Security specific checks
    You need to pay special attention in SAP security area if your security model is based on traditional instead of “BW object based security model or “BW analysis authorization”.

    Fig-17
    So using BW HANA Migration workbench – “Security” option,  Basis security and BW team can covert/migrate all old BW reporting based role into new BW analysis authorization model . SAP always advice this role migration should take place before actual BW release upgrade.
    2.2.7 ABAP specific checks ( Run ABAP Code inspector )
    This is one of most critical pre-migration steps to identified affect customize ABAP code due to HANA migration and effort require to remediate those affected code. This step will be perform by ABAP team

    Fig-18 : BW on HANA Migration cockpit – ABAP activities
    Most critical steps are :
    • ABAP Routine Analyzer and
    • ABAP Code Inspector
    ABAP Routine analyzer will help ABAP team to identify the code optimization require for your custom code once you migrate to HANA platform.
    Many ABAPer prefer to use “ABAP Routine analyzer” directly as per the following OSS note, instead of “BW Migration Workbench”.
    1847431 – SAP BW ABAP Routine Analyzer
    Download the ABAP report attached to this OSS note and run the following report as per your BW release :
    SAP BW release 7.0 or higher run the report à ZBW_ABAP_ANALYZER
    SAP BW release 3.5 run the report à  ZBW_ABAP_ANALYZER_3X
    Code Inspector will help you to use various tools to perform static and dynamic checks of the correctness of your ABAP programs and other objects.
    2.3 Migration export/import 
    You have completed all pre-tasks including cleanup and database stats update in the source system. Now next step is to perform the actual HANA migration export/import. There are two main approaches for HANA migration
    • Classical Migration approach
    • DMO approach
      Fig-19 : BW on HANA Migration export/importClassical Migration approach : Once your SAP BW system meets the minimum required support pack level ( eg : BW 7.3 SP13 ) to migrate to HANA you can use classical migration approach (, no need to upgrade the SAP BW system along with migration). This migration approach is similar to any SAP OS/DB migration methodology, where you need to perform export (using SWPM/MigMon) and import to HANA database. You can use parallel export/import or offline approach based on your infrastructure situation. There are many organizations prefer to use two steps approach of upgrade the current SAP BW system to BW 7.31/BW 7.4 , stabilize and use the classical export/import approach to migrate to HANA.DMO approach : SAP introduced DMO (Database Migration option) along with upgrade tool SUM (since SUM 1.0 SP9). So using DMO of SUM you can perform both SAP release upgrade and Migration (including Unicode conversion) as one steps approach. With DMO approach there is only one downtime window for HANA migration project; that means  there is no separate downtime or testing effort for upgrade and migration. You can combine both into one downtime window and testing effort.
    • 2.3.1 Classical Migration approach 
    You need to perform the following steps as part of your classical HANA migration approach
    • Split JAVA stack ( in case of dual stack system ).
    • Export Preparation run
    • Table splitting
    • Determine the customize order of export/import
    • Run the report SMIG_CREATE_DDL
    • Migration export
    • Target system build and HANA import
    2.3.1.1 Split Java stack ( in case of dual stack system )
    In case of dual stack BW system, split the dual stack . If necessary build your BI-JAVA system and perform the integration. I am not going to cover Java stack split here, as it’s more generic Basis activities.
    2.3.1. 2 Export preparation ( in Source system )
    This step is required to create the export file system structure and I believe most of the Basis folks are familiar with this step.

    Fig-20
    All inputs are very clear. Make sure you put correct input for “Export Location”
    2.3.1.3 Table splitting
    Please use R3ta / Java splitter for table splitting. The simplest way is to use SWPM: 

    Fig-21
    The most important input for table splitting is a text file with list of largest  tables and associated number of splits :

    Fig-22
    Here I passed “split_input.txt” file as input for table split. The content of the file is as follows :
    Table-1%split numbers
    Table-2%split numbers
    After successful run of table splitter it will generate *.WHR file in “DATA” directory of export location.
    2.3.1.4 Determine the customize order of export/import
    Order of export and import will play a vital role for your overall export/import time. As a general rule of thumb larger table should in the top of the order_by.txt file
    You need at least two end-to-end export/import run to optimize order_by.txt input. First run with generic rule of thumb and second run with optimize order.
    2.3.1.5 Run the report SMIG_CREATE_DDL
    Before starting the export you have to run the SMIG_CREATE_DDL report to generates structure (*.STR) files for “non-database” specific tables. This is common for any OS/DB migration activities however for HANA migration SAP added few enhanced features to SMIG_CREATE_DDL report.
    For detail enhancement please see the following OSS notes
    Note : 1921023 – SMIGR_CREATE_DDL: Corrections and enhancements for SAP HANA 
    2.3.1.6 Migration export
    Now you need to start your actual export using SAPINST (SWPM). At this stage you have performed all pre-tasks and please note the following recommendation:
    • Kick of your export/import from CI/PAS or any SAP App server, so that you can increase the number of R3load processes and fully utilize db-host resource for database purpose only.
    • If you run export from CI/PAS or SAP App Server – associate the export file system to the App server ( instead of NAS or NFS ).
    • If possible (within the same data center ) use parallel export/import
    • For SWPM log directory use local file system.
    Now start the SWPM to start your export as follows. I have included all important input screens :
    If your target database is BW 7.31 – please download the rowstotelist.txt file from the following OSS note and place into <EXPORT>/ABAP/DB/HDB location
    1659383 – RowStore list for SAP Netweaver 7.30/7.31 on SAP HANA database
    Fig-23
     Path is NW 7.x (current source release ) à Current source database à System Copy à Source system à Based on AS ABAP à Database instance Export

    Fig: 24 : Export location :
     

    Fig-25 : 
    Location of  file those are generated by SMIGR_CREATE_DDL 

    Fig – 26
    You have to select Target Database Type à SAP HANA Database 

    Fig-27
    These are similar kind of inputs use for any OS/DB migration project. The most critical input is “Number of parallel Jobs”. I would recommend to use 3-4 R3load processes per Physical CPU and 2-3 R3load processes per vCPU.
    For Linux OS (currently HANA supports on Linux) you have to select “Little Endian” as Target Hardware Platform.
    SWPM will generate an order file ( order_by.txt ) in SWPM log directory. You can manipulate this file and set your customize order. Best approach is to copy this file and include your customize order of export/import.
    Network exchange directory is needed in case of parallel export/import. If you are not using parallel export/import this selection will be not available. 

    Fig-28
     After all input kick off your export and monitor till the end. There are many ways you can monitor including SWPM status bar ( which contains currently running processes, completed and failed processes ).
    2.3.1.7 Target system build and HANA import
    Target system build and HANA import step consisting of the following. There are many steps those are new as compared to traditional OS/DB migration. I will focus mostly on all new steps come as part of HANA import. 
    • HANA Appliance check
    • Perform Import
    2.3.1.7.1 HANA Appliance check
    Once you receive your HANA appliance hardware from your h/w vendor first thing is to perform HANA h/w check and perform basic sanity check whether HANA appliance are delivered and setup as per your requirement or not.  For more detail info check the following OSS note :
    1652078 – SAP HANA database: Hardware check
    Execute HanaHwCheck.py‘ python script available ‘/usr/sap/<SID>/HDB<instanceNumber>/exe/python_support’ location.
    Do not confused with the tools or check performed for TDI approach. If you are using TDI (Tailored Data Center Integration) approach use the following OSS note to validate your HANA infrastructure (including storage and network bandwidth ).
     1943937 – Hardware Configuration Check Tool – Central Note
     OS level parameter settings :
    For each OS release there is a specific OSS note talks about OS level settings. For example if you are using Redhat Linux 6.5 please use the following OSS note to validate you OS settings:
    2013638 – SAP HANA DB: Recommended OS settings for RHEL 6.5
    Similarly for SUSE Linux 11. x you will get specific guideline for OS level settings.
    Generic Basis HANA check
     Verify your HANA appliance – memory, CPU and node info. Logon to HANA studio and verify the followings: 

    Fig-29
    Fig-30 : HANA Studio à Landscape à verify all services and hosts ( in case of scale out setup ).
    Fig-31
     Verify HANA files systems – data volume and log volume etc.
                            2.3.1.7.2          Perform Import
    It’s highly recommended to set the HANA database log mod to ‘overwrite’ before start of the import. You set this setting from HANA Studio à Configuration. If you have already setup your HA/DR for HANA database, please disable during import phase.
    Now start your SWPM to import HANA database.
    Before import set the following OS environment variables for the SWPM sessions:
    MASSIMPORT=YES
    In the following section I will focus on HANA specific input, all other steps are similar to traditional OS/DB migration inputs. 

    Fig-32
     
    In the above example I have showed BW 7.4 as target release. Select HANA Database  à System Copy à Target system à Distributed System à
    Install ASCS instance first ( it’s standard for any SAP system ). There are many arguments whether install the ASCS in HANA database server or in SAP Primary App servers. HANA SP08 onwards support ASCS installation on HANA database server. My recommendation is to isolate HANA database server from SAP components. So install ASCS instance on SAP Primary App server. In case of HA setup you need multiple SAP servers to install ASCS/ERS etc.
    Once you completed your ASCS installation proceed with your “Database Instance”.
    You can run SWPM  “Database Instance” from SAP CI/PAS  or directly from the DB host.

    Fig-33

    Fig-34
     : HANA Client software media 

    Fig-35 :
    Migration export location
    Fig-36
     HANA Database specific parameters. I would recommend to keep the same schema name and password as your source system.
     Fig-37: HANA specific parameter – use the default one.
    Fig-38 : Use the default parameters
    Fig-39
    Download the file TABLE_PLACEMENT.TXT  from   OSS note1819123 – BW on SAP HANA SP5: landscape redistribution:
    This file is applicable for scale out setup and determine how various BW objects (eg : DSO, PSA and Infocube tables )  are partitioned across multiple slave hosts.

    Fig-40 :
    These are generic OS/DB migration parameters.
    Fig-41
    Once you successfully completed the import, install your SAP PAS and perform all post migration tasks ( refer to 2.4 Post Migration section )
    2.3.2 DMO Approach
    As of SUM 1.0 SP9 SAP introduced a new capability called “DMO – Database Migration Option” along with SUM tool to perform both Upgrade and HANA migration as single run approach. If your source SAP release (DB + OS combination) supports DMO options, no need to perform BW on HANA migration as two steps approach. So DMO option cut down to a single downtime approach as compared to multi steps upgrade and migration work.

    Fig-42 : DMO approach vs Classical two steps approach
    How DMO approach works
    DMO approach is similar to any SAP upgrade steps plus your HANA migration export/import. One of the interesting fact is that upgrade downtime steps executed on Target systems (after export/import of application data) that why there is no changes to source system and if situation demand you can easily reset uptime of upgrade part in source system. Please find the following figures for explanation of DMO steps :

    Fig-43
     : Upgrade Uptime and Application data export/import

    Fig-44
     : Upgrade downtime executed on the target system
    Before staring SUM with DMO read all relevant OSS notes:
      1799545 – Using DMO of SUM for SAP BW systems
    Also gather all information about restrictions ( dos and don’ts ) for particular SUM support release. You can get these information from release note of SUM SPxx.
    e.g.: check the following OSS note for SUM 1.0 SP16
    2198483 – Database Migration Option (DMO) of SUM 1.0 SP16
    I am giving some important restrictions for SUM 1.0 SP16. However for all other points please go throw the SUM 1.0 SP specific release note:
    Sl NoRestrictionsExplanation
    1Minimum SAP BW source release
    Start release: SAP BW 7.00 (or higher)
    at least SP17 à SAP_BASIS 7.0
    at least SP02 à SAP_BASIS 7.01
    at least SP19 à SAP_BW 7.0
    at least SP02 à SAP_BW 7.01
    2Minimum BW Target releaseSAP BW 7.31 (or higher)
    3Minimum HANA DB version (for target system )SAP HANA version is 85 or higher
    Please find the following supported migration path (source and target release) by SUM 1.0 SP16.

    Fig-45
    You can download above mentioned (*.pdf file) matrix from SUM 1.0 SPxx release note.
    Some recommendation before starting DMO
    Sl NoAreasRecommendation
    1Technical requirement for SUM with DMOSAPHOSTAGENT must be running. If SAPHOSTAGENT is not installed in your system, you have to install.
    2Where to run SUM with DMOI would suggest executing DMO from PAS/CI of source system.
    3Source DatabaseIn most cases no need to upgrade / patch your current source database – however I would suggest to upgrade your source database to minimum database version / patch level as per the target system SAP release requirement.( please check PAM ).
    4Stack xml requirementFor DMO approach you need at least one support stack upgrade. For example if your current BW is BW 7.4 SP06and part of DMO approach you have to upgrade to at least BW 7.4 SP07 ( Current SP + 1)
    5Unicode conversionWith DMO approach migrating to BW 7.5 source system must be Unicode enabled. So combine Unicode conversion and HANA migration to BW 7.5 with DMO approach is not possible .Please note that it’s possible for migrating BW 7.4 release.
     Perform upgrade and migration using SUM with DMO
    DMO approach is a combine approach of upgrade and migration and most of the SAP Basis folks are familiar with SAP upgrade processes of SUM or SUM roadmap (Initialization à Extraction à Configuration à Checks à Preprocessing à Execution à Postprocessing ). So I will not cover generic upgrade steps in the following section and I will focus on new DMO steps:
    • Make sure SAPHOSTAGENT is running in your system (otherwise start / install ).
    • Start SUM à SAPUp process from OS level (SUMSTART)
    • Start DMO UI from browser ( of your local PC ) as follows :
    http://:1128/lmsl/upgrade//doc/gui
    Login using <sid>adm user and password

    Fig-46 : Extraction Phase:
    Fig: 47 Enter password for DDIC, <sid>adm and database password
    Fig-48
     You have to specify the target Database ( as SAP HANA ).
    One of the key inputs for “Landscape Reorganization for scale out HANA setup”. There are two main inputs
    • Phase : REQ_LANDSCAPE_REORG à download the .SQL file from the OSS note 1958346 – BW on SAP HANA: Landscape redistribution check procedures and pass as input.
    • Phase : REQ_LANDSCAPE_REORG_2 à download the file TABLE_PLACEMENT from the oss note 1908075 – BW on SAP HANA: Table placement and landscape redistribution and pass as input.
    Configuration Phase

    Fig-49
    This step is similar to any SAP upgrade. I would suggest to go with default “Standard Option” if your are not familiar with all Advanced mode selection.

    Fig : 50 HANA client media path
    .
    Fig-51
    Enter HANA Database specific parameters : hostname, HANA SID name, HANA instance number and license file

    Fig-52 : 
    Password for SAP<SID> or HANA schema user.
    Check Phase

    Fig – 53
     BW specific cleanup parameters. SUM tool enforces to cleanup few BW specific logs / trace etc.
    If you are not sure about these parameters, I would suggest involving SAP BW team for these parameters.
    Fig-54 
    ASU steps are similar to cleanup and BW specific pre-steps performed in “pre-migration” section using “BW Migration cockpit”. So it’s not necessary to perform those steps again. However I would recommend to manually start ASU toolbox and check any mandatory cleanup steps are missing.
    Preprocessing Phase
    Fig-55
    Preprocessing steps are similar to generic SAP upgrade steps, so I will not go throw all screens. Finally we are at the downtime phase of upgrade/migration.
    Downtime Phase :

    Fig-56
    During downtime phase actual application data migration (Reload export/import ) take place. Once all Application data migration completed connection changed from source database to target HANA database. After connection changed, SAP upgrade ‘downtime steps’ will be executed on Target HANA system till the end of the upgrade.

    Fig-57
    Postprocessing Phase

    Fig-58 
    SPAU phase.

    Fig-59

    Fig-60 
    DMO approach upgrade and migration completed.
    2.4 Post migration tasks
    This is one of the critical steps for any SAP migration projects and it’s primarily based on your environment / landscape. It could be a simple list of tasks without complex interfaces and inter connected systems. Apart from core HANA specific steps there could many steps related to your interfaces / interconnected systems. I will not cover any ABAP remediation, BW upgrade specific generic steps and interface specific issues rather I would highlight some key HANA specific steps :
    SlNoPost Migration tasksActivities
    1
    Run the RS_BW_POST_MIGRATION report

    Executing report RS_BW_POST_MIGRATION (which must be executed with variant SAP&POSTMGRHDB )
    2System Health check
    Perform a generic health check for HANA DB from HANA studio and perform generic health check from SAP level.
    Verify CPU usage, memory footprint and system load for HANA DB
    3
    Perform all post steps as per OSS note : 1734333

    Implement the OSS note 1734333 – BW Pre and Post Upgrade and Migration Tasks – perform all possible post tasks those are important for your landscape.
    Table consistency checkRun the report RSDU_TABLE_CONSISTENCY to check table consistency.
    4
    Perform all post steps from HANA Migration cockpit.

    Perform all possible post tasks those are important for your landscape using  ZBW_HANA_MIGRATION_COCKPIT
    5Change the default Log Mod and backup location from HANA database
    It’s highly recommended to change the HANA default backup location to a separate file system. Use HANA studio to change the backup location.
    Also change the Database log mod to ‘Normal’ for all important systems.
    6Security specific stepsExecute t-code RSADMIN with ENBL_HDB_MIGR_DSO=X
    7
    Validate BW source system connectivity (BW )

    Validate BW source system connectivity (BW )
    8Enable HANA standby node and DR replication
    Activate HANA standby node ( in case of n+1) scale out setup.
    Setup HANA DR site ( optional )
    9Install SAP Dialog instances
    Install SAP Dialog instances ( if exist )
    Note : Migration of SAP Application server is not supported by DMO of SUM approach
     10
    Migrate DSOs to new HANA optimized DSOs ( BW )

    This is BW specific steps, so BW team will perform this step.
     11
    Migrate InfoCubes to new HANA optimized InfoCube ( BW )

    This is BW specific steps, so BW team will perform this step.
     12
    Solution Manager setup and alert configuration

    Solution Manager setup and alert configuration

    3. Best practice in place

    Prior start of the migration; perform all necessary housekeeping tasks to delete unwanted data from database which will help to reduce downtime for migration.
    1. Consider Table splitting for larger tables.
    2. Use BW HANA Migration Readiness check ( as per OSS note : 1729988).
    3. User BW HANA Migration cockpit for pre/post migration work ( OSS note : 1909597 )
    4. Cleanup BW temporary and old PSA data as before migration.
    5. Please always use latest kernel, R3load and R3ta tools for export/import process to avoid errors.
    6. In order to speed up export/import process – prepare a list of tables/packages with appropriate order.
    7. Please always use latest list of row store tables for migration to HANA database (Note 1659383).
    8. Use HANA mass import option by setting the appropriate environment variables.
    9. Disable HA and DR setup during HANA migration import.
    10. Do not use parallel export/import in case of data center migration with low bandwidth.
    Continue Reading
    Newer Posts Older Posts Home
    Subscribe to: Posts (Atom)
    Designed By: Blogger Templates | Templatelib