Go Coding

Author: Rudramani Pandey

  • Options for Deploying SAP on Azure

    Preface – This post is part of the SAP on Azure series.

    Introduction

    When we deploy SAP on Azure, a lot of things runs behind it. From creating infrastructure, to creating a builds and ultimately deploying them out using various tools. In this article we will try to explore all the possible options for Deploying SAP on Azure.

    Options for Deploying SAP on Azure

    Both SAP and Microsoft Azure provide various ways to deploy SAP on Azure, they are via:

    • Azure Portal
    • SAP Cloud Application Library (CAL)
    • Terraform and Ansible
    • Arm Templates and Ansible

    Deployment of SAP on Azure using Azure Portal

    We can go directly to the Azure Portal.

    Deployment of SAP on Azure using Azure Portal

    Using the available resources here, we can manually provision all the required artifacts relevant to SAP. Then we can either provision SAP Virtual Machines or even have Azure Virtual Machines, and then install SAP bits over these Virtual Machines.

    Deployment of SAP on Azure using SAP Cloud Application Library (CAL)

    We can go to SAP Cloud Application Library (CAL).

    Deployment of SAP on Azure using SAP Cloud Application Library

    Here SAP provides option to connect to Azure system. It also provides various products that you can deploy to you Azure Subscription.

    Deployment of SAP on Azure using Terraform and Ansible

    You can build and deploy code of Architecture i.e. the networking, the storage, etc using Terraform. And then you can build and deploy code of SAP, SAP bits and other required configurations using Ansible.

    Deployment of SAP on Azure using Arm Templates and Ansible

    You can build and deploy code of Architecture i.e. the networking, the storage, etc using Arm Templates. These templates are maintained by Azure, and it stands for Azure Resource Manager templates. And then you can build and deploy code of SAP, SAP bits and other required configurations using Ansible.

  • SAP on Azure Greenfield Journey

    Preface – This post is part of the SAP on Azure series.

    Introduction

    Greenfield Implementation in SAP means a new implementation of SAP S/4HANA. It involves complete re-engineering and process simplification. In previous articles, we have discussed about SAP on Azure and types of Azure sizing based upon use case. In this article we will discuss SAP on Azure Greenfield Journey.

    SAP on Azure Greenfield Journey

    In Greenfield Migration, following are the steps that we need to follow:

    1. SAP on Azure Planning: It involves all the standard procedure provided by Azure.
    2. Build of IaC for cloud Infrastructure and CaC for OS & SAP Applications: Here infrastructure code that involves networking and other infrastructure related code is built as Iac (Infrastructure As Code). And the Operating System and SAP Application code is built as CaC (Configuration As Code).
    3. Automated Deployments: Using Terraform and Ansible, the above codes are deployed within Infrastructure and Deployment servers in Azure respectively.
    4. Deployment as ECC or S/4HANA: Now using SAP AnyDB on Azure and SAP HANA on Azure, we deploy ECC or S/4HANA.

    SAP on Azure Greenfield

    Source: Google

    SAP on Azure Planning

    We have already discussed the phases involved in SAP on Azure Projects, you can read them here. SAP on Azure planning is a very critical process and it requires all checklist to be ready. The six phases includes:

    1. Project preparation and planning phase
    2. Pilot phase (strongly recommended)
    3. Non-production phase
    4. Production preparation phase
    5. Go-live phase
    6. Post production phase

  • SAP on Azure Migration Journey

    Preface – This post is part of the SAP on Azure series.

    Introduction

    In previous articles, we have discussed about SAP on Azure and types of Azure sizing based upon use case. In this article we will discuss SAP on Azure Migration Journey.

    SAP on Azure Migration Journey

    When we say migration, it is either ECC to S/4HANA migration for on-premise or from on premise to cloud migration. It involves the following steps:

    1. SAP on Azure Planning
    2. Mapping On-premise SAP Instance to the required one among the following:
      1. SAP AnyDB on Azure
      2. SAP HANA on Azure
      3. S/4HANA on Azure
    3. Performing Migration Operation:
      1. Lift & Shift
      2. Lift & Shift/Migrate
      3. Transformation to S/4HANA & Azure Consolidation, Re-implementation

    SAP on Azure Migration

    Image source: Google

    SAP on Azure Planning

    We have already discussed the phases involved in SAP on Azure Projects, you can read them here. SAP on Azure planning is a very critical process and it requires all checklist to be ready. The six phases includes:

    1. Project preparation and planning phase
    2. Pilot phase (strongly recommended)
    3. Non-production phase
    4. Production preparation phase
    5. Go-live phase
    6. Post production phase

     

    Performing Migration Operation

    Once you identified what exactly you want in terms of Infrastructure, then you can perform any of the following paths:

    Path A: We can do a lift & shift of our existing environment up to Azure without any DB changes, and later we can do migration to HANA or conversion to S/4HANA.

    Path B: We can do a lift & shift of our existing environment up to Azure without any DB changes, and then migrate the database to HANA database. Till now, we will be running ECC on HANA. From here again we can perform the conversion from ECC on HANA to S/4HANA.

    Path C: We can directly perform transformation to S/4HANA & Azure Consolidation or Re-implementation of ECC in S/4HANA (which will be then a Greenfield implementation).

  • Sizing for SAP on Azure Projects

    Preface – This post is part of the SAP on Azure series.

    Introduction

    Sizing for SAP on Azure Projects is all about determining the following:

    • Hardware requirements for your Virtual Machines (VMs) including:
      • Memory
      • CPU Power
      • Disk Space
    • I/O Capacity
    • Network Bandwidth

    Sizing according to the type of SAP Project

    Sizing for SAP can be broadly divided into three types:

    • Greenfield Sizing: It is the sizing of a fresh and new SAP instance
    • Brownfield Sizing: It is the sizing for an existing SAP Instance that will either be migrated to the cloud, upgraded, or re-sized
    • Expert Sizing: It is done based upon the tools provided by SAP. This is mainly used in complex sizing and is processed with the help of a sizing expert.

    The above types will highly depend upon your use case:

    • If you have a new SAP System and you want to develop fresh implementations there, then it will be part of the Greenfield Sizing
    • If you have an existing SAP system and you are migrating it to the cloud, then you will need Brownfield sizing
    • If you have a current SAP Cloud system, and you plan to re-size them, then again, you will need Brownfield sizing

    The above types are just to differentiate the sizing based upon your use case. The actual tools for sizing will be discussed next.

    Sizing in SAPS

    Sizing in SAP is known as SAPS. SAPS stands for SAP Application Performance Standard. SAPS is a hardware-independent unit of measurement that describes the performance of a system configuration in the SAP environment. Derived from the Sales and Distribution SD-Benchmarks, where 100 SAPS is defined as 2,000 fully business processed order line items per hour.

    SAP came with SAP Standard Application Benchmarks which makes the sizing process easy. You can view the official page here. Here you can filter and understand where you will land in terms of sizing based upon your filter.

    SAP Quick Sizer

    SAP Quick Sizer is a free web-based tool built by SAP in partnership with platform partners such as Azure to help with sizing your SAP instance. You can check it out here.

    Quick Sizer (classic / HANA) translates business requirements into technical requirements used for sizing. Quick Sizer is basically an online questionnaire that you work through, and it spits out sizing results.

  • Phases of SAP on Azure Projects

    Preface – This post is part of the SAP on Azure series.

    Introduction

    Understanding the phases of SAP projects on Azure is a very important aspect for the successful completion of SAP on Azure projects. In this article, we will discuss all the phases in detail and also share official Microsoft Azure documentation.

    Phases of SAP on Azure Projects

    Phases of SAP on Azure Projects is designed by Microsoft in the form of checklist for the customers who are already using SAP NetWeaver. This checklist helps a client to identify small issues and hence prevents bigger future issues. These phases do not include any tasks that are independent of Azure, e.g. SAP GUI related changes.

    Following are the six phases of a SAP on Azure:

    1. Project preparation and planning phase
    2. Pilot phase (strongly recommended)
    3. Non-production phase
    4. Production preparation phase
    5. Go-live phase
    6. Post production phase

    Project preparation and planning phase

    This phase is where you plan your SAP migration or new SAP deployment on Azure. During this phase, we typically create High-level design and Technical design documents to guide us through the project. They cover:

    High-level design document

    • (If migrating): inventory of current SAP landscape including components, applications, network, security, compute, operating system, database, & HA/DR
    • Build the responsibility assignment matrix (RACI)
    • A high-level solution architecture
    • Automation & operation plans, procedures, & processes

    Technical design document

    • A diagram for the solution & architecture including networking, high availability & DR Sizing for computing, memory, storage, & networking
    • Operating System, Database, kernel, & SAP support pack versions
    • Interfaces inventory including SAP & non-SAP

    You can read the checklist here.

    Pilot phase (strongly recommended)

    This is the pilot/proof of concept (POC) phase. This phase is for testing the designs & approaches from the planning phase. In this phase. it is also common to include a full build of HA/DR, security, & scalability testing. Microsoft strongly recommends having this phase as a part of the SAP on Azure journey. You can read the checklist here.

    Non-production phase

    In this phase, we deploy non-production SAP systems on Azure. This deployment should include development systems, unit testing systems, and business regression testing systems. You can read the checklist here.

    Production preparation phase

    In this phase, we deploy production SAP systems on Azure. We incorporate lessons learned & experience from the non-production phase. If migrating we upgrade SAP systems & prepare for data transfer between our current SAP instance location & Azure. You can read the checklist here.

    Go-live phase

    In this phase, we utilize the playbooks from our earlier phases. We execute the steps that have been tested & practised in earlier phases. In this phase, we freeze all changes in processes and configurations. You can read the checklist here.

    Post production phase

    The phase is post production and includes monitoring the deployment, operating & administering the systems. You can read the checklist here.

     

    References

    https://docs.microsoft.com/en-us/azure/virtual-machines/workloads/sap/sap-deployment-checklist

  • Types of SAP on Azure Projects

    Preface – This post is part of the SAP on Azure series.

    Introduction

    SAP and Microsoft have a 25 years of partnership. Microsoft Azure provides end to end support for both SAP on Premise and SAP HANA Cloud. In this article we will try to explore the types of SAP on Azure Projects.

    SAP on Azure Projects

    SAP Projects on Azure are divided into two types, i.e.:

    • Migration
    • Greenfield

    These two types of projects are for a client who is either existing old client or a new client of SAP. Based upon their need they can choose the project. By choosing project, it doesn’t mean that the client need to go and order these types, but it is there to identify the type of infrastructure and services related to the type of SAP project.

    Types of SAP on Azure Projects

    Migration

    This is the most common type of SAP on Azure Projects. This is typically migrating an on-premise instance of SAP (typically ECC) to SAP HANA Cloud or S4HANA.

    Greenfield

    This is the type of SAP for the industries that do not have currently SAP, but wants to start with SAP in the Cloud. It means it is a fresh implementation of SAP.

    You can read more about the projects of SAP on Azure here:

    https://docs.microsoft.com/en-us/azure/virtual-machines/workloads/sap/sap-supported-product-on-azure

    https://docs.microsoft.com/en-us/azure/virtual-machines/workloads/sap/sap-deployment-checklist

  • SAP Cloud Hosting options

    Preface – This post is part of the SAP on Azure series.

    Introduction

    SAP, headquartered in Waldorf, Germany, with a location in Frankfurt, New York and Bangalore, is a large enterprise having ERP & Business objects software as its main product. SAP stands for “System, Applications & Products in Data Processing”. SAP is mainly divided into two parts in terms of hosting i.e. on premise hosting and Cloud Hosting. The SAP on premise hosting is mainly SAP HANA hosting which a relational database. In this article we will discuss in detail regarding SAP cloud hosting options.

    Different SAP Cloud Hosting options

    SAP, with its partnership with different global cloud hosting companies provides the following cloud hosting options:

    • HANA Enterprise Cloud (HEC)
    • AWS
    • GCP
    • Microsoft Azure
    • Alibaba cloud

    Alibaba has signed a contract recently with SAP, and is majorily focused for the clients in China and nearby regions.

    SAP HANA Enterprise Cloud is a HANA service provided by SAP on its contract. All the data was initially saved in SAP environment, later SAP opened it up to an eco-system of external hosting partners such as DXC, IBM Cloud and NTT.

    Comparison of different SAP Cloud Hosting options

    Let us compare the major SAP Cloud Hosting Providers:

    Factors Google Cloud AWS Azure
    Compute Very large VMs SAP S/4HANA up to 4 nodes totalling 48 TB of memory VMs support up to 24TB & 48 TB memory Very large VMs and bare metal for HANA SAP S/4HANA up to 24 TB RAM scale-up, and up to 60TB RAM scale-out
    Storage Cloud Storage EBS & S3 Cloud storage & Elastic File System Azure Storage and Azure NetApp Files
    Network Virtual networking & Interconnect Virtual networking (VCP) & Direct Connect Virtual networking & ExpressRoute
    Security (IAM) Cloud Identity and Access Management (IAM) AWS IAM Azure AD, RBAC, MFA
    Monitoring Custom monitoring agent collects metrics from SAP HANA & sends to Google Cloud Monitoring CloudWatch & CloudTrail Azure Monitor for SAP Solutions
    Automation Automation tool portfolio Automation tool portfolio Automation tool portfolio
    Backups Backups via SAP Backint agent, snapshots, or backup to cloud storage Backups via EC2 Create Image function & Amazon EBS snapshots SAP HANA backup using Azure Backup Highley Available VMs
    HA/DR HA via Linux clustering across regions & zones HA and DR via multiple Availability Zones and Regions HANA system replication / Azure Site Recovery

  • Security in SAP MTA and CAPM

    Preface – This post is part of the SAP Multi-Target Application (MTA) and SAP CAPM series.

    Introduction

    In SAP CAPM and MTA, the security can be taken care using the implementation of best SAP standard practices and using SAP Infrastructure. The entire application is divided into multiple layers such that the user cannot access the database layer or business logic directly from the browser.

    Implementation

    The implementation is an important aspect of security execution. That’s why it has been divided into multiple parts:

    • Development

    The role of the developer is to implement the security aspects wherever required. In case any external API is implemented, he must get it reviewed. Also, in case if a security issue is found, then a proper solution is provided to the developer, and he must implement the same.

    • Review

    The role of the reviewer is to analyze the security of the infrastructure and the services within it. Once the developer completes its development, the entire project is once reviewed and then sent to the tester for further analysis.

    • Penetration Testing

    The penetration testing team performs pen tests using different scenarios and possible ways of intrusion. Based on their analysis, either they mark it passed or come back with issues. These issues are then checked by developers and, once solved, again tested by the tester until the entire application is secure.

     

    Use Case in CAPM and MTA

    Malware check-in Server-Side

    With the help of a malware scanner in Node.js, the documents and files sent to the server are scanned before passing them to the database.

    Encryption & Decryption in Server and Client-side

    The passwords and other important data are encrypted using a standard encryption mechanism

    Destination in Cloud platform

    Destination in Cloud platform not only helps in implementation of CORS services but also hides the visibility of important service location from users

    Role-based access

    The role-based access helps the developer to keep the data safe from unwanted users. The roles are specific to an application, and it is mandatory for the user to have it for access.

  • Service Consumption and Web APIs using SAP ABAP RAP

    Preface – This post is part of the SAP ABAP RAP series.

    Introduction

    In this article, we will see how to create services in SAP RAP (RESTful Application Programming) and consume the same in UI5/Fiori using the given steps:

    1. Create service definition
    2. Expose entities in the Service Definition
    3. Create Service Binding
    4. Publish OData service
    5. Implement OData in UI5/Fiori

    Create Service Definition

    Right-click on Package >> New >> Other Repositories Objects >> Service Definition.
    Provide the details to create a Service Definition.

    SAP RAP Create Service Binding

    Once the Service Definition is created, expose the required entities and activate it.

    expose the required entities

     

    Create Service Binding

    Right-click on Package >> New >> Other Repositories Objects >> Service Binding.
    Provide Package details, Name, Description and Service Definition name. Additionally, select the Binding Type to create Service Binding.

    SAP RAP Create Service Binding

    Verify the information. To expose the service, click on activate.

    You can access the metadata details by following the Service URL provided in Service Binding. To preview the application, click on provided Preview button.

    OData Publish SAP RAP

    How to consume OData create by SAP RAP

    Like any other OData created by CDS or SEGW, the OData of SAP RAP can be used similarly in UI5/Fiori Applications. Read more about OData here.

  • Dealing with Existing Code in SAP RAP

    Preface – This post is part of the SAP ABAP RAP series.

    Introduction

    This article will provide the step-by-step enabling of existing code in RAP. Using the steps below we will learn “Dealing with Existing Code in SAP RAP”.

    Steps:

    1. Create data model with CDS views
    2. Create Behavior Definition
    3. Add transactional behaviour in Behavior Definition
    4. Create Behavior Pool
    5. Implement transactional behavior of the existing application

    Create data model with CDS views

    Click here to follow step 1

    Create Behavior Definition

    Procedure

    1. Right-click on root CDS view
    2. Select New Behavior Definition
    3. Provide the details (Name, Description).
    4. Select implementation type as unmanaged
    5. Click Next and provide the Transport Request number.
    6. Select Finish.

    Create Behavior Definition SAP RAP

    Add transactional behaviour in Behavior Definition

    Add transactional behavior (Create/Update/Delete/Actions) of business objects.

    Add transactional behaviour in Behavior Definition SAP RAP

    Add transactional behaviour in Behavior Definition ABAP RAP

    Create Behavior Pool

    You can assign any number of behavior pools to behavior definition. Within a single global class, you can implement multiple local classes which defines the transactional behavior of the business object.

     

    Procedure

    Behavior Definition >> Right-click >> select New Behavior Implementation >> Provide details >> Finish

    Splitting implementation into different behavior pools

    Figure 1:Splitting implementation into different behavior pools

     

    Behavior Pool

    Figure 2: Behavior Pool

    When you go to Local Types in Behavior Pool, you can see below local classes.

    local classes in Behavioral Pool

    local implementation classes SAP RAP

    Within these local implementation classes, you can implement the business logic of existing behavior objects and test the end-to-end scenario using EML (Entity Manipulation Language) syntax.