User Experience Insights
Connecting SAP BAS for BTP to GIT
BTP is here to stay.
ABAPers of the world unite! The world is changing and the constant chant is keep the core clean and extend with BTP.
I was fortunate enough to be on the SAP Code Jam for Cloud Application Programming Model in Sydney on the 20th of June.
Firstly it was great to catch up with Thomas Jung who I had not seen for a very long time and of course to learn all about the lastest state of the CAP Programming Model.
If you have been on these recently you will attest to the content and Tom’s teaching. He is more than patient with the delegates and is always ready to help.
I had set up my prerequisites the night before and was ready to go until I had to log in to BTP and then Cloud Foundry. Even thought I had set up my universal id like a good little community member I didn’t realise the underlying accounts still had their own passwords.
This caused me great consternation and no end of chasing my tail for quite some time and ended up cursing the technology induced “can’t change your password more that once in 24 hours” rule. I got through all the hoops in the end and then was working happily until the end of the day when once again Universal Id had a fight with 1Password and I couldn’t complete my final set of deploying tasks.
I was at a quandary, so knowing this is a temporary environment I blew away the database and the Cloud Foundry environment and told myself I would come back to it and have another go. This is great in practice to solidify the learning but also allowed me to check some other steps I glossed over during the code jam.
At the end of the “Create a SAP CAP Project for SAP HANA Cloud” there is a comment about the local git that has just been initialised:
For a real project it is recommended to set a remote repository, for example GitHub. This will allow you to have a copy of your code outside the SAP Business Application Studio Dev Space.
On my second go around I was rather keen to set this up rather than risk having to blow away my cloud computing box that had just been created.
Before writing this, I saw that a couple of articles and blog posts had been created about how to connect a remote git to the BAS.
I would like to lay out the steps for connecting via ssh and the command line which is much nicer in my opinion than an https connection. You could also use a deploy token or even the gh command line tool.
The first thing to do is to create a new github repository. Alternatively subsitute your chosen git remote repository system.
The zeroth step though is to set up the ssh connection to git.
On your Business Application Studio instance in a bash terminal you need to create a new sshkey. Alternatively you could re-use one you already have but I wasn’t about install the private key onto a cloud server so I think a new key is best.
These commands will create a new key.
cd ~/.ssh; ssh-keygen
This will ask you several questions and you can take the defaults if you like which will create a pair called `id_rsa` in the folder .ssh
This is fine I like to call mine something that will remind me of what I have used this key for when I come back it next year so something like `btp_trial` would be good.
This though creates another issue but we will get to that later.
Now you have to navigate to github – settings – keys to add your public key.
Again use a nice friendly name and paste in the content of your public key – that is the one ending in `.pub`
In order to copy that you can issue the `cat` command.
Copy this from BAS to git save it and you are done.
Now it is best to test your connection so back in the BAS bash terminal enter:
ssh -T email@example.com
This will either respond with successful authentication or `an error has occurred`
Now we have to cope with the consequences of not using the standard
Once you get to the initial commit – do not do anything but follow
The problem with the ssh connection is that is doesn’t know which key to use and it cycles through the standard names not knowing that we have been kind to our future selves and give it a non-standard but meaningful name.
An ssh config file is our saviour and all the vim fans can rejoice here:
If on BTP you are still in the .ssh directory go ahead and vim up a file:
You will now want to add the following lines to tell ssh which server to use:
Host github.com HostName github.com User git IdentityFile ~/.ssh/ IdentitiesOnly yes
This is going to tell the ssh command (which git uses on commits, clones, pulls etc) which server and identity file to use when you interact with it.
The ssh config file is very powerful. For a hot ssh config tip 👇
If you have several git accounts for different clients or a personal and an organisational account, then you can create several entries where the hostname is an alias for that account. For example
This of course means when you checkout from git you will need to add that prefix so the clone will become
git clone firstname.lastname@example.org:<accountname>/<repo>.git
If you made it this far you should now have a BAS account that can ssh to you remote git provider.
So now that the Zeroth step is complete we can create our repo on the remote git in the usual way.
Don’t initialise the repo with a readme or a licence.
The important on the next page is:
git remote add origin email@example.com:<accountname>/<repo>.git git branch -M main -- the BTP repo defaults to main so this step is redundant git push -u origin main
And just like that you have a BAS project on a remote git repo.
Next time you loose your BAS system or you need to delete and recreate it you want have to start coding from scratch.
One more tip for the road
If you are working in the web version of BAS, verses VS Code, you might like to create the Business Application Studio into its own window. In chrome you can use the menu More Tools -> Create Shortcut, then click the “Open as window” checkbox.
This will become available as a tab-less window that won’t get lost among all your other blogs.sap.com and stackoverflow.com tabs.
Enjoy your BTP development with a remote git repository.