How Akamai works in SAP Cloud for Customers
SAP uses its partner Akamai to speed the delivery of web content to our customers using IP acceleration and edge caching, which entails storing replicas of static text, image, audio, and video content in multiple servers around the “edges” of the internet, so that user requests can be served by a nearby edge server rather than by a far-off origin server.
The perception is that it is really simple to get to your data over the Internet.
The reality is that the users are constantly connected on multiple types of devices over different types of networks to different kind of applications and still expect a consistent experience. The problem is that the native internet is not efficient, and it doesn’t offer a straight path to connect to the content.
Cloud for Customers uses a product from our partner company Akamai to accelerate the traffic over the Internet. This product relies on the Geolocation of the External (or forwarder) DNS server to provide an entry point (or Edge Server) to the Akamai network, finding the best route from the user to the SAP Datacenter where the customer’s tenant is located. In order to take full advantage of this feature, it is required that the DNS server and the user are in the same geographical area.
How Akamai works
- End-User Machine ask it’s local DNS server to translate hostname to IP address
- Internal DNS server forwards request to central, non-local DNS (forwarder) server for translation
- The External DNS resolves against the Akamai Name Server, which identifies the closest Akamai edge server to external DNS Server
- End-User Machine contacts the Akamai Edge server and request content
- Akamai uses it’s private high-speed network to connect to another Edge Server near the Host.
- Edge host requests content form host’s servers
Customer with multiple office and independent internet exits will find the closest Akamai Edge server to the end user location.
What can affect Akamai?
A common problem is where the end-user connects to an External DNS server which is located in a different geographical region to resolve DNS queries, in those cases the DNS server will resolve the Cloud for Customer tenant DNS name to IP close to the External DNS server but not necessarily to the user having a long last mile between the Akamai Edge server and the end user, examples are where a user from Europe is trying to access a SAP Cloud for Customer tenant in Europe and is using a DNS server in America, in that case the user from Europe will communicate with an Edge Server in America forcing the user to connect from Europe to the Akamai server in America to then connect to the SAP Cloud for Customers tenant in Europe, causing considerable network overhead. One method on how to identify if the DNS resolution and TCP routing is happening under the same region is explained in this blog
Very useful article, can you please advise on the below:
We have Event Notifications configured in C4C that sends Event notification messages to an API end-point, so in this case will Akamai play any role, i.e., will it route through Akamai and the IP address would be dynamic or will the Outbound IP address will always be the same as of the SAP Data Centre where the Tenant is hosted as given in this KB https://apps.support.sap.com/sap/support/knowledge/public/en/2570539?
If the traffic comes from *.crm.ondemand.com and *.hana.ondemand.com the IP address will change depending of the Edge Server that you are hitting, there might be hundred of edge servers that you can hit depending or your location and the level of high availability that Akamai might have.
Please let me know if that answers your question.
Thank you Raul for your response. Yes this answers one part of the question. However, for the outgoing messages like Event Notifications my question was if there is Akamai involved. We have now tested this and found Akamai is not for outgoing event notifications from C4C.
thank you for the insight. We are currently facing an issue where the contents of a response to one of our requests seems to be altered by Akamai CDN and as a result becomes empty.
The response we receive contains the header: X-Akamai-Transformed: 9 0 0 pmb=mRUM,1
This case is incredibly hard to analyse since it only is present in the communication of two specific hosts.
Do you have any advice on who to contact about problems suspected of being caused by the CDN itself?