AWS for SAP

Deploy APIs for SAP Using Amazon API Gateway

KK Ramamoorthy is an SAP Digital Consultant at Amazon Web Services.

Your customers, partners, and employees want a seamless, secure user experience across various channels. For example, a customer who places an order using a voice-enabled device like Amazon Alexa should have the same experience on a mobile device. Or a field technician who is accessing training manuals using a mobile app should also be able to access and interact with these manuals on an augmented reality app.

Application programming interfaces (APIs) play a crucial role in building such a unified user experience. With APIs and an API management platform, you can expose easy-to-consume domain-driven services in an agile, flexible, secure, and scalable way.

API management platform

An API management platform provides the following key capabilities:

  • Performance at any scale
  • Security and flexibility
  • Ability to throttle traffic
  • Support for global deployments and edge caching
  • Lifecycle management and versioning
  • Support for canary deployments
  • API key management
  • Monitoring of API activity
  • SDK generation for multiple coding languages
  • Cataloging and documentation of APIs

Amazon API Gateway is a serverless API management platform that is fully managed, performs at any scale, and demonstrates all these capabilities. API Gateway can easily connect to HTTP(S) endpoints or invoke AWS Lambda functions for performing custom business logic. You also have the flexibility to cache data within API Gateway without having to hit your backend systems for every service call. These are just few of the capabilities of API Gateway. For more information, see API Gateway on the AWS website.

API Gateway and SAP

How can SAP customers benefit from API Gateway? SAP provides SAP Gateway to easily expose REST-based services using Open Data Protocol (OData). You can quickly stand up an SAP Gateway hub system in a private subnet within your virtual private cloud (VPC) and then securely expose it to API Gateway through a Network Load Balancer. After your API resources are exposed through API Gateway, you can further fine-tune them depending on your specific business needs. For example, you can choose to enrich the responses for certain services whereas for others you might want to just proxy through or cache locally.

For web and mobile apps, you can add AWS AppSync along with API Gateway. AWS AppSync is a fully managed service that enables data-driven app development. It also supports offline and conflict resolution out of the box. Find more information on AWS AppSync.

Reference architecture

This sample reference architecture illustrates how all these components tie together.

API Gateway and SAP architecture

  • A private subnet in the VPC contains your SAP applications, including SAP Gateway.
  • A Network Load Balancer, placed in the private subnet, will have access to the HTTP(S) ports of the SAP Gateway system and will proxy any requests that are intended for it. To simplify, the SAP Gateway system appears as an Amazon Elastic Compute Cloud (Amazon EC2) instance in this architecture. Note, however, that you need to implement multiple app servers and web dispatchers for effective load balancing.
  • A VPC link securely connects API Gateway with the Network Load Balancer. This enables you to expose your SAP services securely through API Gateway without having to expose the SAP systems to the external network. If required, you can further secure your services with a client certificate that is issued by API Gateway and trusted by the SAP system. This adds an additional layer of security by making sure that only API Gateway can access the SAP Gateway services.
  • For complex business logic, you can use API Gateway to trigger Lambda functions that are deployed in your VPC.
  • After the APIs are exposed, you can use AWS AppSync to further abstract your APIs for data-driven mobile and web app development.
  • Other AWS services like Amazon Lex and AWS IoT can also integrate with API Gateway to consume the exposed services.
  • Amazon Cognito ties all these services securely by managing user identities (both user pools and federated identities) to persist the context of the logged-in user across all AWS services and SAP backend.

Setting it up

Now, let’s go ahead and implement this architecture. We will expose a sample service provided by SAP through API Gateway. See the SAP documentation on the sample service. This service exposes various business objects like Business Partners, Contacts, Orders, and Products as OData services.

  1. Install an SAP NetWeaver Gateway Advanced Business Application Programming (ABAP) system in a private subnet. Developer editions are available from SAP: SAP NetWeaver AS ABAP 7.51 SP02 or SAP NetWeaver AS ABAP 7.51 SP02 on HANA (Cloud Appliance Library edition).
  2. After the SAP system is installed and configured, open the Amazon EC2 console at https://console.aws.amazon.com/ec2/. In the navigation pane, under Load Balancing, choose Load Balancers, Create Load Balancer, and create an internal Network Load Balancer with the SAP NetWeaver ABAP system as the target. Note the DNS name of the Network Load Balancer; we will need this for setting up API Gateway later.

    Creating a load balancer

  3. From the API Gateway console at https://console.aws.amazon.com/apigateway/, create a VPC link. This will provide a secure access through API Gateway to the SAP system in the private subnet.

    Creating a VPC link

  4. API Gateway supports proxy integration as pass through. This comes in handy when you want API Gateway to simply pass the request and response between client and server (in this case, SAP). We will create a proxy resource with path /sap/opu/odata/IWBEP/GWSAMPLE_BASIC/{proxy}.

    Creating a child resource

  5. We will add an ANY operation under the {proxy} resource to resolve various HTTP methods (for example, GET, PUT, POST) and proxy it to the SAP Gateway system through the VPC link. Remember the DNS name that you noted in step 2? You will use that DNS name as the endpoint URL here.

    Adding ANY operation under proxy

  6. Now, you might want to cache some resources at the API Gateway layer so that you don’t have to do the round trip to the backend SAP Gateway system. Caching improves performance of the APIs. In our example, let’s cache the product data because it is master data and doesn’t change often in the SAP system. To cache the data, go to the API Gateway console, choose the /GWSAMPLE_BASIC resource, create a child resource for ProductSet, and add the GET operation to it.

    Caching resources

  7. It’s time to deploy the API. Let’s deploy it to the stage called dev.

    Deploying the API

  8. In the API Gateway console, navigate to the dev Stage Editor and check the Enable API cache box under Cache Settings. Set Cache capacity at 0.5 GB and Cache time-to-live (TTL) at 3600 seconds. It will take 4-5 minutes to build the cache.

    Configuring cache settings

  9. You want to cache only the ProductSet resource. To avoid caching the {proxy+} resources, choose the GET operation. Choose Override for this method and clear Enable Method Cache. Do this for all the other methods as well.

    Caching only the ProductSet resource

  10. Test the APIs using a tool like Postman. You will notice that after the first call to the ProductSet API, subsequent calls will be retrieved from the cache. You can validate this in two ways:
    • Check the Amazon CloudWatch Logs for CacheHitCount and CacheMissCount metrics.
    • Stop the backend SAP Gateway system and then call the APIs.

    The ProductSet API should still work, but data will be fetched from the cache instead of a roundtrip to the backend SAP system.

    Testing the APIs

    Note: In this test, we used Basic authentication (in the Authorization header field), which is OK for testing purposes. However, for production scenarios, you will use OAuth 2.0 flows for authentication. SAP ABAP-based applications support two types of OAuth 2.0 flows:

    • Authorization code flow for OAuth 2.0 – This is a user-initiated flow and best suited when a user is available to provide login credentials. Examples include web or mobile applications where a user is available to initiate login.
    • SAML 2.0 Bearer Assertion Flow for OAuth 2.0 – This is a server-to-server communication flow where the user context of an already authenticated user in one server is used to log in to another server without user involvement. For example, API Gateway calls a Lambda function that can issue a SAML assertion for the AWS logged-in user by using an open source SAML SDK like OpenSAML2. Then, using the SAML assertion, you can get access tokens for the same user in SAP.

    There’s a lot to say about these two flow types, and we’ll cover them in more detail in a subsequent blog post.

Next steps

We have only scratched the surface of the various capabilities here. What we shared in this blog should get you started quickly on integrating Amazon API Gateway and with SAP. Here are some of the things you can do after you have integrated your SAP processes with AWS services using API Gateway:

  • Enrich your apps with chatbot capabilities using Amazon Lex.
  • Increase productivity with image recognition capabilities using Amazon Rekognition.
  • Empower your users with augmented reality apps using Amazon Sumerian.
  • Build data-driven apps using AWS AppSync, which supports offline use cases out of the box.
  • Test, deploy, and maintain your mobile apps using AWS Mobile Hub.
  • And many other options…

The possibilities are endless, and most AWS services are only an API call away. API Gateway provides a fully managed, pay-as-you-go service that enables you to create and manage APIs easily at scale. We hope you found this article useful. Please don’t hesitate to contact us with your comments or questions.