DevOps for SAP

This post was originally published in the Spring 2023 DevOps Enterprise Journal.

Overcoming old ways of work is one of the main challenges for all companies worldwide. Even though there are areas inside those companies that apply best practices for development and operations, there are likely still several others that still lack basic improvements. One of the areas inside big enterprises that still moves slowly toward modernization with DevOps practices is the SAP area.

What Is SAP?

SAP, the company that produces the SAP software, is the sixth biggest IT company worldwide. And they became huge like this because SAP is the most famous, used, and effective software for enterprise resource planning (ERP). If you work at a manufacturing company, SAP will control the quotes you give suppliers and allow you to place the order to purchase some goods. SAP will also track the logistics of the shipment, monitoring and recording when you receive them on your branch stock, put them in the warehouse, and use them in your manufacturing line. Finally, SAP also covers sales, inventory, deliveries, and more—all while controlling the controller, HR, and project areas. According to the SAP website, 77% of the world’s transaction revenue touches at least one SAP system. So this is huge, right?

A Typical SAP Installation

SAP installations haven’t changed much in the past decades. SAP was created in the 1980s. Of course they’ve evolved a lot—they don’t put their software on CDs anymore, for example. But still, when you install SAP, the company will send you some media files and you’ll have to take several steps to prepare the operating system and then install SAP itself.

 A typical SAP installation is made of five different applications. There’s the database, the ABAP SAP Central Services (or ASCS), which is the communication server, and the Primary Application Server (PAS), which is where your users will actually connect to. ASCS will require an Enqueue Replication Server (ERS) to be configured for high availability, and so PAS will require an Additional Application Server (AAS) as well. You’ll also need to consider connectivity with some file system like Amazon EFS to share data across the required nodes.

Here’s an overview of the installation process: (1) Select your operating system. (2) Create and prepare ownership of several folders on the OS. (3) Connect your instance to a shared file system to control all of your data. (4) Select the database you want to use and configure SAP to connect to it. (5) Configure High Availability as well. As you can see, installing SAP in your organization’s workflow requires an extensive amount of work. It’s not fast. And in many cases, it can take up to two months to install a full SAP landscape.

Problems of Manual Installation

With all those steps, SAP installations tend to be very error-prone. And when you’re doing operations manually, you are distant from getting any DevOps benefits. By doing an SAP installation manually, you have the problems of not having things in code:

• You will never repeat exactly the same process.
• You are centralizing knowledge on just a few folks’ specialized heads.
• Since you can’t repeat it, every time you do an installation, you’ll be rediscovering the process and using another two months to do so.
• Since you don’t have your resources in code, it will be harder to prove to Audit what and how your team did.
• Not having resources in code means poor documentation.

Common Automations

Mainly the SAP basis, which is the role that typically drives the installation, comes from an IT operations background. They usually are very familiar with Bash. Because of that, many small pieces of automation are available out there for simple tasks like creating the folder structure, installing package manager (YUM or ZYPPER) packages, configuring host names, and mapping your instances to know each other. But with all of this in place, we’re still missing the installation itself.

Then enters the problem with Bash. Bash is a very low-level language: it will require you to go raw into the OS (Operating System) and apply all your changes one by one. If some command fails, it’s up to you to fix that as well. And for you to build good and reliable code, when compared to more high-level languages (which abstract some of the heavy lifting of coding), it’s gonna take a lot of time. Also, maintaining this code in the future will be hard, since Bash code can very easily turn confusing. And there’s a final blocker for that. During an SAP installation, you’ll have to reboot the instances at least once, and once you reboot your instance from within it, you lose connectivity to it. And because of that, you’ll need a central controller assigning tasks so you don’t miss your fleet during the installation.

Ansible Automation for SAP

The project found in the “Automating SAP Installation with Open-Source Tools” blog post automates the whole process of installing SAP from the get-go. It uses Terraform for the infrastructure creation on AWS all the way until Ansible gets to the instance. Then Ansible does all of the preparation work, changes host names, does mappings on /etc/hosts, does package manager installations, prepares folders and logs, and performs several other activities that used to be done manually. After all that, it finally triggers the SAP software installation within those instances. A Jenkins pipeline controls the process, and Jenkins itself acts like the controller assigning the installation tasks mentioned above.

Here’s an overview of this Jenkins pipeline:

• Create environment with Terraform on AWS.
• Install HANA database.
• Install ASCS/ERS in parallel with HANA.
• Install PAS.

This takes less than two hours to complete and can be repeated as many times as necessary.

How to Run the Automation

There is this open source repository on GitHub under the AWS samples group. The user initiates a local Jenkins main node on their own instance, then fills in the parameters like: (1) Where are your SAP media files on an S3 bucket. (2) Do we want the installation to be highly available or not? (3) Host names. (4) The SAP ID, etc. Once you’re done with that, you will trigger the installation and wait for about two hours.

Challenges throughout the Process

SAP has its own libraries and its own packages that you will use to interact with the SAP system on the terminal on the command line. Having all these libraries available in Linux PATH variable was one of the main challenges. Once Ansible can add those variables to the PATH, then SAP interaction happens fine. That was a little more complicated while running from Jenkins than just SSHing into the instance because of how Ansible connects to the instance itself. Loading the regular SAP scripts that populate the PATH variable caused Ansible and Jenkins to hang indefinitely. Troubleshooting deeply the instance led to the creation of a copy of the regular scripts removing the commands TSET (or reset) that made the hanging to happen.

Benefits for the Organization

After automating all of those processes, you’ll get all of these benefits:

• Ansible is a high-level language, and therefore it’s easier to maintain.
• Because your installation is now coded, there are no manual steps to remember, and the process is replicable.
• With installation as code, you’re able to quickly provision environments to internal teams for sandboxes or training purposes.
• Intelligent check for parameters of this solution will make sure you have feedback sooner at the very beginning of the installation instead of having some failure during the installation or utilization themselves.
• This process reduces errors due to less human interaction and also reduces dependency on highly skilled people for tasks that can be automated.
• All processes written in code are auditable.
• Installation as code increases traceability in operations.

Read more guidance papers in the Spring 2023 DevOps Enterprise Journal.

- About The Authors

Guilherme Sesterheim

Follow Guilherme on Social Media

•