Академический Документы
Профессиональный Документы
Культура Документы
API Management
Systems of innovation
Days
Customers Employees Partners
SAP API Management – SAP HANA Cloud Platform
Pace of change
Systems of record
Internet of Things
IT-as-a-Service
API platform provides tools to expose and API analytics provides powerful tools Developer services provides tools
manage APIs for API usage analysis. to manage API usage by app
Helps create and consume APIs, be it building Show API usage based on IP address, developers.
API proxies as a service provider or using APIs, URL, and user ID information etc. Control access to APIs through a
SDKs, and other convenient services as an app Collect and analyze latency data. developer portal that exposes the
developer publicly available API products
* Bimodal IT is the practice of managing two separate, coherent modes of IT delivery, one focused on stability and the other on agility.
Mode 1 is traditional and sequential, emphasizing safety and accuracy. Mode 2 is exploratory and nonlinear, emphasizing agility and speed.
When using SAP API Management, you will be creating and working with four different entities:
1) API Providers : The backend business systems whose APIs need to be exposed
2) API Proxies : 1 or more URLs exposed by a backend system
3) Products : Aggregations of 1 or more API Proxies that form the unit of “API exposure”
4) Applications : Aggregations of 1 or more Products that form the unit of “API consumption”
API Proxy API Proxy API Proxy API Proxy API Proxy API Proxy API Proxy API Proxy
There are two distinct views of the APIM data. These are provided through two different tools:
API Portal – Used by the developer of API Proxies and is concerned with exposing API Proxies as Products
Dev Portal – Used by the consumer of the API Proxies and is concerned with creating Product subscriptions
known as “Applications”
API Proxy API Proxy API Proxy API Proxy API Proxy API Proxy API Proxy API Proxy
To start the configuration process, you must first create an API Provider.
In the API Portal, select “Configure” from the hamburger menu in the top left of the screen. Application
Now you can create a new API Provider.
Product
API Proxy
API Provider
Develop
Important:
The API Management service within SAP CP maintains its own set
of destinations that are independent from standard SAP CP
destinations!
© 2016 SAP SE or an SAP affiliate company. All rights reserved. Customer 15
SAP API Management – API Development Using the API Portal
Create an API Proxy
Once a System has been created, you may now create an API Proxy for any service exposed
by that system, E.G. an OData service. In the API Portal, select “Manage” from the
hamburger menu, Application
Then select “API” from the Toolbar.
Now you can create a new API Proxy. Product
API Proxy
API Provider
Develop
An API Proxy will remain hidden from the outside world until it is added to a Product.
Think of a Product as the basic unit of “API Exposure”.
Application
In the same “Manage” screen in which you created the API Proxy, select “Product” from the
toolbar.
Now you can expose API Proxies for consumption by adding them to a new Product. Product
API Proxy
API Provider
Develop
API Proxy
System
API Proxy
System
The three steps necessary to make an API Proxy ready for consumption are now complete.
We have: Application
1. Created an API Proxy
2. Exposed the API Proxy to the outside world by adding it to a Product Product
3. Subscribed to that Product by creating an Application
API Proxy
We must now perform two preliminary configuration steps before we can consume our API
Proxy using a Template Wizard in Web IDE.
Once these configuration steps have been performed, they do not need to be repeated when creating further apps
in Web IDE.
In order for Web IDE to be able to consume API Proxies, we must create two SAP CP
destinations:
1. One used by the WEB IDE Template Wizard at design time
2. The other used by Web IDE apps at runtime
HTTP HTTP
WebIDEEnabled = true WebIDEEnabled = true
WebIDEUsage = api_mgmt_catalog WebIDEUsage = api_mgmt_proxy
When creating these SAP CP destinations, you may give them any names you like.
However, you must ensure that the WebIDEEnabled and WebIDEUsage properties have been
set correctly.
Create an SAP CP destination for use by the template wizard at design time.
You are free to choose any name and description you like for this destination
Enter the URL to either your Dev Portal or some public API service such as the SAP API Hub
You must add the additional properties shown below, otherwise Web IDE will not:
1. Be permitted to use this destination
2. Recognise this destination as a source of API Management Proxies
Destination Configuration
New Property
* Name: API_Management_Dev_Portal_Trial Additional Properties
Type: HTTP WebIDEEnabled true
Description: API Management Dev Portal WebIDEUsage api_mgmt_catalog
Destination Configuration
New Property
* Name: API_Management_Endpoint_Trial Additional Properties
Type: HTTP WebIDEEnabled true
Description: API Management EndPoint trial HCP landscape WebIDEUsage api_mgmt_proxy
Product
API Proxy
System
Each API Proxy performs its own check for an API Key.
As we know, multiple API Proxies can be added to the unit of exposure known as a Product.
And multiple Products can be subscribed to through the unit of consumption known as an Application.
Application
Product Product
API Proxy API Proxy API Proxy API Proxy API Proxy API Proxy
Check for API Key Check for API Key Check for API Key
Therefore at runtime, it is entirely possible that your Application will provide access to a mixture of API Proxies:
Some that check for an API Key,
And some that do not.
Consequently, from the perspective of Application consumption, it is best practice always to supply the API Key,
even if the individual API Proxy you are consuming does not require it.
If you get both of the error messages “FailedToResolveAPIKey” and “HTTP 401 Unauthorised”, then the text
shown in red below indicates where the API policy is looking to find the API Key.
Destination Configuration
{
"fault":{
"faultstring":"Failed to resolve API Key variable request.header.APIKey",
"detail":{
"errorcode":"steps.oauth.v2.FailedToResolveAPIKey"
} Here, the API policy is looking for an
} HTTP header field called “APIKey”
} Both are perfectly
But here, the API Policy is looking for a valid possibilities
query string parameter called “apikey”
Destination Configuration
{
"fault":{
"faultstring":"Failed to resolve API Key variable request.queryparam.apikey",
"detail":{
"errorcode":"steps.oauth.v2.FailedToResolveAPIKey"
}
}
}
CAUTION: Although it makes good sense to use a field name such as APIKey or apikey, this is not a requirement.
In reality, the field carrying this value can have any name the API Proxy developer wants!
© 2016 SAP SE or an SAP affiliate company. All rights reserved. Customer 30
API Management
Consuming API Proxies in Web IDE
SAP API Management
Consuming API Proxies in Web IDE 1/4
§ Endpoint Segments
§ Flow Processing
Stages
§ Scripts
§ Endpoint Segments
§ Flow Processing Policy Types
Stages
§ Scripts
§ Endpoint Segments
§ Flow Processing Policy Types
Stages
§ Scripts
IMPORTANT:
The Policy Flow Routing diagram only shows you part of the overall request/response cycle.
API Management divides the request/response cycle into two distinct segments.
The difference between these segments determines whether or not the processing happens before or after the
Route Rules are applied.
Incoming Stream
Route
Rules
Outgoing Stream
The incoming request is received by API Management and any policies assigned to the Pre Flow processing
stage are executed.
For example, checking for the presence of an API Key or that a usage quota has not been exceeded etc.
Incoming Stream
Request Route
Pre Flow
Rules
Outgoing Stream
A Condition Flow is a predicate to which zero or more policies can be assigned. Any Condition Flow that evaluates to true will have its
policies executed. A Condition Flow is automatically generated for each collection in an OData service.
E.G. If you want a particular API Policy to run when a request is made to a specific OData Collection, then assign that API Policy to that
OData Collection’s Condition Flow.
Incoming Stream
Outgoing Stream
Once all the matching Condition Flows have been executed, any policies assigned to the Post Flow processing
stage are executed.
Incoming Stream
Outgoing Stream
Now we must decide whether or not the request should continue on to the backend system.
At this point, the Route Rules can, if necessary, abort the entire request and return a null response to the requestor.
E.G. if an HTTP request uses the HEAD or OPTIONS method, then there is no need to pass such a request on to the backend.
IMPORTANT: Only the first matching Route Rule will ever be executed.
Incoming Stream
Outgoing Stream
Now that we know for certain the request will be passed to the backend, then another set of Pre Flow, Condition Flow and Post Flow
processing stages are performed in the Target Endpoint Segment.
The policies assigned to these processing stages focus on managing requests for the specific target system. E.G. Handling parameters
related to ad campaigns or the link referrer.
Incoming Stream
Outgoing Stream
Once the backend has serviced the request, then if present, the Pre Flow, Condition Flow and Post Flow
processing stages in the Target Endpoint segment are now executed on the Outgoing Stream.
Incoming Stream
Condition
Post Flow Pre Flow
Flows
Outgoing Stream
If present, the final set of processing stages are now performed in the Proxy End Point segment.
Here, you would typically handle tasks such as format conversion or hiding internal server hostnames.
Incoming Stream
Response
Condition Condition
Post Flow Pre Flow Post Flow Pre Flow
Flows Flows
Outgoing Stream
The Policy Flow editor provides a graphical representation of the incoming and outgoing policies assigned to one
stage of a processing segment.
IMPORTANT
This diagram does not show you all the policies that might be processed during the entire
request/response cycle.
It shows only the policies assigned to the selected stage of the selected segment.
From the Flows menu on the left of the Policy Designer, collapse both menu items and you will see that you are
looking at the two processing segments seen in the overview diagram below:
Incoming Stream
NONE
Proxy Endpoint Target Endpoint
Client Segment Segment Backend
Outgoing Stream
From the Flows menu on the left of the Policy Designer, collapse both menu items and you will see that you are
looking at the two processing segments seen in the overview diagram below:
Incoming Stream
NONE
Proxy Endpoint Target Endpoint
Client Segment Segment Backend
Outgoing Stream
Incoming Stream
NONE
Proxy Endpoint Target Endpoint
Client Segment Segment Backend
Outgoing Stream
By selecting the PostFlow stage of the ProxyEndpoint segment, we are now looking only at these policies.
Incoming Stream
NONE
Proxy Endpoint Target Endpoint
Client Segment Segment Backend
Outgoing Stream
Finally, by selecting one of the Condition Flows of the ProxyEndpoint segment, we are now looking only at
these policies.
Incoming Stream
NONE
Proxy Endpoint Target Endpoint
Client Segment Segment Backend
Outgoing Stream
Here, the Policy Flow diagram shows the policies assigned to the PreFlow stage of the ProxyEndpoint segment.
In this case, the Incoming Stream (the line along the top) has three policies assigned to it,
and the Outgoing Stream (the line along the bottom) has no policies assigned to it.
If we now select the PostFlow stage, we can see a single policy has been assigned its Outgoing Stream.
In this case, this particular policy is designed to mask the hostname of internal servers that
might appear in the response.
From the menu on the right, scroll down to the bottom of the list and press the plus sign next
to the “Verify API Key”.
In the “Create Policy” pop-up screen, give the policy instance a name (“CheckAPIKey” in this case) and ensure
that it is assigned to the Incoming Request stream.
IMPORTANT
Do not use spaces within a Policy name.
Although this is permitted by the editor, one policy will not be able
to refer to any other policy that contains spaces in its name.
Our CheckAPIKey policy has now been assigned to incoming stream of the PreFlow processing stage of the
ProxyEndpoint segment. In the editor window underneath the diagram, we can see the definition of this
particular policy.
CheckAPIKey
Edit the value of the ref field to point to the location in which this
policy expects to find the API Key value.
Here, by using request.header.APIKey, we are instructing
this policy to look in the HTTP header for a field called “APIKey”
Route Rules are used to decide whether or not a request should be passed to the backend system.
E.G. If the HTTP request uses the HEAD methods, then there is no reason to pass that request on to the backend.
To add a Route Rule, select the API Proxy you wish to modify.
Now press Edit
In this case our route rule will reject incoming requests that use the HTTP method (or verb) “HEAD”.
The Target Endpoint dropdown list defines where the request will be routed if the condition evaluates to true.
By setting the Target Endpoint to NONE, we indicate that a null request is to be returned to the client if the condition
is route rule condition evaluates to true.
IMPORTANT
Route Rules are checked sequentially and only the first matching rule will be obeyed. After that, no further route
rules are tested. Therefore, you should place the most specific rules first and the most generic rules last.
Notice that the last entry is a “default” route rule with no condition. This ensures that after all the route rules have
been checked, all requests are routed to the default Target Endpoint.
Contact information:
chris.whealy@sap.com
No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP SE or an
SAP affiliate company.
SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE
(or an SAP affiliate company) in Germany and other countries. Please see http://global12.sap.com/corporate-en/legal/copyright/index.epx for additional trademark
information and notices.
Some software products marketed by SAP SE and its distributors contain proprietary software components of other software vendors.
These materials are provided by SAP SE or an SAP affiliate company for informational purposes only, without representation or warranty of any kind, and SAP SE or its
affiliated companies shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP SE or
SAP affiliate company products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing
herein should be construed as constituting an additional warranty.
In particular, SAP SE or its affiliated companies have no obligation to pursue any course of business outlined in this document or any related presentation, or to develop or
release any functionality mentioned therein. This document, or any related presentation, and SAP SE’s or its affiliated companies’ strategy and possible future
developments, products, and/or platform directions and functionality are all subject to change and may be changed by SAP SE or its affiliated companies at any time for
any reason without notice. The information in this document is not a commitment, promise, or legal obligation to deliver any material, code, or functionality. All forward-
looking statements are subject to various risks and uncertainties that could cause actual results to differ materially from expectations. Readers are cautioned not to place
undue reliance on these forward-looking statements, which speak only as of their dates, and they should not be relied upon in making purchasing decisions.