Install Abap Platform Developer Edition on Docker for MacBook
[UPDATE September 2022: for a few months now, the image has not been available, instead there is a message on the relevant Docker Hub site:
This product is no longer maintained on this page, and will be removed in the future. The publisher may offer a more recent version elsewhere in Docker Hub.” … so unless SAP makes a new image available someday, then this blog is “historical” rather than “actionable”].
For a few months I thought “well, there is the requirement to give the Docker container 16GB of RAM, but my home laptop only has 16GB RAM in total, and it needs some RAM for itself to keep running, so it isn’t going to be possible to try this new stuff out.” Then a few days ago I thought “maybe I should just try and run this Docker-based system on, say, 14GB RAM, and see what happens..” … and … it works! So, this blog describes how to run ABAP Platform 1909 Developer Edition on Docker on a 16GB RAM MacBook.
I don’t have any Windows laptops, and anyway there are already blogs about running the ABAP Platform SDK on Windows, see for example this one:
I do have an old Linux (openSUSE) server in the sauna outhouse, maybe one day I will get around to a How To version of this blog for Linux, although on the other hand people who are using Linux laptops are often proud of their nerdiness levels and would prefer to work out by themselves how to do this ABAP Platform SDK installation.
Note that although using this ABAP Platform SDK will still be good for practicing Abap, there is less Basis and Linux competence needed than when using the NetWeaver Dev Edition with ASE database. Also note that I don’t run a Helpdesk, so these notes are just that, some notes I took, you need to use your own debug skills and Internet search skills if you get stuck.
Installing and running the ABAP Platform Dev Edition on Docker.
The main link you need is this one:
To access the instructions and to download the docker image, you need an account with Docker Hub. If you don’t already have an account then sign up, and then login.
Then you can access the Setup Instructions. (For convenience I also printed those instructions to a PDF file on local machine, easier for referring to later). It will be a good idea to read through these instructions a couple of times, to save weeping and gnashing of teeth later on, so I recommend doing that now instead of just quickly skimming those and jumping in like I did at first, learning by getting it wrong 🤣.
So next thing is to install Docker Desktop for Mac. (Back in the days, there wasn’t such a thing as Docker for Mac or Docker Desktop, there was only Docker on Linux and the good old command line, so writing this blog has been a bit of a learning journey for me too).
You can get Docker Desktop for Mac here:
Currently my Mac runs on an Intel (x86_64) chip, rather than an Apple M1 (arm64) chip, anyway you choose to download whichever version matches your chip architecture, obviously. If you have an M1 Mac then according to the instructions from Docker website as of September 2021 you will also need the Rosetta 2 native x86_64 emulator for Mac, install as follows:
[UPDATE MAY 2022: for M1 Mac users, the following might be useful:
Then just open the dmg and drag the Docker.app into your Applications folder. Then start the app, first time you need to click “Open” as this is downloaded from web and not App Store; then you need to give your admin password to allow Docker to do network config and so on (similar purpose and reasoning as when you set up a Type 2 Hypervisor and find that sudo access is needed).
I recommend doing the Getting Started tutorial that is suggested. (IMHO no matter how expert you are in some topic, there is always value in going through “basics tutorials”). Also it will be a good idea to sign in to Docker Hub, as suggested at the end of the tutorial. Then I recommend exploring the Docker Desktop a little bit, e.g. opening a command shell in the running container using the “CLI” button from the dashboard, and so on. Overall, it seems the GUI Docker Desktop has the main functions of starting up the underlying Docker Engine, and defining “global settings” such as RAM and storage and vCPUs; then it also offers e.g some visibility of images and containers, as well as some common functions like Start/Stop/Delete Container.
The Setup Instructions say to assign at least 16GB of RAM, and at least 170GB of storage space, for downloaded files plus their extracted files, plus later the container-related storage (of the actual SAP system).
For the RAM, decided at first we can afford to give 14GB. [UPDATE: it’s better when possible to assign 15GB for many activities, such as accessing the Fiori Launchpad (considered later in this blog) – I would say you should consider always using 15GB, even though I used 14GB or 14.5GB during most of this blog-writing].
So in Settings → Resources, assign 14 (or 15)GB of RAM. Then, what I should have done, and you should do, is set 170GB for Disk Image Size (at first I assigned much less than that, see below for error that came from this later on, when downloading and extracting, and then when executing ‘docker run…’ the first time). Minimum vCPUs is 4 so I kept the default suggested value of 6 vCPUs (i.e. half of the vCPUs on the host MacBook). Then press Apply & Restart, and wait for the Docker status icon to be in a green box (“running”-state) again:
The next thing is to switch to the command line, and check that our recent Docker Desktop installation has indeed given us the docker utility:
If you have Docker Desktop open and are signed in through that GUI app, then good; otherwise, login to Docker Hub using the command:
Generally: if docker commands fail with errors like “unable to connect to docker daemon”, then open Docker Desktop, which will then start up the Docker Engine.
Then, we need to get hold of the ABAP Platform docker image from Docker Hub. In May 2021 the instructions are to use this command (when you do this step the version may be different from 1909, in that case adjust your command to suit):
docker pull store/saplabs/abaptrial:1909
Since the main download file is about 23.5GB, depending on your Internet connection that might take a few minutes or a few hours, meanwhile you get to watch the command line update on the progress of the download, if you find that that is a fun way to spend time.
Since I had an average download speed of around 2 MB/second that day, so that means about 3 hours to download the whole thing (plus about 15 minutes of extracting). Generally you will want to do this download in a place and time where you have a reasonable download speed: just doing the arithmetic shows that with a slow download speed it may take several hours, or even many days, to download 23GB.
Eventually, the image gets downloaded ok:
[The reason my session says “newer image” is probably because docker recalls an earlier unsuccessful download attempt that ran out of storage space, as in Docker Desktop I had nowhere near enough Disk Image Size assigned]. You can check your new image is available using the command:
Or you can look in Docker Desktop under Images → Local tab:
Ok let’s try to start a container based on the image. Before creating and/or starting the SAP container, it’s a good idea to e.g. reduce the number of browser tabs and other memory-hungry apps you have open on the host MacBook, since Docker will start to claim quite a lot of memory when the container is being created or is starting up, so the host machine needs to get by on less memory than usual. The instructions say to add the parameter -skip-limits-check if using Mac or Windows, so we do that. [If you like, you can also add the parameter -agree-to-sap-license to the end of this command, if so you will save time later whenever you are restarting your a4h container].
docker run --stop-timeout 3600 -i --name a4h -h vhcala4hci -p 3200:3200 -p 3300:3300 -p 8443:8443 -p 30213:30213 -p 50000:50000 -p 50001:50001 store/saplabs/abaptrial:1909 -skip-limits-check
We accept the Developer License, then the container continues its startup procedures:
Noting the warnings – our parameter -skip-limits-check means that the startup procedures continue. However, an error then appeared for me:
Retrying didn’t help. So there are two relevant hints here… one hint is that the container needs 16GB of RAM, we cannot supply quite that much due to the physical limit of our host machine’s RAM; the other hint is that there should be 70GB of disk free… and actually, that is the thing I needed to fix, e.g. using Docker Desktop: originally I had assigned much less than 170GB of storage, even after expanding Disk Image Size to solve the download and extract error, and that is why this startup error occurred. So, changed the Disk Image Size to 170GB, Apply and Restart, wait for the Running status to appear, then in the command line we ‘docker run…’ again. A new error appears:
docker: Error response from daemon: Conflict. The container name “/a4h” is already in use by container “d35750a594f04a77290964622c6a661745db2789681dc0fba5dc8c9b4582b564”. You have to remove (or rename) that container to be able to reuse that name.
Let’s check what containers we have:
docker container ls -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
d35750a594f0 store/saplabs/abaptrial:1909 “/usr/local/bin/abap…” 27 minutes ago Exited (0) 17 minutes ago a4h
dd2b95fc54fe docker101tutorial “/docker-entrypoint.…” 23 hours ago Exited (0) 23 hours ago docker-tutorial
8114b2f3a7e5 alpine/git “git clone https://g…” 23 hours ago Exited (0) 23 hours ago repo
We want to remove the one that is blocking us, in my case the short-form container ID is d35750a594f0 so that means we execute the command:
docker container rm d35750a594f0
Or, an easier way to get rid of the existing container is just to use its name, which is “a4h”, and add the “-f” (force) flag to make sure:
docker rm -f a4h
Confirm it is gone by listing the containers again; then we ‘docker run…’ again (here we give the example command with the -agree-to-sap-license parameter added):
docker run --stop-timeout 3600 -i --name a4h -h vhcala4hci -p 3200:3200 -p 3300:3300 -p 8443:8443 -p 30213:30213 -p 50000:50000 -p 50001:50001 store/saplabs/abaptrial:1909 -skip-limits-check -agree-to-sap-license
After a couple of minutes of waiting for the various scripts to run, things start to look promising:
Also in the Docker Desktop you can see that the container is up and running:
[Sometimes that error “service HDB has failed to start… You can try your luck [1-10] times…” appears when starting up the container – including, for me, even after I solved the problem of the disk space. In those later cases, hitting Enter did indeed improve my luck and the SAP system started up normally. Update: since I moved the Docker RAM to 15GB, this error has not occurred again].
Now, there is still some config to do before we can login to the system. If you configure SAPGUI now, sure you will be able to open the SAPGUI login screen, but you will not actually be able to login, as there are no valid licenses currently associated with the new SAP system. So scroll up a bit in the command line window to find the output of the Terminal window about License Key Administration, which mentions the A4H Hardware Key:
Retrieving AS ABAP license information
SAP License Key Administration – Copyright (C) 2003 – 2016 SAP AG
System ID. . . . : A4H
Hardware Key . . : J1851296352 (of this computer)
Installation No. : *** not yet assigned ***
System No. . . . : *** not yet assigned ***
Release. . . . . : 777
Software products: NetWeaver_HDB
AS ABAP license can be automatically renewed from the file /opt/sap/ASABAP_license
Hint: new container : docker run … -v <local file path>:/opt/sap/ASABAP_license
Hint: existing container: docker cp <local file path> <container name>:/opt/sap/ASABAP_license
Not updating AS ABAP license: the file /opt/sap/ASABAP_license was not found
asabap_license_update: started, pid=2279
[Note that this system license requirement is entirely separate from the Developer License you accepted when spinning up a container; basically all SAP Abap-based systems require this system license based on a hardware key, whereas only the free SAP “Developer Edition” products also require accepting the Developer License].
You need to now either transcribe the Hardware Key value correctly, or copy and paste that value (in MacBook Terminal, Command+C – not Control+C – works as a copying combination).
Now it is possible to keep the a4h container running and try to associate the licenses “online”, or you can stop the container before uploading the license to container storage; to stop the container you press Control+C in the Terminal window (i.e. press the key in MacBook called “control”, and the “C”-key). After Control+C, wait for a bit for everything to really get stopped i.e. not doing docker stuff as soon as “Goodbye!” message appears, instead wait until the command prompt (“cursor”) appears again.
Next, you go to this website maintained by SAP:
You select the System called A4H, then scroll down to fill in the fields in a form, including the value of your Hardware Key that you saved earlier:
Then press the “Generate”-button, and a text file containing all needed licenses is generated by SAP and downloaded to your local machine, called something like “A4H_Multiple.txt”.
Next, you “upload” this file so that your container can access it via Docker storage, so for example I switched to my Downloads directory where “A4H_Multiple.txt” was located, and did a ‘docker cp…’:
cd Downloads docker cp A4H_Multiple.txt a4h:/opt/sap/ASABAP_license
If you left your container running, you can now run a ‘docker exec…’ command to install the new licenses:
docker exec -it a4h /usr/local/bin/asabap_license_update
Or, if you stopped the container before uploading license file to container storage, you can now restart the container, so the license should be picked up and installed during the startup procedures:
docker start -ai a4h
In case you created the container without the -agree-to-sap-license parameter, accept the Developer License again.
[The difference between ‘docker start…’ and ‘docker run…’, is this: ‘docker start…’ starts an existing, stopped container, whereas ‘docker run…’ creates a new container and then starts it. Thus ‘docker run…’ is the command where you can usually specify many options and parameters, which are not available when simply restarting an already existing container].
Now in the output of Terminal you will see that the startup procedure gets the A4H system license file that you uploaded to container storage, and assigns the 2 licenses from that file to your SAP system:
Updating AS ABAP license: found the file /opt/sap/ASABAP_license
Removing the current AS ABAP License
SAP License Key Administration – Copyright (C) 2003 – 2016 SAP AG
2 license key(s) were deleted.
Installing the license from the file /opt/sap/ASABAP_license
SAP License Key Administration – Copyright (C) 2003 – 2016 SAP AG
2 SAP license key(s) successfully installed.
asabap_license_update: started, pid=1985
Smoketesting our new SAP system.
We can set up a new SAPGUI for Java connection item, using “Advanced” config (it’s really not that advanced, honest 😀 ):
[This blog doesn’t show how to obtain and install SAPGUI for Java client. If you don’t have an S-user, don’t panic, you can e.g. get the files for installation by downloading and unpacking the SAP NetWeaver Dev Edition:
To unrar the files, this free utility is useful:
If I recall right, the unpacked files contain SAPGUI for Java files for both macOS and Linux, and an html manual with installation instructions including JVM requirements. Or you can look around on Internet for tutorials on installing SAPGUI for Java on Mac, such as:
The hostname “localhost” in the connection string refers to your MacBook, and 3200 is the port that was port-forwarded for your docker container when creating the container, go review that ‘docker run…’ command if you don’t believe me.
Incidentally, I modified my hosts file:
sudo vi /etc/hosts
… to also point the new “vhcala4hci” host of our SAP system to the loopback address 127.0.0.1 (as localhost already does), so that now the hosts file contains the line:
127.0.0.1 localhost vhcala4hci
If you are sharp-eyed you may notice that Docker Desktop installation also added a mapping line and some enclosing comments to the hosts file, referring to the loopback address (don’t delete any of this, as Docker Desktop needs that mapping):
# Added by Docker Desktop
# To allow the same kube context to work on the host and the container:
# End of section
Now we can login as user DEVELOPER using the password supplied in the Setup Instructions in Docker Hub.
This blog is not an Abap tutorial, but here’s a test program I created via t-code SE38:
If you want to login to the container running the SAP system itself, use this command:
docker exec -it a4h bash
Once logged in, you can for example check the Linux VM that the container is itself running in as a process (SUSE Linux Enterprise Server 12 SP5), and you can switch user and check the main SAP processes, etcetera:
You might remember from the ‘docker run…’ command that port 3300 is forwarded; our SAP system’s instance number is 00, so port 3300 is for RFC communication with the SAP system. This is not a tutorial about RFC, or about the SAP Java Connector “JCo”, but the screenshot anyway shows an example of a Java client calling our SAP system using JCo libraries and an RFC connection, getting an answer back from the remote-enabled function module “STFC_CONNECTION” of the SAP system:
If you want to use SAP Cloud Connector, which is a small Java program that works as a reverse-invoke proxy server – “a what??” – ok, in English: a server that allows you to connect to subaccounts of SAP Cloud Platform (nowadays called “SAP BTP”)… then just follow the Setup Instructions from Docker Hub to login to the container and start the Cloud Connector daemon. Then goto the URL for the Cloud Connector:
…click past any warnings from the browser about untrusted server, as we know that this is our server, then login using the credentials from the Setup Instructions:
As the Setup Instructions also point out, it’s a very good idea to stop the Cloud Connector daemon cleanly before exiting the container.
If you want to test the HTTP and HTTPS ports (50000 and 50001 respectively), then here is one quick way: in SAPGUI, go to t-code SICF. Then click to node default_host/sap/public/ping , which is probably greyed out (inactive). Right-click on the node, Activate service, Test service. Assuming you have related vhcala4hci to 127.0.0.1 in your hosts file, this Test will then open your system default browser (Safari) at:
… the webpage should say “Server reached”. To test the HTTPS port, URL is:
… after clicking past SSL security warning, you again get the webpage that says “Server reached”.
If you want to connect to the HANA database using the Eclipse tools for HANA, this blog isn’t really a tutorial for that, but the following hints might be useful to get started:
Once you have those tools, in Eclipse open menu Window → Perspective → Open Perspective and choose SAP HANA Administration Console. Then use the Add System icon – for example to add the SYSTEMDB I chose Hostname “localhost”, instance “02”, option “Multiple Containers” -> “System Database”, add user SYSTEM and password (from Setup Instructions), uncheck “Enable Start Service Connection”.
If you want to test out the Fiori Launchpad, or generate EPM data using tcode SEPM_REF_APPS_DG, or basically do anything that might involve a fair hit on memory usage, then if you do not already have 15GB of RAM available to the Docker container, it’s best to proceed as follows: stop the container, raise the RAM in Docker Desktop settings to 15GB, Apply & Restart Docker Desktop, quit all other apps except for one browser tab, SAPGUI for Java, and a Terminal window… then start up the container.
The Fiori Launchpad is at:
Hopefully the login screen loads ok (if not, I think the issue has no workaround on a 16GB RAM MacBook, so maybe you would need to ask your boss to get you a 32GB RAM MacBook for e.g. “essential research purposes”, good luck with that request now 😀):
… and then after logging in, and waiting a bit, the sample app tiles should all (eventually) appear:
The above 2 screenshots were taken with 14.5GB of RAM assigned and using Chrome, then I ran into an HTTP 500 error when clicking on a tile, so I stopped the container, moved up to 15GB and restarted Docker Desktop, and restarted the container… then using Firefox this time because, well, why not?… got to view the items in “Manage Products” tile via Fiori Launchpad in the end:
In general, having 15GB of RAM available to the container seems to be a good thing, for example there are less short dumps when compiling the various SAP-supplied programs – often, the first time someone (most likely you are that someone, in this laptop SAP case 😀) accesses a tcode or Fiori webpage in SAP, then SAP compiles the various classes and so on needed for the transaction. So go with 15GB whenever possible.
Anyway, I think we have now completed our smoketesting of the main services offered by the Docker ABAP Platform Developer Edition.
When you are finished for the day with writing Abap or whatever it is you are doing, remember to logoff from your SAPGUI sessions, using menu path System → Log Off:
… and then stop the container, either by Control+C as mentioned above, or from another terminal you can give the command:
docker stop --time 7200 a4h
Once that’s done, it’s time to reward yourself with an ice-tea!