Introduction
Although Git may seem like a trivial feature in SAP Business Application Studio (BAS), it plays a critical role in project development. It is an essential tool for collaborating with your development team. A typical developer’s day often starts with a git pull to stay up to date and ends with a git push to share their progress.
However, encountering unexpected errors during these operations can be frustrating. Interestingly, Git-related issues generate a disproportionately high number of customer support tickets in BAS compared to other components.
According to the SAP BAS document on Connecting to a Corporate Git Repository, when using an on-premise Git backend, Cloud Connector (SCC) and a properly configured subaccount destination are required to allow BAS, a cloud application, to access it. In this article, I will highlight some common Git connection issues caused by incorrect destination and SCC configurations and how to resolve them.
1. Incorrect Destination Properties
When configuring the destination, ensure that the following properties are correctly set:
WebIDEEnabled = true
HTML5.DynamicDestination = true
Failing to configure these properties correctly can cause BAS to fail when connecting to your on-premise Git system, often resulting in 500 or 502 errors depending on whether http or https is used in the Git command.
If your destination URL uses HTTP (http://), you may encounter:
If your destination URL uses HTTPS (https://), you might see:
Note The ProxyType of an On-Premise destination is HTTP, but the communication between BAS cloud application and SCC is encrypted and safe, there’s no much difference whether the destination URL and the Git command uses “http://” or “https://”.
Besides above two properties, misuse of other properties can cause failures too. In one support case, a customer said they correctly set up Cloud Connector and the subaccount destination but still encountered a 500 Internal Server Error. Even with detailed logging enabled, git clone provided no additional clues beyond the error message. Git requests never reached the Cloud Connector at all. After extensive troubleshooting together with various teams, we discovered that the customer had mistakenly set the HTML5.ForwardAuthToken property to true. This property is designed to send oAuth token to the destination, it should not be turned on for an on-premise type destination or a destination with NoAuthentication because there’s no oAuth token to forward at all.
The customer wasn’t sure why or when they added this property, but simply removing it resolved the issue.
2. Letter case mismatch in hostname
To expose an on-premise Git system, you must map it to a virtual host (hostname + port) in SCC. This virtual host is used when defining the destination URL and in Git commands.
While hostnames are generally case-insensitive, different behaviors across SCC, BTP Cockpit, and BAS can cause unexpected errors.
SCC: Uppercase letters are not allowed in both virtual and internal hostnames, the Administration Console converts them to lowercase.
BTP Cockpit: Allows uppercase letters in the hostname for the destination URL, the check connection test may still succeed if there’re uppercase letters in the URL.
SAP BAS: Treats hostnames in the destination URL as case-insensitive.
For example, if your destination URL is “https://mygit:443“, BAS will successfully match it, regardless of how you type it in Git commands:
git clone https://MyGit:443 git clone https://myGit:443 git clone https://MYGIT:443
However, SCC (Expose Intranet Systems) requires that the destination URL hostname exactly matches the virtual hostname defined in Cloud Connector. A mismatch can result in 500 or 502 errors.
Recommendation
To avoid inconsistencies, always use lowercase hostnames when configuring SCC mappings, destination URLs, and Git commands in BAS. This reduces the risk of unexpected errors caused by inconsistent case handling across different systems.
3. Duplicate destinations with the same hostname
When executing a Git command, BAS generally selects a destination whose URL matches both the hostname and port number in the Git command. If there’s no port number specified, it defaults to 443 for https and 80 for http.
In BTP, you can create multiple destinations with the same hostname but different port numbers or properties. However, this can lead to unexpected behavior when using Git in BAS. It may unpredictably routing your Git command through an unintended destination to a wrong backend system.
Example Scenario
Destinations Defined in BTP
NameURLDest1http://git.int.mycompany.com:8088Dest2http://git.int.mycompany.com:44300Dest3http://git.int.mycompany.com:443
Resource mappings in SCC
Virtual HostInternal HostProtocolResource1git.int.mycompany.com:8088localhost:3001httpsResource2git.int.mycompany.com:44300localhost:3002httpsResource3git.int.mycompany.com:443localhost:443https
When running Git commands in my BAS:
BAS always used the third destination (Dest3), routing requests to localhost:443, regardless of the specified different port. However, after deleting Dest3, the first two Git commands correctly reached their intended destinations (localhost:3001 and localhost:3002). A little wierd!
?
Recommendation
To avoid confusion caused by above behavior:
Create only one destination per virtual host.Avoid relying on port numbers for differentiation (even though SCC supports it).When adding a new resource mapping in SCC, use a new virtual hostname instead of different ports.
4. Host In Request Header in SCC
In SCC, there’s a hostInHeader property in resource mapping, corresponding to the “Host In Request Header” field in SCC Admin Console.
This property controls the value of the Host http request header before SCC forwardsthe request to the backend. If hostInHeader is virtual, the Host header will be the virtual host (same as what you use in BAS git commands, no modification); otherwise SCC modifies the Host header to the internal host.
Although this setting typically doesn’t affect most web servers, some systems impose strict security policies requiring that the Host header matches their website hostname. In such cases, setting hostInHeader = internal is necessary to prevent 503 Service Unavailable or other errors.
Conclusion
By following recommendations in this article, understanding and properly configuring destination and SCC, removing duplicate destinations, you can avoid common Git-related issues and have a pleasant experience working with Git in SAP BAS.
IntroductionAlthough Git may seem like a trivial feature in SAP Business Application Studio (BAS), it plays a critical role in project development. It is an essential tool for collaborating with your development team. A typical developer’s day often starts with a git pull to stay up to date and ends with a git push to share their progress.However, encountering unexpected errors during these operations can be frustrating. Interestingly, Git-related issues generate a disproportionately high number of customer support tickets in BAS compared to other components.According to the SAP BAS document on Connecting to a Corporate Git Repository, when using an on-premise Git backend, Cloud Connector (SCC) and a properly configured subaccount destination are required to allow BAS, a cloud application, to access it. In this article, I will highlight some common Git connection issues caused by incorrect destination and SCC configurations and how to resolve them.1. Incorrect Destination PropertiesWhen configuring the destination, ensure that the following properties are correctly set:WebIDEEnabled = trueHTML5.DynamicDestination = trueFailing to configure these properties correctly can cause BAS to fail when connecting to your on-premise Git system, often resulting in 500 or 502 errors depending on whether http or https is used in the Git command.If your destination URL uses HTTP (http://), you may encounter: If your destination URL uses HTTPS (https://), you might see: Note The ProxyType of an On-Premise destination is HTTP, but the communication between BAS cloud application and SCC is encrypted and safe, there’s no much difference whether the destination URL and the Git command uses “http://” or “https://”. Besides above two properties, misuse of other properties can cause failures too. In one support case, a customer said they correctly set up Cloud Connector and the subaccount destination but still encountered a 500 Internal Server Error. Even with detailed logging enabled, git clone provided no additional clues beyond the error message. Git requests never reached the Cloud Connector at all. After extensive troubleshooting together with various teams, we discovered that the customer had mistakenly set the HTML5.ForwardAuthToken property to true. This property is designed to send oAuth token to the destination, it should not be turned on for an on-premise type destination or a destination with NoAuthentication because there’s no oAuth token to forward at all.The customer wasn’t sure why or when they added this property, but simply removing it resolved the issue.2. Letter case mismatch in hostnameTo expose an on-premise Git system, you must map it to a virtual host (hostname + port) in SCC. This virtual host is used when defining the destination URL and in Git commands.While hostnames are generally case-insensitive, different behaviors across SCC, BTP Cockpit, and BAS can cause unexpected errors.SCC: Uppercase letters are not allowed in both virtual and internal hostnames, the Administration Console converts them to lowercase.BTP Cockpit: Allows uppercase letters in the hostname for the destination URL, the check connection test may still succeed if there’re uppercase letters in the URL.SAP BAS: Treats hostnames in the destination URL as case-insensitive.For example, if your destination URL is “https://mygit:443”, BAS will successfully match it, regardless of how you type it in Git commands:git clone https://MyGit:443 git clone https://myGit:443 git clone https://MYGIT:443 However, SCC (Expose Intranet Systems) requires that the destination URL hostname exactly matches the virtual hostname defined in Cloud Connector. A mismatch can result in 500 or 502 errors.Recommendation To avoid inconsistencies, always use lowercase hostnames when configuring SCC mappings, destination URLs, and Git commands in BAS. This reduces the risk of unexpected errors caused by inconsistent case handling across different systems.3. Duplicate destinations with the same hostnameWhen executing a Git command, BAS generally selects a destination whose URL matches both the hostname and port number in the Git command. If there’s no port number specified, it defaults to 443 for https and 80 for http.In BTP, you can create multiple destinations with the same hostname but different port numbers or properties. However, this can lead to unexpected behavior when using Git in BAS. It may unpredictably routing your Git command through an unintended destination to a wrong backend system.Example ScenarioDestinations Defined in BTPNameURLDest1http://git.int.mycompany.com:8088Dest2http://git.int.mycompany.com:44300Dest3http://git.int.mycompany.com:443Resource mappings in SCC Virtual HostInternal HostProtocolResource1git.int.mycompany.com:8088localhost:3001httpsResource2git.int.mycompany.com:44300localhost:3002httpsResource3git.int.mycompany.com:443localhost:443httpsWhen running Git commands in my BAS: BAS always used the third destination (Dest3), routing requests to localhost:443, regardless of the specified different port. However, after deleting Dest3, the first two Git commands correctly reached their intended destinations (localhost:3001 and localhost:3002). A little wierd!? RecommendationTo avoid confusion caused by above behavior:Create only one destination per virtual host.Avoid relying on port numbers for differentiation (even though SCC supports it).When adding a new resource mapping in SCC, use a new virtual hostname instead of different ports.4. Host In Request Header in SCCIn SCC, there’s a hostInHeader property in resource mapping, corresponding to the “Host In Request Header” field in SCC Admin Console.This property controls the value of the Host http request header before SCC forwardsthe request to the backend. If hostInHeader is virtual, the Host header will be the virtual host (same as what you use in BAS git commands, no modification); otherwise SCC modifies the Host header to the internal host. Although this setting typically doesn’t affect most web servers, some systems impose strict security policies requiring that the Host header matches their website hostname. In such cases, setting hostInHeader = internal is necessary to prevent 503 Service Unavailable or other errors.ConclusionBy following recommendations in this article, understanding and properly configuring destination and SCC, removing duplicate destinations, you can avoid common Git-related issues and have a pleasant experience working with Git in SAP BAS. Read More Technology Blogs by SAP articles
#SAP
#SAPTechnologyblog
