Category: SAP

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

Introduction

Azure DevOps is a powerful version management tool. Its CI/CD pipeline keeps the work in flow without interruption. But sometimes, even Azure DevOps ends with errors. These error can be categorized as follows:

• Build Definition based errors: It means the error is in the Pipeline build.
• Release Definition based errors: It means the error is in pipeline release.
• Build Artifacts based errors (Error in code): It means the error is in the code. Sometimes the code is converted successfully into build artifacts (or drop files), but generates error during deployment.
• Deployment environment generated errors: It means the error is generated by external deployment environment. The error may be in pipeline configuration or the build code.

Debugging and Troubleshooting Errors on Azure DevOps

All the debugging and troubleshooting Errors on Azure DevOps starts from log. Once the deployment fails, you can see error directly in the console as shown below:

You can click the error above to read more or simply download the log and explore later, as shown below:

You can further turn debugging mode on, and run pipeline again, and then download logs for debugging. To turn the debugging mode on, you need to enable system diagnostics as shown below:

In case something went wrong, then the environment too returns log for analysis. For example, in case deployments in SAP Environment fails, they give cloud foundry commands to download the logs, something like this:

-> cf deploy -i f450e444-8632-11ea-abb3-eeee0a8f6ba7 -a monitor                                  

Updating application "uiDeployer"...

Application "uiDeployer" attributes are not modified and will not be updated                     

Uploading application "uiDeployer"...

Content of application "uiDeployer" is not changed - upload will be skipped.                     

Starting application "uiDeployer"...

Application "uiDeployer" started

Application "uiDeployer" executed

Stopping application "uiDeployer"...

Deleting discontinued configuration entries for application "uiDeployer"...

Service key "onboarding-workflow-credentials" for service "workflow" already exists

Uploading content module "onboarding" in target service "workflow"...

Deploying content module "onboarding" in target service "workflow"...

Skipping deletion of services, because the command line option "--delete-services" is not specified.

Process finished.

Use "cf dmol -i f450e444-8632-11ea-abb3-eeee0a8f6ba7" to download the logs of the process.

 

Then, you can use terminal/command prompt to download the logs using the command as mentioned above. This will only work, once you login into their environment using the CLI.

Now, you have successfully downloaded the log and you need to identify the issue so that you can troubleshoot, you can follow below steps to do the same:

• Download the log
• Identify the type of error, as discussed in the introduction
• In case it is a pipeline error, check where exactly it failed. If it failed during build extract, you can simply try redeployment. If security files or YAML has issues, then you need to Google and identify the fix of the same. If the pipeline itself has error like “Deployment YAML file is not found”, then again you need to check if you are providing the right configuration in the YAML or Release pipeline or not
• In case it is an error related to the code, then identify if it is a part of Frontend, Backend or Database, then accordingly assign the bug to respective developer
• In case it is an error related to the environment, then check if the environment configuration is correct or not, download the log provided by the environment to identify the root cause. In case, you are still unable to fix environment based error, then raise a ticket to respective Admin team

Common Errors on Azure DevOps

Pipeline won’t trigger

• UI settings override YAML trigger setting
• Pull request triggers not supported with Azure Repos
• Branch filters misconfigured in CI and PR triggers
• Scheduled trigger time zone conversions
• UI settings override YAML scheduled triggers

 

Pipeline queues but never gets an agent

• Parallel job limits – no available agents or you have hit your free limits
• Can’t access Azure Key Vault behind firewall from Azure DevOps
• You don’t have enough concurrency
• Your job may be waiting for approval
• All available agents are in use
• Demands that don’t match the capabilities of an agent
• Check Azure DevOps status for a service degradation

 

Pipeline fails to complete

• Job time-out
• Issues downloading code
• My pipeline is failing on a command-line step such as MSBUILD
• File or folder in use errors
• Intermittent or inconsistent MSBuild failures
• Process stops responding
• Line endings for multiple platforms
• Variables having ‘ (single quote) appended
• Service Connection related issues

References

Troubleshoot common errors in Azure DevOps CLI

DevOps: Common mistakes and how to avoid them

Troubleshoot connecting to a project

Troubleshoot pipeline runs

Review logs to diagnose pipeline issues

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

Introduction

Azure DevOps pipeline configuration starts with Azure Repository and Branches. We firstly create an Azure DevOps Repo, and then create our branches within it. Then only we can configure Azure Pipelines. In this article we will explore both Azure Repository and Branches.

Azure DevOps Repository

Azure DevOps Repository is a space where all the branches are created. We create separate Repos for individual projects.

Steps to Add Repository

1. Create a new Repository (You need Authorization to do so)
   
2. Assign a name to your Repository e.g. “Test Repo”, and choose Type as Git:
   

You can find your Repo, like mentioned below:

Azure Git Branches

When a new Repository is created, it just has master branch. As per the requirement of your project, you can create multiple branches. A simple flow of code includes three branches i.e. Develop, Release and Production. The Develop is the one where all the development is done, Release is where all the testing is performed by the testers and the Production is the one that has stable code, available for end users.

Adding Branches

According to your use case you can create Develop, Release and Production branch with certain policies (The branch will be on top of Master)

Enter required details:

Add in Favorite:

Adding Policies in DevOps branches

To add or change branch policies, you need to click on the three dots next to the branch and then click on “Branch policies”.

Following are some ideal policies:
1. Require a minimum number of reviewers

2. Mark “Check for linked work items” as “Required”

3. Mark “Check for comment resolution” as “Required”

4. Set “Limit merge types” as below:

We can make more changes as per the project requirement. We can read more about policies here.

5. Now add reviewers

And then add these:

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

Introduction

A pipeline is a user defined flow of deployment steps. Azure too provides an option to design a pipeline. Azure Pipelines combines powerful automation activities such as Continuous Integration (CI) and Continuous Deployment (CD) to test, build and deploy developer’s code. In this article we will try to understand all the important aspects of Azure Pipeline.

Azure Pipelines Overview

Under Azure Pipeline we will discuss the following activities performed by a Change Manager:

• Pipelines
• Releases
• Library

Although, we have these all options available under Azure Pipelines:

Pipelines

Pipelines within the Pipelines (as shown above) is the place where we define a build. A build is a deployable file (also referred a drop in DevOps) that is further transferred to Releases for deployment. We can automate the operation of build, and that is then referred as Continuous Integration. We will learn creation of Pipelines in detail here.

After successful completion of build, the Pipelines build looks like this:

Releases

Releases under Pipelines is the place where we deploy the drop or build to a defined destination or environment. We can automate the Releases too, and that is then referred as Continuous Deployment. We will learn creation of Releases in detail here.
After completion of Release, the pipeline looks like this:

Library

All the files that are used within Pipelines and Releases are saved here, under Secure files tab. We can access these files wherever we want. Many times we need to save a file at DevOps level and use it only during build or deployment. In that case, you can save the file within Library and use it whenever and wherever required.

The library within Azure DevOps looks something like this:

Azure Pipelines Flow

Let’s understand in simple words the flow of a pipeline:

• Before a pipeline is build, a Repository is created
• When a new Repository is created, it just has master branch
• You need to create dev, release and prod branch with certain policies (According to your requirement)
• Now, you need to create a Pipeline. There are two ways to create a pipeline: One with the help of YAML, it adds a YAML file to your base branch, and secondly manually adding the tasks or stages in pipeline
• Once you have created a pipeline, you can run it with the branch you want. On success, the pipeline creates a drop file (or artifact) that can be used by Release for deployment. You can add a trigger A trigger tells a pipeline to run, in this case you can triggered it manually.
• Now, you need to create a Release. Here, you need to specify the sourcee. the build pipeline and a trigger to tell when to start deployment. Based upon the available environment, we will do configuration in Release and Create Release after that.
• Once we start a Release or Build, the task to build or deploy is assigned to Azure Pipelines Agents. These agents can be seen within Agent Pool Jobs. An Agent is a cloud infrastructure that runs a job. In our use case, it will run build and deployment respectively.
• Once the Agent completes its job, the Release Pipeline will mark your stage as green.

That’s it. You have successfully created, configured and ran a pipeline in Azure DevOps.

References

Check key concepts related to Azure Pipelines here: https://docs.microsoft.com/en-us/azure/devops/pipelines/get-started/key-pipelines-concepts?view=azure-devops

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

Introduction

Microsoft in 2008 came with a cloud computing service and named it Windows Azure which was later known as Microsoft Azure. Till 2018, developers using Azure or non-azure service was provided with a code version control tool called Microsoft TFS, which was later upgraded and called Azure DevOps. Likewise Azure, Azure DevOps too is a cloud-based service used mainly for version control and project planning.

What is Microsoft Azure

Microsoft Azure is a cloud computing service offering that includes Software as a Service (SaaS), Platform as a Service (PaaS) and Infrastructure as a Service (IaaS).

What is Microsoft Azure DevOps

Microsoft Azure DevOps is a planning and collaboration tool inbuilt with version control (both Git and Microsoft TFS). Microsoft DevOps provides the following options:

• Azure Boards: Users can create Kanban boards, interactive backlogs and plan a sprint for developers and testers.
• Azure Repos: With Git and TFS, user can create a Repository, branches and their policies to control the flow of a project.
• Azure Pipelines: Users can build, test and deploy to any cloud or on-premise environment using CI/CD Pipelines.
• Azure Test Plans: Users can manage Quality Assurance with the help of test plans and improve the quality of their project.
• Azure Artifacts: With the help of Azure Artifacts, users can share npm, python and other packages with the entire team.
• Azure Extension Marketplace: From Docker to slack, everything can be integrated with Azure DevOps.

The architecture of Azure DevOps lifecycle

Azure DevOps lifecycle includes almost all the services that we have discussed above. It starts with project planning, and the task is created for developers using Azure Boards. Then the developer starts coding in an IDE with the help of branches created over Azure Repos. Once the development is completed, then the user creates a CI/CD pipeline using Azure Pipelines and deploy it in the required environment. Once the deployment is completed, tasks are created for testers who use Azure Test Plans to execute the tests. These steps are shown in the image below:

The above diagram shows end to end lifecycle of our CICD pipeline, including all other Azure DevOps steps.

Difference between Microsoft Azure DevOps and Microsoft TFS

Microsoft TFS (Team Foundation Server) was introduced by Microsoft to manage high volume codes for big organizations. Later, with the introduction of Git in the market and an increasing number of Git users, Microsoft integrated it too and launched a tool called Azure DevOps. Let’s discuss all the differences between Microsoft Azure DevOps and Microsoft TFS:

Features	Microsoft Azure DevOps	Microsoft TFS
Type	It is a distributed source control system	It is a Centralized Source control system
Scaling	It cannot scale to a very large code base, but it is highly distributed between teams	It scales to a very large codebase
Version Control	It has repository and branch level version control	It has fine level version control
Usage Monitoring	No usage monitoring system	It allows usage monitoring
File lock option	No lock files options	It has the ability to lock files exclusively
Code bases	It is mainly used for modular codebases	It is mainly used for Large Integrated codebases
Offline Experience and Speed	It has full offline experience and speed	It needs always to be online
CI/CD Support	It supports continuous integration and continuous delivery of codes	No CI/CD option

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

Introduction

In previous article we have learnt different ways to deploy SAP project on Azure. One of them was the deployment to Azure from SAP Cloud Appliance Library (CAL) Portal. In this article, we will explain you the basics of CAL and steps of deployment.

SAP Cloud Application Library (CAL)

SAP Cloud Application library is an online tool provided by SAP that can be used to instantly deploy up-to-date, preconfigured and ready-to-use SAP solutions. These solutions can be deployed into any of the public cloud accounts including Microsoft Azure, Amazon Web Services (AWS), Google Cloud Platform (GCP) and Alibaba Cloud. This portal enables kick-start of SAP projects using public cloud.
You can access the portal here.

Once you are logged in, the home dashboard looks like this:

By default, you will see all the solutions provided by SAP CAL with filter options. You can filter the types from All to free, paid and others. Also, you can filter on the basis of Cloud Provider i.e. Microsoft Azure, Amazon Web Services (AWS), Google Cloud Platform (GCP) and Azure China. The other tabs in the left pane i.e. Instances, Accounts, Users and My Subscriptions are only applicable once you create an instance by choosing one of the Solutions on home screen. You can check the portal introduction by SAP here.

Steps of Deployment to Azure from SAP Cloud Appliance Library (CAL) Portal

Step 01: Create an account on SAP CAL by clicking here. If you have existing SAP account, then you can use the same here. You will be asked to upgrade your account:

Step 02: From Dashboard, choose a solution relevant to your cloud, in our case we will filter based upon Microsoft Azure and Free Solutions.

Now, you need to visit each of the instance and check which one suits you the best. To do that, just click on any solutions provided above (Do not click create Instance). When you click on the solution, it gives you the information about what it is with recommendation.

Step 03: Once you decide the right solution for yourself, then you can click on “Create Instance”. It will ask a few questions like the name of Instance, its description and the cloud provider. Choose “Microsoft Azure” in the cloud provider.

Step 04: Enter the Microsoft Azure Subscription ID. You can get your subscription ID from here. Check out this documentation to find the steps to fetch the same.

And then enter the same below and click Authorize, this will grant permissions to SAP Cloud Appliance Library to access your Azure Active Directory.

Step 05: Now, you will be asked to Enter Instance details, as shown below:

Step 06: Now, you can plan the size of your Virtual Machines, as shown below:

Step 07: Based upon the data you provided in the above steps, an instance will be created and you will find your instance under “Instances” tab with given options:

You will also find these instances added within your Microsoft Azure “Resource Groups”:

That’s it. Now you can play with your Azure Resource Group and proceed with further installations related to SAP.

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.

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).

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.

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.

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

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

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).

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.