SAP Community - SAP S/4HANA migration cockpit

SAP S/4 HANA Data Migration Cockpit: Migrate Your Data App Guide

2023-06-23T16:23:14+02:00

Hello All,

In this Blog post, I would like to explain

Data Migration Cockpit Overview

Migrate Data directly from SAP System.

Migrate Data using Staging Tables

Export Migration project

Context:

Previously we have Used LTMC to access the Migration Cockpit, SAP S/4 HANA 2020 an Later Versions We have Migrate Your Data that Support for Data Migration Activities.

Introduction

Migration Cockpit is a S/4HANA Fiori app that replaces LTMC.

In SAP S/4HANA 2020 and Later versions Support Migrate Your Data app.

Data Migration Cockpit Overview.

With this app, you can migrate business data to SAP S/4HANA. You can migrate data directly from certain SAP source systems, or you can use staging tables to migrate data.

Key Features

You can use this app to:

Create migration projects to migrate data, and to monitor the status of the migration.

Select the migration objects that are relevant for your migration scenario (the app uses migration objects to identify and transfer the relevant data).

Process any mapping tasks for the migration objects.

Simulate the migration before migrating your data to SAP S/4HANA, and monitor the status of the simulation process.

Migrate your data to SAP S/4HANA, and monitor the status of the migration.

Migrate Your Data App –Migration Approaches

Migrate Data Directly from SAP System

Migrate Data using Staging Tables

Available Migration Objects in Migration Cockpit and Migration Approaches.

Migrate Data directly from SAP System.

Prerequisites

Add-on DMIS needs to be installed in the source system (included in the license for SAP S/4HANA), check SAP Note 2973957.

RFC connection from ERP/AFS/EWM/CRM/APO SPP source to SAP S/4HANA target system.

Further details on section Project Setup.

Open SAPGUI:

T Code: /n/ui2/flp to Open Firoi Apps

Create the project:

a)General Data: Specify the Name/Scenario/RFC Details/Development Package.

b) Data Selection : Specify the required Company Code to Select the Data from Source.

c) Select the Object: Select the object

Key Features

Monitoring tab Will be use to track the status of activity and extract the logs(Errors/Warnings/information).

Job Management Tab will be used to increase the Background Jobs.

Select Data: in this Step Data Will be selected from the Source system.

We can exclude the selected instances based on field values.

Mapping Tasks: Field Conversion according to the business rules and Requirements.

Example:

Source Company code	Target Company code
0001	1000

Download the all mapping values and populate the values according to the Mapping sheet/Rules and Upload.
Simulation: Simulation is a test run against the target and provides the information/Errors/Warnings we can extract the logs by using monitor tab.

Finally Migrate Your Data.

Once Migration is completed we can check the data in the Target.

Common Errors:

Configuration Missing in Target.

Number ranges not defined.

RFC Related Errors

3.Migrate Data Using Staging tables.

Migrate using Staging table is widely used Method in Data Migration Cockpit.

Create the Project by Providing Name/Mass Transfer ID/Database connection Details and select the required object.

Mass Transfer ID:

it will be auto generated and unique for project(We can also populate valid ID).

Mass Transfer ID Will be used to Export the Project into another environment.

Database Connections: We have two option Local and Remote Database.

Staging tables will be created automatically along with project creation.

Populating Data into Staging Tables:

XML/CSV File Upload.

ETL Tools.

XML File Upload:

Populate the all mandatory sheets and fields in the template and upload.

Once file Uploaded We need to perform below steps.

Prepare: will prepare the staging tables in this step.

Provide the mapping task and proceed with the simulation and migration.

Once migration is completed if we have any errors Create Correction file option will be enabled.

Correction file :it will contain the failed records.

ETL Tools: (Data Services ,SDI)

We will use the BODS to populate the staging tables.

HANA Database Datastore required to import the DMC Staging tables into Data service.

Once Staging table imported into the data service Connect Source and LT table by using Query transformation, Provide the Required mapping and execute the job.

Provide the mapping task and proceed with the simulation and migration.

Correction file Option not available in ETL Approach.

4.Export Migration project.

scenario: if we have any Customized Migration Object available in system and want to move it to another system.

Version of the two system should be same.

Go to SE38 : /LTB/MC_PROJ_Q2P

Execute the Program and Provide Mass Transfer ID of the Project that you want to Export(Mass Transfer id will be available in Project settings.

Specify the Path to download attachment.

Once downloaded go to the system that you want import the Project and use the same T Code.

Select import and execute ,provide the file path to import.

Summary and Conclusion:

it's a over View of Fiori Data Migration Cockpit and loading Methods.

Please follow and refer the Page for DMC Updates

https://community.sap.com/topics/s4hana-migration-cockpit

Thanks for reading, please provide the your valuable feedback for the Blog.

Regards

Sandeep

Troubleshooting long running Data Migration Jobs.

2023-07-19T15:36:35+02:00

This is a powerful data migration tool included in the S/4HANA license and it delivers preconfigured content with automated mapping between source and target, this means that if your need matches the migration objects available, you do not have to build a tool from the scratch, it is all ready to use, reducing the effort of your data load team.

But when you run the Migration jobs the below symptoms can occur.

Migration jobs get stuck and running for a long period.

Preparation step has failed with run time errors.

Object is not ready for Import/Processing.

Validation is running for longer period.

This blog will guide you the step by step analysis about what you need to check and make the system to adopt the migration cockpit.

Step 1:Determining the state of the Technical Job Repository.

The Technical Job Repository screen should display one of the following messages:

Automatic Job Scheduling is switched off in this system
Indicates that the Technical Job Repository is deactivated on your system.

Automatic Job Scheduling is not active in this client
Indicates that the Technical Job Repository is activated on your system but deactivated on the client you are logged into.

Autom. Job Scheduling available in client, but user is locked
Indicates that the Technical Job Repository is activated on the system and the client you are logged into, but the step user is locked in transaction SU01. Step user may be a user you previously created and registered, user SAP_SYSTEM or user DDIC.

Jobs are automatically scheduled by Technical Job Repository
Indicates that the Technical Job Repository is activated on the system and the client you are logged into.

For example, It is recommended to have the below Job definitions activated in all the clients (Scope and Job status column should be green) . SJOBREPO - Transaction code.

/LTB/JOB_DISPATCHER

/LTB/RETENTION

Step 2:Maintain the step user.

The Technical Job Repository requires a step user, also known as a technical user, to schedule and run technical background jobs. Since step user creation is client-dependent, you should create the step user in every client where the Technical Job Repository is active.The step user is a system user assigned to the profile SAP_ALL. The user DDIC is a service user. For security reasons, you should lock the user SAP_SYSTEM. You can check the same in SJOBREPO_STEPUSER transaction.

Step 3: Run the program /LTB/JOB_DISPATCHER.

Step 4: Implement all corrections.

Follow the blog How to implement the latest corrections released for Migration cockpit | SAP Blogs

Step 5: User authorization.

Make sure that the dialog user(who execute migration) should have the below roles.

SAP_CA_DMC_MC_USER (SAP S/4HANA Migration - Data Transfer). This role allows users to start and run such activities.

SAP_BR_CONFIG_EXPERT_DATA_MIG (Configuration Expert - Data Migration). This role allows users to open and browse the Migration Cockpit app.

LTMC S/4HANA 2022 - Migrate Your Data

2023-08-03T15:39:48+02:00

In this blog post, I am going to explain the step-by-step execution of data migration through "Migrate Your Data" app in S/4HANA 2022 version. As you are aware that Migration Cockpit (Transaction LTMC) – Deprecated from 2020 version onwards. So, to migrate your data, we need to use “Migrate Your Data” app only. The app Migrate Your Data - Migration Cockpit is the successor of the Migration Cockpit (Transaction LTMC) app. The Migration Cockpit (transaction LTMC) app is deprecated and can no longer be used to migrate data to SAP S/4HANA.

Some of our friends already posted blog posts on LTMC topic with lower versions. In this version (2022) is little different than other old versions. Preparing the Migration template with Excel file wise there is no difference but process wise have some differences.

This topic we can divide into two parts.

A. Project Creation

B. Data Migration

Part A: Project Creation:-

Typically, you first create a project in a test system which is a copy of the SAP S/4HANA production system. The more the data in the test system resembles the data in the production system, the more precise your test will be.

For each test transfer, you create a new migration project in the test system that includes any corrections or refinements identified in the previous test. When you are finally ready to transfer your data to the SAP S/4HANA production system, you create a project in the production system.

To transfer data using the SAP S/4HANA migration cockpit, a user with the role SAP_CA_DMC_MC_USER is required in the SAP S/4HANA system. This user must also have the role SAP_BR_CONFIG_EXPERT_DATA_MIG for the front-end server.

To create a Project, use “Migrate Your Data” app. With this app, you can migrate business data to SAP S/4HANA. You can migrate data directly from certain SAP source systems, or you can use staging tables to migrate data.

Choose Create and then Migrate Data Using Staging Tables. The system displays the New Migration Project screen.

Under Development Package, you specify a development package for your project. If you are unsure about which option to use, please contact your system administrator.

If you use a local development package ($TMP), it is not possible to transport the project to another system in your system landscape using the Change and Transport System (CTS).

Under Migration Objects, the system displays a list of available migration objects. Select the migration objects that are relevant for your project.

Review your settings and choose Create Project to create your project.

Here you can see your Migration Projects list, and also you can edit, copy, delete and finish the existing projects.

Part B: Data Migration:-

When you open a migration project, the system displays the Migration Project screen. On the Migration Project screen, you trigger the steps that are required to transfer the data for each migration object to the target SAP S/4HANA system.

For your Migration Object, download the relevant template. Here you have two options. 1. Download with XML file, 2. Download with CVS file.

Using XML template files is the default option for filling the staging tables with data. The XML template file contains detailed information about the relevant data structures as well as instructions about how to enter data in the file.

For each migration object, these steps are:

Uploading a template file for a migration object (if using template files to fill the staging tables with data).

Preparing the staging tables.

Processing any open mapping tasks.

Simulating the migration to the target SAP S/4HANA system (optional).

Migrating the data for the migration object to the target SAP S/4HANA system.

Source: SAP help portal

Once you have filled the XML template file for a migration object with data, you can upload the file to the SAP S/4HANA migration cockpit. The system then validates the data in the file and transfers the data to the staging tables that were generated for that migration object.

If there are any issues with the data in the file, you can view the relevant messages. To resolve any validation issues, you must delete the file and adjust the data in your file accordingly. You can then upload the file and the system will start the validation process again.

Once the file has been validated successfully, the system automatically starts transferring the data in the file to the staging tables that were generated for that migration object. Once all the data in the file has been transferred to the staging tables, the system displays the information Data Successfully Transferred to Staging Tables.

The system will prepare the staging tables so that they can be used to transfer data to SAP S/4HANA. This process must be repeated whenever new data is added to the staging tables.

You can monitor the status of the migration for a migration object. On the Migration Project screen, choose the button Monitoring.

Now, you need to process any open mapping tasks for the migration object before you can proceed with the simulation or the migration.

On the Mapping Tasks screen, you can view the open mapping tasks (open mapping tasks have the status To be Confirmed) as well as any confirmed mapping tasks. You can also view whether any errors exist for mapping tasks. The system displays the mapping tasks in a list.

Once you have prepared the staging tables and processed all open tasks for a migration object, you can simulate the transfer of data to the target SAP S/4HANA system.

Once Simulation processed you can see the successful instances for the migration object, now you can migrate the object.

You can monitor the status of the migration for a migration object. On the Migration Project screen, choose the button Monitoring. The system displays the Monitoring screen, where you can view the active and completed activities, for example Migration Started or Migration Completed. You can view the number of migration object instances that have been processed, as well as the number of background jobs that are used for the migration.

When you click on successful instance numbers, it will take you to Migration Object Instances screen, you can view the migration results for migration object instances by switching to the Migration Results view.

Herein you can see the migrated data which we have done through Migrate Your Data App.

For more detailed information please visit SAP help portal.

https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/29193bf0ebdd4583930b2176cb993268/a4d4119a2cc9448a98e5d17e6dd0eac4.html

I would very much appreciate your comments and suggestions.

Happy Learning, see you in my next blog 🙂

Thanks & Regards

Pulla Rao Tulava

New Open SAP courses from PM of migration cockpit team!

2023-08-16T16:30:11+02:00

Hello, I am happy to announce that our PM of SAP S/4HANA migration cockpit team prepared 2 new open SAP courses that will start in September!

Migrating Data to SAP S/4HANA Cloud, Public Edition https://open.sap.com/courses/s4h33 is a 1-week course, where you will learn how to use SAP S/4HANA migration cockpit for your initial data load to the SAP S/4HANA, public cloud. Demos & materials based on SAP S/4HANA Cloud 2302

Migrating Data to SAP S/4HANA Using the Migration Cockpit https://open.sap.com/courses/s4h35 is a 3-week course, where you will deep dive into the SAP S/4HANA migration cockpit and SAP S/4HANA migration object modeler. Demos & materials based on SAP S/4HANA 2022 FPS1

Good luck!

Best regards,

Elizaveta

SAP S/4HANA Data Management and Analytics empowered by SAP HANA Cloud

2023-09-02T06:43:55+02:00

Purpose of this blog

SAP S/4HANA data capabilities can be much empowered by SAP HANA Cloud.

Automate E2E Data Migration Process (Extract / Transform / Loading)

Cross-system Data Lakehouse and analytics in S/4HANA

Large Data Volume Management in SAP S/4HANA by analyzing data moved outside together

Data Storage for CFIN third party scenario and Syniti

Data-Hub: central point to extract data from S/4HANA and other data sources

CAP app based on HANA Cloud accessing to S/4HANA remotely (Extension scenario)

The purpose of this blog is to explain the scenarios and technical settings in which SAP S/4HANA is empowered by SAP SAP HANA Cloud, a scenario of BTP Side-by-Side Extensibility,

For non-production purposes like PoC, you can use Free SAP SAP HANA Cloud.

Cost of SAP SAP HANA Cloud can be optimized by adjusting allocated resources and moving data to data lake (low-cost storage).

Scenarios

Functions for Integration scenarios in HANA

Getting started with SAP SAP HANA Cloud

Configurations

Move data to Data Lake

Analyzing data in SAP S/4HANA or SAP HANA Cloud

SDI - Data Transformation

Scenarios

Data Migration

Data Lakehouse Capabilities inside SAP S/4HANA

Data Volume Management for SAP S/4HANA

Others

Functions for Integration scenarios in HANA

Smart Data Access (SDA) and Smart Data Integration (SDI): With SDA and SDI it is possible to read/write data in the external database　to SAP HANA via Virtual Table. More sources are supported in SDI than SDA (SAP Note 2600176 - Supported Remote Source of SDA). SAP HANA Cloud is supported by bot SDA and SDI. Cloud Connector is needed to use SDA in SAP HANA Cloud, and DP Agent is needed for SDI. Watch Microlearning.

Calculation View: Calculation View is used for analytical app like SAC in SAP HANA Cloud. See the tutorial and microlearning for Calculation View and this microlearning for SAC. Web IDE is used to create Calculation View. To access the data of S/4HANA remotely in HANA Cloud with 3rd party tool, need to check the license issue.

SAP HANA Cloud, data lake: SAP SAP HANA Cloud, data lake is one of the components that make up SAP SAP HANA Cloud. Data can be moved from SAP HANA Cloud In-Memory database to data lake to optimize the cost. Internally, technology of SAP IQ is used. Use SAP SAP HANA Cloud Capacity Unit Estimator to estimate the cost. See also the blog: Estimating the costs of SAP SAP HANA Cloud

Thoes scenarios are valid also for S/4HANA Private Cloud Edition, e.g. to create Virtual Table in HANA for S/4HANA with help of SAP ECS team. See more in SAP Note 3169613,

Getting started with SAP SAP HANA Cloud

SAP HANA Cloud is very easy to use. Follow the tutorial of “DA261 - SAP SAP HANA Cloud Database Administration and Development” (especially SAP HANA Database Explorer - 25 minutes). For the scenario of SAC for SAP HANA Cloud and SDI, WebIDE has to be used. For other scenarios, Database Explorer is enough.

Skillset for SAP HANA Cloud can be found by reviewing the Learning for SAP HANA Cloud. To understand SAP HANA Cloud, there are many public sources, e.g. openSAP, SAP Tutorials for Developers and Youtube HANA Academy > SAP SAP HANA Cloud.

Configurations

Sign up for an SAP SAP HANA Cloud

Firstly, SAP HANA Cloud and Data lake have to be deployed. For non-production purpose, you can use Free Trial Account. Create BTP Trial account and deploy SAP HANA Cloud. This guide would also help. BTP Trial Account is available up to 90 days, if you want to use an existing SAP BTP account, SAP HANA Cloud Free Tier is available, which has no time limit. Step1 of “Start Using SAP SAP HANA Cloud Trial in SAP BTP Ceockpit” would help adding entitlements to your SAP BTP account to start using the appropriate services. See the blog to understand more.

When deploying SAP HANA Cloud, specify the parameter in JSON format like below. See the blog more about it.

{

"data": {

"systempassword":"",

"edition":"cloud",

"enabledservices": {

"docstore": false,

"scriptserver": false

},

"memory": 30,

"memoryScaleOut": 0,

"storage": 120,

"vcpu": 2

}

}

Change the setting to allow all IP addresses directly and via SAP Cloud Connector.

Open In SAP HANA Cloud Central.

Go “Manage Configuration”

Set to allow all IP addresses in Connections and Cloud Connector.

To deploy SAP HANA Cloud, Data Lake, follow the steps in the guide.

Enter Instance Name, Description, Administrator Password, select Allow all IP Addresses, and push “Create Instance”.

Data Lake is created.

Create Table with data for the test

For the test purpose, a table with data should be created in the schema of GLOBAL.

Follow the steps of 2. SAP HANA Database Explorer in the blog. You can use the test data, e.g. Orders.csv in the github.

Connections

There are 2 connection scenarios:

A. In SAP HANA Cloud to (1) ABAP Stack and (2) HANA for SAP S/4HANA via SDI DP Agent

B. In HANA server for SAP S/4HANA to SAP HANA Cloud

A. In SAP HANA Cloud to (1) ABAP Stack and (2) HANA for SAP S/4HANA via SDI DP Agent

Create Users:

Before creating connections, create users used in the setting.

Open in SAP HANA Database Explorer in BTP Cockpit.

In SQL Console, run the statements to create the users and add the authorizations.

--Create User and Schema

CREATE USER GLOBAL PASSWORD Welcome1

NO FORCE_FIRST_PASSWORD_CHANGE SET USERGROUP DEFAULT;



-- Authorization

GRANT CATALOG READ  TO GLOBAL;

GRANT CREATE SCHEMA TO GLOBAL;

GRANT CREATE REMOTE SOURCE to GLOBAL;

GRANT CREATE VIRTUAL TABLE on VIRTUAL_TABLES TO GLOBAL;



-- Authoriazation for Remote User

GRANT CREATE REMOTE SOURCE TO GLOBAL;



-- Disable password lifetime

ALTER USER GLOBAL DISABLE PASSWORD LIFETIME;

Create DP Agent Admin User: DPA_ADMIN

-- DP Agent Admin user

CREATE USER DPA_ADMIN PASSWORD Welcome1

NO FORCE_FIRST_PASSWORD_CHANGE SET USERGROUP DEFAULT;



GRANT AGENT ADMIN          TO DPA_ADMIN;

GRANT ADAPTER ADMIN        TO DPA_ADMIN;



-- Disable password lifetime

ALTER USER DPA_ADMIN DISABLE PASSWORD LIFETIME;

Create DP Agent Message User: DPA_MSG

-- DP Agent user for message

CREATE USER DPA_MSG PASSWORD Welcome1

NO FORCE_FIRST_PASSWORD_CHANGE SET USERGROUP DEFAULT;



-- Disable password lifetime

ALTER USER DPA_MSG DISABLE PASSWORD LIFETIME;



-- Disable password lifetime

ALTER USER DPA_MSG DISABLE PASSWORD LIFETIME;

In the statement above the password is “Welcome1”. Please change it to your password.

Create Remote Source:

See the blog more about the setting for 1), and this blog for 2). For 1), you can skip the chapter of “Set up your SAP ERP system” for SAP S/4HANA.

Script

C:\usr\sap\dataprovagent01\bin>agentcli.bat --configAgent



Configuring the Agent at the following location:

C:\usr\sap\dataprovagent



Initializing DPAgent Configuration Tool



************************************************************

                 DPAgent Configuration Tool

************************************************************

1. Agent Status

        :

7. SAP HANA Connection

        :

************************************************************

Enter Option:7

************************************************************

                    SAP HANA Connection

************************************************************

1. Connect to SAP SAP HANA Cloud via JDBC

        :

************************************************************

Enter Option:1



************************************************************

             Connect to SAP SAP HANA Cloud via JDBC

************************************************************

Press "Enter" button to keep default or skip an optional setting.

If a setting cannot be skipped, that means it is required.

************************************************************

Enter Use encrypted JDBC connection[true]: Valid options: true|false

true

Enter Host Name:



Enter Port Number:

443

Enter Agent Admin HANA User[DBADMIN]:

DPA_ADMIN

Enter Agent Admin HANA User Password:



Enter Agent Admin HANA User Password:  (confirm)



Enter Use Proxy Server[false]: Valid options: true|false

false

Enter HANA User Name for Agent Messaging:

DPA_MSG

Enter HANA User Password for Agent Messaging:



Enter HANA User Password for Agent Messaging:  (confirm)



Connecting to SAP HANA server via JDBC...

Agent configuration tool is connected to SAP HANA server via JDBC.



Press Enter to continue...





************************************************************

                    SAP HANA Connection

************************************************************

1. Connect to SAP SAP HANA Cloud via JDBC

    :

b. Back

************************************************************

Enter Option:b

Initializing DPAgent Configuration Tool



************************************************************

                 DPAgent Configuration Tool

************************************************************

    :

8. Agent Registration

    :

************************************************************

Enter Option:8

************************************************************

                     Agent Registration

************************************************************

1. Register Agent

    :

************************************************************

Enter Option:1

************************************************************

                       Register Agent

************************************************************

Press "Enter" button to keep default or skip an optional setting.

If a setting cannot be skipped, that means it is required.

************************************************************

Enter Agent Name[AGENT1]:



Enter Agent Host Name[XXXXXXX]:



Registering agent 'AGENT1' with SAP HANA.

Agent 'AGENT1' successfully registered.



Press Enter to continue...



************************************************************

                     Agent Registration

************************************************************

   :

b. Back

************************************************************

Enter Option:b





************************************************************

                 DPAgent Configuration Tool

************************************************************

   :

9. Adapter Registration

   :

************************************************************

Enter Option:9

************************************************************

                    Adapter Registration

************************************************************

1. Display Adapters

   :

************************************************************

Enter Option:1

Number of Adapters: 26

Adapter Name                            Registered              Custom Adapter

ABAPAdapter                             No                      No

   :

   :



Press Enter to continue...



************************************************************

                    Adapter Registration

************************************************************

   :

2. Register Adapter

   :

************************************************************

Enter Option:2

Enter adapter name:

ABAPAdapter



Adapter 'ABAPAdapter' successfully registered.



Press Enter to continue...



************************************************************

                    Adapter Registration

************************************************************

   :

2. Register Adapter

   :

************************************************************

Enter Option:2

Enter adapter name:

HanaAdapter



Adapter 'HanaAdapter' successfully registered.



Press Enter to continue...



************************************************************

                    Adapter Registration

************************************************************

1. Display Adapters

   :

************************************************************

Enter Option:1

Number of Adapters: 26

Adapter Name                            Registered              Custom Adapter

ABAPAdapter                             Yes                     No

   :

HanaAdapter                             Yes                     No

   :



Press Enter to continue...

************************************************************

                    Adapter Registration

************************************************************

1. Display Adapters

2. Register Adapter

3. Unregister Adapter

q. Quit

b. Back

************************************************************

Enter Option:q

Create Virtual Tables:

Either by running statement or with Database Explorer, it is possible to create Virtual Table in SAP HANA Cloud (1,2). To create Virtual Table, ABAP Program has to be run in Application Server layer in SAP S/4HANA (if HANA Enterprise Edition is used, you can run statement directly in HANA DB Layer).

For creating virtual tables in SAP HANA Cloud (1, 2), run the following statements.

create virtual table "S4H100_IFICOMPANYCODE" at "S4H100"."".""."ABAP_CDS.IFICOMPANYCODE$P";

create virtual table "HANAS4H_ZARTEST01" at "HANAS4H".""."SAPHANADB"."ZARTEST01";

Virtual tables are created.

Table ZARTEST01 in SAP S/4HANA.

Select and Insert data in HANA for SAP S/4HANA. “Insert” to Virtual Table is also possible.

-- Select and Insert data in Virtual Tables

Select top 100 * from "S4H100_IFICOMPANYCODE";



insert into "HANAS4H_ZARTEST01" values ('L','2','3');

Select top 100 * from "HANAS4H_ZARTEST01";

Data in ZARTEST01 in SAP S/4HANA.

It is possible for Virtual Table to have data physically by adding Replica. There are 2 types of replication: Real-time and Snapshot. See the blog for further detail. See the views M_VIRTUAL_TABLE_REPLICAS and M_VIRTUAL_TABLE_REPLICA_ACTION_HISTORY for checking the status of replica.

--- Create Replica for Virtual Table

-- Add Replica - Realtime

alter virtual table "HANAS4H_ZARTEST01" add shared replica;



--- Drop Replica - Realtime

alter virtual table "HANAS4H_ZARTEST01" drop replica;



-- Add Replica - Snapshot

alter virtual table "HANAS4H_ZARTEST01" add shared snapshot replica;



-- Add Replica - Refresh Snapshot

alter virtual table "HANAS4H_ZARTEST01" refresh snapshot replica;



-- Add Replica - Snapshot Drop

alter virtual table "HANAS4H_ZARTEST01" drop replica;

It is also possible to connect via SDA. SAP Cloud Connector is needed instead of DP Agent in the case. Refer to the blog for more about it.

B. In HANA server for SAP S/4HANA to SAP HANA Cloud

Create Remote Source:

To create Remote Source in HANA for SAP S/4HANA, follow the steps in SAP Help. Below are the statements run in SQL Console in HANA Studio logging with SYSTEM.

CREATE PSE HANAC;



CREATE CERTIFICATE FROM '

-----BEGIN CERTIFICATE-----



-----END CERTIFICATE-----

' COMMENT 'BTP'; 



SELECT CERTIFICATE_ID FROM CERTIFICATES WHERE COMMENT = 'BTP'; 

ALTER PSE HANAC ADD CERTIFICATE ;



SET PSE HANAC PURPOSE REMOTE SOURCE;



CREATE REMOTE SOURCE SAP HANA CLOUD ADAPTER "hanaodbc" 

CONFIGURATION 'Driver=libodbcHDB.so;ServerNode=xxxxxx.SAP HANA Cloud.ondemand.com:443;

encrypt=TRUE;'

WITH CREDENTIAL TYPE 'PASSWORD' USING 'user=GLOBAL;password=Welcome1';

“SAP HANA Cloud.ondemand.com:443”: replace to the endpoint of your SAP HANA Cloud.

Replace “Welcome1” of the user GLOBAL to your password.

Create Virtual Tables:

To create Virtual Table in ABAP stack, run the program ZICA_CREATE_VIRTUAL_TABLE. See the blog to understand more.

In the following parameter, the virtual table for the table ORDERS in the Schema GLOBAL is created.

To read the data via the virtual table, run the SELECT statement with Tcd DBACOCKPIT > Diagnostics > SQL Editor in SAPGUI.

“/1BCAMDP/” is added as the prefix of the VT_NAME.

Tcd DBACOCKPIT > Diagnostics > SQL Editor.

Result:

Create CDS View for the Virtual Table.

Table function and AMDP are created for the virtual table, and CDS View is created on top.

Table Function

@ClientDependent: false

@EndUserText.label: 'ZPT_CUSTOMERS'

define table function ZPT_CUSTOMERS

returns {

  CUSTOMERID: abap.char(50);

  CITYID: abap.char(50);

  COUNTRYID: abap.char(50);

  REGIONID: abap.char(50);

  CUSTOMER: abap.char(50);

  CITYNAME: abap.char(50);

  COUNTRYNAME: abap.char(50);

  REGIONNAME: abap.char(50);



}

implemented by method ZCL_AMDP_FUNCTIONS_NOCL=>GET_CUSTOMERS_FOR_CDS;

Class-Method of AMDP used in the Table Function.

class zcl_amdp_functions_nocl definition

  public

  final

  create public .

  public section.

    interfaces if_amdp_marker_hdb .

    class-methods GET_CUSTOMERS_FOR_CDS

        for table function ZPT_CUSTOMERS.

  protected section.

  private section.

endclass.

 class zcl_amdp_functions_nocl implementation.



    method GET_CUSTOMERS_FOR_CDS by database function

        for hdb

        language sqlscript.

--        options read-only.

        RETURN

        SELECT

        CUSTOMERID,

        CITYID,

        COUNTRYID,

        REGIONID,

        CUSTOMER,

        CITYNAME,

        COUNTRYNAME,

        REGIONNAME

        FROM "/1BCAMDP/SAP HANA CLOUD_CUSTOMERS" AS CUSTOMERS;



    endmethod.



ENDCLASS.

CDS View:

@AbapCatalog.sqlViewName: 'ZIVHCCUSTOMERS'

@AbapCatalog.compiler.compareFilter: true

@AbapCatalog.preserveKey: true

@AccessControl.authorizationCheck: #CHECK

@EndUserText.label: 'ZI_VHANAC_CUSTOMERS'

define view ZI_VHANAC_CUSTOMERS as select from ZPT_CUSTOMERS {

CUSTOMERID,

CITYID,

COUNTRYID,

REGIONID,

CUSTOMER,

CITYNAME,

COUNTRYNAME,

REGIONNAME    

}

Data Preview of the CDS View.

Move data to Data Lake

Data in SAP HANA Cloud can be moved to SAP HANA Cloud, Data Lake.

It is possible to create table in Data Lake by running Procedure in SAP HANA Cloud. To do that, privilege has to be added in Database Explorer.

GRANT HANA_SYSRDL#CG_ADMIN_ROLE TO GLOBAL;

Then, run the procedure REMOTE_EXECUTE.

CALL SYSRDL#CG.REMOTE_EXECUTE('BEGIN

CREATE TABLE "CUSTOMERS"(

	"CUSTOMERID" VARCHAR(50),

	"CITYID" VARCHAR(50),

	"COUNTRYID" VARCHAR(50),

	"REGIONID" VARCHAR(50),

	"CUSTOMER" VARCHAR(50),

	"CITYNAME" VARCHAR(50),

	"COUNTRYNAME" VARCHAR(50),

	"REGIONNAME" VARCHAR(50),

PRIMARY KEY(CUSTOMERID)

);

END');

Remote Source SYSRDL#CG_SOURCE in SAP HANA Cloud is that for Data Lake. In the remote source, the table “CUSTOMERS2 is created.

Create Virtual Table for this table in GLOBAL Schema.

Object Name: DATALAKE_CUSTOMERS

Schema: GLOBAL

--- Create UNION View Table in SAP HANA Cloud and in Data Lake

create view CUSTOMERS_TOTAL as

select * from GLOBAL.CUSTOMERS

union all

select * from GLOBAL.DATALAKE_CUSTOMERS;



--create Procedure to move data to Data Lake

--DROP PROCEDURE  MOVE_DATA;

CREATE PROCEDURE MOVE_DATA(CID int)

 LANGUAGE SQLSCRIPT AS

 BEGIN

	DECLARE CUSTOMERS_COUNT int;

	DECLARE CUSTOMERS_COUNT2 int;

	select count(*) into CUSTOMERS_COUNT from CUSTOMERS_TOTAL;

	insert into "GLOBAL"."DATALAKE_CUSTOMERS" select * from CUSTOMERS where CUSTOMERID < CID;

	delete from CUSTOMERS where CUSTOMERID < CID;

	select count(*) into CUSTOMERS_COUNT2 from CUSTOMERS_TOTAL;



	IF CUSTOMERS_COUNT= CUSTOMERS_COUNT2

	  THEN commit;

	ELSE

	  rollback;

	END IF;

 END;

 

--- Run Procedure

 call MOVE_DATA(10);

Select data in the Virtual Table

select * from "GLOBAL"."DATALAKE_CUSTOMERS"

Data of CUSTOMERID < 10 are moved to table in the Data Lake.

Analyzing data in SAP S/4HANA or SAP HANA Cloud

It is possible to analyze data either/both in SAP S/4HANA and SAP HANA Cloud on SAP S/4HANA or SAP HANA Cloud.

Characteristics of analytics in SAP S/4HANA

SAP Fiori analytical apps can be used. SAC is optional.

Analytic Engine coming from BW is available for analytic query. See Wiki and the section of the blog for further detail.

Users/authorizations in SAP S/4HANA is available.

Table Function/AMDP has to be created for the data in SAP HANA Cloud in addition to Virtual Table.

SAP Named User license for SAP S/4HANA is required for SAP Fiori analytical apps. In case of SAC, SAP Named user license should not be necessary. (Need to reconfirm SAP license sales).

Deeper knowledge is needed of CDS View.

Refer to the blog to understand more about SAP S/4HANA Analytics.

Characteristics of Analytics in SAP HANA Cloud

Analytics tool like SAC is mandatory.

SAP Named User license is not necessary.

Mainly modeled with SQL in SAP HANA Cloud,

Firstly, Calculation View has to be created in SAP HANA Cloud, then create Live Connection to the SAP HANA Cloud in SAC. Model and Story are created (Tutorial).

SDI - Data Transformation

It is possible to use Smart Data Integration (SDI) function for Data Transformation within SAP HANA Cloud without additional license. You can enjoy higher productivity for data transformation in SAP HANA Cloud.

SAP HANA Cloud can be connected with many sources by creating Remote Source. Virtual Table is created to access the data in external source. Flowgraph is created for data transformation.

It could be used for data migration, data transformation for data distribution. DP Agent has to be installed to connect to many sources.

See the blog for further detail.

S4 Hana Migration Cockpit - File Approach Deep Dive

2023-09-06T03:44:49+02:00

Hello Learners,

Hope you all are doing Great!

Welcome back to my data migration blog series.

Purpose of this Blog :

We learnt about the SAP Migration Cockpit within S4 HANA which is the latest DM tool for S4 implementation projects. You can have the recap for the same using below link -

https://blogs.sap.com/2023/02/19/sap-data-migration-cockpit-nutshell/

Today we will go deeper into one of its commonly used data migration approach which is File Based Approach.

What’s in it for you?

The blog will explain File Based data migration approach in detail manner. This approach is very useful and quick to setup for migration activities.

Let’s deep dive into this approach!

Note - This blog is based on S4 2020 version using LTMC tcode. The approach is slightly different on recent versions of S4. I will cover important changes at the end of this blog and will cover details in next blog 🙂

Overview -

File Based approach can also be termed as Template based approach or Inbuilt content Usage approach.

The reason we call it as template or Inbuilt content based approach is, here SAP has provided standard templates for different set of data objects where you can simply add data and then you can follow the data migration steps inside cockpit to load data into system

Most of the data which gets added to templates is transformed as per target system requirements though you can still do some value transformations/conversion in the convert step of cockpit.

Pros :

Easy to setup, less development/customization required

User friendly and can be performed by functional as well as business users

Covers many standard fields and also allows customization of adding own fields

Cons:

Size constraints- Only 100mb of file size is allowed to be uploaded in cockpit within this approach

Additional splitting and management of files required when data volumes are high

Manual preload data validations efforts

Less automated way hence risk of more errors during process

Template formatting and structure to be preserved to avoid upload issues

There could be more pros and cons depending on project requirements.

Now lets learn some important options and way of handling this approach -

Setup-

Considering you are already inside the LTMC tcode, the first step is to setup a project. Below steps to be performed for the same.

Click on Create Project, Give suitable name (eg - DM_File_Approach)

Select the DM approach as - File Based Approach

Make a note of mass transfer ID generated or generate one of your own. This would be useful while migration projects from one environment to another

Once you have completed all the above steps, you are all set!

Project Setup

How to use File Based Approach-

Once you are inside your project, select one object for which you want to migrate data (eg -Product Master)

When you will select the object, you will have screen with different buttons/options to carry out the migration
- Download Template - using this options, you can download the standard template to your system and add data to it. Templates are XML files but with excel file look.
- Each template will have different sheets as per object.
  - first sheet is always Instruction sheet, which has all the details on how to use template and copy or add data to template. Its a good practice to go through before adding data to template
  - Second sheet is Fields sheet, This sheet has all the fields available in template with their details like Name, data types, table name, sheet name etc.
  - Apart from these 2 common sheets, you will have data object specific sheets and they are further classified as mandatory and optional sheets
  - Mandatory sheets are highlighted in yellow and required to be filled in. Optional fields can be filled if required or they can be left blank
- Upload Template - Once you add required data as per template requirements you are ready for upload. Make sure you have filled in mandatory fields whatever sheets you have filled in with data
- Cockpit will do the validations while uploading file but it is good practice to perform some common validations prior to upload to avoid going back and forth between tool and changing data to template
  - Mandatory Fields validation check- Make sure all the mandatory fields are populated on sheets which are being used for data object
  - Duplicate check - Make sure key column(s) of every sheet have unique values else you will get an error during validation step
  - Data Type validation - Enter correct values as per data type and follow length restrictions etc.

Once you have uploaded the template filled with data, you can click on Start Transfer button/option and follow the four step data migration process.

The allowed file size for a single upload is 100MB or 160MB for a zipped file

You can upload multiple files of 100MB or less and then process them together when you are working with high volumes. Splitting of files is covered in another section in this blog

Cockpit always create a background job for each data migration step, can be monitored in SM 37 with filters as - Job Name =/LT* and User = * (or you can use SAP_SYSTEM)

Max Transfer Jobs - This option is useful when you are using multiple files and processing them together. For n no of files you can set this parameter upto n-1 value. It is by default set to 1 initially. This will create that many jobs and can be monitored in SM37. It also can cause problem if you have data dependencies

Each step will give you an option to download logs with limited numbers

Once you have completed all the steps, a delta file will automatically generated with failed records. Errors can be fixed and file can be reuploaded.

Above is the procedure to perform data migration for any object using file based approach.

Selecting Data Object

File based Approach Options

Splitting of Files-

Splitting of loadfiles would be required if your file is more than 100MB in size

You can split the xml files/load files using splitter tool created by SAP itself

The tool helps you split files and make the size less than 100MB

No of split files required can be decided based on total size of main file (eg - if file is 564MB then you would need to split the main file into 6, basically divide by 100 and round off)

link to download splitter tool is below, it has details to run the tool also.

Link to tool - https://github.com/SAP-samples/s4hana-mc-xml-file-splitter

Handling Internal number range mappings with File based approach-

Many SAP implementation project use internal number ranges for product master, Business partner etc. In those cases it is important to map the old source number to newly generate number by the system. Below are some important points to note down while working with internal numbering system.

You can maintain a cross reference file with Old to New number mapping and then use lookup wherever required and replace the old number with new number. As this is manual way hence it is not recommended

Migration cockpit handles this internally by itself. Cockpit stores the old to new number mapping internally and auto populate the mapping during convert step of migration process.

Make sure you are using same project for dependent objects where these mappings are used because it will only store old to new mapping for the records which are created through that project

Important Points to Pen down-

Common validations to be done prior to upload as otherwise it can be repetitive process and consume more time for initial steps to run successfully like upload and validate

Limit the use of this approach based on data volumes though you can use it for high volumes but you would need to manage multiple files and more manual efforts that can lead to errors

Follow the naming conventions for all your templates/loadfiles with proper versioning

avoid using multiple projects for same objects to handle multiple files as it will not help you preserve some mappings where you are using internal number ranges (eg - product number)

When dealing with multiple files for an object, once upload of all the files is complete; activate all the files first before you click on start transfer option to process all the files together.

Add descriptions of file and versioning when uploading files to cockpit, this will be helpful in identifying corresponding delta files when the records would fail.

You can not upload file with same name if it is already uploaded and exist in the object.

You can only delete the files uploaded until their status is NOT FINISHED.

File approach in Fiori-

As mentioned at start of the blog, I covered the file based approach using LTMC tcode but with recent S4 versions this has been modified slightly and combined with staging approach.

Below are some important changes or details with fiori app - Migrate your Data way-

File and staging approaches are merged in fiori app - Migrate Your Data and called as Staging approach only

During project setup while selecting DB connection you can choose Local or Remote Db option. When you use local DB option that is your file based approach.

Once you are inside the project then you can follow the same procedure listed above with little changes to the UI as it is Fiori based

The data from templates get stored in staging tables

You can upload as many as 100MB files and data will reside in staging tables which can be directly accessed in S4 Hana System

If you try to upload same data then system gives you an option to skip or replace the existing data

You can not upload file with same name if it is already uploaded and exist in the object.

Conclusion-

File based approach is very useful when you have the data extracted and transformed already as per requirements of target S4 system.

you can handle large volumes with cons like manual efforts and multiple files handling

Overall it is a very useful approach and widely used in S4 implementation projects because of its ease of use.

I will cover more advanced topics in upcoming blogs so stay tuned!

Please do share and subscribe the blog and share your valuable feedback so that I can improve my content and help readers get more better learning experience around SAP data migration and data quality.

Happy Learning and reading!! 🙂

SAP S/4HANA migration cockpit - new open SAP courses - for free - starting soon

2023-09-11T13:15:14+02:00

We have 2 new openSAP courses starting September 2023 for you:

SAP S/4HANA Migration Cockpit for Public cloud

Course summary: This course gives an overview of the features and functions of the SAP S/4HANA migration cockpit. You will also be guided through the migration process and shared the best practices with as well as information about related apps. The course contains detailed system demos based on SAP S/4HANA Cloud 2302.

Course date: open from September 13 to October 19, 2023.

Course duration: 4 hours in total and open for 4 weeks

To register: ENROLL HERE

The detailed demos in this course are based on SAP S/4HANA Cloud 2202.

SAP S/4HANA Migration Cockpit for OnPrem/Private Cloud

Course summary: This 3-week course covers for the new implementation scenario SAP S/4HANA migration cockpit for OnPrem/Private Cloud. A deep dive into both the SAP S/4HANA migration cockpit and the migration object modeler will upskill you on the latest functionality.

Course date: open from September 27, 2023

Course duration: 3 weeks, 4 hours per week

Exam date: October 18, 2023, 9:00 UTC - October 26, 2023, 9:00 UTC

To register: ENROLL HERE

The detailed demos in this course are based on SAP S/4HANA 2022 FPS1.

These courses are offered totally FREE of charge. Register now so that you won't miss this invaluable opportunity!

Sybille Lackermeier, SAP S/4HANA migration cockpit Product Management

Displaying Header and corrosponding item data for each header in single table in Adobe forms

2023-10-11T21:57:31+02:00

This article explains how to display header corrosponding items to each header in tabular format in Adobe forms.

Here is the example .

Requirement : To display VABK(Invoice Header) and VBAP(Invoice Item) data in tabular format in adobe form , For every invoice header we need to display invoice items and go for next header and item in single table.

Example :

Billing doc no	Creation date	Sales org	Currency	Header
Item No	Material No	Rice	Sales Unit	Item
931214438	01-06-2020	4700	USD	Header Data
10	20505306	0	cs	Item Data
20	20505306	1,728.00	cs
30	20505306	1,728.00	cs
40	20505293	0	cs
931214439	01-06-2020	4700	USD	Header Data
10	20505306	0	cs	Item Data
20	20505306	1,728.00	cs
30	20505306	1,728.00	cs
40	20505306	0	cs

Step 1 : Go to Transaction code SFP(Form Builder).

Step 2: We need to create interface first before creating adobe form for this Enter the Name of the Interface as shown below and click on Create button.

Step 3: A pop up will be displayed. Enter the description and Interface Type .Click on Save.

Step 4: Save it on the Transport which is required and an interface will be displayed like below.

Step 5: Goto Types tab and create types and table types for Header and item data as below.

Step 6: Go to Global data tab and declare header and item internal tables as below

Step 7: Goto Code initialization tab and fetch the data to gt_header and gt_item internal table from VBRK and VBRP tables as below.

Now the data is available in the internal tables , please create an adobe form to display the data in tabular format as per the requirement.

Step 8: Goto T-Code SFP and Give form name as below and click on create the Adobe form.

Step 9: Provide short description and provide above created interface ZADOBE_HEADER_ITEM at interface input and save it in Transport and create adobe form as below and activate it.

Step 10 : After you activate your form , Please drag your header internal table form interface to context level as below .

Step 11: Now Right click on the GT_HEADER at context and create loop and add GT_ITEM in the table input .

Step 12 : Now Provide the condition that item should loop for appropriate header , As per below screen shot put the condition that gt_header-vbeln = gt_item-vbeln in where condition tab at item level as below.

Step 13 : Context level part is completed , Now go to layout part for designing , for this click on layout and open design page and create a table which as 4 rows 2 is for header text and item text and another 2 for header GT_HEADER data and GT_ITEM as per header record as shown below.

Step 14: In First two rows hard code the header and item texts .

To show the difference in heading i have made header text as centre aligned and item text as left aligned.

Step 17 : Now before binding to header and item data make the last two rows as group as section , then it will become one row and behaves as single internal table deep structure , please follow as per below screenshot.

Procedure : Select Row 3 and Row 4 at hierarchy level -> Right click -> Group as section.

After this Group as section on top of Row 3 and Row 4 at hierarchy level a virtual row will create and that will became as the main row for our understanding i have renamed as Main row as below.

Step 18: Now Bind the header and item data for this make all the data cells as text fields then Goto to each cell -> Click on pallets -> object -> Binding -> Bind the header and item data for all the cells.

Note Bind header data at Row 3 and Item data at Row 4 as below.

Sample binding process as below.

Step 19 : After data binding , For Row 3 and Row 4 Remove Repeat row for each data item check box and check for Main row , this shows repat for all the group rows.

Step 20: Wrap the Table in subform and put it as flowed and make even main form also in flowed mode , Final layout like below.

In the Above 1 indicates warp table in subform and make it as flowed and 2 indicates make main form as flowed.

Step 21 : Save the form and activate and execute the form give printer as LOCL or LP01 and the output shown as below.

Migration Cockpit error “Not ready for processing” and use of Note Analyzer

2023-11-25T15:16:34+01:00

This blog is aimed to let you know how to solve the DMC error of “Not ready for processing” in the version SAP S/4HANA 2022 FPS0 and data migration approach of staging table. Hope it will be helpful for you.

Background:

Since we know that the transport concept of migration cockpit in S/4 project is available now, we can create multiple migration cockpit projects and assign the selected standard objects in it, then via LTMOM to generate TR for the transport. So we call those migration cockpit projects as “transported project” in QAS or PRD.

Client modifiable only in Development system:

Issue:

we supposed all the transported project via TR into QAS/PRD could be workable, but you may also meet the error that the transported project status is displayed as “Not ready for processing” from “imported” after the database connection setup.

Status of screen:

All the button is grey, it can’t be downloaded or uploaded any load file, even the “prepare project” job doesn’t been generated or running.

Root caused:

The assembly of the SAP S/4HANA 2022 FPS0 is incomplete regarding data migration objects. Here SAP recommends using Note Analyzer to implement the missing/latest notes, and SAP keeps updating the latest notes via this Note Analyzer. So the specific regular checking timeline for the latest notes is necessarily needed.

Below are the steps of resolve error “Not ready for processing”:

Step 1 – Implement Important Corrections Note 3291483

Step 2 – Implement TCI Note 3291767

Step 3 - Implement SAP Note 3016862 to get the Note Analyzer

Step 4 – Implement multiple Notes extracted from Note Analyzer

Step 5 – Refer to Note 3094534 to check Stepuser existed with correct security or not in Job Repository (T-code /nsjobrepo)

How to use Note Analyzer to get latest notes for S4HANA Migration Cockpit (MC):

Go to T-code SE38 and execute program CNV_NOTE_ANALYZER_MC_EXT or use T-code CNV_NA_MC into the same page.

Only select/tick migration approach of staging tables and untick the rest bucket.

Get the list of notes for implementation.

Solved:

After all relevant notes implemented and transported, the migration cockpit project status changed into “Ready for Processing”.

Partner Function update in PS Project WBS (Table IHPA)

2023-12-11T10:58:26+01:00

Introduction:

In Projects there are various people involved. This may include the project managers, project owners, Division Head, Finance etc. Normally most consultants use “Pers. Resp.No.” (VERNR) field to maintain this information. However, the requirements is to add multiple ids with different roles. This is where the concept of Partner Function in Project Systems comes in the picture.

Partner functions can be added both at Project Definition and at WBS level.

Issue

During PS Project system data migration there are no standard template to do so. The partner function data gets reflected in the IHPA table. There is no direct way to update the table.

Solution

We can use FM “PM_PARTNER_UPDATE” to do so. The same FM can be called through data services as well.

Sample dataset looks like below :-

Please keep in mind to populate the field UPDKZ. Otherwise it won’t reflect in the table.

'D' Delete

'L' Physically delete

'E' Inherited

'I' New

''' No alteration

'U' Update

UPDKZ = 'D' ---> Updates the field KZLOESCH as 'X' in the table IHPA.

UPDKZ = 'U' -> Updates entry in the table.

UPDKZ = 'I' --> Inserts new record into the table.

UPDKZ = 'L' ---> Record is deleted from the table.

Data Migration Strategy in S/4 HANA Projects

2024-02-04T12:34:45.605000+01:00

At the beginning, I would like to point out that the article was written assuming that a new implementation project will be made.

Data Migration Strategy is one of the 3 most important components in a typical S4HANA project.

The other two: Scope (BPML, Product BOM, Depth of usage, WRICEF...), Users (People, company culture, satellite solutions...). The parenthetical items in both categories can be further varied, but this should be covered in another article.

It is necessary to complete the following headings in order to transfer the data completely and accurately to the newly designed S/4 HANA system at the planned time.

Separate Team

Since the Data Migration process is very important in S/4 HANA projects, it will be very useful if it is carried out by a team positioned under a separate leader. There must be at least one functional consultant with logistics and finance background in the team to be established. I think having an abap developer who has moved data using traditional methods would be a lifesaver. Additionally, if it is planned to be used, an Information Steward and Data Services expert should also be included.

If possible, people from business units whose job is Data Management should be included in the team. If there is no one with such a job description, someone from the finance team and engineering units who knows the organization and is experienced should be assigned.

Select Migration Objects

When the newly designed S/4HANA solution goes live, all the necessary data must be prepared 100 percent accurately and completely. The data can be roughly divided into two heads:
Master data, transactional data.

Under the master data heading, there are data objects such as material, customer, vendor, bank information that change slowly and affect the content of transactional data. Transactional data, on the other hand, consists of objects produced as a result of daily operations such as purchasing contracts, sales documents, and loans, etc.

Taking an inventory of all data objects, regardless of their type, would be the best start. In its simplest form, an Excel sheet consisting of the following information will be sufficient, ideally you can track each object as a separate item with a jira-like tool. Required information (Roughly):
Data object,
Relevant module,
Source,
Method,
Precondition,
Source owner,
S/4HANA owner,
Test cycle1 result,
Test cycle2 result,
Integration test result,
UAT result,
Explanation

Get Data (Extraction)

When the object list is completely prepared, the first thing to do is to determine the data extraction method with the most up-to-date way allowed by the source. Some data objects may need to be cleaned, transformed and enriched according to the new design. Data object transfer method; Depending on the size of the data, frequency of change and complexity of subsequent operations, one of the following two options may be possible:

Extract data from source files using DS/DI/ETL Tools jobs and bring them into a staging HANA DB.
Manually extract data and push it to staging or xml files of Migration Cockpit.

Profile Cleanse Transform Validate

Source data can be profiled to better understand current data quality and build your transformation or cleansing requirements for migration. SAP Information Steward and Data Services can be used for Data Profiling & Validation.

To transfer data using the SAP S/4HANA migration cockpit, you will need a user with the role SAP_CA_DMC_MC_USER is required in the SAP S/4HANA system. This user must also have the role SAP_BR_CONFIG_EXPERT_DATA_MIG for the front-end server. To use the SAP S/4HANA migration object modeler (transaction LTMOM), role SAP_CA_DMC_MC_DEVELOPER is required in the SAP
S/4HANA system.

S/4HANA Migration Cockpit support pre-load validation as defined in load APIs and simulation before starting actual data load. This pre-load validation can be changed for customer specific requirements. Data Services can be configured to have pre-load validation and error handling steps to capture all the possible data issues.

S/4HANA Migration Cockpit standard content should be used to migrate Master Data, open items and balances into S/4HANA system.

In the diagram above, the summary of what was previously explained is shown on a single page.

Testing

The success of the constructed Data Migration Strategy depends on testing it in the right cycle and method.
Each object must be tested at least 3, but ideally 4 times, depending on the chosen method. In each test, the data content for the object used in the previous test should be increased and, if possible, 100 percent real data should be used in UAT tests.

Migrate Business Data into SAP S/4HANA Cloud Public Edition with SAP S/4HANA Migration Cockpit

2024-02-13T09:28:53.681000+01:00

You are implementing SAP S/4HANA Cloud Public Edition and would like to understand/ learn more about how your legacy data can be migrated to new SAP S/4HANA Cloud Public Edition system?

Then please join us for our upcoming expert session around this topic, focused on the SAP S/4HANA migration cockpit. The SAP S/4HANA Migration Cockpit is SAP’s data migration tool that helps you as a customer migrate business data from legacy systems to your new SAP S/4HANA Cloud Public Edition system.

In this virtual live session hosted by the SAP Enterprise Support Academy you will get an overview of the SAP S/4HANA migration cockpit including basic functions and learn about two different migration approaches (including the new 2402 release “Migrate Data Directly from an SAP System”). Finally, we will also cover where to find further information on this topic.

Goals of the session:

Get an overview on the basic features and functions of the SAP S/4HANA migration cockpit
Get to know the new migration approach “Migrate Data Directly from an SAP System” for SAP S/4HANA Cloud Public Edition
Learn where to find the SAP S/4HANA migration cockpit documentation with the new design of the SAP S/4HANA migration cockpit landing page

Before you can access the link below, a one-time registration in SAP Learning Hub, edition for SAP Enterprise Support, is required. A detailed step-by step guide to registration can be found here.

Click here to register: How to Migrate Business Data into SAP S/4HANA Cloud Public Edition with SAP S/4HANA Migration Cockpit - Apr 10th 10:00 am EST

News on SAP S/4HANA migration cockpit in SAP S/4HANA Cloud Public Edition

2024-02-14T18:10:02.826000+01:00

Hello migration cockpit users,

for SAP S/4HANA Cloud Public Edition 2402, we have some great news:

The approach "Direct Transfer" is now available - here, you connect via a communication arrangement to your SAP ERP system and data is fetched directly from the system.

Find the list of available migration objects here: Migration Object for Direct Transfer
Find more details for the Direct Transfer approach in the public cloud in the following slide deck:
SAP S/4HANA Migration Cockpit SAP S/4HANA Cloud Public Edition 2402.

Best regards,
Sybille

Step-by-Step Guide: Creating a Custom Migration Object: SAP QM Certificate Profile

2024-02-25T21:20:32.849000+01:00

Hi Guys,

In this blog we are going to see the process of creating a custom Migration Object and the various Little Things that can be done to the migration object. You will be learning.

1. How to create a Custom Function Module for Migration object not available in SAP Standar

2. Create Custom Translation Object.

3. Out of the Box Reporting Capability of MIgration Cockpit.

1. Create a Custom Function Module.

Lets say we want to migrate, Several Certificate profile as of S4 HANA 2023, there is no Standard Migration Object Given by SAP to meet the requirement, but there are guidelines given by SAP, mentioning below is a summary as per the SAP user Guide.

1. commit work and Rollback work statement should not be written in the custom Function module, as the SAP Migration cockpit takes care of the same.

2 For Error Handling the function module must use the ABAP Dictionary structure BAPIRET2 as a structure to return messages to the SAP S/4HANA migration object modeler. Also the function module should not throw a exception, and lastly Abort message should be converted to Error Message.

3. The function module must have a TESTRUN FLAG, so that the Migration object can be run in the Simulation Mode.

4. Developers can implement Consistency check and Plausibility Check similar to one mentioned in the Standard Migration Object FM : BAPI_ACC_DOCUMENT_CHECK for Plausibility check.

considering the above statement, the function module should look like this somewhat

first we create a Table type using se11

on a similar fashion create for qcvm and qcvv and use the same in the importing of the function module.

Code for function module.

Please note : The Below code also consist of Logic to create a Status Object Number and Depending on the user Input fields for the data migration, the certificate profile is created in the Released Status or in the Created status.

AREAS OF IMPROVEMENT : Current Code is not designed to handle the User status Profile, but depending on the business requirement, the below code should be modified to fit the purpose. Also the Code is not well Written as it is from the functional Perspective, More well Talented ABAPer can enhance it further.

FUNCTION zqc01_create.
*"----------------------------------------------------------------------
*"*"Local Interface:
*" IMPORTING
*" VALUE(TESTRUN) LIKE BAPIE1GLOBAL_DATA-TESTRUN OPTIONAL
*" VALUE(ST_QCVK) TYPE ZTT_QCVK OPTIONAL
*" VALUE(ST_QCVM) TYPE ZTT_QCVM OPTIONAL
*" VALUE(ST_QCVV) TYPE ZTT_QCVV OPTIONAL
*" VALUE(RELEASE) TYPE XFELD OPTIONAL
*" TABLES
*" RETURN STRUCTURE BAPIRET2 OPTIONAL
*"----------------------------------------------------------------------
DATA : ls_qcvk TYPE qcvk,
lt_qcvk TYPE TABLE OF qcvk,
ls_qcvv TYPE qcvv,
lt_qcvv TYPE TABLE OF qcvv,
ls_qcvm TYPE qcvm,
lt_qcvm TYPE TABLE OF qcvm,
lt_onnr TYPE TABLE OF onr00,
wa_onnr TYPE onr00,
lt_JSTAT TYPE TABLE OF jstat,
wa_JSTAT TYPE jstat,
lv_release type QKZ.

MOVE RELEASE TO LV_RELEASE.

LOOP AT st_qcvk ASSIGNING FIELD-SYMBOL(<fs_qcvk>).
"check if data already exist in the system.
SELECT SINGLE * FROM qcvk INTO _qcvk WHERE ctyp = @<fs_qcvk>-ctyp AND vorlnr = @<fs_qcvk>-vorlnr AND version = @<fs_qcvk>-version.
IF sy-subrc EQ 0.
PERFORM set_return_message USING 'E' '' '' <fs_qcvk>-vorlnr <fs_qcvk>-version <fs_qcvk>-ctyp 'already exist in the system' CHANGING return.
APPEND return TO return.
ENDIF.

" check if valid certificate type has been given the load file.
SELECT SINGLE * FROM tq05 INTO _Qcvk WHERE zgtyp = @<fs_qcvk>-ctyp.
IF sy-subrc NE 0.
PERFORM set_return_message USING 'E' '' '' <fs_qcvk>-ctyp 'is not a valid certificate type' space space CHANGING return.
APPEND return TO return.
ENDIF.
"check if valid stock transfer level has been specified in the load file
IF <fs_qcvk>-withtransf = '1' OR <fs_qcvk>-withtransf = 'X' .
PERFORM set_return_message USING 'E' '' '' 'Not a Valid Stock Transfer level has been defined' space space space CHANGING return.
APPEND return TO return.
ENDIF.

ENDLOOP.
"check whether the characteristics exist in the database or not
LOOP AT st_qcvk ASSIGNING <fs_qcvk>.
LOOP AT st_qcvm ASSIGNING FIELD-SYMBOL(<fs_qcvm>) WHERE ctyp = <fs_qcvk>-ctyp AND vorlnr = <fs_qcvk>-vorlnr AND version = <fs_qcvk>-version .
CALL FUNCTION 'CONVERSION_EXIT_ALPHA_INPUT'
EXPORTING
input = <fs_qcvm>-version
IMPORTING
output = <fs_qcvm>-version.

SELECT SINGLE * FROM qpmk INTO @DATA(ls_qpmk) WHERE zaehler = @<fs_qcvm>-zaehler AND mkmnr = @<fs_qcvm>-mkmnr AND version = @<fs_qcvm>-version.
IF sy-subrc NE 0.
PERFORM set_return_message USING 'E' 'QS' '145' <fs_qcvm>-zaehler <fs_qcvm>-mkmnr <fs_qcvm>-version space CHANGING return.
APPEND return TO return.
ELSE.
MOVE '1' TO <fs_qcvm>-blocknr.
MOVE sy-tabix TO <fs_qcvm>-merkmalnr.
TRANSLATE <fs_qcvm>-vorlnr TO UPPER CASE.

APPEND <fs_Qcvm> TO lt_qcvm.
PERFORM set_return_message USING 'I' '' '' <fs_qcvk>-vorlnr <fs_qcvk>-version <fs_qcvk>-ctyp 'will be loaded' CHANGING return.
ENDIF.
ENDLOOP.
ENDLOOP.

* SELECT SINGLE stsma FROM tq05 INTO @DATA(ls_status_profile) WHERE zgtyp = @<fs_qcvk>-ctyp.

" Get internal object number.
DATA : lc_objnR_new TYPE qcvk-objnr.
DATA : lc_objnr_old TYPE qcvk-objnr.

CALL FUNCTION 'QAST_STATUS_OBJECT_CREATE'
EXPORTING
iv_obtyp = 'QC1'
iv_stsma = ''
IMPORTING
ev_objnr = lc_objnr_old
EXCEPTIONS
invalid = 1
OTHERS = 2.
IF sy-subrc <> 0.
"Implement suitable error handling here
ENDIF.

IF RELEASE NE 'X'.
CLEAR lt_jstat.
wa_JSTAT-stat = 'I0098'.
wa_jstat-inact = ''.
APPEND wa_jstat TO Lt_jstat.
CLEAR wa_jstat.
wa_JSTAT-stat = 'I0001'.
wa_jstat-inact = 'X'.
APPEND wa_jstat TO Lt_jstat.
ELSE.
CLEAR lt_jstat.
wa_JSTAT-stat = 'I0098'.
wa_jstat-inact = 'X'.
APPEND wa_jstat TO Lt_jstat.
CLEAR wa_jstat.
wa_JSTAT-stat = 'I0001'.
wa_jstat-inact = 'X'.
APPEND wa_jstat TO Lt_jstat.
wa_JSTAT-stat = 'I0002'.
wa_jstat-inact = ''.
APPEND wa_jstat TO Lt_jstat.
ENDIF.
"update object number to ONR00 table

*
* CALL FUNCTION 'STATUS_BUFFER_SET_OBJECT'
* EXPORTING
* client = sy-mandt
* objnr = lc_objnr_old
* obtyp = 'QC1'
* stsma = ''
* TABLES
* status = lt_jstat.
*
* CALL FUNCTION 'STATUS_BUFFER_EXPORT_TO_MEMORY'
* EXPORTING
* i_memory_id = 'BSVA_BUFFER'.

CALL FUNCTION 'OBJECT_NUMBER_GET_GENERIC'
EXPORTING
i_obart = 'QC'
i_objectkey = ''
IMPORTING
e_objnr = lc_objnr_new
EXCEPTIONS
number_already_exists = 1
obart_invalid = 2
objectkey_missing = 3
OTHERS = 4.

IF sy-subrc <> 0.
* Implement suitable error handling here
ENDIF.
*
* CALL FUNCTION 'OBJECT_NUMBER_GET_QC'
* IMPORTING
* objnr = lc_objnr_new.

CALL FUNCTION 'STATUS_OBJECT_SWITCH_NUMBER'
EXPORTING
client = sy-mandt
objnr_new = lc_objnr_new
objnr_old = lc_objnr_old
EXCEPTIONS
object_not_found = 1
objnr_new_invalid = 2
objnr_old_invalid = 3
status_object_already_exists = 4
OTHERS = 5.
IF sy-subrc <> 0.
"Implement suitable error handling here
ENDIF.

CALL FUNCTION 'OBJECT_NUMBER_SAVE_GENERIC'
EXPORTING
i_update_task = 'X'.


CALL FUNCTION 'STATUS_CHANGE_INTERN'
EXPORTING
* CHECK_ONLY = ' '
* CLIENT = SY-MANDT
objnr = lc_objnr_new
* ZEILE = ' '
* SET_CHGKZ =
* IMPORTING
* ERROR_OCCURRED =
* OBJECT_NOT_FOUND =
* STATUS_INCONSISTENT =
* STATUS_NOT_ALLOWED =
TABLES
status = lt_jstat
EXCEPTIONS
object_not_found = 1
status_inconsistent = 2
status_not_allowed = 3
OTHERS = 4.
IF sy-subrc <> 0.
* Implement suitable error handling here
ENDIF.

"Define internal fields.
<fs_qcvk>-objnr = lc_objnr_new.
* <fs_qcvk>-stsma = ls_status_profile.
<fs_qcvk>-obtyp = 'QC1'.
<fs_qcvk>-ersteller = sy-uname.
<fs_qcvk>-ersteldat = sy-datum.
TRANSLATE <fs_qcvk>-vorlnr TO UPPER CASE.

IF testrun NE 'X'.
GET TIME STAMP FIELD <fs_qcvk>-changeddatetime.
ENDIF.

CALL FUNCTION 'CONVERSION_EXIT_ALPHA_INPUT'
EXPORTING
input = <fs_qcvk>-version
IMPORTING
output = <fs_qcvk>-version.

APPEND <fs_qcvk> TO lt_qcvk.

"check whether the material exist in the database or not.
LOOP AT st_qcvk ASSIGNING <fs_qcvk>.
LOOP AT st_qcvv ASSIGNING FIELD-SYMBOL(<fs_qcvv>) WHERE ctyp = <fs_qcvk>-ctyp AND vorlnr = <fs_qcvk>-vorlnr AND version = <fs_qcvk>-version.
SELECT SINGLE * FROM mara INTO @DATA(ls_mara) WHERE matnr = @<fs_qcvv>-matnr.
IF sy-subrc NE 0.
PERFORM set_return_message USING 'E' 'M3' '305' <fs_qcvv>-matnr space space space CHANGING return.
APPEND return TO return.
ELSE.
SELECT SINGLE * FROM mara INTO ls_mara WHERE matnr = <fs_qcvv>-matnr AND lvorm NE 'X'.
IF sy-subrc NE 0.
PERFORM set_return_message USING 'E' 'M3' '008' space space space space CHANGING return.
APPEND return TO return.
ELSE.
SELECT SINGLE * FROM tq30 INTO @DATA(ls_tq30) WHERE art = @<fs_qcvv>-art.
IF sy-subrc NE 0.
PERFORM set_return_message USING 'E' '' '' 'No Valid Inspection type has been specified' space space space CHANGING return.
APPEND return TO return.

ELSE.
SELECT SINGLE * FROM tq31 INTO @DATA(ls_tq31) WHERE herkunft = @<fs_qcvv>-herkunft.
IF sy-subrc NE 0.
PERFORM set_return_message USING 'E' '' '' 'No Valid Inspection lot origin has been specified' space space space CHANGING return.
APPEND return TO return.
ELSE.
APPEND <fs_qcvv> TO lt_qcvv.
ENDIF.
ENDIF.
ENDIF.
ENDIF.
ENDLOOP.
ENDLOOP.


IF NOT return-id = 'E'.
MODIFY qcvk FROM TABLE lt_qcvk.
MODIFY qcvv FROM TABLE lt_qcvv.
MODIFY qcvm FROM TABLE lt_qcvm.

ELSE.
CLEAR ls_qcvk.
CLEAR lt_qcvk.
CLEAR ls_qcvv.
CLEAR lt_qcvv.
CLEAR ls_qcvm.
CLEAR lt_qcvm.
ENDIF.

IF testrun EQ 'X'.
CALL FUNCTION 'BAPI_TRANSACTION_ROLLBACK'.
* ELSE.
* CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'
* EXPORTING
* wait = 'X'.
* IMPORTING
* RETURN =
ENDIF.

ENDFUNCTION.

Code for the set_return_message.

*----------------------------------------------------------------------*
***INCLUDE LZQIRF01.
*----------------------------------------------------------------------*
*&---------------------------------------------------------------------*
*& Form set_return_message
*&---------------------------------------------------------------------*
*& text
*&---------------------------------------------------------------------*
*&      --> P_
*&      --> P_
*&      --> P_
*&      --> CUSTOMERNUMBER
*&      --> P_
*&      --> SPACE
*&      --> SPACE
*&      <-- RETURN
*&---------------------------------------------------------------------*

FORM set_return_message  USING  VALUE(p_msgty)
                              VALUE(p_msgid)
                              VALUE(p_msgno)
                              VALUE(p_msgv1)
                              VALUE(p_msgv2)
                              VALUE(p_msgv3)
                              VALUE(p_msgv4)
                     CHANGING p_return LIKE bapiret2.

      DATA: BEGIN OF message,
          msgty LIKE bapiret2-type,
          msgid LIKE bapiret2-id,
          msgno LIKE bapiret2-number,
          msgv1 LIKE bapiret2-message_v1,
          msgv2 LIKE bapiret2-message_v2,
          msgv3 LIKE bapiret2-message_v3,
          msgv4 LIKE bapiret2-message_v4,
        END OF message.

         message-msgty = p_msgty.
  message-msgid = p_msgid.
  message-msgno = p_msgno.
  message-msgv1 = p_msgv1.
  message-msgv2 = p_msgv2.
  message-msgv3 = p_msgv3.
  message-msgv4 = p_msgv4.

   CALL FUNCTION 'BALW_BAPIRETURN_GET2'
    EXPORTING
      type   = message-msgty
      cl     = message-msgid
      number = message-msgno
      par1   = message-msgv1
      par2   = message-msgv2
      par3   = message-msgv3
      par4   = message-msgv4
*     log_no = ' '
*     log_msg_no = ' '
    IMPORTING
      return = p_return
    EXCEPTIONS
      OTHERS = 1.
ENDFORM.

Code for the PLV

*&---------------------------------------------------------------------*
*& Include ZDMC_PLV_OLO_SIF_CERT_PROF
*&---------------------------------------------------------------------*


LOOP AT _lt_io_r_st_qcvk INTO _wa_io_r_st_qcvk .

PERFORM _rule_plv_olo_p
     USING
     _wa_io_r_st_qcvk-ctyp           "key value1
     _wa_io_r_st_qcvk-VORLNR       "key value2
     _wa_io_r_st_qcvk-VERSION                          "key value3
      ''
      ''.                            "key value4
             "additional text

  ENDLOOP.
*embed Include DMC_PLV_OLO for PLV processing
INCLUDE dmc_plv_olo.

** End of block for PLV application **

Step 2 : Create a Custom migration Object:

First we need to have a project created in Migrate your Data Fiori App.

In the same Project, we create a Migration object > User Defined > Using Staging table.

Next we define the source Structure, which will have the fields of our area of interest. The advantage of this is we can add more fields as the target structure qcvk, qcvv and qcvm supports it.

After we define the source structure we define the Relationship between the source and Target Structure.

As QCVM is a Item table, which will consist of the Characteristics for each of the Header Certificate profile, so the header Table in such cases will be Mapping only and the Item table will Loop at Table.

After the structure Relations are established, we need to do the fields mapping between the source and destination ( function module Import Parameters ) fields.

Now assume a scenario, where we extract the data from the table and load the data in the excel, but as the Material number is changing in every SAP Instance , Dev, QA, Pre Prod and Prod. A Mapping object ( Translation Object ) Becomes handy.

Here we can leverage the Standard Pre-Delivered SAP Mapping Rules or we can create our own Rules with a check to the Standard Configuration value.

in the target field , just right click and click on assign rule and select from the available standard for the project.

Lets assume , we want to create a Translation object.

1.First we need to create a Translation object.

Please note the Translation object is create at the Sub-project Level and not at the migration object Level.

the Advantage of creating at the subproject level, is other objects Standard or custom Developed in the same project can use it.

Now we create a rule at the subproject Level with a similar intention so that it can be leveraged at Cross Object Level.

Note : if the mapping object is defined at the Project level then at the end of the Mapping object _M is to be added if its subproject then _S, if at the Object level then just the name of Translation object is enough

At the end in the field mapping of the LTMOM assign the assign to the required field.

Once all the process is complete Generate the migration Object, after that, the migration object is visible in the FIORI app : Migrate your Data.

Hope you a bit of insight of the possibility of the data Migration using Migrate Your Data Fiori app

Happy Learning:

Thanks and Regards,

Abhishek Parab.

Adding a Standard field/ custom field to the standard SD Migration cockpit templates.

2024-02-27T18:29:23.747000+01:00

In this blog, we will discuss the step-by-step process to add a Standard field/ custom field to the standard SD Migration cockpit templates.

Eg: While uploading the Open Sales orders Header currency field won’t be there, so to change the currency we can add the currency field to the template and upload. Along with the Currency field, we will add the below fields as well.

Header Data – Shipping type, Currency Key, Your reference.
Item Data - Sales Unit, Item Number of the Underlying PO, Storage Location

Procedure:

Create a Project (Migrate using Staging Tables) to upload Sales orders.

Input Project Name. Search and Select the Migration object SO- Sales order (Only open SO) to upload Sales orders and Save.

2.Goto LTMOM tcode, Select the project created and go to edit mode.

3. Select Source Structures and select Header data on the right screen. Click on highlighted Add Field to add the custom fields in the template.

4.Add the required fields like shown below.

5. Similarly, add other fields to corresponding source structures.

6.Once all the required fields are added, the field mapping is to be performed (The added fields are to be linked to the corresponding target structure fields (FM field)). Goto Field Mapping and on the right side the Target structures will be displayed. Drag the added field from the source structure and map the same to the corresponding field in Target Structure. Follow the same process and link all the added fields.

Note: All the fields which we are adding should be available in the source structure.

Author

M Tharun Kumar

Updating an SAP HANA System Landscape - Overview

2024-03-15T17:26:23.664000+01:00

Updating an SAP HANA System Landscape - Overview

Revision Update

Support Packages (SPS) Update
Version Upgrade – SAP HANA 1.0 to SAP HANA 2.0

SAP HANA system components like,

SAP HANA Database
SAP HANA client
SAP HANA studio

Additional system components like,

Application Function Libraries (AFL, EML and the product-specific AFLs IBP, RTL, TRP, VCH, XRP)
SAP liveCache applications (SAP LCA or LCAPPS plug-in)
SAP HANA EPM-MDS (EPMMDS plug-in)
XS advanced runtime applications
SAP HANA smart data access (SDA)
SAP HANA XS Advanced Runtime

Above components can be updated using the SAP HANA database lifecycle manager (HDBLCM)

To update an SAP HANA system, we need to first download the individual components from Service Marketplace (SMP). This can be done manually download.

Prerequisite:

Before starting the update for the components in your SAP HANA landscape several prerequisites have to be fulfilled.

Make sure you fulfil the following prerequisites:

If you are performing an offline update, you have all the necessary installation files for the individual components.
You have a valid, permanent SAP license for the SAP HANA database.
You have user names and passwords for the following users:
- <sid>adm user
- sapadm user
- S-user for the SAP Support Portal
You have carefully read the update instructions for the individual components.
You have made the necessary preparations to perform backups for the SAP HANA database and the other components.

Check you planned SAP Hana Target Version & Current Operating System Version. If required OS Upgrade for Target Planned SAP HANA version first Upgrade OS.

Upgrade the Operating System

The different versions of the SAP HANA Platform are only supported on specific operating system versions. For information about supported operating system versions for SAP HANA, see "SAP Note 2235581 - SAP HANA: Supported Operating Systems".

When updating to SAP HANA Platform 2.0 SPS 00, you may need to upgrade the operating system. For information about the upgrade, refer to the documentation of the operating system vendor. For the operating system, we recommend that you choose a new installation as the upgrade procedure. We recommend the following procedures:

RHEL

For RHEL 7.2 we recommend a new installation.

SLES

For SLES 12 SP1 we recommend a new installation.

Here we example to take SAP HANA Database Component

Source System: 2.00.040.00 (Revision 40)

Target System: We planned to Update Revision 48

Source Version:

Software From Service Market Place with SAPCAR from Extract SAR File

Start Resident HDBLCM from below location:

Target Version:

SAP S/4HANA migration cockpit - live session 10.04.2024 - SAP S/4HANA Cloud 2402 - including DT

2024-04-08T17:01:42.086000+02:00

Dear SAP S/4HANA migration cockpit friends,

we´ll have a session for customers/partners on our Learning Hub platform - valid S-User is mandatory.

Learning Objectives:

Get an overview on the basic features and functions of the SAP S/4HANA migration cockpit
Get to know the new migration approach “Migrate Data Directly from an SAP System” for SAP S/4HANA Cloud Public Edition
Learn where to find the migration cockpit documentation with the new design of the migration cockpit landing page

Registration for Customers
Register Wednesday, April 10, 2024 10:00 AM - 11:30 AM ((UTC-05:00) Eastern Time (US & Canada))

Best regards, Sybille Lackermeier, SAP S/4HANA migration cockpit Product Management

To access the SAP Learning Hub, edition for SAP Enterprise Support, a one-time sign up is required https://support.sap.com/en/offerings-programs/enterprise-support/enterprise-support-academy/learn.html

Only customers with one of the following maintenance agreements are eligible to access the support edition: SAP Enterprise Support, SAP Enterprise Support, Cloud Edition, or SAP Product Support for Large Enterprises (PSLE).

How to set up the Data Migration Cockpit

2024-04-20T11:56:49.009000+02:00

Efficient SAP role management for the migration cockpit

In the context of the migration cockpit, SAP roles are used as a basis to ensure smooth data migration. Key roles such as SAP_CA_DMC_MC_USER provide basic access rights for standard functions, while SAP_BR_CONFIG_EXPERT_DATA_MIG enables experienced users to optimally customize Fiori applications. The SAP_CA_DMC_MC_DEVELOPER role is essential for more extensive customizations and developments in the SAP system. Targeted role management ensures the efficiency of the migration process and enables successful data migration. I have added the roles to my user via transaction SU01.

After successfully assigning the roles, the app appears in the Fiori Launchpad.

The app cannot yet be used here as the system is not yet configured for this. The following steps have been carried out for this.

System changeability

In order to carry out the required customizing, it is necessary to set the system changeability for the "USER INTERFACE TECHNOLOGY" to changeable.


Enter transaction /n/iwfnd/gw_client to open “SAP Gateway Client”	In the field “Request URI”, enter “/sap/opu/odata/LTB/MIG_MC_ODATA_SRV/$metadata” and choose the “Execute” button

If the system returns the status code 403 and the error message “No Service found for namespace ‘/LTB/’, name ‘MIG_MC_ODATA_SRV’, version ’0001’”, continue with step 2 below. If the system returns the status code is 200, proceed to step 6 below to add the missing system alias.	2, Enter transaction /n/IWFND/MAINT_SERVICE to open “Activate and Maintain Services”. Choose the “Add Service” button

3, Locate the service “MIG_MC_ODATA_SRV”. You can use the following filter criteria to do this if required: System Alias: LOCAL External Service Name: MIG_MC_ODATA_SRV 4, Select the line with external service name “MIG_MC_ODATA_SRV” and choose the “Add Selected Services” button.	5, In the “Add Service” dialog, enter the following information: Technical Model Name: ZMIG_MC_ODATA_MDL Package Assignment: $TMP/ZBOND

	6, The OData Service “MIG_MC_ODATA_SRV” should now be configured correctly. Ensure that the “System Alias” is specified (see screenshot below). If the system alias is missing, choose the “Add System Alias” button add the system alias.

Update
When the migration cockpit is executed for the first time, an update must be downloaded from SAP. To do this, the report cnv_pe_mc_load_objects is executed in SE38.

Tables were copied and created. The template is client 000.


	The error message in the app has disappeared and the app can be used.

Migrating data from SAP ECC to SAP S4/HANA with the migration cockpit

2024-04-20T12:15:10.760000+02:00

Migrating data from SAP ECC to SAP S/4HANA is a crucial step for companies that want to benefit from the improved functionality and performance of S/4HANA. Effective data migration is crucial for a smooth transition and the success of your project. The Migration Cockpit is a powerful tool designed specifically for this purpose, helping companies to migrate data quickly, easily and reliably.

In its simplest terms, data migration involves extracting data from one system and loading it into another. In practice, however, this is rarely possible without transforming the extracted data before loading it into the target system. The transformation can contain formatting values that fit into the target fields. You can also use this phase to ensure the quality of your data (e.g. to identify and eliminate duplicate master data).

The data migration process follows the extract - transform - load approach. At the start of a project, you define the migration objects that you want to use. Each migration object describes a specific type of data, e.g. bank master record, customer, supplier, etc. In the migration cockpit, you can see which migration objects depend on others. For example, to migrate cost centers, you must first migrate your profit center structure.

The data migration process is based on an approach that includes extraction, transformation and loading. At the beginning, the migration objects are defined, which describe different types of data, such as bank master records, customers or suppliers. The dependencies between the migration objects become visible in the migration cockpit. For example, the migration of cost centers requires the prior migration of the profit center structure.

Once the relevant migration objects have been defined, the data is retrieved from the source system, depending on the migration method selected. The data is then assigned to the corresponding fields in SAP S/4HANA, with automatic mapping suggestions providing assistance. Transformations may also be necessary to adapt the data to the requirements of the SAP S/4HANA system, such as converting "GER" to "DE" for country codes.

Simulating the data migration makes it possible to identify potential errors without actually saving the data. After a successful simulation, the actual migration takes place, during which the data is saved in the system. In the event of errors, these can be identified, corrected and reprocessed in the migration cockpit.

The first approach to data migration uses staging tables, which serve as a cache for data. These tables are filled with data from the source system and the "Migrate data" app collects this data from the staging tables for migration.

The source system can either be an SAP system or a third-party system. With this approach, you have the option of downloading an Excel template into which you can load the data from your source system. You can then upload the content of the Excel file to the staging tables. Alternatively, you can fill the staging tables directly with SAP Data Services, your own SQL programming or a third-party ETL tool.

The third approach to data transfer is direct transfer. Here, the SAP S/4HANA system collects the data directly from the source system. The source system must be either an SAP Business Suite system, SAP Apparel and Footwear, SAP CRM or SAP EWM.

The advantage of this approach is that it is suitable for any amount of data. As the data is transferred directly from the source system, there is no intermediate step of storing it in staging tables. This can be particularly advantageous if real-time data transfer or large volumes of data are required.

Here I show you how to perform a migration.


App Migrate Open your data.

Migrate data using staging tables	Assign a name for the migration project

Assign the project to an existing package	At this point, you can select the migration object that you want to migrate.

It must then be checked.	It can be created by clicking on the "Create Project" button.

Progress can be observed in the monitoring map.	Basic mapping tasks must be carried out.

Download template	Upload completed file

First click the Upload button. The validation starts automatically.	This step can also be observed via Monitorig.



Progress can be observed under Monitoring.	Warnings Errors Successes can be viewed using the "Show messages" button.

	Any parameters can be mapped and confirmed under Mapping tasks.

Prepare migration.	Prepare staging tables. Click the Prepare staging tables button here.

This point can also be observed under Monitoring.	After completing the preparation, you can view the errors, warnings, successes and information and correct errors if necessary.

	You can then perform the mapping tasks again.

Mapping	Mapping

Next point, simulate.	For example, you can simulate with 10% of the data.

The progress can be observed in the monitoring.	Errors can be analyzed with "Show messages".

Trigger migration process	Trigger the migration of data.

Information message	Migration started,

The progress of the migration can also be monitored.

Unsuccessfully migrated data records can be reprocessed separately in a correction file. in this case 10 data records.	These ten data records can be reworked and must then be migrated again.

EXTRACTING DATA FROM SAP S/4HANA CLOUD USING THE CUSTOMER DATA RETURN APP AND TRANSFERRING IT

2024-05-15T10:59:33.027000+02:00

EXTRACTING DATA FROM SAP S/4HANA CLOUD USING THE CUSTOMER DATA RETURN APP AND TRANSFERRING IT TO ANOTHER SAP S/4HANA CLOUD INSTANCE USING THE SAP S/4 HANA MIGRATION COCKPIT

This blog post provides general information for extracting data from SAP S/4HANA Cloud Public Edition and transferring data to SAP S/4HANA Cloud Public Edition. Users and customers who have basic knowledge of SAP data migration and new implementation topics or who are interested in these subjects can benefit from the information provided here. This blog gives more details about SAP tools that support the extraction and transferring of data from and to SAP S/4HANA Cloud and it also gives some useful examples.

There is currently no automated way to transfer data from SAP S/4HANA Cloud Public Edition to SAP S/4HANA Cloud Public Edition or SAP S/4HANA Cloud Private Edition. However, SAP provides some standard tools that when used together, support the data extraction from SAP S/4HANA Cloud Public Edition and the data transfer to another SAP S/4HANA Cloud Public Edition instance.

For extracting data, customers can use the SAP standard tool Customer Data Return and for transferring (migrating) data, customers can use the SAP S/4HANA migration cockpit.

Note that there are also other extraction options such as Customer Data Browser, extractors or CDS Views (available in the SAP Business Accelerator Hub). These extraction mechanisms might be simpler if data is only partially extracted or extracted step by step, for example object by object.

However, the focus tool for this blog is the Customer Data Return app as it is a straightforward way to download all customer business data at once and it has a simple and user-friendly interface. The main differentiator and advantage of the Customer Data Return app is that all SAP S/4HANA Cloud (public) customer data can be extracted and downloaded.

The use of the Customer Data Return application may conflict with the data protection policies of your organization. The authorization concept does not support any filtering by the Data Controller or by typical attributes reflecting the purposes of processing. In addition, a download of the data is a transfer in a software/environment that is potentially not secured. Hence, before using the Customer Data Browser application, please ensure that you follow the data protection Policies in your organization.

Transfer of business data (Master Data and Transaction Data) using current released SAP S/4HANA Cloud public edition standard means

The transfer of data to another target SAP S/4HANA system or cloud instance might represent a challenge as the data models, data, and file formats from both SAP tools differ. Therefore, the data extracted by the Customer Data Return app must be transformed and adjusted so to match the data format of the XML or CSV files of the SAP S/4HANA migration cockpit – Migrate your Data app.

ETL Process: Customer Data Return & Migrate your Data -Migration Cockpit app

Below you will find more detailed information about the SAP standard means for extracting and transferring data from SAP S/4HANA cloud data to another cloud instance.

For data extraction from SAP S/4HANA Cloud Public Edition, one of the possible SAP standard means that extracts all customer data and can be used by Cloud Public Edition customers is the Customer Data Return app:

1.- Data Extraction – with the Customer Data Return (CDR)

Customer Data Return (CDR)

With the Customer Data Return app, customers can download SAP S/4HANA business data or archived data owned by customers from SAP S/4HANA cloud systems to a local machine. The files can be downloaded in a compressed format, such as ZIP files. The compressed files contain the actual data files in XML or CSV format.

SAP provides two Customer Data Return apps for extracting and downloading SAP S/4HANA business data, namely:

Customer Data Return – Extraction : This app is used to extract customer owned data and returned it to customer especially in case of cloud off-boarding.
Customer Data Return – Provision: This app is used to download the data extracted with Customer Data Return – Extraction app.

In principle, both apps are used together so that users can extract and then download its SAP S/4 HANA business data.

First, users need to trigger the file preparation (carried out by the extraction user). For more details, see SAP Help Portal - Data Extraction Process. Then, after having created a package, assigned an extraction scope for your package, and started the file preparation task you can then download the files (extracted data).

To execute the file download, you will need a provisioning user. For more details, see SAP Help Portal - Data Provisioning Process.

For more details about how to work with the Customer Data Return, see:

Working with Customer Data Return | SAP Help Portal

The system will prepare ZIP files containing one or more XML or CSV files, depending on the package settings and configuration you have set up. Users can change the file format and file size before preparing them as ZIP files.

To see and rework the CDR XML or CSV files, you can unzip the ZIP files in a folder in your computer. The XML/CSV files will be extracted in folders corresponding to their specific topic or area. For example, “CO” for Controlling, and so on.

Each database table will be extracted to one or more XML or CSV files. The number of XML or CSV files extracted for a particular database table will depend on the size of the table and the File Size (MB) field specified in the package settings of the Customer Data Return app.

For example, for Cost Center; (CDR) structure name CSKS / (Migration Cockpit) data structure S_CSKS one or more files can be generated using the Customer Data Return app.

These files start with the name of the CDR structure name CSKS_<file number>.xml, for example: CSKS_00001.xml, CSKS_00002.xml, CSKS_<XXXXX>.xml. In the example below, only one XML file was generated for structure Cost Center. In contrast, for COEP line Items (by Period), 7 files were generated.

We recommend opening the CDR XML file using Excel or another spreadsheet application. The data is divided into two parts. First, you can view general information about the structure such as:

Structure name
(technical) field name
Position
Key flag
Data type
Length
Decimals
Nullable
SRS_ID

After these rows, you can view the customer data for the relevant structure. These column names correspond to the technical field name of the relevant structure.

More details about the Customer Data Return app can be found in the SAP Help Portal and the KBA (Knowledge Base Article) below:

2.- Data preparation and transformation – for uploading to another SAP S/4HANA Cloud public instance / target system

To transfer (migrate) the Customer Data Return (CDR) downloaded data for upload to another SAP S/4HANA system or cloud instance, you can use the SAP S/4HANA Migration Cockpit. For this, you will need to rework or transform the data in the CDR files and adjust it to the file format and definition used in the Migration Cockpit.

Note that users can also load (migrate) data to SAP S/4HANA Cloud public edition, using the SAP S/4HANA Migration Cockpit. For more details about the migration cockpit see: http://help.sap.com/S4_OP_DM . Consider that the functionality of the SAP S/4HANA migration cockpit for cloud and SAP S/4HANA might differ. Furthermore, the number of migration objects and its definition might vary from SAP S/4HANA Cloud and SAP S/4HANA. For available migration objects for SAP S/4HANA see: http://help.sap.com/S4_OP_MO.

For data transformation and enrichment, you can either do the transformations and modifications by yourself using, for example, Excel or your ETL (Extraction, Transformation, and Loading) tool of choice and then transfer your data to the corresponding XML or CSV templates of the SAP S/4HANA migration cockpit. Also, you can use other standard SAP tools such as SAP Smart Data Integration (SDI) and SAP HANA Smart Data Quality or XSA to transform the data and generate new files which will match the definition of the migration cockpit. SAP Tools such as Smart Data Integration allow users to transform and enrich data during the integration process. Therefore, these SAP Tools could be used in cases where calculations, filters or modification of business logic are required before the data transfer to other systems or displaying the data to users.

Note that the use of tools such as SAP Smart Data Integration and SAP HANA Smart Data Quality, require particularly good usage knowledge and experience with these tools.

The example in this blog will show some general and useful information of the data files and file format for Customer Data Return and the SAP S/4 HANA migration cockpit, including an easy example on how to manually transform the data coming from Customer Data Return. This example applies for cases when customers prefer or must do the transformation using simple tools such as excel or Notepad or do not want or cannot use other ETL tools or other SAP products.

As mentioned in Point 1 – Data Extraction – with the Customer Data Return (CDR) app, in the XML/CSV files coming from Customer Data Return, after the rows that contain the general information about the structure, you can view the customer data for the relevant structure. These column names correspond to the technical field name of the relevant structure.

Usually, the Migration Cockpit structure names and field names will be the same or similar to the ones used for the Customer Data Return app. For example, for Cost Center, the structure name and XML file name will start with the technical structure name, CSKS. Whereas, for the migration cockpit CSV files, the technical structure name will start with an S_ and then the structure name as in XML file(s) of the Customer Data Return app (for example: S_CSKS for Cost Center).

CO - Cost center

Customer Data Return:

File name: CSKS_00001.xml
Structure name: CSKS

SAP S/4HANA migration cockpit – Migrate your Data app:

Migration Object: Z_KOSTL_MASTER_MCE
Migration Object – Technical Structure Name: S_CSKS
Migration Object – XML Template Title: Source Data for Migration Object: CO – Cost center

The XML template file of the Migration Cockpit – Migrate your Data app looks like this:

In hidden row 5, you will find the technical names of the fields and in row 8 you will find the field description and other relevant field information.

The CSV file template of the Migration Cockpit – Migrate you Data app looks like below:

In the CSV template file of the Migration Cockpit, only the technical names of the fields and information about if the field is a key and/or required field are included.

You can copy the CDR relevant data to the corresponding fields of the CSV or XML file templates of the migration cockpit. For example, Cost Center, Valid From, Valid To, Cost Center Name, Description field data from the Customer Data Browser .xlsx file to the corresponding column and rows in the XML template file Source Data for Migration Object: Co-Cost center.

After filling the corresponding data for Cost Center in the Cost Center XML template file in the migration cockpit, the file will look like this:

We recommend that you check for differences between the newest and previous releases:

SAP S/4HANA Cloud – Release Comparison of Migration Object Templates

Important Notes:

Note 1: In case that you recently have performed a new implementation using the SAP S/4HANA Migration Cockpit you might consider using the XML or CSV migration cockpit's template files from previous new implementations. It is certainly worth considering reusing these files at least for the master data. Nonetheless, these files should be used carefully as you must ensure that the template release, template fields and data is still correct. Otherwise, you must update these files so to avoid upload, validation and/or migration errors.

Note 2: While performing the re-formatting of the data to adapt the CDR field information to the migration cockpit template files, you should consider that some information might differ, such as table/structure name, field names, and field format. Usually, the (technical) field names will be the same for both CDR and for the migration cockpit (for example: KOSTL for Cost Center; KOKRS for Controlling Area). However, there are some cases where the field names will be different. Furthermore, CDR XML files usually have a greater number of fields than the XML template files of the migration cockpit.

Note 3: Consider that the Customer Data Return and the SAP S/4HANA Migration Cockpit only handle business data but not configuration information. Therefore, before starting the data migration to the new SAP S/4HANA Cloud instance, you must ensure before that any configuration differences between the SAP S/4HANA Cloud instances have been solved. Additionally, you must ensure that naming conflicts are resolved before the data transfer to the new SAP S/4HANA Cloud instance.

Note 4: Note that with the SAP S/4HANA migration cockpit a migration of historical data is not fully possible. Currently, only the data migration of historical balances or GL account is possible (for more details see KBA 2943035 - Migration of historical balances to SAP S/4HANA and SAP S/4HANA Cloud. For migrating data of all other historical transactional data, customers could use the SAP Datasphere, SAP BW Bridge-Data Tiering.

3.- Data load to the target instance (S/4HANA cloud, public edition) - with the SAP S/4HANA migration cockpit.

For loading data to SAP S/4HANA, you can use the SAP S/4HANA Migration Cockpit – Migrate your Data app.

SAP S/4HANA migration cockpit (MC) for Data load to SAP S/4HANA Cloud

The SAP S/4HANA migration cockpit is designed for customers who have just installed SAP S/4HANA and want to move their legacy data from SAP or non-SAP software systems. It allows you to migrate your master data and transactional data (open items and balances) to SAP S/4HANA, and it facilitates this process by providing predefined migration content and mapping. It can be launched using the Migrate Your Data app in the Fiori Launchpad (Data Migration Launchpad). The migration cockpit is part of both SAP S/4HANA and SAP S/4HANA Cloud and is included in these licenses.

Note: The SAP S/4HANA Migration Cockpit is a tool that provides multiple methods of migrating data from as many legacy systems, SAP or non-SAP, as needed. It has a comprehensive library of migration object templates with the necessary fields already defined to help you migrate data to the HANA database. To perform a data migration using the SAP S/4HANA Migration Cockpit – Migrate your Data app, users must perform some activities. The tool automatically maps source data from the templates to the SAP S/4HANA target system and guides you through a series of step-by-step activities to confirm the mappings and finalize migration, with validation checks occurring in the background.

With the migration approach “Migrate Data Using Staging Tables” of the migration cockpit you can:

Use staging tables to migrate business data from any legacy system to SAP S/4HANA Cloud.
Select the migration objects that are relevant for your migration project.
Generate staging tables for your migration objects and populate these staging tables with data by using template files.
More details can be found in the SAP Help Portal:
- Data Migration – SAP S/4HANA Cloud (Landing page SAP S/4 HANA migration cockpit (Cloud))
- Migration Objects for SAP S/4HANA Cloud – Available Migration Objects
- Transferring Data to SAP S/4HANA Using Staging Tables

For uploading the reworked customer data files, you downloaded from the CDR app to another SAP S/HANA cloud instance, you can use SAP S/4HANA Migration Cockpit - Migration approach Migrate Data Using Staging tables. If you use the migration approach Migrate Data Using Staging Tables, the SAP S/4HANA migration cockpit automatically creates staging tables for each migration object that is relevant for your project. You can fill the staging tables with data either using XML templates, CSV files, or manually using the SAP HANA Studio or by using third party or SAP’s ETL tools (for example SAP Smart Data Integration or SAP Agile Data Preparation).

You must upload the new and reworked data using these XML templates or CSV files of the migration cockpit. This should be done for each migration object XML template or each CSV file, for which you need data to be transferred to the new target system or cloud instance.

For more details on how to load data using the migration cockpit, you can check the following blogs:

Part 1: Migrate your Data – Migration Cockpit (from SAP S/4HANA 2020, SAP S/4HANA Cloud 2008), Migrate data using staging tables and methods for populating the staging tables with data – This blog gives a brief introduction and overview of the SAP S/4HANA migration cockpit and, more details about the migration approach Migrate Data Using Staging Tables see the blog in the link below. There you can also find more details about loading data to the staging tables using XML files:

SAP S/4HANA migration cockpit – Transferring Data from CSV Template Files to Staging Tables – CSV File Upload. This blog provides step-by-step examples on how to load data into the staging tables using CSV files.

_____________________________________________________________________________________

Customer Data Return (CDR) References, and Useful Links

Fiori Apps Library Links:
- Customer Data Return – Extraction: This app is used to extract customer owned data and returned it to customer especially in case of cloud off-boarding
- Customer Data Return – Provision: This app is used to download the data extracted with Customer Data Return – Extraction app.

__________________________________________________________________

SAP S/4HANA Migration Cockpit (Public Cloud) References, Blog Posts, and Useful Links

SAP help portal:

– Cloud:

Data Migration – SAP S/4HANA Cloud (Landing page S/4 HANA migration cockpit (Cloud))
SAP S/4HANA Migration Cockpit – Migrate Your Data to SAP S/4HANA Cloud (Slide Deck presentation, Cloud)
Migration Objects for SAP S/4HANA Cloud – Available Migration Objects
SAP S/4HANA Cloud – Release Comparison of Migration Object Templates
Transferring Data to SAP S/4HANA Using Staging Tables
FAQs – SAP S/4HANA Migration Cockpit (New Fiori UI) for SAP S/4HANA Cloud 2008

SAP Communities:

Training Materials & Videos:

Blog posts (SAP S/4HANA migration cockpit)

Relevant SAP Notes/KBAs:

2538700 – Collective SAP Note and FAQ for SAP S/4HANA Migration Cockpit (Cloud)
2733253 – FAQ for SAP S/4HANA migration cockpit – Transfer option: Transfer data from staging tables

Newsletters:

Other Useful Links (Data Migration, Data Transformation):

______________________________________________________________________________________

Other Extraction Mechanisms

CDS Views (in the SAP Business Accelerator Hub):

Customer Data Browser:

Customer Data Browser

SAP BW/4HANA Content for SAP S/4HANA Cloud / CDS View Based Extractors from SAP S/4HANA Cloud:

Extractors / SAP BW/4HANA Content for SAP S/4HANA and SAP S/4HANA Cloud (based on CDS-Views): SAP BW/4HANA Content.
To extract data from SAP S/4HANA Cloud to SAP Datasphere: see best practice scope item 53L.

Business Content Service (SAP S/4HANA and SAP S/4HANA Cloud):
- Blog: Discover CDS View Based Extractors from SAP S/4HANA Cloud

ABAP Core Data Services Extraction for SAP Datasphere (53L):

Extract data from SAP S/4HANA Cloud to SAP Datasphere: see best practice scope item 53L.
SAP Datasphere | SAP Help Portal
SAP Datasphere Community Page (incl. SAP Datasphere, SAP BW bridge)
Getting Started with SAP Datasphere, SAP BW Bridge | SAP Help Portal
SAP Community Blog: Overview and Technical Deep Dive

Other useful information: