Need to contact an HCP Admin for "Destination" settings problem. (Error msg in Attachement)

Note: I'm using a valid customer USER ID and trying the HCP on account.hanatrial.ondemand.com.

I created some API but I can't Publish any Product that contains my test API because the user configured in Destination is forbidden.

I don't know how to do.

Can You provide me an Admin contact for this intricated problem resolution?

Regards,

Stefano Scalcinati

Policy Management

Policies are applied to an API Proxy to customize its behavior. These are preprocessing steps which are run on the SAP API Management layer and not on backend services.

Policies can be broadly classified into following four categories:

• Traffic Management Policies
• Mediation Policies
• Security Policies
• Custom Policies

Traffic Management Policies

The traffic management policies let us configure cache, control traffic quotas and spikes, set concurrent rate limits. Example of these types of policies are:

• Cache Policies
• Concurrent Rate Limit Policy
• Quota Policy
• Spike Arrest Policy

Mediation Policies

These policies let us perform message transformation, parsing, validation and raise faults and alerts. Examples include the following policies:

• XSL Transformation Policy
• XML to JSON Policy
• Fault Rule Policy
• Key value Map Operations Policy
• JSON to XML Policy
• Assign Message Policy
• Access Entity Policy
• Extract variables Policy

Security Policies

These policies controls the security related aspects for API Proxies. Examples include:

• Access Control Policy
• Basic Authentication Policy
• JSON Threat Protection Policy
• OAuth Policy
• Verify API Key Policy

Custom Policies

These policies let us provide custom policy functionality, with support for features as service callout, message data collection, and calling Java, JavaScript and created Python behavior. Examples include:

• Java Script Policy
• Message Logging Policy
• Statistics Collector Policy

How Policies Work?

When a policy is added to an API Proxy, then it is added to a specific flow which defines when the policy is executed. Each request and response path in a proxy endpoint and target endpoint defines the following flows:

• Pre Flow
  • Always executes before any other flows.
  • The policies defined in the pre flow are applied to every message that passes through an endpoint.
• Conditional Flows
  • Execute only when a conditional statement defined for the Flow evaluates to true.
  • An endpoint can define any number of conditional Flows, but only the first conditional Flow whose condition evaluates to true executes. That means the policies attached to the conditional Flow only execute when the conditional Flow executes.
• Post Flow
  • Always executes after all other Flows.
  • Like Pre Flow, the policies defined in the Post Flow are applied to every message.

Add first policy: Verify API Key Policy

Let’s add a policy to an API Proxy.

• To start with, login to SAP API Management’s API Portal.
• Create an API Proxy from API Portal, [refer here for more details].
• To add the Verify API Key Policy, following the steps mentioned below:

Click on Launch Policy Designer

Click on PreFlow (in left panel) and then click on Verify API Key among the list of policies (on right side panel).

Just add the policy name and click Add.

Then, the policy will get added & then add the following text in the script area:

Then update the policy by clicking Update.

• The APIKey ref is the key which is used while consuming this API.
• Since, the key is saved as request header, so the while consuming, this key is to be passed as request header.
• Refer here for more details.

Then the API Proxy will be updated with newly added policy; and then Click Save.

The API Proxy will be updated successfully.

Create a Product having this API Proxy

Create a product, adding this newly created API (“CATALOGSERVICE”). Refer here for more details.

Publish this product

Consuming the API

To consume the API via product, we need to now login to the developer portal. Once logged in, we will find the newly published API Product here.

Then, an application has to be created using this Product. Refer here for more details.

Open the details of this product and subscribe it to a new application; as shown below:

Enter application details like name, description and click save to create the application. Once created successfully, you will get an appkey and secret for that application.

Testing the API using Verify API Key Policy

• To test the API, we will be using the SAP API Management’s Test Console. Refer here for more details.
• Add the proper URl and Authentication (if any) in the Test Cosole.
• Add the appkey (which was retrieved while creating application) as the Header and click Send to get the result.

This is how you can create an API proxy with Verify API Key Policy and consume the same.

Related Content

SAP API Management Online Guide

Now that SAP API Management is available you probably also have seen the fantastic blog from Bhanu Pratap Sharan about policies and how to use them. It explains what policies in SAP API Management are, which ones are available and how you can use them.

When following my first blog on How to use SAP API Management on HCP Trial you might have noticed that when calling the "proxified" URL to the ES4 system (e.g. https://trial.apim1.hanatrial.ondemand.com:443/<account>trial/GWSAMPLE_BASIC)  yxou can still see URLs like https://sapes4.sapdevcenter.com/sap/opu/odata/iwbep/GWSAMPLE_BASIC/ in the response.

Obviously that doesn't make a lot of sense. So we have to tell the API proxy, that it should hide / "mask" the real URL. There are plenty of ways how this can be done. In this blog I want to show the power of one of the policies that we have: the JavaScript policy.

Although you can make this policy very generic, I will keep to the very basic and actually tell the script what the target server is and what the SAP API Management Proxy URL is.

Lets pick-up where we left in the How to use SAP API Management on HCP Trial

I had created a plain API proxy that would just connect to the ES4 system. Lets take another look at this API Proxy and go to the "Launch Policy Designer" in the API Artifacts section (for more details, take a look at the blog SAP API Management – Policy Management)

Once you launch the Policy Designer you can see an empty policy screen. In this screen, enable the Edit mode, by clicking on Edit and then add a script (by clicking on the "+" sign which will appear once you are in Edit mode)

Once you click on the "+" sign you can give the new script a name like "urlrewrite"

This will be the script that reads the actual URL and replaces it with the URL from our SAP API Management proxy. So once you click on Add in the pop-up above you can select the script name ("urlrewrite") that we just created and add the content:

var rc = context.getVariable("response.content");

var newstr = rc.replace(/SAPES4.SAPDEVCENTER.COM:443/gi, "trial.apim1.hanatrial.ondemand.com");

var newpath = newstr.replace(/\/sap\/opu\/odata\/iwbep/gi, "\/d044410trial");

context.setVariable("response.content", newpath);

In these four lines (of course it could have been less :-)) we retrieve the content from the response, replace the targetserverhost and targetserverport (in my case the SAP Developer System) with the information from the api proxy, changes the path and put this new information back in the context. Quite straight forward.

Now we only have to tell the flow that and when we want to call this script.

So on the left hand side, scroll down to TargetEndpoint and select the PostFlow (after all we want to replace the results from the server response). Then on the right hand side click on the "+" sign for the JavaScript policy

A new pop-up will open where we can specify the name of this policy. Enter something like "maskurlfromresponse" and make sure that you select "Outgoing Response" from Stream. Then click on Add

This policy now allows us to call / do whatever we want in JavaScript. In our case, we will just call the script that we had previously created: the urlrewrite script. In order to do that just replace/add the name of the script with the urlrewrite script so that the content looks like this:

(since we won't use a helper.js file, you can also remove the lines:

  <!-- contains reference to any library scripts that help the main code file -->

  <IncludeURL>jsc://helper.js</IncludeURL>

<!-- this policy allows us to execute java script code during execution of an API Proxy -->

<Javascript async="false" continueOnError="false" enabled="true" timeLimit="200" xmlns='http://www.sap.com/apimgmt'>

  <!-- contains the name of the main code file -->

  <ResourceURL>jsc://urlrewrite.js</ResourceURL>

</Javascript>

And that's it! Now you can click on Update

and then on Save

... from now on your API calls to a backend systems should really mask the URL.

I hope this small example not only showed you how you can mask the URL, but also gave you a glimpse of the power of these policies. With the JavaScript policy you can actually do whatever you want in your flow. You can filter traffic, redirect URLs, change content, check or validate content, ... The possibilities are endless.

In future blogs we will go in more detail and talk about some other things you can do with the JavaScript policy. We could for example make this script more dynamic so that it first retrieves the target URl and uses the API Proxy name -- so that you do not have to hardcode this information.

Feel free to add your comments & feedback.

In today’s digital era, to connect your enterprise to the digital economy, APIs are the fastest and most efficient way. Lightweight and versatile APIs provide easy exposure of data in a device agnostic manner.

SAP API Management enables businesses to manage all the digital assets that companies publish, manage, monitor and monetize as APIs on a single platform from the various data sources and systems of records across various technologies from Cloud or On-premise.It has capabilities to provide a unified access for APIs based on open standards such as REST, OData, OAuth with secure and seamless connectivity to your applications and platforms.

API management helps make APIs secure and stable. It provides uniformity of APIs and enables businesses to more easily see who is using the APIs to access data. It also provides an easy way to onboard developers and enables them to develop application using the exposed APIs.

There are three main components for SAP API Management.

• API Platform - provides the tools to create and manage API. This is accomplished using the API Portal

• Developer Services - provides the tools to manage App developers. It comes with a developer on-boarding mechanism and enables developers to consume the exposed APIs. This is accomplished using the Developer Portal

• API Analytics - provides tools to view analytical trends of the API usage

I am going to share some of my experience and also provide you a step-by-step guide on how to create a basic API using the API Portal and consume it as a developer from the Developer Portal.

As a pre-requisite you need have a trial account on HCP and also registered for a user in ES4 system

SECTION 1: Accessing HCP Cockpit & enabling services

In this section, you will get to know how to access the HCP Cockpit and enable the API Management

Accessing HCP Cockpit & setting up API Management

• Launch HCP Trial and login with your trial user.
• Navigate to the Services section in the menu and search for API Management

• If you the service is not enabled, click on the service and enable it

• Click on the “SAP API Management API Portal” to launch the configuration settings

• Notice there will be a destination which is automatically created with the name “DEST_CI”
• Click on the Roles menu to view the predefined 7 roles. Assign the service user  “p1940842373“ to the below roles
  • APIPortal.Service.Administrator
  • APIManagement.Service.Administrator
  • APIPortal.Service.CatalogIntegration

    Assign your user (without the word trial) to the Role APIPortal.Administrator

• Go back to the main screen of the SAP API Management by clicking on the link at the top

• Click on the API Management Dev Portal to configure the Dev Portal

• Notice there will be a destination which is automatically created with the name “apimgmt_portal”
• Click on the Roles menu to view the predefined 8 roles. Assign the service user “p1940842373“ to the role AuthGroup.ContentAuthor and your user to the role AuthGroup.API.ApplicationDeveloper.

      If the roles are already assigned, there is nothing much to do in the setup.

SECTION 2: Using the API Portal to create API's

In this section, you will get to know how to use the API Portal to create API's, assign policies and test them.

2.1  Create a System

     Launch the API Portal from the API Management main menu

• There will be no systems registered. Click on the Create button to create a new system and provide the below values.

• Click on Save and hit the back arrow above the system name. You should now be able to see you system listed in the Systems section

In the other tab which is still open, navigate back to the API Portal Configuration page by clicking on the link as shown.

Notice that a new destination has been created for ES4 ABAP System. Click on the pencil icon and update the user/password with your details and save the settings.

2.2  Create an API

In the API Portal, click on the Panel icon at the top left corner and select “Manage” from the menu. This will take you to the screen which lists out all the API

• Click on “Create – Create API”
• Select the System as “SAP_ES4” and click on the “Discover” button

    Search for an select “GWDEMO”. Accept the defaults and click on Create button.

The system will display all the available 25 resources under this OData service. You also have options to set the operations against each resource. For example, you can only restrict GET operation for SalesOrderCollection. You can also change the documentation against each resource.For now accept the defaults and click on create.

You have now created an API

2.3 Set policies for API

In this section we will explore on some of the policies which can be applied to API’s. There are many predefined polices which are available for us to use.

Click on the “Policies on API” tab, and select “Launch Policy Designer”. This will open the policy designer where you can add some of the predefined policies.

• The Policy Designer canvas provides a representation of the Request Response pipeline of the API proxy. Pipeline represents the flow pattern and specifies the condition on which this policy should be executed.

Under the ProxyEndpoint, select preflow and click on Edit button. On the right hand side select the “+” symbol next to Quota and provide a name  as shown and click on Add button

In the script which shows up in the middle of the screen, change the number from 2 to 4. This means that you will not be able to call this API for more than 4 times a minute. This is one way to throttle your requests. Click on Update button.

Now go back to the Policy Designer to add one more policy. Under the ProxyEndpoint, select preflow and click on Edit button. On the right hand side select the “+” symbol next to XML to JSON and provide a name as shown and click on Add button. This will ensure you will always get to see a JSON output instead of the XML output. Click on update button.

This is how the policy designer will look like after your save your work.

2.3  Test the API

From the menu, select “Test”. Select “GWDEMO” as the service and in the drop down select “SalesOrderCollection”. Set the operation as “GET”. Set the Authentication to Basic and provide your details. Click on send. Notice that the output is ion JSON format.

If you try to execute the service from more than 4 times, you will end up with a policy error as shown.

Finally, before publishing the API, let’s add one more policy. This policy ensures that there is always an API Key provided when executing an API. Now go back to the Policy Designer to add one more policy. Under the ProxyEndpoint, select preflow and click on Edit button. On the right hand side select the “+” symbol next to Verify API Key and provide a name as shown and click on Add button.

In the script section, change the APIKey ref to 'request.header.apikey’ as shown. Click on update button.

This is how the policy designer will look like after you save your work.

2.3  Publish the API

• Select “Manage” from the menu and navigate to the Product tab.
• Click on “Create” button to create a Product. A product can have one or more related API’s.

Give the name and title for the product and click on the + icon to add the API which we created earlier.

Publish the Product.

You have now created a Product and is ready to be consumed from the Developer Portal.

I have published the remaining steps as Part 2 in the following article.

In the previous article Building & Consuming API's using SAP API Management (Part 1), I showed how easy it is to create API's and publish them using the API Portal. Now we are going change personas and login to API Management as a Developer.

SECTION 3: DISCOVER API'S TO CONSUME

Developer portal is an application that provides a common platform for Application developers to consume APIs. Every SAP API Management customer is provided with their own Developer portal application on cloud. The Developer portal offers capabilities to onboard application developers, explore and test APIs, create and subscribe to Applications

3.1 Accessing DEV Portal

     Navigate to the API Management main menu and launch the DEV Portal

     Notice that our new product is already made available in the DEV Portal.

     Open the Product and explore the API along with the documentation. Notice that everything generated in the API Portal is automatically translated to the      Dev  Portal. You can see the operations against each resource including the documentation which was added for each of the resource.

     From the Product page, click on Subscribe > New Application

Provide the name for the Application and click on Save button

3.2 Consuming the Application

         Navigate to the Consume section to see the App you recently created.

     Open the App to locate the Application Key and make a note of this key.

3.3  Testing the API

Navigate to the Test section of the Dev Portal.

•    Select the GWDEMO API

•    For Authentication, provide Basic authentication with your user/password

•    Select the collection as SalesOrderCollection

•    Under Header, provide a new variable apikey and paste the application key you copied earlier.

•    Test the service by clicking on Send button.

If you didn’t not provide an API Key, you will be given an error message as shown.

Now with your fully configured OData API Proxy, with control policies, and API Key, the API is ready to have an App developed on it!

SECTION 4: Troubleshooting Tips

When creating an API in the API Portal, I was confronted with this error message. It didn’t allow me to Save an API

Similarly when I tried to subscribe to a Product in the Dev Portal, it gave me the below error message.

It turned out that all these errors were due to incorrect role assignments. If you bump into these issues, ensure that additional access is not given to your user account as well as the service user p1940842373.Sounds strange, but it worked for me.

I hope you found this informative.

Hi,

I'm trying to create a API for a service host on HCP.  But while testing in API Test Console keep getting 405 Method not allowed.  Looking at HCP Access Log there are no requests with code 405 for that service.  Also used debug but no apparent reason for failure (but then again I might not know what to look for).

Seems as though API proxy endpoint does not accept GET which does not make sense.  Ideas on what I'm missing?

API endpoint URL: https://trial.apim1.hanatrial.ondemand.com:443/[inumber]trial/piggybankCP/cashposition

Target endpoint: https://piggybank[inumber]trial.hanatrial.ondemand.com/piggy-bank-web/API/cashposition

In API Management created the System, tested destination and working

Then created the API

Testing results in

On this page we want to provide you with an overview of available documentation / how-to guides / tutorials / ... that help you get started with SAP API Management on HCP.

Official Documentation

• https://help.hana.ondemand.com/apim_od/frameset.htm

Introduction / Getting Started

• Free Trial of SAP API Management on HANA Cloud Platform is available now!
• How to use SAP API Management on HCP Trial
• Building & Consuming API's using SAP API Management (Part 1)
• Building & Consuming API's using SAP API Management (Part 2)

Connecting Systems

• <in progress>

Creating APIs

Working with Policies

• SAP API Management – Policy Management
• SAP API Management - Enabling URL masking

Analytics

• <in progress>

Consuming APIs

• <in progress>

If you have are missing anything or have other feedback, please let us know!

Is there any version for Windows available for SAP API Management - On Premise ?

I've downloaded the OP version available on SAP Marketplace but the installation is shell script based (for LinuxOS).

Or any other alternate way to install SAP API Mgt / Apigee on Windows server.. Thanks in advance.

Reagrds

Hardeep

Now that SAP API Management is available on HCP Trial we already can see quite a lot of people using it.

So far we have covered topics like Policy handling, URL masking and much more content is on its way. As of now we talked mainly about how to consume OData services or how to pass-through SOAP calls. In this blog I want to outline how you can connect to a SOAP service and expose it as REST.

The beautity of this approach is that developers who want to consume the service do not have to struggle with creating a correct SOAP envelope, find out the correct structure on how to retrieve the information, ...

Instead we can completely rely on REST attributes: we can use simple GET parameters to query something and could also implement PUT and POST methods to actually update information.

Recently we used a SOAP service for a Credit Check in a customer project which worked extremly well. The complexity of the SOAP structure was hidden behind a simple REST call. Unfortunately this service is not public so for this blog I have to fall back to a simple GeoIP service. This service takes an IP address and returns the details of the Country Name and Country Code.

GeoIPService Web Service

You can find more information and details here:

http://www.webservicex.net/New/Home/ServiceDetail/64

The typical payload for this service looks like this:

POST /geoipservice.asmx HTTP/1.1
Host: www.webservicex.net
Content-Type: text/xml; charset=utf-8
Content-Length: length
SOAPAction: "http://www.webservicex.net/GetGeoIP"<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">  <soap:Body>  <GetGeoIP xmlns="http://www.webservicex.net/">  <IPAddress>string</IPAddress>  </GetGeoIP>  </soap:Body></soap:Envelope>

and as a result you would get something like this:

HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: length<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">  <soap:Body>  <GetGeoIPResponse xmlns="http://www.webservicex.net/">  <GetGeoIPResult>  <ReturnCode>int</ReturnCode>  <IP>string</IP>  <ReturnCodeDetails>string</ReturnCodeDetails>  <CountryName>string</CountryName>  <CountryCode>string</CountryCode>  </GetGeoIPResult>  </GetGeoIPResponse>  </soap:Body></soap:Envelope>

The goal of this blog is now to reduce the input of service to something simple as

/v1//ipinfo/?ip={adress}

and have an equaly simple response like

{"ReturnCode":1,"IP":"String","ReturnCodeDetails":"String","CountryName":"String","CountryCode":"String"}

So lets get started.

At first we need to create a new API Proxy. Since we will connect directly to this specific service we do not have to create a seperate System. Instead we will just specify the URL and define the API Base Path.

So go to your HCP Trial -> SAP API Management subscription -> click on Manage and -> Create (see How to use SAP API Management on HCP Trial) for more details.

In the Proxy details page you can just click on Save to save the API Proxy:

Now we have to do the mapping. This will be done via the Policy Designer. Go to the 4th icon and click on the Launch Policy Designer:

Extract IP-Address

Assuming that we want the developer to call the URL

/v1/ipinfo/?ip=123123

we need to first extract the IP information. For this click on Edit, then PreFlow on the left hand side and finally the Policy "Extract Variables" on the left.

In the Create Policy screen enter the name

extractIPAddress

and leave the Stream as "Incoming Request"

Then click on Add

In order to retrieve the query parameter "ip" change / replace the content with this information

<!-- Extract content from the request or response messages, including headers, URI paths, JSON/XML payloads, form parameters, and query parameters --><ExtractVariables async="true" continueOnError="false" enabled="true" xmlns='http://www.sap.com/apimgmt'>  <QueryParam name="ip">        <Pattern ignoreCase="true">{IPAddress}</Pattern>    </QueryParam>     <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables></ExtractVariables>

In line 03 we look for the query parameter ip and assign it in line 04 to the variable {IPAddress}

Create SOAP Request

With that we can create the SOAP request which we can send to the actual service.

For this click again on the PreFlow on the left and select the "Assign Message" Policy on the right. Now enter a name

setSOAPRequest

for the new Policy.

In the editor we can replace / enhance the content with the following.

<!-- This policy can be used to create or modify the standard HTTP request and response messages --><AssignMessage async="false" continueOnError="false" enabled="true" xmlns='http://www.sap.com/apimgmt'>  <!-- Sets SOAP request header, payload and method to POST -->  <Set>        <Headers>            <Header name="Content-Type">application/soap+xml; charset=utf-8</Header>        </Headers>        <Payload contentType="text/xml">            <soap:Envelope                xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"                xmlns:xsd="http://www.w3.org/2001/XMLSchema"                xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">                <soap:Body>                    <GetGeoIP                        xmlns="http://www.webservicex.net/">                        <!--Optional-->                        <IPAddress>{IPAddress}</IPAddress>                    </GetGeoIP>                </soap:Body>            </soap:Envelope>        </Payload>        <Verb>POST</Verb>    </Set>  <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>    <AssignTo createNew="false" transport="http" type="request"/></AssignMessage>

In this AssignMessage Policy we set the header in line 07, and then put the Payload exactly like the SOAP Service is looking for. For the parameter <IPAddress> we add the variable {IPAddress} which we extracted in the set before.

Response from the Service -> XML to JSON

Once we do this call to the service, we will get back a SOAP reply. This is nice, but we actually want to return data in JSON format. So we need to convert the XML SOAP response to JSON. In order to do that, make sure that you select the PreFlow from the TargetEndpoint and click on XML to JSON:

In the Create Policy windows enter a name

convertToJSON

and select

Outgoing Response

from the Stream drop-down

In this policy we can replace / edit the content to

<!-- This policy converts an XML payload to JSON structure --><XMLToJSON async="false" continueOnError="false" enabled="true" xmlns='http://www.sap.com/apimgmt'>  <Options>  </Options>  <!-- The variable to which the converted JSON should be assigned to -->  <OutputVariable>response</OutputVariable>  <!-- The variable that we want to convert to JSON -->  <Source>response</Source></XMLToJSON>

Basically what we are doing here is taking response from the service (Line 08) and put it back as JSON (Line 06)

Simplify JSON response

The final step is that we want to reduce the response and only return some portions of it. In order to do that, make sure that you have still the TargetEndpoint -> PreFlow selected on the right hand, and select Extract Variables on the left hand side. In this new policy enter the name

extractResponse

while making sure that you have the Outgoing Response selected from the drop-down

The response that we would get so far is something like that:

{"Envelope":  {"Body":  {"GetGeoIPResponse":  {"GetGeoIPResult":  {"ReturnCode":"1",  "IP":"172.16.254.1",  "ReturnCodeDetails":"Success",  "CountryName":"Reserved",  "CountryCode":"ZZZ"}  }  }  }
}

What we want is only the part from the GetGeoIPResult. So edit / replace the content of the policy with this:

<!-- Extract content from the request or response messages, including headers, URI paths, JSON/XML payloads, form parameters, and query parameters --><ExtractVariables async="true" continueOnError="false" enabled="true" xmlns='http://www.sap.com/apimgmt'>  <!-- the source variable which should be parsed -->  <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>  <JSONPayload>        <Variable name="soapresponse">            <JSONPath>$.Envelope.Body.GetGeoIPResponse.GetGeoIPResult</JSONPath>        </Variable>    </JSONPayload>    <Source>response</Source></ExtractVariables>

Here we look at the content from the response (line 10), extract the path Envelope.Body.GetGeoIPResponse.GetGeoIPResult (line 07) and put it in the variable soapresonse (line 06).

Set the response

That's almost it. Now we only have to put the soapresponse back in the actual response. So again, make sure that you have the TargetEndpoint -> PreFlow selected, click on Assign Message on the left and enter a name

setResponse

for the new Policy while making sure you have the Outgoing Response selected

In the editor we will edit / replace the content to:

<!-- This policy can be used to create or modify the standard HTTP request and response messages --><AssignMessage async="false" continueOnError="false" enabled="true" xmlns='http://www.sap.com/apimgmt'>  <!-- Sets the converted json to the response -->  <Set>  <Payload contentType="application/json">{soapresponse}</Payload>  </Set>  <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>  <AssignTo createNew="false" type="response">response</AssignTo></AssignMessage>

In line 06 we set the payload to {soapresponse} -- the variable we extracted in the previous step -- and that is it!

Testing

Now we are ready to test the API. Make sure you click on Update and Save when exiting the Policy Editor.

Now if you go to the Test Console you can select the IPInfo API, add an IP address, select Get and fire your request:

As a result you get an easy to consume response :-)

Hi Techies,

We are using SAPJCO 3.0.9 in the external System (java) for processing the Idocs.

We receive idocs in the external system then we process them and send a response to SAP R/3 System

using ALEAUD.

When idocs are received simultaneously and responses are sent simultaneously we are getting Status as: 

- Status 51: Application document not posted

- Status Text : Error when locking the audit statistics for <Client> <LogicalSystem> <BASICTYPE>

This is happening for responses of few idocs and few are successful where we see them as:

- Status 53: Application document posted

- Status Text : (without error message)

Is there any programatic way we can resolve this ALEAUD idocs?

Regards,

Yogesh.

Ever since we released SAP API Management on Trial we got some very good feedback. The scenarios to connect to an OData service, or to consume SOAP service, protect these service, ... are very well received. We have started to collect all the information here,SAP API Management - Overview & Getting started

However, there is one piece missing: how can I -- easily -- connect to my on-prem system?

Unfortunately SAP API Management does not yet "natively" support SAP HANA Cloud Connector. We are currently working on a scalable solution. Until that (and mainly in order to get you unblocked) I want to outlined steps on how you can still use SAP API Management together with SAP HANA Cloud Connector. We will do this by using a small workaround :-)

Since SAP API Management does not have a proxy which can use SAP HANA Cloud Connector based Destinations we will use a proxy that is created by WebIDE and used by a simple SAP UI5 app . Then SAP API Management will connect to the services used by this app and connect from there to the backend system. This is not supposed to be a productive solution, but it should be good enough for a test on HCP trial or for a POC.

With that: lets get started!

Connecting on-prem system to HCP

At first you need to install and connect SAP HANA Cloud Connector to your HCP Trial landscape. I will not go through the installation, the official documentation is here and there are also some blogs / and multi-part blogs to get you started with this.

As a result you should have a working Connectivity in your HCP Trial Cockpit:

Now lets create a Destination which can be used in WebIDE. For me the resulting destination looks like this:

Creating WebIDE Project

Again I will not outline the steps, there are plenty of good blogs out there, like:

• Setting up SAP Web IDE with On-Premise System
• Setup your SAP Web IDE on HANA Cloud Platform Part 4

Once you have your SAP UI5 project in WebIDE, there is one step that we need to do in order to make the setup simpler. Right now the project is protected by SAML. Since I don't want to add the required policies in SAP API Management to enable SAML, I will just change the authentication to None.

For this open the neo-app.json and add the line

"authenticationMethod": "none",

Once that is done we can deploy the application on HCP:

You will get some pop-ups to authenticate, but in the end you just need to click on Deploy.

Once the deployment is finished, you can start the active version of the application...

... and see the UI in the browser.

What we are interested in is actually not the UI, but the underlying services. So start a network trace (-> "F12 Developer tool") and look for the call to the backend system:

This is the URL we are interested in:

https://connectionviawebidetocctobacke-p1941782771trial.dispatcher.hanatrial.ondemand.com/sap/opu/odata/iwbep/GWSAMPLE_B…

via this URL we can connect to our backend system.

SAP API Management

Now we can open SAP API Management and use this URL to connect. I will use the direct route, but of course you could create a system, add resources, documentation, policies, ... and all the fun stuff that SAP API Management provides.

When you now click on Save

You have the API Proxy URL that you can use to connect to your on-prem backend systems:

When you call this URL now then SAP API Management will use the service used by the SAP Fiori WebIDE project that we created, leverage the SAP HANA Cloud Connector to connect to the SAP Backend system and of course require you to authenticate there. Once you do that, you get the data from your on-prem SAP system:

That's it! Now you can use SAP API Management to connect to your on-prem systems. I want to highlight that this setup should not be used in a productive environment -- but should get you started connecting your on-prem systems to HCP Trial (without having to open ports in your firewall and installing a reverse proxy!)

Now that SAP API Management is available on HCP Trial we already can see quite a lot of people using it, which is good.

So far we have covered topics like Policy handling, URL masking and much more content is on its way. You can always refer back to this living document SAP API Management - Overview & Getting started in order to keep up to date on what is available.

This blog will serve as a companion to the Policy handling blog mentioned above, as an explanation of how an API Proxy runs through policies, and how to decide where a policy will therefore live in that "Flow". For explanation about what a policy is or what it does, please refer to the blogs specifically written to explain that.

TOC

• How Do Policies Work
• How to Visualize API Proxy Flow
• How To Actually Do It
• Flow Example
• Final Thoughts

How Do Policies Work in an API Proxy?

When a policy is added to an API Proxy, it is added to a specific point in the data stream, thus providing highly granular control. This is broken down into 2 "Endpoints":

• API Proxy Endpoint
  • Incoming request – Requests from external source (User application, B2B resource, etc.) to the API Proxy residing on SAP API Management
  • Outgoing response – Data request sent from API Proxy residing on SAP API Management to original request source.
• Target Endpoint
  • Incoming request – Requests from API Proxy on SAP API management to Target Endpoint
  • Outgoing response – Data response from Target endpoint to API Proxy on SAP API management, in response to request received from API Proxy.
    
    

After determining the appropriate Endpoint placement, and request or response, the next step is selection of subdivision of flow which defines when the policy is executed. Each request and response path in a proxy endpoint and target endpoint is broken down into the following flows:

• Pre-Flow
  • Always executes before any other flows.
  • The policies defined in the pre-Flow are applied to every message that passes through an endpoint.
• Conditional Flows
  • Execute only when a conditional statement defined for the Flow evaluates to true. These conditions tell the Proxy, “if you see this, then do that.”
  • An endpoint can define any number of Conditional Flows, but only the first Conditional Flow whose condition evaluates to true executes. That means the policies attached to the Conditional Flow only execute when the Conditional Flow executes.
• Post-Flow
  • Always executes after all other Flows.
  • Like Pre-Flow, the policies defined in the Post-Flow are applied to every message.
• (OPTIONAL – only for certain policies)
  • PostClient-Flow
    • § Executes after entire flow, including response to the Client has been completed.
    • § Only used by certain logging policies to track various metrics about API Proxy usage.

How to Visualize API Proxy Flow

At first this sounds complex, but after working with policies for a little bit, it becomes second nature, and becomes a powerful tool to controlling interactions. There are many ways to visualize this, but I like to think of it as 4 quadrants, each of which allow controls on data behavior.

The Client initiates a request, which connects to the API Proxy endpoint (Incoming Request), following PreFlow, Conditional Flow, PostFlow, and then traverses the diagram to the right, hitting the Target Service, which is then processed, and returned to the Target Endpoint (Outgoing Response), traversing to the left until it is returned to the Client. A policy could be placed in any of the 12 Flow points.

How To Actually Do It

Inside of the API Management Portal this is all managed in the Policy Designer page:

By selecting the appropriate flow (shown in boxes above), then choosing incoming request or outgoing response, a policy is placed at the right point in the API Proxy flow. One thing to note is that when multiple policies are placed in the same flow area, they are processed sequentially, in the same order as shown in the first diagram (Left to Right for requests, Right to Left for responses).

Some people say, that's great theory and all, but I would like an example, so here is a simple (and lightly contrived) example of flow in action.

Flow Example

A high level example of what this could look like in action – We have an example API proxy called “SalesOrder” which exposes an OData resource, from an EPM backend, as a single part of a Sales Order process. More specifically let’s look at the flow for reading a specific OData resource called “Products” which returns a list of available Products.

Client Request calls the API-Proxy, specifying the Products resource. This triggers the following sequence:

1) Proxy Endpoint Incoming Request

• Pre Flow Policies triggered
  • Verify API Key– Checks URI request for valid APIKey to ensure that Client has permissions to access this API
• Conditional Policies triggered for resource “Products”
  • Default - Checks that user request has permissions to perform “GET” operation on Products
  • Quota– Checks that resource requests are not overloading backend system
• Post Flow Policies
  • Assign Message - Strip out the API Key from the URI to be passed to the backend, both for security and because this would not be understood by the backend system.
  • Response Cache– Check for cached data, if request was made recently, return Cached data from SAP API Management instead of going to BackEnd.

2) Target Endpoint Incoming Request

• Pre Flow Policies triggered
  • JSON to XML– Prior to passing request to backend, convert JSON request to XML, so that Backend can understand data.

3) Target Endpoint Outgoing Response

• Post Flow Policies triggered
  • Response Cache– Pull response data into Cache within API Management, so that if another request is made in defined period, Cached data can be returned from SAP API Management.

4) Proxy Endpoint Outgoing Response

• Pre Flow Policies triggered
  • XML to JSON– After response received from Backend, per form conversion of XML response back to JSON format, for efficient transport, and to meet expectation for client.
• PostClient Flow Policies triggered
  • Statistics Collector – After API Proxy has run in its entirety, collect information about full end to end response times to track API Proxy performance. This is separate from standard Analytics which are collected by default on every API call.

We see here then the flow that our API Proxy processes, as well as some simple examples of Policies living in Pre-Flow, Conditional Flow, and Post-Flow. Depending on the specific need, some of these policies could have been placed in a different part of the flow cycle, the API Proxy and Policy design provides for a great deal of flexibility and control over what happens in a request made to a backend resource.

Final Thoughts

This Products Request example could also have many more Policies depending on need, for example, if the product listing were part of a catalog which only was exposed to employees, there might be an OAuth verification Policy. If the Proxy needed to provide a CSRF security token, there might be a Service Callout policy to make a Fetch token request to the backend, followed by an Extract Variable policy to get the Token response value, and an Assign Message Policy to add that Token value to the message Header being sent to the Backend, and more. Hopefully this example explains the basics of flow however.

Please continue to check back for more informational content surrounding SAP API Management !

For questions, feedback, concerns, feel free to leave a comment, or send us an E-Mail.

Follow us online
SAP API ManagementSAP.com|SCN|Youtube

Hi experts,

I'm using API Management in the HCP trial edition.

I have created an API connected to a remote non-SAP API server. The API seems to work correctly: I can POST requests and get the expected XML response using the following URL:

https://trial.apim1.hanatrial.ondemand.com:443/pxxxxxxxxxxtrial/XmlAPIService

Now I want to consume this API from a SAPUI5 app deployed in the same HCP.

Unfortunately, the app doesn't work because it isn't compliant with SOP: the SAPUI5 app is on an slightly different domain of the API.

https://appname-pxxxxxxxxxtrial.dispatcher.hanatrial.ondemand.com/?hc_reset

How can we configure the API so that we can consume it from the SAPUI5 app?

Can we configure CORS between SAPUI5 and the API in HCP API Management?

Thanks in advance,

Jon

Are there any resources (documentation, blogs, tutorials, videos) which use a HCP trial account HANA system and HANA XS service with API Management?

I successfully used API Management with a remote ABAP system (SAP Gateway) Destination, the corresponding Catalog Service, and a Gateway OData service.

I created a trial HANA database schema, HANA XS Service (.xsodata), and Destination, but am not able to discover service Resources within API Management.

Currently, I am trying to determine if it is a configuration issue (authentication, users, roles, privileges, properties, etc), a trial account limitation, or if I am entirely missing a critical concept such as cloud-connecting the cloud to itself

Introduction:

Analytics on API Portal provides a wealth of information captured through the use of API’s configured on the API Portal.

API’s usage are collected, analyzed and provided real time for the users of API Portal using Analytics. This Analytics section helps in statistically understanding lot of information and the same is visualized using different charts and Key Performance Indicators, as like:

    KPI's

For an API Portal user, there can be numerous data of interest namely but not limited to:

• API Traffic
• Frequently used API’s
• Error Prone API’s
• Most Active developers
• Key Performance Indicator

   Chart : Frequently used API's

  Chart : API Traffic

These are some example use cases and a lot of other information is available in Analytics section for the API Portal users to analyze for their organization and interest.

Let’s Dive in:

The Analytic's is accessible as a menu option from the API Portal.

   API Portal : Analytic's Dashboard

Let’s have a look on components of Analytic's on API Portal for its easy understanding:

1. Charts: Analytic's provide user with two set of charts, pre-configured charts and the custom charts. These charts are of different types also as like line, bar, pie.

All the charts on the API Portal can be resized or viewed in the detailed chart page by selecting the appropriate chart options from the top right corner in every chart container.

2. KPI’s: Key Performance indicators, they provides comparative indicators to the users to determine an overall picture of the API’s.

3. Views: There are three views present in the Analytic's, the view can be selected from the top left drop down. The views are :

1. a. Performance view: This view provide the KPI’s and charts which provides performance overview of the API’s, Products, Applications and Developers.
2. b.  Error View: This view provides the KPI’s and charts which provides Error overview of the API’s and Applications.
3. c. Custom View: This view gives a vast data in the hand of the API Portal users in form of custom charts which are created by API portal Admins as per their needs.

4. Time Interval: The user can view data within different intervals which are selectable from top middle pane.

    Interval selection Pane

5. Analyse Data: Every API Portal Admin has unique data needs. This feature gives the user benefit of adding new charts. These charts are displayed in the Custom charts view.

Analyse Data is accessible by clicking Analyse Data button from the bottom right corner on the analytic's page

   Custom Analyse Page

Step 1. Select a Measure:A list of static and custom(measures created using Statistics collector policy of an API) measures would be listed in left top panel. A Measure is plotted on vertical scale (Y Axis) of a chart.

Step 2. Select a Dimension: A list of static and custom(dimensions created using Statistics collector policy of an API) dimensions would be listed in left bottom panel. A Dimensions is plotted on horizontal scale (X Axis) of a chart.

Step 3. Select Time Interval: Admin can analyse data in multiple intervals, the interval could be selected from the interval selection pane from the top middle pane, by default the data is visualized for a month.

Step 4. Set Chart Filter:As per the requirement for data analysis, admin can apply filter on selected chart data (Data generated using selected measure, dimension and time interval) using filter button in the chart options in top right corner.

Filtering chart data with respect to particular API or developer can help in refined analysis.

Step 5. Select Chart Type: Every chart has a unique use , at times a Pie chart could help represent proportional data,  a Line Charts is an excellent trend analysis tool, at other times a Column chart can populate an enormous data an give a bird's eye view.

Analytic's provide three charts: Column , Line and Pie Chart.

Chart types are selectable from the top right corner in charts container.

Step 6. Give Chart Title And Save.  After clicking on Save, the chart is persisted and would be available for all the user of API Portal from the custom view in Analytic's Dashboard..

This blog is first in the series of the blogs on Analytic's on API Portal.

Please comment and share your feedback, we would be happy to read your experience with Analytic's on API Portal.

More details on SAP API Management is available in SCN community

Co-author : Sunil Kumar Chhajer

Hi all,

Have anyone installed the on-premise edition of SAP API Management by Apigee ? What feature difference did you see from cloud offering? Also the UI in the cloud version is less like "apigee" .

Please let me know your experiences of your premise edition.

Regards

Sujith Mathew

Hello All,

Did anyone use caching in the trial version? We applied  response cache policy for a scenario and can see it is working partially. It is deriving the CacheKey but  I don't think it is retrieving the value from the cache as the cache source says cache_miss though policy is executed successfully.

Alternatively,We also looked to create custom cache for testing using procedure described here. However We couldn't get it to successfully create a custom local cache using my tenant ID https://apiportal<tenantid>trial.hanatrial.ondemand.com/apiportal/api/1.0/Management.svc/CacheResources. We are unable to retrieve meta data either from the service. Did any one get this working successfully?

Hello,

We wish to connect an e-commerce site to SAP BYD via API (e-commerce)
When creating the order we would like to act on the sales tax through the interface. I have the following error message:

<Note>Price Component State sales tax (%) is not valid</Note>

Is this possible? Does anyone has an example to propose?

Thanks for your feedback

I want modify "tax rate"

The world of integration is changing really fast nowadays. It seems like only yesterday when everybody started to talk about SOA principles. In the last years many companies have done a heavy investment implementing their services in SOAP and REST/OData.

With the digital revolution there is a need of consume information on new ways, also companies need to expose their services to allow to developers to create new apps, everything has to be fast, easy to use, documented and of course secure.

Most SAP customers already have their interfaces built on PO/PI or Gateway, here is where API Management comes in, as a key end point in our landscape, to provide this information both internally and externally. But this new product it’s not limited to just traditional SAP landscapes API Management allows you to connect to any system, even other services outside your organization.

Some months ago we had the opportunity to experience SAP API management, first in the Beta program and then later in the customer validation.

During these sessions we had the chance to implement the scenario I'm going to explain:

AS IS

One of our customers is a wholesale company that wants to improve their catalog of products, they are also trying to find new business opportunities and build the business case to fund the project.

They have already built many services in their landscape, but it's still too complex.

They need a platform with the following attributes:

• Simple, scalable and secure.
• On boarding process for third party developers.
• Service discovery.
• Well documented
• Analytics
• Integrated with SAP.
• Monetise
• Role based

Solution: SAP API MANAGEMENT

In the following diagram we can see the current landscape of the wholesale company.

In terms of integration, they already have a Gateway server that exposes OData services to be consumed by UI5 Apps.

And they also have a PO box with some BPM process and EDI interfaces.

What we wanted to add, is an extra layer to manage APIs consuming resources from SAP Gateway.

These APIs could be consumed by mobile devices, message brokers, and even by developers inside the organisation.

Our target was to create two APIs:

• A public API to receive the catalog of products from multiple providers.
• A "Price Comparator", the API that our customer is going to monetize.

And now let’s be hands on and build the scenario!

First we configure the connection to our Gateway box, and this is where we find the first issue. API manager doesn't connect automatically with Cloud Connector (feedback has been shared with SAP and they will work on that).

By using the option to discover the service, in literally 2 minutes we have our first API available in the system.

• First we have to chose the system we want to connect to, in our scenario we are connecting to a gateway service.
• Then API Management will show us the list of services available in our system.
• Finally, we will choose one and will assign the base path we want to use to expose the data.

Once we have imported the service, API management will create the API in our system, reading all the documentation for the fields and services available in the gateway system.

We have our API imported, it’s time too add policies to our APIs. A policy is a program that executes a specific function at runtime and API management provides more than 20 policies out of the box.

One of the things I really like about API management is the new look and feel really easy to understand, within a few clicks our API has two policies: Check quota & check API key.

In the public API we are just checking the API Key to validate that is consumed by one of the configured applications.

Additionally, we added a quota policy in the Price Comparator, so we’ll be able to control and monetize our API (in future versions they will add more tools around this concept).

Once we have defined the APIs, we create some applications, it’ll be by subscribing to an Application how developers will get the key required to access the APIs.

And finally, after playing a bit with SOAP UI to automate my tests, these are the results displayed in a nice out of the box Lumira style dashboard.

I think SAP has done really smart move adding API Management in their portfolio, it’ll allow to existing customers to create their own APIs with a really low investment reusing what they have implemented in their PO/Gateway systems. It’s really easy to use, secure and the onboarding system allows to have a platform really developer friendly to discover the APIs avaiable in your organization.

I hope you found this blog useful!

Jorge

Hello Experts,

I need to pull data from the payment gateway API using SAP ABAP, Can some one provide me  step by step, mainly from ABAP end