SAP OS/DB Migration - II

Details:

SAP OS/DB Migration - II

Solution:

Different System Copy Methods

SAP System Copy or Migration Tools for ABAP

SAPINST:

SAP system installer controlling the system copy process.

R3LDCTL:

Create database independent table and index structure files (*.STR).

Create view structure file (SAPVIEW.STR).

Create database specific DDL command tempelate (DDL<DBS>.TPL or DDL<DBS>_LRG.TPL).

R3SZCHK:

Computes the size of ABAP tables/indexes and stores them in extent file (*.EXT).

Limit Calulation of object extent size to 1700 MB.

Create target database size file (DBSIZE.XML)

R3LOAD:

Unloads or loads ABAP table data from or into the DB.

Write platform independent data dump format.

Supports table splitting.

Character set conversion to unicode are implemented in R3LOAD.

Control the restart of object if R3load fails by using task file (*.TSK).

SMIGR_CREATE_DDL (ABAP Report):

Generates DB-specific DDL statements for nonstandard DB objects of the ABAP Dictionary, mainly SAP Business Warehouse (BW) objects.

Generate <TABART>.SQL files

RS_BW_POST_MIGRATION (ABAP Report):

Posts system copy activities for nonstandard DB objects in the ABAP Dictionary.

Mandatory for all SAP BW and SAP SCM systems.

MIGMON: 

Migration Monitor is a tool provided by SAP for managing and monitoring the migration process during an SAP system migration. It is designed to assist in executing, controlling, and tracking the various steps involved in a system migration.

SAP OS/DB Migration - I

Details:

SAP OS/DB Migration - I

Solutions:

SAP OS-DB migration is a conventional technique used to migrate the operating system or database of an SAP system to a newer version, implement system architecture changes, or transition to a different operating system or database supported by SAP. This migration process can be classified into two types: homogenous and heterogeneous system copies.

Homogenous System Copy :

A homogeneous system copy refers to a migration process where the source and target systems have the same operating system and database platform. In other words, the underlying technology stack remains consistent throughout the migration.

Hetrogenous System Copy :

A heterogeneous system copy involves migrating from one operating system or database platform to a different one. This means that the source and target systems have different operating systems or database platforms. In this scenario, additional steps and considerations are necessary to ensure a successful migration and compatibility between the systems.

After reading the above information , there is a question which will usually arise in mind that, "What is the difference between Migration and System Copy ? ".

Migration and system copy are related concepts in the context of SAP systems, but they have distinct meanings and implications.

Migration generally refers to the process of moving an existing SAP system from one environment to another. This could involve transferring the entire system, including the operating system, database, and application components, to a new server or infrastructure. The goal of migration is to ensure a smooth transition of the entire system while minimizing downtime and preserving data integrity.

On the other hand, a system copy specifically refers to duplicating an existing SAP system, either in the same environment or in a different one. System copies are often performed for various purposes, such as creating development or testing environments, system upgrades, or system refreshes. The focus is on replicating the system configuration, data, and settings rather than transferring the entire system infrastructure.

In the context of SAP OS/DB migration, the import/export method and the backup/restore method are two distinct approaches used for different purposes. Here are the differences between the two methods:

Import/Export Method in SAP OS/DB Migration:

Scope: The import/export method focuses on transferring specific data objects or subsets of data from the source system to the target system.

Data Granularity: It allows selective extraction and migration of specific data sets, such as tables, records, or schema.

Format: Data is typically exported in a structured format, in data dump file.

Transformation: The exported data may require transformation or manipulation before it can be imported into the target system. This could involve data mapping, conversion, or cleansing.

Flexibility: The import/export method provides flexibility in terms of migrating specific data components or subsets, allowing customization of the migration process.

Backup/Restore Method in SAP OS/DB Migration:

Scope: The backup/restore method focuses on capturing and restoring the entire SAP system, including the operating system, database, application components, and configurations.

Completeness: It provides a comprehensive snapshot of the entire system at a specific point in time, ensuring the recovery of all system components.

Format: Backups are typically created in proprietary formats specific to the SAP system, optimized for efficient storage and restoration.

Point-in-time Recovery: The backup/restore method enables the restoration of the system to a specific point in time, facilitating recovery from system failures, data corruption, or other issues.

System-level Restore: It involves restoring the complete SAP system infrastructure, including the operating system, database, application files, and associated configurations.

In summary, the import/export method in SAP OS/DB migration is focused on selective data transfer, while the backup/restore method is concerned with system-level recovery and restoration of the entire SAP system.

SAML2 Configuration for SAP ABAP Platform

Details:

Step-by-step configuration instructions for Single Sign-On (SSO) access to SAP ABAP using IDP (ADFS). We have two scenario, for the configuration of SAML2

Scenario 1:

We have a SAP Web-dispatcher infront of SAP Application Server to access the url.

Scenario 2 :

We are directly accessing the service of SAP Application Server (Without Wed-dispatcher)

Pre-requisite:

SSL need to be configured first before configuring for SAML2 authentication.

Steps:

Activating the Services

1. Goto Transaction SICF, enable below services 

    /sap/bc/webdynpro/sap/saml2

    /sap/public/bc/sec/saml2

   /sap/public/bc/sec/cdc_ext_service

   /sap/bc/webdynpro/sap/saml2

   /sap/public/bc/icf/logoff

   /sap/public/bc/sec/saml2

   /sap/public/myssocntl

   /sap/bc/saml2/idp/sso

   /sap/bc/webdynpro/sap/SAML2_IDP

2. On the Maintain Services page, enter one of the service name from the list.

3. Right-click the service in the tree menu view, select Activate Service.

4. Prompt to activate the service, click Yes with tree option.

Enable SAML2 Local Provider Setting

1. Run the transaction SAML2 or open the URL 

https://<FQDN>:<ICM_HTTPS_PORT>/sap/bc/webdynpro/sap/saml2?sap-client=100&sap-language=EN

Note : If you want to use webdispatcher then open the SAML2 URL through webdispatcher Url 

https://<WEBDISPATCHER_FQDN>:<WEBDISPATCHER_ICM_HTTPS_PORT>/sap/bc/webdynpro/sap/saml2?sap-client=100&sap-language=EN

2.  Click on Enable SAML2.0 Support and Select "Create SAML 2.0 Local provider".

3. Enter the Provider Name https://<SID>CLNT<CLINET_NO> on Intital setting screen. Click Next.

4. Choose Automatic in Selection Mode on Service Provider Settings and Select Finish.

5. After Click on Finish, it will be redirect you to Configuration Page.

6.  Click on Metadata button to get pop-up for the metadata download, then select Download Metadata.Make sure browser pop-up is allowed.

7. Share the Metadata.xml file with the ADFS team, for Relying Party Trust (RPT) in ADFS for the SAP system.

8. Once RPT is done, ADFS will share the federation XML file and certificate which has been used to sign your metadata xml. If in case they do not share the certificate then you can extract the certificate from federation xml.

9. As a next step, open the SAML2 and click on Trusted Providers tab.

10. Select the the Upload Metadata File

11. Upload the federation xml in Metadata file.

12.  In the Next Step Metadata Verification, Upload the federation certificate and Click Next

13. In Signature and Encryption Step Choose the Digest Algorithm

14. In Authentication Requirements, Choose the shown and Click Finish.

15. First Click on Edit and then Add then select the Unspecified and then Save the setting.

16. Then Click on Enable to activate the configuration.

17. Goto Transaction SICF , enter the service name or external alias example /sap/bc/ui2/flp and open the service

18.  Select Logon Data Tab. Choose the Alternative Logon Procedure and set SAML Logon at 1 and Save.

19 . Test the Service by directly copying the require in browser. In case of any RPT error . Please reach out to ADFS Team.

20. For any other issue access the Security Diagnostic tool using the URL: https://<host>:<port>/sap/bc/webdynpro/sap/sec_diag_tool?sap-client=<sap_client>

21. Log on with a user that has the role SEC_DIAG_TOOL_VIEWER or full administrative rights in the specified ABAP system.

22. In the Name field, enter a description trace file name.

23. Choose the severity of the trace which you needed  (ex :  Debug, Info, or Error).

24. Click on Start to activate the trace.

25. Reproduce the SAML2 error.

27. Stop the Activated trace, download the generated file. If you need help from SAP then Incident can be raised on component BC-SEC-LGN-SML.

Note :

- Till now due to SAML2/ADFS limitation it is not possible to configure the SAML2 SSO for two different client of the same system.

- If you want to configure the SAML2 SSO for both Webdispatcher and Backend URL then additional share the below URL to ADFS team during RPT.

Example :

https://<Webdispatcher_ALIAS_FQDN>:<WEDB_ICM_PORT>/sap/saml2/sp/acs/<CLINET_NO>

https://<Webdispatcher_Physical_FQDN>:<WEDB_ICM_PORT>/sap/saml2/sp/acs/<CLIENT_NO>

https://<BACKEND_FQDN>:<BACKEND_ICM_PORT>/sap/saml2/sp/acs/<CLIENT_NO>

https://<Webdispatcher_ALIAS_FQDN>:<WEDB_ICM_PORT>/sap/bc/ui2/flp?sap-client=<CLIENT_NO>&sap-language=EN#

https://<Webdispatcher_Physical_FQDN>:<WEDB_ICM_PORT>/sap/bc/ui2/flp?sap-client=<CLIENT_NO>&sap-language=EN#

https://<BACKEND_FQDN>:<BACKEND_ICM_PORT>/sap/bc/ui2/flp?sap-client=<CLIENT_NO>&sap-language=EN#

How to Create HTTP RFC destination between two ABAP systems

 Details:

Create HTTP RFC destination between two SAP systems

Steps:

1.  Go to the transaction SM59.

2. Click on Create as shown in the screenshot.

3. Provide RFC Destination , Connection Type - H , Target URL & ICM Port.. As a good practice for the HTTP ABAP connection always recommended to create a destination with name convention <SID>CLNT<CLIENT_NO>_HTTP. Also, if you want to access some service give the path of the service in path prefix.

4. Click on Logon Security tab and provide target system Client no., Username and Password and Click on Save to Save the RFC destination.

5. Click on Unicode tab. Now a days all the abap systems are the unicode system. So select the UNICODE radio button and Click on Save.

6.  To test connection goto the shown path to test if the target system is reachable. If the test is successful result will be as shown below.

Note:

- Always make sure to use the SYSTEM type user for the RFC destination.

- Never use DIALOG / COMMUNICATION user type in RFC destination, if the system parameter login/password_expiration_time is set then the user password will expire and RFC will fail.

- In some special case scenario SERVICE type user can be used in RFC destination.

- For trust SSL Handshaking Choose SSL => ACTIVE and Certificate List PSE. Also Upload and save the certificate in the same PSE from STRUST.

How to create RFC destination between two ABAP System

Details:

Create RFC Destination between two ABAP system of type 3

Steps:

1.  Go to the transaction SM59.

2. Click on Create as shown in the screenshot.

3. Provide RFC Destination , Connection Type, Hostname and Instance no.. As a good practice for the ABAP connection always recommended to create a destination with name convention <SID>CLNT<CLIENT_NO>.

4. Click on Logon Security tab and provide target system Client no., Username and Password and Click on Save to Save the RFC destination.

5. Click on Unicode tab. Now a days all the abap systems are the unicode system. So select the UNICODE radio button and Click on Save.

6.  To test connection goto the shown path to test if the target system is reachable. If the test is successful result will be as shown below.

7. You can also perform the authoziation test to test if maintained username / password in RFC destination is correct and user have enough autorization for the connection. Test output will be as shown.

Note:

- Always make sure to use the SYSTEM type user for the RFC destination.

- Never use DIALOG / COMMUNICATION user type in RFC destination, if the system parameter login/password_expiration_time is set then the user password will expire and RFC will fail.

- In some special case scenario SERVICE type user can be used in RFC destination.

SAP SNC Single Sign-On for SAP GUI

Pre-requisite -

Install the SAP Secure Login Client on End-user Desktop/Laptop.

Configuration Steps - 

1. Run the transaction SNCWIZARD. Click on Continue to go to next step.

2 . Provide the SPN name "CN=SPN_NAME" which has been created in ADFS for SSO. Click Continue

3. System will show all the required parameter which are need to be set in DEFAULT.PFL and it will automatically setup in this step.

4. It will show you the private key information. Click Continue.

5. Click on Complete to finish the Configuration.

6. Take the restart of the application server. So that the set parameter will come into effect.

7. Run the transaction SPNEGO. Click on Add button

8. Provide the SPN name with domain address and its password. Continue and exist the transaction.

9. Go to Transaction again. Go to User mapping to find out the actual syntax which need to be maintained in SU01, SNC tab.

10. Update the SPN Name in SAP Logon Pad system details and Click OK.