
1. Your <a href="#technical_debt">technical debt</a> is out of control, and it takes you weeks to move transports to production.
2. You use <a href="#sandbox_systems">sandbox systems</a>, but they take a lot of time and money to provision, only to have the data quickly become stale.
3. Your <a href="#project_based_development">project-based development</a> has numerous challenges, and you never ship on time.
4. Your <a href="#transition_to_hana">transition to S/4HANA</a> will take years and require significant effort from your already overburdened team.
5. You need to <a href="#validate_processes">validate processes</a> but are restricted by the system landscape.
6. Testing <a href="#cross_system_compatibility">cross-system compatibility</a> is unattainable.
 
 
Chances are you have at least one of these pain points in the SAP space. Luckily, we can mitigate or eliminate these issues with modern technology.
 
Please post in the comments if you would like a deeper dive into any of these issues.

<h2 id="technical_debt">Technical Debt</h2>
<br /><b><u>Problem</u></b><br />
Technical debt is primarily due to the centralized architecture of SAP. Centralized development is when all development and configuration occur in a shared system. This shared space introduces numerous challenges. 
<ul>
    <li>The quality of the data quickly degrades. </li>
    <li>To test your results, you need to move your code or configuration back and forth from DEV to QAS.</li>
    <li>It's challenging to update existing code since you don't understand the implications. Instead, you add to it, making it more complex and keeping obsolete code buried in your system.</li>
    <li>Changes are in disparate areas (data dictionary, report, class, methods), making it difficult to conduct peer reviews.</li>
    <li>Static analysis is tedious to set up, and manual checks are slow and error-prone. Think of anything hindering your workflow, and you accept it as "this is the SAP way."</li>
</ul>

<br /><b><u>Solution</u></b><br />
Modern development relies heavily on testing, which requires ephemeral systems. Ephemeral systems are used for a specific purpose and can live for as short as a few minutes. Consider an SAP system that spins up in three minutes, runs unit or integration tests, reports the results, then is deleted. This system likely ran thousands of tests and modified the database, so it should be short-lived. Implementing this type of modern architecture requires the use of containers. 
<br /><br /> 
With containerized SAP, you can implement a modern workflow. Your workflow should facilitate peer reviews, run static analysis, validate that unit tests exist and are passing, and merge the code to the main branch of your code repository. Applying this workflow to a feature or bug fix is a pipeline. CI/CD pipelines are popular because they help create higher quality code and deploy faster. CI/CD has been around for over a decade, but it requires ephemeral systems to implement, so it was not previously possible for SAP. Well, it is now. 

<h2 id="sandbox_systems">Sandbox Systems</h2>
<br /><b><u>Problem</u></b><br />
Sandbox systems are a stepping stone to maintaining a clean system landscape. Typically, sandbox systems are refreshed once per year to facilitate access to high-quality data in an isolated environment. However, this is still not frequent enough, and it's a time-consuming and expensive process. Since users know that they can try anything in a sandbox, the system requires more frequent refreshing. It also involves a considerable manual effort to port the changes from sandbox to development.
<br /> 
<br /><b><u>Solution</u></b><br />
You need a consistent way to "refresh" the system and keep the data up-to-date. However, you should also have a way to allow users to keep their changes. The last thing you want is a system refresh that wipes a week's worth of development. Do not worry; modern development has a solution for this too! You should be using containers for your sandbox systems. With containers, you can perform a "refresh" in minutes to restore the sandbox to its original state and revert any data changes. Development and config can be saved using abapGit and restored after the "refresh." You can also maintain recent data in your container system by leveraging tools such as SAP TDMS or other available third-party tools. These tools allow you to time slice data from production to keep your containers up-to-date. Using these tools, you can even anonymize/scramble sensitive data to ensure security compliance.

<h2 id="project_based_development">Project-based Development</h2>
<br /><b><u>Problem</u></b><br />
If you've been on an SAP project, you've experienced at least some of these issues every single time. 
<ul>
    <li>You run into object locks with other developers or team members.</li>
    <li>You have trouble getting consistent data to test your features.</li>
    <li>You keep a spreadsheet with a list of transports for production.</li>
    <li>You have to handle failed transports when moving to production.</li>
    <li>You experienced project delays.</li>
    <li>You have to implement a code freeze during User Acceptance Testing (UAT).</li>
    <li>You have trouble fixing production bugs found in locked code for the current project.</li>
</ul>

<br /><b><u>Solution</u></b><br />
If you've read these headaches in order, you'll notice I'm starting to sound like a broken record. All these issues stem from the fact that we're trying to run billion-dollar companies using a shared system! Using SAP containers that run in the cloud, you should be able to provide systems for each project team where they can do all of their development and testing. Once the project is ready for UAT, you can move it to your central landscape, but at this point, containers allowed you to perform such exhaustive testing that UAT is nearly error-free. You can even provision production replica containers for your UAT team to work as efficiently as possible. Since the container systems run in the cloud, you provision them on-demand and delete them when the project is over. 

<h2 id="transition_to_hana">Transition to S/4HANA</h2>
<br /><b><u>Problem</u></b><br />
Upgrades are challenging. Everything from setting up the system to ensuring it performs as expected becomes a daunting task. Significant changes in the system mean that you will make errors. You are also starting fresh, so you do not want to repeat yesterday's mistakes. The good thing is that you know your expected results, and you can improve on the status quo.
<br /> 
<br /><b><u>Solution</u></b><br />
Leveraging the concepts covered above, you can use this transition as an opportunity to stop banging your head against the wall. This is the perfect time to implement better workflows and improve your system landscape. This approach requires using containers to allow teams access to sandbox systems, implementing CI/CD pipelines, and creating a culture where you encourage automated testing.

<h2 id="validate_processes">Validate Processes</h2>
<br /><b><u>Problem</u></b><br />
Your QAS system and PRD system are likely very different. You have probably experienced production issues that you cannot replicate in QAS. Or maybe you want to validate processes in a production replica before you perform them in production! Process validation was previously just wishful thinking but containerized SAP makes that possible. 
<br /> 
<br /><b><u>Solution</u></b><br />
Containerized SAP with the latest production data using a tool like SAP TDMS or third-party solutions makes this a realistic option. Validating processes in an isolated system can help save a lot of effort and headaches and ensure business continuity. 

<h2 id="cross_system_compatibility">Cross-system compatibility</h2>
<br /><b><u>Problem</u></b><br />
If you're an SAP partner and building solutions, you need the ability to validate that your solutions work on a variety of systems. Validating across systems is a costly and resource-intense process. You might have created your solution on ERP 6.0 Ehp7 on an ASE DB but need to test ERP6.0 Ehp8 on HANA and S/4HANA 2021. 
<br /> 
<br /><b><u>Solution</u></b><br />
You should only run systems when needed. By running containerized versions of SAP, you can achieve this. You can improve the quality of your solutions while not spending your entire budget running systems full-time and starting with configured systems that include data.

<br /><br /> 
If your first thought of the headaches listed here is "that sounds nice, but it's too expensive to adopt," you're wrong! The flexibility and system requirements of containerized SAP cloud systems also mean that they can be significantly more affordable than typical setups. So you get better functionality while spending less!


Learn how modern technology can help you solve these issues.

Chances are you have at least one of these pain points in the SAP space. Luckily, we can mitigate or eliminate these issues with modern technology.

Top 5 Development Headaches and How to Make Your Life Easier


<div className="feature-list shadow-xl">
    <div>
        <p>
            $ ./create_vm_instance.sh vm-1217 <br />
            $ docker-compose up
        </p>
    </div>
</div>

The first time I installed SAP, I failed at it. I had been trying for about three months before giving up. It seemed impossible.

A few years later, a more tenacious team member got as far as starting the installation via SWPM, but it failed due to system requirements. He shared everything he had learned with me, and I set out to try again.

I worked on my next attempt for about one month before seeing that wonderful screen load.

<img src="/images/blog/devops/sap.png"/>

After that, I kept running through the installation process and iterating on it, learning a ton along the way, including that SAP offers a method to perform an unattended installation. I got to the point where I could install SAP ERP in about one day.

<br />
<b>One day was not fast enough.</b>

Modern DevOps relies on spinning up a server in minutes to run automated tests and ensure the code is safe to move to production. We needed a better way.

<br />
<i>This article is a follow-up to <a href="/blog/practical-guide-to-devops-for-sap">A Practical Guide to DevOps for SAP ERP</a></i>

One of the advantages of working on a cross-disciplinary team is that you’re not bound by the old way of doing things and instead can share better ways of accomplishing a task. Our team includes non-SAP developers who had no idea of the existing limitations and underestimated the task’s difficulty. This turned out to be a great thing.

## Infrastructure as Code (IaC)
Today we can prepare a machine to run SAP in about 2 minutes by running one command.

<div className="feature-list shadow-xl">
    <div>
        <p>
            $ ./create_vm_instance.sh vm-1217 <br />
        </p>
    </div>
</div>
A lot is happening here. This command makes a call to a hyperscaler to create a virtual machine with the proper system requirements to run SAP ECC in a container. Once the VM is provisioned, it installs all dependencies required, including Docker, docker-compose, npm, VPN, nano, configures hostnames, and more.

<div className="feature-list shadow-xl">
    <div>
        <p>
            $ docker-compose up
        </p>
    </div>
</div>

The second command is also dense. If you’re not familiar with Docker, it uses images as a type of snapshot to run nearly any application. In our case, it downloads an image of an SAP system that runs on Docker. It contains production-quality data and points to virtualized or non-production interfaces. Creating the image is no easy task, and it requires a significant understanding of containers and SAP to complete an installation that works in a container environment. Once the container is created, it can be reused as many times as you want from that point on. For example, you can load it with three years or one month of data from a production environment. The command above triggers the image’s initial download and extraction, which is the slowest part of the process to provision a new VM with SAP. The process takes around 30 minutes (depending on the system size). The next step is to start a container from this image, and this takes about 3 minutes which is the time for SAP to start.

The VM’s we found work for our system are 4 vCPU, 32768 RAM (MiB), and 500 GB SSD. We use technologies compatible with any hyperscaler, such as AWS, GCP, or Azure.

## Automate Everything
Now that your infrastructure can be deployed with code, the possibilities are endless.

You can integrate IaC with a nice frontend. The frontend allows employees or contractors to access a self-service portal to provision VM’s and start, stop, and delete containers. You can set limits on their access (e.g., number of VMs, what images they can download, etc. ) through configuration and create a dashboard to manage resources. Development of this self-service portal goes through a CI/CD pipeline, of course!

<br />
<img src="/images/blog/devops/iac_neo.png"/>

Another possibility is to manage your IaC in your CI/CD pipeline. Since it’s code, you can test like you usually do with your pipelines. Part of this is possible because of the use of artifacts. In the context of IaC, artifacts are your Docker images or VM images. If you make code changes to your infrastructure, such as reducing your VM’s disk space and RAM, you can test your artifacts deploy correctly after the changes. Even though the test process is long, it’s scalable and automated, so it’s worthwhile to do.

<br /><b><u>Practical Example</u></b><br />
I want to test 5 different variations of the RAM and disk space. I create five branches and assign the different test values to each, then run automated testing. I can check back later that day to see which variations had errors. If any of them were successful, I conclude that SAP runs without issues on a more affordable machine. I can then submit a PR for the branch that worked. The next time the command to provision a VM is executed, it uses the latest code (i.e., with the more affordable machine). This test took about 15 minutes of my time and a few hours of machine test time. If you use infrastructure as code, you can test that infrastructure as code!

<br /><br />
<img src="/images/blog/devops/whoa.png"/>

## Change Management
For most people using a solution like this, the changes are reasonably transparent. They still connect to SAP in the same way as before and only need to learn how to click a few buttons to manage their SAP system.

Developers have a bit more upskilling to do but nothing unreasonable. They need to learn the basics of GitHub or whatever git tool you use. They also need to become more familiar with unit tests and implement an adequate test suite.

## Security
Access control is still restricted, and traffic goes through a VPN. Production data can be sensitive, so the copy should include synthetic data or data obfuscation. These tools maintain the integrity of the data while creating completely fake records.

## Looking to the Future
<img src="/images/blog/devops/future.png"/>

There are still some unknowns with this approach, but one thing is for sure, enterprise technology has fallen behind. I understand that some challenges are more nuanced, but software development is decades ahead of where we currently are with ERP systems.

Projects should not take years.

Code freezes belong with floppy disks.

Repetitive tasks are best left to the machines.

Deploying code to production should take hours and be nearly risk-free.

Enterprise IT modernization isn’t happening overnight, but companies need to get serious about it or risk becoming obsolete. I hope sharing our experience provides some value to others and helps move us forward.

If you enjoyed this post sign up for our newsletter where we'll continue sharing our journey with DevOps.

## Credits
<blockquote>Photo by <a href="https://unsplash.com/photos/xU5Mqq0Chck" target="_blank">Drew Beamer</a> on <a href="https://unsplash.com/" target="_blank">Unsplash</a></blockquote>

Originally posted on the SAP Community Blog
<a href="https://blogs.sap.com/2021/12/17/infrastructure-as-code-devops-and-the-future-of-enterprise/" target="_blank">Infrastructure as Code, DevOps, and the Future of Enterprise</a><br />


Applying modern development methods to legacy ERP

Modern DevOps relies on spinning up a server in minutes to run automated tests and ensure the code is safe to move to production.

Infrastructure as Code, DevOps, and the Future of Enterprise


We’ve been applying DevOps for SAP to our product development and couldn’t be happier with the results. Below is a high-level overview of how we implemented DevOps for our team, and I hope it helps move the practice forward and gain adoption within SAP.

<ol>
    <li>Run SAP ECC in a Docker container and allow each developer to run an isolated system.</li>
    <li>Use abapGit to save ABAP code with a code repo such as GitHub.</li>
    <li>Leverage ABAP Unit to execute unit tests and measure coverage.</li>
    <li>Configure GitHub Actions to
        <ul>
            <li>Run all tests and ensure minimum coverage</li>
            <li>Enforce syntax rules with abaplint</li>
            <li>Require peer review</li>
            <li>Spin up a “QA” system for the test team to use</li>
        </ul>
    </li>
    <li>Code that makes it to the main branch is production-ready code</li>
</ol>

## Containers Change the Game
<img src="/images/blog/devops/containers.png"/>

If you’re not familiar with containers, you can think of them similarly to virtual machines. A virtual machine allows you to run an operating system, and a container enables you to run a single program. In our case, the goal was to run SAP ECC in a container. One advantage of containers is that they are quickly replaceable. For example, you can break your system and start a new container in about three minutes. This is possible because containers are based on images. Images are like “snapshots” that store the system in a known state.

Each developer, functional resource, or tester can use containers to run their own SAP system. Running SAP in a container environment provides system isolation, so work never impacts others. Isolation is a massive advantage as you don’t have to worry about object locks, overwriting data someone else was using, or creating inaccurate results if your work depends on theirs.

There are several options to run containers, but one of the most popular is Docker. We built our containers using Docker mainly due to the large community and trusted name.


<br /><b><u>Practical Example</u></b><br />
You have multiple images available to use:

<ul>
    <li>SAP ERP 3 years of data</li>
    <li>SAP ERP 1 month of data</li>
    <li>SAP ERP no data</li>
    <li>SAP S/4HANA 2020</li>
</ul>

You receive a requirement to format all the phone numbers in your SAP ERP system to match the country’s format for that customer. You start a container based on “SAP ERP 3 years of data” and write your first draft of the logic. You test it individually for 12 phone numbers, and it works. Then you decide to run it on all 125,000 customers and realize that it deletes every other phone number.

In a traditional scenario, this might make any developer panic. However, container isolation means you only impacted the current container you are running. You decide to remove that container and start a new one, again based on the image “SAP ERP 3 years of data,” so all of your customer phone number data is back to the original state after 3 minutes. Time to try again.

## The Missing Source Code Manager
<img src="/images/blog/devops/github.png"/>

The keen reader might wonder, “what happens to my code if I remove a container?” Any changes you make to a container are wiped when you remove it. The new container is a replica of the image you use, introducing a new problem – how do we save our code?

abapGit to the rescue! abapGit is an opensource git client for ABAP. It allows us to use a tool such as GitHub for source code management. Instead of transports, we use abapGit to manage our code changes inside a container. There are countless tutorials on git and GitHub, so I will only cover the basics.

Git uses the concept of repositories which are very similar to SAP packages. Each repository corresponds to an SAP package. By default, your repository has one main branch considered the definitive branch. You can create feature branches to experiment with before committing it to the main branch. When you begin working on a feature or bug fix, you create a branch (e.g., my-feature-branch.) Any code changes you make are committed to this branch. The branch is now part of the repository and visible to others who have access. Now you can start a new container and pull your feature branch into the new container.

<br /><b><u>Practical Example</u></b><br />
Before removing my container, I create a branch “nl-format-phone-numbers” and commit the changes. Then I can safely remove that container and start a new one. When the new container spins up, it will pull the main branch by default, but I can navigate to t-code ZABAPGIT and change the branch from main to the nl-format-phone-numbers branch. I can now pull my feature code and continue working where I left off.

## Goodbye Test Team
<img src="/images/blog/devops/automation.png"/>

As a developer, reducing the cycle of code, test, debug, repeat is crucial. The reality is that testing is difficult, and the feedback loop when humans are testing is far too long. Automated testing helps reduce this cycle and deliver better software.

Testing requires an organizational change. ABAP unit testing is not new in SAP but is rarely used. Using automation to enforce unit testing can train developers to follow the recommended practice. It’s too easy in a standard development workflow to skip the tests. Using GitHub Actions, you can make it a requirement to have adequate test coverage and tests that pass to merge a feature branch to the main branch.

Writing tests upfront is more work, but it’s well worth it in the long run. Tests don’t need to be overly complicated. The benefit is realized because they are run in aggregate by a machine and expose any dependencies across projects. If you do not have automated testing, a human needs to be aware of all the dependencies and manually test them when any change is made. This manual approach is not reasonable or sustainable.

<br /><b>The “Goodbye Test Team” is said tongue-in-cheek.</b> In reality, we’re just shifting the test team’s responsibilities to help develop tests cases before development begins. The updated test process allows the developer to write code to test valid business scenarios and provide sufficient coverage. It also changes the flow so that the test team doesn’t need to perform the repetitive task that a machine can perform.<br />

<br /><b><u>Practical Example</u></b><br />
<ul>
    <li>Select 50 customer phone numbers at random and validate that the final format is correct.</li>
    <li>If reasonable, check at least one phone number from each country and validate the final format is correct.</li>
    <li>Check that the total number of entries with a valid phone number are the same before and after formatting.</li>
</ul>

## Clean Code Only
<img src="/images/blog/devops/actions.png"/>

Putting it all together leads to the final step before merging a feature branch to the main branch. This step uses GitHub Actions and is highly configurable, but we share a proposed strategy that can be used by organizations starting their DevOps journey.

GitHub Actions allows you to automate workflows. In our case, when a developer completes a feature, they will want to merge the code to the main branch via a pull request (PR). Before allowing this, we need to:
<ol>
    <li>Execute all unit tests and make sure everything passes and the minimum test coverage is met.</li>
    <li>Run abaplint to confirm the correct syntax is used.</li>
    <li>Require a code review from another developer.</li>
    <li>Spin up a “QA” system that the test team can use to run any manual tests required.</li>
</ol>

This entire process should only take a few hours. It provides a better separation of duties so that once a developer completes their development, it is unlikely the code will come back to them for additional revisions. This updated workflow allows all team members to focus more on their core responsibility instead of wasting time in the back and forth involved with the legacy process.

<br /><b><u>Practical Example</u></b><br />
<ol>
    <li>I complete my feature branch, run my automated tests on my local environment, and commit my changes.</li>
    <li>I go to the GitHub website and create a PR that triggers the workflow.</li>
    <li>All my tests pass, but during the code review process, a fellow developer notices that my comments are not helpful and provides suggestions on how to improve them. They do not approve the request and instead request I implement the changes.</li>
    <li>I update my comments, commit my changes, and add a comment on GitHub, letting the reviewer know, “Thanks for the suggestions. Comments are now updated!”</li>
    <li>The reviewer approves the code.</li>
    <li>The test team runs some manual tests and finds nothing wrong. They approve the changes.</li>
    <li>GitHub has everything it needs and merges the nl-format-phone-numbers branch with the main branch.</li>
    <li>GitHub Actions triggers another action to pull the code in dev and create and release a transport.</li>
    <li>The transport is safe to move to PRD and moves automatically via a batch job at 2 AM.</li>
</ol>

## Change is Hard
<img src="/images/blog/devops/metamorphosis.png"/>

We treat the main branch as production. Once code makes it to the main branch it is production-ready. A transport can be automatically created and released in the development system. Since the code has been tested in a containerized version of QA, it is safe to move directly to production.

Of course, there are exceptions, but these can be handled as such and outside the standard workflow. For example, you must coordinate the process and manually move transports if a manual process is required.

<img src="/images/blog/devops/architecture.gif"/>

As a starting point, it’s good to handle transports manually to provide confidence that this modern process works and does not disrupt production. If appropriate, you can move to more automation after establishing a certain comfort level.

## Credits
<a href="https://abapgit.org/" target="_blank">abapGit</a> on <a href="https://github.com/abapGit/abapGit" target="_blank">GitHub</a><br />
<a href="https://abaplint.org/" target="_blank">abaplint</a> on <a href="https://github.com/abaplint/abaplint" target="_blank">GitHub</a>
<blockquote>Photo by <a href="https://unsplash.com/photos/tjX_sniNzgQ" target="_blank">Frank McKenna</a> on <a href="https://unsplash.com/">Unsplash</a></blockquote>
<blockquote>Photo by <a href="https://unsplash.com/photos/wX2L8L-fGeA" target="_blank">Roman Synkevych</a> on <a href="https://unsplash.com/">Unsplash</a></blockquote>
<blockquote>Photo by <a href="https://unsplash.com/photos/FTfjMijq-Ws" target="_blank">Rock'n Roll Monkey</a> on <a href="https://unsplash.com/">Unsplash</a></blockquote>
<blockquote>Photo by <a href="https://unsplash.com/photos/KE0nC8-58MQ" target="_blank">Carl Heyerdahl</a> on <a href="https://unsplash.com/">Unsplash</a></blockquote>
<blockquote>Photo by <a href="https://unsplash.com/photos/VMKBFR6r_jg" target="_blank">Suzzane D. Williams</a> on <a href="https://unsplash.com/">Unsplash</a></blockquote>

Originally posted on the SAP Community Blog
<a href="https://blogs.sap.com/2021/12/13/a-practical-guide-to-devops-for-sap-erp/" target="_blank">A Practical Guide to DevOps for SAP ERP</a><br />


We've been applying DevOps for SAP to our product development and couldn't be happier with the results.

A Practical Guide to DevOps for SAP ERP


## Authentication: Do your customers need yet another website login?

As the number of logins people need to remember increases, extra authentication measures create friction that discourages customers and becomes a barrier to adoption. Busy B2B customers don’t want to waste time going through yet another registration process when buying through an e-commerce platform for the first time. If you’re not offering secure and straightforward access, there’s a high chance your customers will go to Amazon or another platform for which they already have an account.

<div className="feature-list shadow-xl">
    <div>
        <p className="font-medium text-center text-red-500">
            Busy B2B customers don’t want to waste time going through yet
            another registration process...
        </p>
    </div>
</div>

<p>
    <span
        className="hs-cta-wrapper"
        id="hs-cta-wrapper-7a363ab1-7124-4178-8bc9-44f98db8a88c"
    >
        <span
            className="hs-cta-node hs-cta-7a363ab1-7124-4178-8bc9-44f98db8a88c"
            id="hs-cta-7a363ab1-7124-4178-8bc9-44f98db8a88c"
        >
            <a
                href="https://cta-redirect.hubspot.com/cta/redirect/6971110/7a363ab1-7124-4178-8bc9-44f98db8a88c"
                target="_blank"
            >
                <img
                    className="hs-cta-img"
                    id="hs-cta-img-7a363ab1-7124-4178-8bc9-44f98db8a88c"
                    src="https://no-cache.hubspot.com/cta/default/6971110/7a363ab1-7124-4178-8bc9-44f98db8a88c.png"
                    alt="Get your free report with insights on how to implement authentication."
                />
            </a>
        </span>
    </span>
</p>

These days people typically have to remember dozens of different sets of login credentials. Unfortunately, this challenge encourages people to reuse the same passwords across multiple accounts. Moreover, trivial inconveniences, such as forgetting the login credentials, can affect your internal team and your customers. Current solutions often require additional help from the internal IT team to handle user password resets. Together, these complications increase the chances of someone gaining unauthorized access to customer accounts, placing a severe burden on your account management, security, and compliance teams.

## Solving the problem with a single sign-on approach

When it comes to user authentication, there is no need to reinvent the wheel. Existing solutions like Microsoft 365, Google Workspace, and Okta can easily be integrated into any modern e-commerce platform, such as Nuve. Your platform should recognize the account and associate it with the corresponding customer in your SAP or ERP system. That way, users can log in using an account that they already have with a supported platform. Many B2C marketplaces have been doing this for quite some time, albeit usually via Facebook or Google logins.

### Added Convenience

The single sign-on (SSO) approach provides two significant benefits – convenience and security. As far as convenience is concerned, providing seamless access without any barriers creates a positive first impression. Customers can connect an existing account instead of filling in a registration form and remembering another set of login credentials. It would be best to offer authentication using the popular SSO providers to allow customers to access your platform right away.

SSO also benefits your internal team. Your team can use their own Google Workspace or Microsoft 365 accounts to access the tools and data they need to do their jobs. The IT team can also benefit from the extra convenience on the customer’s end. They would no longer have to handle any password reset issues. The reduced likelihood of unsafe password practices means having a more secure business all around.

### Increased Security

Shifting the responsibility to a third party like Google or Microsoft is truly a situation where all parties win. The major SSO providers typically offer multi-factor authentication and have some of the most robust security policies and controls in place of any organization in the world. Few e-commerce enterprises can expect to compete with the aforementioned industry-leading giants in information security. If you’re a mid-market enterprise, developing an <a href="/blog/cybersecurity-should-never-be-an-afterthought" target="_blank">in-house authentication mechanism can lead to security gaps</a> in your identity and access management (IAM) solutions. Few things do more damage to a brand’s reputation than customer accounts and compromised data by hackers. The risk is even more significant in the case of B2B transactions. Such issues can affect entire supply chains and often involve the movement of large sums of money.

Integrated third-party authentication measures remove those unnecessary access barriers to encourage customer retention and offer a better customer experience all around. This ease of access applies regardless of whether they’re authenticating into your e-commerce platform via a mobile app, website, or other connected sales channel.

<script charSet="utf-8" src="https://js.hscta.net/cta/current.js"></script>

<script charSet="utf-8" src="/js/hs.js"></script>


Leverage SSO to Avoid Yet Another Login

As the number of logins increases, authentication creates extra and unnecessary friction for customers. Fortunately, there is a better way to ensure security.

Do Your Customers Need Yet Another Website Login?


## Our Journey with SAP ERP DevOps

The 2006 release of SAP ERP 6.0 predates Docker's initial release by seven years! The two technologies are geared towards different scenarios: think monolithic on-premise server vs. cloud-native microservices. What could be gained by combining the two? Software development teams outside of the SAP ecosystem are years ahead in leveraging DevOps ideas, automated testing/continuous integration, and modern version control tools (i.e., GitHub) to realize tremendous productivity and quality gains. Containerizing ERP would be a considerable step towards accessing these advantages for ABAP development.

Here at Nuve, we developed our product to give customers access to SAP's powerful sales and distribution functions through a modern REST API. Our team was not satisfied with the status-quo ABAP development experience, so we decided to take a fresh look at community efforts to run SAP ERP inside a container. We were excited by the prospect of productivity gains and the new development workflows we could achieve -- if only we could spin up ERP instances in a matter of minutes. Spoiler alert: we got there, and it takes 3 minutes to get a fresh ERP instance ready to go! We created a DevOps workflow around this capability that accelerates Nuve development and will ensure we always deliver a fast, effective, and tested solution to our customers. In this blog post, we explore why containerizing SAP ERP was such a tantalizing possibility, an overview of challenges we faced during our journey, and our take on the future of ABAP development.

## Background

If you're new to containers, check out <a href="https://docs.docker.com/get-started/overview/" target="_blank">Docker's introduction</a>.

We need to shout out to one of the critical technologies that enable our approach: <a href="https://docs.abapgit.org/" target="_blank">abapGit</a>. This open-source software provides a 2-way connection between git repositories (GitHub in our case) and an SAP ERP instance. We use this to install code during initialization and also to upload incremental code changes during development.

## What can we do with SAP ERP in a container?

Our goal is to install ERP once, perform basic setup, and then capture this system's snapshot as a docker container image. This image will allow us to quickly replicate our baseline ERP instance by starting a docker container. Armed with this building-block, we next add our ABAP code into ERP by connecting to our git repositories using abapGit. SAP is now ready for development, automated testing, or any other use we can imagine. Here at Nuve, we have two specific use cases:

## Use Case 1: To Each Their Own (An Instance of SAP for each Developer, that is!)

ABAP developers are often forced to develop code in a development system that has been subjected to untold rounds of experimental changes during previous projects, may be shared by developers on concurrent projects, and is often a shared resource among colleagues who may be working on additional aspects of the same project!

We can all relate to this scenario: everything worked at the end of the day yesterday, but now this morning, you can't reproduce your results. You know you didn't change anything, so somebody else likely made changes that interfered with your work. This problem derailed your plans for a productive morning, and you have to spend time tracking down the issue! At Nuve, we do development work inside ERP running in a container. This practice eliminates uncertainty stemming from unrelated changes being made in shared systems. Developers can also be confident that their results will be reproducible in their colleagues' systems. Since everyone works from a common container image with identical versions, enhancement packs, and base configuration (matched to the customer's requirements), no time is wasted resolving compatibility problems or struggling to reproduce results on another system.

Giving each developer their containerized ERP instances has even more benefits: No risk to testing out experimental changes – it's easy to revert the SAP system to a known state. The SAP instance can be run locally or in the cloud, and each developer can run as many systems as they need. Improvements to the base configuration are easy to share with all developers – pull the latest docker image!

## Use Case 2: Is the Phrase "ABAP DevOps" Still an Oxymoron?

At Nuve, we strive to use software development best practices. When working with ABAP code, we are constrained by the tool compatibility with SAP. Here is our (in our opinion modest) list of fundamental ideas for modern DevOps workflows:

-   Keep the code in a git repository instead of in the SAP database (we use GitHub)
-   ABAP code commits must pass automated tests before they can be merged
-   Developers can run automated tests locally to aid in development (tests should be fast so that developers can iterate efficiently)
-   Test results must be deterministic

After analyzing how we could implement these ideas, we determined that we needed a container that would quickly bring up an ERP instance to build the DevOps workflow we wanted. After some container experiments, we settled on a design that bundles a fresh ERP install with these customizations: We apply basic config typical for a manufacturing company, add several materials and customers for testing. We pre-load abapGit along with a small suite of custom Remote Function Calls (RFCs) that allow us to choose additional software repositories to install via abapGit. We can specify code repositories to install when starting the container or call RFCs to do so after the container starts. We have configured our SAP databases to auto-grow. This is important because we'd like to size the DB's such that they are just about to hit their auto-grow thresholds in order to minimize the size of the final docker image. When our container starts, it automatically starts the database and then the application server.

With this configuration, the container is not only helpful in developing ABAP code, but we can also use it in automated testing. The git repositories can contain more than just code; they can define SAP Gateway services and include test data sets for automated testing.

Our automated testing procedure looks something like this:

1. A developer modifies ABAP code in an SAP container instance. They create a feature branch to hold their work. When the code is ready to be merged, they create a pull request from the feature branch in GitHub.
2. Each pull request triggers (via a <a href="https://docs.github.com/en/github-ae@latest/developers/webhooks-and-events/webhooks" target="_blank">webhook</a>) an automated test of the latest code. The code to be tested is the main branch's HEAD with the feature branch applied on top.
3. The repository also contains the automated testing configuration. In our case, it describes Kubernetes Pods to start up and a series of commands to run inside of them. One of the containers inside the Pod runs our SAP ERP image.
4. We run a series of RFCs on the SAP instance to instruct abapGit to install the version of the code being tested, along with specific versions of any other repositories that are dependencies.
5. The results of these tests are reported back to GitHub and are required to succeed before the pull request can be merged (check out <a href="https://docs.github.com/en/github/administering-a-repository/about-protected-branches" target="_blank">GitHub's Branch Protection Rules</a>).

## Docker Challenges

Getting SAP ERP to run inside a container took a great deal of persistence along with trial and error. We developed a procedure to perform an unattended SAP install but still had to keep careful notes of several manual steps of the post-install process. To complicate our effort, Docker's default configuration is not compatible with this use case. For example, Docker assigns randomly-generated hostnames to each container build step, but SAP requires the hostname to be a fixed value. We have to employ some Linux tricks to convince the SAP installation process that our container has the expected hostname.

Another issue we ran into was a limitation on the "base device size" (by default, Docker's dm.basesize is 10GB). Our image turned out to be over 100GB. Remember that you will also have to upload this image to the cloud (we are using Google Cloud Platform's Container Registry). If your internet connection isn't up to the task of uploading 100GB, you may have to run the entire docker build process inside a VM in the cloud.

We also experienced strange behavior getting SAP to start in our completed image – the container would hang for several minutes when starting the database. After hours of investigation, we realized that Docker's default overlay2 storage driver uses file-level copy-on-write. The first time you write to any file inside the docker image, the file has to be copied out of the image so that the local writes can be tracked. The SAP main database file was 88GB, and it was taking so long to copy the file that the SAP start script timed out and assumed something had gone wrong. This problem was tricky to solve. We found an alternative docker storage driver that handled SAP's large DB files more efficiently, but it wasn't supported by Google Cloud Platform's managed Kubernetes service. Ultimately we placed SAP's database files in volumes and used volume snapshots to give each container instance fresh copies of SAP's huge database files.

## Results

Ultimately we built a docker container running SAP ERP. We can spin up a fresh instance in about 3 minutes. Almost half of this time is spent restoring volume snapshots for SAP's DB, and the other half is starting the SAP database and application server. Although we'd still like to reduce the container start time (we believe reducing testing iteration time increases efficiency), this solution enables the DevOps workflows we need.

## The Future of ABAP Development

Although SAP is working towards supporting modern development techniques and tools (S4/HANA express edition is available as a <a href="https://hub.docker.com/publishers/saplabs" target="_blank">docker container image</a>), it appears that SAP ERP is largely being left out of the official efforts. With years to go before the current 2027 end-of-life target for SAP ERP 6.0, we will be developing new software for ERP for years while customers start to make long-term plans to upgrade. We believe connecting web services through an API like our Nuve product provides an improvement in the customer's experience using their current SAP ERP instance today, with the bonus of offering a clear upgrade path to S4/HANA equipped with Nuve API in the future. The Nuve API remains constant before and after the upgrade, meaning that a simultaneous upgrade of web services is greatly simplified, and the user experience doesn't have to change at all!

The ABAP open-source community is still small compared to other modern languages but is gaining in strength. I believe we can attribute this acceleration to the increased accessibility offered by the foundational abapGit package, which has finally made it practical to share ABAP code online. ABAP development workflows will always lag behind workflows for modern languages like python and javascript, but hopefully we'll continue to gain access to essential tools that currently do not integrate with SAP.

Originally posted on the SAP Community Blog
<a href="https://blogs.sap.com/2021/03/26/our-journey-with-sap-erp-devops-part-1-2/" target="_blank">Our Journey with SAP ERP DevOps Part 1/2</a><br />
<a href="https://blogs.sap.com/2021/03/30/our-journey-with-sap-erp-devops-part-2-2/" target="_blank">Our Journey with SAP ERP DevOps Part 2/2</a><br />


How We Achieved Tremendous Productivity & Quality Gains

The 2006 release of SAP ERP 6.0 predates Docker's initial release by seven years! The two technologies are geared towards different scenarios: think monolithic on-premise server vs. cloud-native microservices. What could be gained by combining the two? Software development teams outside of the SAP ecosystem are years ahead in leveraging DevOps ideas, automated testing/continuous integration, and modern version control tools (i.e., GitHub) to realize tremendous productivity and quality gains. Containerizing ERP would be a considerable step towards accessing these advantages for ABAP development.

Our Journey with SAP ERP DevOps


Headless architecture has been around for some time but has picked up popularity recently, particularly in e-commerce, as the number of sales channels customers expect continues to grow. Any technology leader needs to learn the differences in architecture and understand the benefits and drawbacks of each. At the 20,000 foot view, there are three different architecture types.

The ugly - adding channels on a case-by-case basis utilizing whatever technology the implementing team finds most straightforward leads to disparate sales channels but gets the job done.

The bad - each sales channel implements business logic and uses a web service to connect to SAP ERP.

The good - a headless API with well-defined specifications separates the business logic and offers an integrated experience for all sales channels.

# Not the web of the 90's anymore

With the advent of the internet came online shopping. For a long time, this was almost exclusively on an e-commerce website. Then the rise of native apps began, and some companies started adding this sales channel. Fast forward to today, customers now shop using smart speakers, social media apps, in-store kiosks, e-commerce platforms, text messages, and much more! The piecemeal approach that used to work is no longer adequate for the rapidly changing e-commerce space. E-commerce-focused enterprises require a future-proof long-term plan that can quickly adapt to the ever-evolving area.

## The Ugly - Independently developed channels

IT departments have constraints, whether it's budgeting, technology expertise, timelines, or something else. The easy route is to approach each project individually and get it done using the least resistance path, which might provide short-term savings but has high long-term costs. There are numerous issues with this approach, the main ones being, adding new sales channels is still a very high level of effort task, and changing business logic requires changes on all integration layers. The former slows the pace of innovation, increases the total cost of ownership (TCO), and creates technical debt. The latter can lead to business logic errors, require a significant effort from the development team, and potential system downtime.

## The Bad - Multichannel

A slightly better solution is a multichannel approach that uses a web service across channels, but each solution implements its business logic. This approach allows customers to purchase from various channels but requires duplicating development efforts for each channel. While it's an improvement over the Ugly architecture, it shares nearly all of the drawbacks and only slightly simplifies integrations. This approach might be acceptable to companies that only plan one or two sales channels and do not need a seamless user experience.

## The Good - Omnichannel and headless

"The Good" solution is the best as it eliminates nearly all of the downsides from other approaches. However, it's not perfect; the initial implementation of this type of architecture requires more planning and can potentially take longer. It's an investment for the future if you know you want a seamless experience across sales channels. Headless architecture dramatically reduces the time to implement and deploy additional channels and allows customers to have a single source, regardless of their connection point. Imagine ordering via text and checking order status via Alexa.


The Good, the Bad, and the Ugly of System Architecture

Headless architecture has been around for some time but has picked up popularity recently, particularly in e-commerce, as the number of sales channels customers expect continues to grow. Any technology leader needs to learn the differences in architecture and understand the benefits and drawbacks of each. At the 20,000 foot view, there are three different architecture types.

Technology

Top 5 Development Headaches and How to Make Your Life Easier

Top 5 Development Headaches and How to Make Your Life Easier

Infrastructure as Code, DevOps, and the Future of Enterprise

A Practical Guide to DevOps for SAP ERP

Do Your Customers Need Yet Another Website Login?

Our Journey with SAP ERP DevOps

Headless Architecture

All

Announcements