Skip to Content

Amazon API gateway offers a relatively new way of dealing with different types of API’s that a business may need access to. In our case, we’ll be looking at the SAP API and how it can interact seamlessly with Amazon’s API gateway. The setup is nothing that’s completely strange or new to users of SAP or SAP S/4 HANA, but it does allow us to take look into how we can link distinct API’s through the API gateway offered by Amazon. SAP utilizes OData in its API to transfer data from the main database across an API interface to connected objects. In this case we’ll be utilizing SAP’s sample service in order to get access to particular business objects such as Contacts, Products, Orders, etc. as OData.

Step 1: ABAP

The first thing we’re going to have to do to have a fully functional SAP interface is to set SAP NetWeaver Gateway ABAP. This is to be done on a separate subnet and SAP NetWeaver AS ABAP 7.51 SP02 is recommended for this purpose (the HANA version may also be used).

Step 2: The EC2 Console

We’re next going to access our EC2 console located at https://console.aws.amazon.com/ec2/. Select under the Navigation pane, Load Balancing and under that Load Balancers. We’ll select Create Load Balancer. This constructs an internal Load Balancer for the network, using as a target the SAP NetWeaver system. Make a record of the DNS which our Load Balancer has been assigned, as we will need it later on.

Step 3: VPC Linking

We’re going to navigate to the Gateway Console located at https://console.aws.amazon.com/apigateway/ and create a VPC link. This secures our access to the SAP system using the API gateway.

Step 4: Creating a Pass Through System

SAP works best when the commands are simply routed to the system, and to get this functionality through the API Gateway we can set it up to pass through requests. For this we will create a proxy resource, with the resource path as: /sap/opu/odata/IWBEP/GWSAMPLE_BASIC/{proxy}.

Step 5: Proxy Setup

Under the proxy description we are going to change the Integration Type to be VPC Link, and ensure that Use Proxy Integration is checked. We are also going to define the operations that use the proxy to be ANY. The VPCLink will be, of course, the SAP Gateway Link you created above in step 3 and we will be using the DNS recorded in step 2 to define our Endpoint URL.

Step 6: Caching

Creating a cache improves performance by ensuring that information that isn’t regularly updates can be accessed without having to send a request through the network. This speeds up the access of the resource and makes for a more efficient system overall. In order to create a cache, we are first going to head to the API Gateway console and from there, select /GWSAMPLE_BASIC and make a new child resource for the ProductSet. In this resource we will assign the GET operation to it.

Step 7: Deployment

Deploying the API allows us to bring it into a usable state. Since this is just a sample API example we’re using, we’ll use the developer deployment. We will select dev as the deployment stage and assign a description to it as we see fit. We now head to the API Gateway interface and from there select the dev Stage Editor. In the resulting page, we will check the Enable API Cache box (located under Cache Settings) and raise the Cache Capacity to 0.5 GB. We will also set Cache time-to-live (TTL) to 3600 seconds. At this point we’ll build the cache, which shouldn’t take longer than five minutes to complete. Please note that we’re only trying to cache the ProductSet resource, and that means that we have to ensure the other resources remain out of the cache. This is a simple matter of selecting the GET operation, ensuring the Override for this Method radio button is selected, and clear the Enable Method Cache button.

Step 8: Testing

We can use a tool like Postman in order to test that our system is functioning as we expect it to. The first call to the ProductSet API should show up as making the round trip to the backend, but subsequent calls should be made to the cache instead like they are at gclub. In order to ensure that this is indeed what’s happening we can either employ the Amazon CloudWatch logs taking care to note the CacheHitCount and CacheMissCount metrics, or by stopping the SAP Gateway backend and seeing if we’re still able to call the API (which would actually result in us calling the cached copy of the database).

Things to Note Moving Forward

This test utilizes simple authentication but a more complex method using SAP ABAP OAuth 2.0 flows in order to improve security on SAP ABAP applications. This simple integration provides a basis for further development using the Amazon API Gateway. Developing applications for SAP using the API Gateway is something that companies can look into implementing once they set up the ABAP back end to handle the processing on the Amazon Server side.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply