Have anybody tried to run SAP API Management on RHEL Version 7.2  ??

Dear Group,

I have been looking for information that advises on the minimum technical specifications for implementing and running SAP API Management on-premise.

I've looked through all the content and a lot of documents but not found anything. Could this group help to point me in the right directions?

Thanks,

Mat.

Introduction

Are you an Integration Architect going ape with positioning API management and the never ending middle ware rebooting? 

I think there are many good blogs explaining the differences of various products and when we have to use them but I want to look at it from the lens of a customer and an integration architect.

Let’s cut the marketing red tape and put the things in a perspective. SMACT (Social, Mobile,Analytics,Cloud,Things) is changing the  "definition of the consumer and the system and an application" .

“Businesses are no longer the sole creator of a brand; it is co-created by consumers through shared experiences and defined by the results of online searches and conversations.”  – Brian Solis

Definition

In theory, the term API means “Application Programming Interface”.  Does that mean we are going back to point to point interfaces and kissing good bye to the ESB products and SOA for connecting up and integrating light weight applications quickly in future?

In my view, if I had the power to redefine the term API then I would define it as, “A light weightagile reverse proxy middle ware used for Any Point Integration of micro service interfaces with no clear definition of boundaries on where and how they are deployed and consumption of micro services quickly”.

Evolution

A decade back, SOA, ESB products and SOAP gained momentum for connecting up and integrating loosely coupled B2B and A2A distributed applications.The web developers still builtpoint to point UI applications for faster user response time i.e. less latency time and throughput. They avoided using SOAP services as they don’t want to hit themselves to the wall due to the performance over head of parsing the XML back and forth.

In 2016 and future, the world and definitions of the applications, integration and data is constantly changing! We have limitless integration possibilities with the driver less connected cars, drones on rampage, bionic 360 degree 3D holographic clones of Leonardo di Caprio , IoT enabled smart cities using energy grids and cyborgs on a high speed cloud!

There was 5 exabytes of information created between the dawn of civilization through 2003, but that much information is created every 2 hours – Eric Schimdt

The Ugly Truth and Sin of the City!

As much as the world hyped SOA and open standards, I don’t think there are many organizations that replaced or service enabled their entire integration landscape using ESB products due to the skyrocketing costs and long-time scales for implementing the integration projects. It is also partially due to the lack of business interest in transforming the integration landscape as they fail to see tangible business benefits of changing some thing that worked for years. 

The classic life of an IT consultant, “If you are finished changing, you are finished”!.

They instead followed a hybrid approach and used ESB products to reconnect all systems without changing the legacy interfaces and created new services using ESB products . They either designed SOAP services on top of legacy interfaces or connected with legacy systems via SOAP Services depending on the capability of the legacy systems.

The file transfers, legacy protocols, JMS messaging and EDI protocols still exists even now and is not going to go away anytime soon as many small scale entrepreneurs still use phone or fax as mechanisms for connecting up in places where there is no internet penetration. I don't think any business would shut the existing channels, but it will open up new channels and decommission the old channels when the world transitions into the next century.

Does Integration Landscape in future looklike a layered cake?  When will we stop using FTP Channels, Does any one know date of expiry for file interfaces or transfers?

I think many big fortune 500 companies still use that as a fundamental mechanism for interfacing. The smaller companies and start-ups are widely using API's built using open standards to penetrate into the new markets quickly and hence if big companies don't catch up then they will surely be wiped off the fortune 500 list. 

Lip Stick on the Pig!!!!

The most meaningful technological innovations cannot be applied as easily as the proverbial “lipstick on the pig” unless the business processes are completely redesigned and developed from scratch to meet the latest market requirements and specifications.

Would you redesign or repair a used dress from the scratch for 21st century after it is made and sold to the consumer unless the product is faulty?

I think the same formulae applies to the integration landscape, we aren't going to change the brittle legacy interfaces using new technology unless you are a  cash rich business to pump money into the integration projects as the legacy systems might disappear in future. Instead, you dress up and mask it and expose it up to the new channels using API management tools. Ain't it?

Future Integration Wardrobe!

The fundamental questions that needs to be answered though the products are not replacing each other, When and why and where will you use API management tool? When and why and where will we use SAP PO? When will you create services and publish on UDDI repository or ESOA discovery platforms and when will you publish services on API Hub platforms?

Gold Standard to  design Micro Services!

According to recent buzz and organizations embracing agile and lean working model, SOAP services will eventually fade out due to the complexity and performance overhead associated with parsing XML(s) and many organizations will go ahead with lightweight REST services until something else sweeps the world in the future.

Ideally, we should redesign the integration landscape using micro services enabled by API management where ever possible for faster penetration into different markets and channels but we all know it is not how it works in reality and big organizations.

My gold standard on when to design and publish services on API Management / API hub is:

• When the organization is designing  customer facing application services that needs to be consumed by various devices
• When the new integration requirement arises for connecting up the applications on the cloud and on premise
• When the organization identifies non-confidential interfaces that can generate revenue when exposed to the wider world
• When the micro services doesn't need to transfer large volumes of data for connecting up applications
• When the integration platforms are upgraded or replaced, we should use the opportunity to perform fitness assessment on whether interfaces can be enabled as micro services using API management tool to tap new markets and channels and consumers.
• When you want to consolidate services across disparate endpoints and systems and expose it a single service to the consumers.
• When services don't need complex mapping  and logic for passing data from the source to destination i.e service should be truly micro service in architecture.

I'm hoping someone out there can help. I've been following the API doc and have tried to make a few simple calls now that I have the auth token piece working but no matter what call I try, the API returns a json with the following error.

{"error":{"code":null,"message":"class java.lang.String:null incompatible with class com.plateau.common.odata.impl.filter.FilterExpression:WebappClassLoader\r\n context: /learning\r\n delegate: false\r\n----------> Parent Classloader:\r\njava.net.URLClassLoader@ce63294\r\n********"}}

I'm calling the API from a PHP Curl script as follows:

function learningPlan($bearerToken){

    $servicePath = "learningPlan/v1/UserTodoLearningItems";

    $qryStr = "\$filter=criteria/targetUserID eq 9359560 and minRowNum eq 1 and maxRowNum eq 10 and retrieveLinkedSchedules eq false";

    $url = 'https://rogers-stage.plateau.com/learning/odatav4/'.$servicePath.'?'.$qryStr;                                                                          

    $ch = curl_init();

    curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 0);

  curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0);

    curl_setopt($ch, CURLOPT_URL, $url);

    curl_setopt($ch, CURLOPT_HTTPHEADER, array('Authorization:Bearer '.$bearerToken));  

    curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);                                                                     

    $response  = curl_exec($ch);

    return $response;

    curl_close($ch);

}

I'm hoping someone out there can help point me in the right direction... I also would like to add that there are some flaws in that API doc that had me chasing for a while, not fun...

As announced in my previous blog, we have now gone live with SAP API Central - the one-stop place to discover, explore and test SAP APIs. This guide explains how to test and explore services published in the catalog.

First, you need to sign in to your developer account on SAP HANA Cloud Plaform. If you don't have an account yet - anyone can register an account for free:

When you access your SAP HCP Trial instance and go to Services you will see one new entry: SAP API Central:

By default it is already enabled so if you click on it you can find the usual description and the URL to access it.

Discovering and Exploring SAP APIs

You will now see the landing page for SAP API Central:

You can expand the hamburger menu and navigate to the Catalog section to discover which APIs are available so far:

By selecting an API Product and expanding the resources, you may explore the API by reading the available documentation in the OpenAPI format. The great thing about the OpenAPI format is, that it tells you what the input structure for the respective API should look like, which input parameters are required, whether they go in the request header, path or body, which input values are available, etc. Also it tells you which possible response codes there are, and in which format you can expect the response.

As an example, take a look at the documentation for the API Management API Portal:

Subscribing to an API

To try out an API, you will have to click the Login button in the top right corner and sign in using your HCP trial account. Now you need to navigate back to the Catalog section in the menu. Now that you are logged in, there will be a new option to subscribe to an API:

You are now asked to either add the API Product to an existing Application or to create a new one. For each application one common API Key and App Secret will be generated. This has the benefit that when you subscribe to multiple APIs from SAP API Central, you will only have to deal with one API Key.

For this example, I am going to create a new application:

As a result, you can now find your personal API Key that can be used to test-drive the services on the API Central:

When you open the documentation for the API Portal again, you will now find the option to get the API key and to actually make test calls using the API:

Now you have everything in place to make your first test call against the API. If you are successful, your response will look as follows:

That is all you need to know to explore and to discover the APIs available today. We will work hard to bring further features to SAP API Central soon and to onboard further SAP APIs.

Please let us know what you think - either by commenting in the API Central itself, leaving a comment underneath this blog or sending us an email.

Since the beginning of the year the SAP API Hub has been available as a service in beta status on SAP HANA Cloud Platform. Today we are seizing the next step and are launching a new version based on the design-winning SAP Fiori design with the new name SAP API Business Hub.

What is SAP API Business Hub?

SAP API Business Hub is targeted at developers and partners that wish to connect to SAP systems using APIs - both cloud and on-prem. We want to make SAP API Business Hub the one-stop place for you to discover, explore and test SAP APIs. We have committed ourselves to publish the API documentation in the popular and widely-used OpenAPI format. And finally - for some APIs this is still a work in progress - we allow you to try out APIs in sandbox systems provided by us. This is a part of the ongoing effort to open up SAP and to connect more easily to SAP systems and and applications.

How to use SAP API Business Hub

In simple terms, to try out the APIs published on SAP API Business Hub, you need to pass an API key with each call you make against the service. To obtain an API key, you need to do the following:

1. Register for a trial account on SAP HANA Cloud Platform.
2. Log in to SAP API Business Hub
3. Find the API you would like to test in the API Catalog
4. Subscribe to the API and create a new application or add it to an existing application. (An application is a bundle of several API registrations, so that you don't have to deal with different API keys for different SAP APIs.)
5. Explore the documentation in the OpenAPI format and make some test API calls.

For a more detailed explanation on this, please follow this step-by-step guide for using SAP API Business Hub.

API Depreciation Policy

Please note that the APIs published in SAP API Business Hub are not meant for productive use and might slightly differ from the actual APIs, i.e.:

• host and base path are modified
• logon credentials are handled by the API Hub and therefore not needed in the API
• an API Key is required to access the APIs in the Hub - this API Key is not needed when working with the live service.

Also - for the time being - we reserve the rights to make changes to the available APIs in SAP API Business Hub at any time or even unpublish these without any ahead notice. Of course, we are working hard on making a more reliable API depreciation policy available to you as soon as possible.

Final remarks

Of course, we'd love to hear your feedback on this. Please let us know if you need any additional information, or if you'd like to see a certain API included. So if you like, please leave a comment below or drop us an email.

SAPPHIRE NOW - A high energy event spanning 3 days in Orlando! Big Keynotes from many Big Names from SAP, and Big Partners around the globe utilizing SAP solutions. You can find ma huge amount of materials from SAPPHIRE NOW and ASUG here:

SAP HANA Cloud Platform - Extend Integrate Build

As part of the SAP HANA Cloud Platform's commitment to simplifying Business in the cloud, Bernd Leukert, in his Keynote introduced SAP API Business Hub as part of SAPs offering to make it easy to discover, integrate and build on top of business Data.

HCI is SAPs well known Integration tool, connecting OnPremise Business Data into the Cloud, or connecting Cloud to Cloud data, but now with SAP API Business Hub, SAP has introduced a centralized location for Customers and Partners to discover Documented Business APIs, upon which they can build new business Apps, leveraging S/4HANA, SuccessFactors, IoT, and more.

Next Steps with SAP API Business Hub

This created a lot of Buzz around the release, and what it can mean for Customers and Partners. How can you get your hands on this? To start Bjoern Woppmann has created a blog to get people started: SAP API Business Hub launched: Discover, explore and test SAP APIs

Free SAP Partner Workshop

For Partners interested in learning more, is hosting a Free Partner Workshop in Palo Alto on June 21st - 23rd, 2016. This workshop will involve Lecture, Hands-on Exercises and Face-to-Face time with Subject matter experts on SAP API Management, SAP API Business Hub, SAP UI5, and Mobility to learn how to tap into these offerings to get started building Apps simply on HANA Cloud Platform.

To register simply follow this link: 2016 Workshop Registration for SAP Partners

For questions, comments, or concerns you can contact SAPAPIManagementInfo@sap.com

Hello all,

I went through the very good guide from Holger in order to get started with HCP SAP APIM.

In order to create a custom dashboard, I would like to retrieve some information from the response of the SalesOrderSet resource, using an ExtractVariables policy, combined with a Statistics Collector Policy.

Here is the XML response I get for a specific SalesOrder:

<?xml version="1.0" encoding="utf-8"?>

<entry xml:base="https://SAPES4.SAPDEVCENTER.COM:443/sap/opu/odata/iwbep/GWSAMPLE_BASIC/" xmlns="http://www.w3.org/2005/Atom" xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata" xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices">

    <id>https://SAPES4.SAPDEVCENTER.COM:443/sap/opu/odata/iwbep/GWSAMPLE_BASIC/SalesOrderSet('0500000000')</id>

    <title type="text">SalesOrderSet('0500000000')</title>

    <updated>2016-05-24T14:26:33Z</updated>

    <category term="/IWBEP/GWSAMPLE_BASIC.SalesOrder" scheme="http://schemas.microsoft.com/ado/2007/08/dataservices/scheme"/>

    <link href="SalesOrderSet('0500000000')" rel="self" title="SalesOrder"/>

    <link href="SalesOrderSet('0500000000')/ToBusinessPartner" rel="http://schemas.microsoft.com/ado/2007/08/dataservices/related/ToBusinessPartner" type="application/atom+xml;type=entry" title="ToBusinessPartner"/>

    <link href="SalesOrderSet('0500000000')/ToLineItems" rel="http://schemas.microsoft.com/ado/2007/08/dataservices/related/ToLineItems" type="application/atom+xml;type=feed" title="ToLineItems"/>

    <content type="application/xml">

        <m:properties>

            <d:SalesOrderID>0500000000</d:SalesOrderID>

To extract the SalesOrderID, I configured my ExtractVariables policy as follows:

<!-- Extract content from the request or response messages, including headers, URI paths, JSON/XML payloads, form parameters, and query parameters -->

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

    <Source clearPayload="false">response</Source>

    <VariablePrefix>SAP_APIM</VariablePrefix>

    <XMLPayload stopPayloadProcessing="true">

     <Namespaces>

            <Namespace prefix="d">http://schemas.microsoft.com/ado/2007/08/dataservices</Namespace>

            <Namespace prefix="m">http://schemas.microsoft.com/ado/2007/08/dataservices/metadata</Namespace>

        </Namespaces>

     <Variable name="SalesOrderID" type="string">

     <XPath>//d:SalesOrderID</XPath>

     </Variable>

  </XMLPayload>

</ExtractVariables>

However, when saving and updating the proxy, I get the following error message:

[Request ID: c27460bb-74f4-427f-a8b7-637f3be0db38]

Policy content for policy "SalesOrderID" is invalid. cvc-complex-type.2.4.d: Invalid content was found starting with element 'Namespace'. No child element is expected at this point.

IMHO, my policy is in line with the documentation SAP API Management

My workaround is pretty easy (XML-to-JSON, and then using a JPath) but I would like to see this working natively.

Thanks for any help!

Sven

So far we have mainly talked about how to expose services via SAP API Management. Obviously we have just scratched the surface and we will continue to provide more and more information on how to build rich APIs.

In this blog we will focus on the consumption side. Of course you can use whatever technology you chose to consume the APIs, however, being based on the SAP HANA Cloud Platform it is fairly simple to leverage other services. One of these services is the SAP Web IDE which allows you to build SAP UI5 based applications like SAP Fiori.

You might have already seen how easy it is to consume OData services based on SAP Gateway. The great thing: the same is possible for APIs from SAP API Management.

The first step is to create two Destinations which will be used by the SAP Web IDE. One will point to the Developer Portal -- having the Web IDE Usage = api_mgmt_catalog -- from where the API Proxies will be retrieved and the second is to the API Portal -- using the Web IDE Usage = api_mgmt_proxy -- which is used during the actual runtime:

Name=API_Management_Dev_Portal_Trial

URL=https\://devportalu34f5b50f-p1941xxxxtrial.hanatrial.ondemand.com/

Description=A - API Management - Dev Portal - Trial

Type=HTTP

Authentication=AppToAppSSO

WebIDEUsage=api_mgmt_catalog

WebIDEEnabled=true

CloudConnectorVersion=2

ProxyType=Internet

The URL to your Developer Portal can be retrieved from your HCP Cockpit from where you enabled the SAP API Management, Free Trial of SAP API Management on HANA Cloud Platform is available now!

Name=API_Managment_EndPoint_trial

URL=https\://trial.apim1.hanatrial.ondemand.com\:443

Description=B - API Management - runtime - endpoint - trial

Type=HTTP

Authentication=NoAuthentication

TrustAll=true

WebIDEUsage=api_mgmt_proxy

WebIDEEnabled=true

CloudConnectorVersion=2

ProxyType=Internet

That's more or less everything you need to do.

If your API Proxy is protected via an API Key (the Verify API Key Policy) you have to make sure that the policy is looking for the value APIKey in the Header property:

So let's get started. For the following steps, I am using a very simple API Proxy that is connected to the GWSAMPLE_BASIC Service on ES4 (similar to what was done here, How to use SAP API Management on HCP Trial)

Open the SAP Web IDE (the URL looks something like https://webide-<yourID>trial.dispatcher.hanatrial.ondemand.com/), select New Project

and click on the "SAP Fiori Master Detail Application" template and click on Next

Enter a project name and click on Next

from the dropdown select the Destination you had previously created (when you are prompted for a username and password, enter your username from the HCP system). You will see a list of API Proxies which are available in your SAP API Management developer portal. Select one of the Proxies and click on Subscribe (if you cannot see the Subscribe button, scroll down a little

Now that you have selected the Proxy that you want to consume, you need to select the Product this Proxy is assigned to. Select the product and click on "Select Product"

Now click on Next and you can assign properties from the API Proxy to your SAP Fiori fields.

We are almost done. The only thing left is that -- if you had set a Verify API Key Policy -- you have to manually add the API Key (something that was done automatically during the designtime in the Wizard; for the runtime you still need to add this manually). To do so, open the manifest.json file in the webapps folder and copy the following lines in the sap.ui5 -> models -> settings section (you might need to switch to the Code Editor at the bottom of the screen). For the API Key you obviously have to take your own for which an Application was automatically created in the Developer Portal.

,  "headers" : {     "APIKey": "4q8Db5rgmnIrYXr4xxx"  }

That's it. Click on Save and run your application which is now connected via SAP API Management to your backend system.

.

Hi Team,

I would link to point out that we are facing issue to consume SAP services in Apigee environment.

Please find below information:

1. We could not able to perform create functionality in Apigee environment.It is because of

CSRF token security in SAP

2. I can able to retrieve CSRF token from SAP, but when I pass this token to post call, It shows CSRF Token Validation failed.

I would appreciate your help, Please let us know, If you have any solution on it.

Expecting your reply,

Regards,

Karthik A

Summary

We are happy to announce the availability of Service Pack 04 for SAP API Management by Apigee 1.0 for on premise deployments.

What's new?

Service Pack 04 includes Backend as a Service (BaaS), which provides web and mobile app developers with a way to link their apps to a datastore and provide features such as user management, push notifications, and integration with social networking and geolocation services. BaaS also enables App event logging which is used in Edge Analytics Services to bring visibility to App usage. Service Pack 04 corresponds to the original Apigee release 4.16.01

Besides the new addition of BaaS it also introduces minor feature additions like target server configuration and key value maps for policies.

More details about the newly added scope will be rolled out soon. Stay tuned!

Where to Download?

Service Pack 04 can be downloaded from SAP ONE Support Launchpad (using your SAP customer S-User ID)

• go to "Support Packages & Patches"
• go to alphabetical list
• select "A" like SAP API Management OP" --> "API Gateway 1.0"
• the zip file contains both the binaries and the documentation for the Service Pack

What's next?

We are in the process of qualifying Apigee release 4.16.05 and plan to ship this by end of July 2016 as SAP API Management by Apigee 1.0, SP05. Stay tuned for more news once this is available.

Hi All.

I would like to know how to write datetime format in Json code for SF OData v2. I tried with this example 01-01-2016T14:42:30 but it gives an error as "Illegal datetime format". I am using this for POST operation.

Dear Experts,

I had a working scenario fetching ODATA service from backend and with couple of other policies added. This is on HCP Trial account.

I added the Verify API Key Policy and things stopped working.

My XML for the policy says >>

<!--Specify in the APIKey element where to look for the variable containing the api key-->

<VerifyAPIKey async='true' continueOnError='false' enabled='true'

xmlns='http://www.sap.com/apimgmt'>

  <APIKey ref='request.header.APIKey'/>

</VerifyAPIKey>

And I am sending a HTTP Header called APIKey using postman / also from a Java program.

This fails with an error as below.

{

  "fault": {

    "faultstring": "Invalid ApiKey for given resource",

    "detail": {

      "errorcode": "oauth.v2.InvalidApiKeyForGivenResource"

    }

  }

}

the Application Key is the exact value copied from the Dev portal , I also tried regenerating and using the new value but the error still occurs. Did also change the name of the header both in policy and in the client(postman / java code) but that does not help either.

Any clues?

Thanks,

Amol

Introduction

In this series of documents, I will introduce you to the concepts and ideas that sit behind SAP's API Management offering.  We'll start by looking at the "the big picture", and then as we progress through the documents, we'll dive deeper into the details so you can see how all the pieces fit together.

By the end of this series of documents, you will be able to build a real-life API Proxy that exposes a Web Service from a backend system.

So, let's start with the 30,000 feet overview...

Where We've Come From

It has long been known that lots of powerful business functionality lies buried deep inside every SAP system.  However, the challenge has always been how to get at that functionality in a consistent and easy-to-consume manner?

Back in the mid-nineties, the Remote Function Call (RFC) interface arrived on the scene (1994 if my memory serves me correctly).  Originally, the RFC interface was accessed from outside the SAP system via a set of C libraries that allowed an external C program to call any ABAP function module that had the "Remote Enabled" flag switched on.

This was certainly a good start, but it was fairly restricted in its adoption for the simple reason that first, in order to make use of this interface you had to be a C programmer, and second, you had to have some internal knowledge of the SAP system in order to understand the data being sent and received.  Needless to say, adoption was limited.

Then, the libraries for accessing the RFC interface were expanded to include Visual Basic and this new fangled language from Sun Microsystems called "Java".  For a while, it looked like everyone was happy.  Visual Basic and its MS Office counterpart "VB for Applications" was widely used and Java was growing in popularity.  But the whole use of RFC based access to SAP imposed a barrier to adoption.  RFC was a proprietary protocol and required the external developer to have at least some knowledge of how an ABAP function modules works.

But the mid-nineties saw the invention of another technology that has now totally transformed the face of both the retail and business computing world - the World Wide Web (now often referred to by non-technical people as "The Interwebs").  Quite soon, businesses began to see the benefits of giving customers access to their systems through these new bits of (not very compatible) software called browsers.

But as with any emerging technology, there's always a scramble for market domination and whoever wins this scrap tends to be able to set the technical standards for how that software should behave.

All of these changes provided SAP with a significant challenge because at that time, the ABAP kernel had no way to communicate using any protocol other than DIAG (used by SAPGUI) and CPIC (used for Remote Function Calls).  Back then, this new fangled protocol called HTTP was completely incompatible with ABAP systems.

So to get the ball rolling, SAP implemented a protocol translation layer called the Internet Transaction Server.  The main job of this software was to translate HTTP messages arriving from browsers into either the DIAG protocol used by SAPGUI or the RFC protocol, then to translate the outbound response from the SAP system back into HTML for the browser.

Step forward to the Millenium Year and a researcher at the University of California, Irvine by the name of Roy Fielding was granted a doctorate for his thesis called Architectural Styles and the Design of Network-based Software Architectures (available here https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm if you're curious).  From this paper, the widely popular concept of Representational State Transfer, or REST has been acquired.

The architectural principles of REST are now taken to be the de facto design philosophy behind all well designed Web software.  Unfortunately, the term "RESTful service" has been bandied around so much nowadays, that some people talk of REST as if it is an alternative protocol to HTTP.  "Yes, we have two types of service, HTTP and REST".

Which reminds me of a scene from the Blues Brothers: Classic Movie Line #5 - YouTube

But anyway, I digress...

All through the browser wars of the late nineties and early naughties, people were experimenting with different protocols.  During this time, SOAP based Web Services started to become widely used (in spite of their dubious grasp of the principles of REST)

All this to say that everyone knew that backend business systems contained lots of useful information and functionality - its just that nobody could agree on a single, unified protocol through which these backend systems could be accessed.

And even today, people still can't agree...

Leveling The Playing Field

In all of this technical maelstrom of conflicting or ambiguous interface standards, and with the petty squabbles over my-interface-is-better-than-your-interface, various companies have decided to sidestep the whole issue and provide software from which anyone can that create their own standardisation layer.  One such company was Apigee.

What SAP has done is to implement the Apigee Edge software as a cloud-based service and then provide all HCP users with access to it via a service called "SAP API Management".

Using the functionality of API Management, you can develop your own proxies to almost any backend service you like - and there's no restriction here to access only SAP backend systems.  You can access any system that is visible to the public internet and supports HTTP based communication.

APIs Are The Fuel That Drives Innovation

Any backend business system (such as an SAP ERP system) is known as a "System of Record".  These systems need to be rock-solid stable simply because large businesses are entirely dependent on the data contained within, and the functionality provided by these systems - if such a system goes down, its quite possible that part (or even all) of the business stops working!

Consequently, these systems do not change either very often or very quickly.

However, in the brave new world of Agile software development and the accelerating pace of change, the systems with which the end users interact are expected to stay up to date with the latest technological developments.  This means new layers of software must be built on top of the systems of record that can accommodate the expectation for a more rapid pace of change.

Hence we now see the emergence of Systems of Engagement that sit on top of the Systems of Record.  Systems of Engagement change faster than the underlying Systems of Record, but still not fast enough to keep up with the pace of change that occurs with technology innovation.  Therefore, we see a third layer of software known as Systems of Innovation.

Systems of Innovation are where the latest technological advances are implemented - yet at the same time, these apps need to access the same functionality exposed by the backend systems of records.

Therefore, to provide a standardised interface, SAP API Management sits in between the systems of Engagement and the Systems of Innovation.

Enabling Innovation and Bimodal IT

In the world of API Management, the term "Bimodal IT" refers to the practice of managing two separate, yet 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.

Starting Your API Management Service

To gain access to this API Management service, you must at least have a Trial Account on the SAP HANA Cloud Platform.  If you don't have one of these, please go and set one up now...

From your HCP account, from the menu on the left, select Services, then scroll down to the section titled "Integration" and click on the "SAP API Management" tile.

When the API Management service screen appears, you will see that there are several different links you could select:

1. The API Portal.  This is used by a proxy developer for creating API Proxies and Products
2. The Dev Portal.  This is used by the developer of a frontend application when they wish to consume an API Proxy developed by the proxy developer
3. Service Configuration.  Here there are two further links that allow you to configure the roles and destinations used by API Management

Click on the link to access the API Portal (not the Dev Portal!) and you will see a screen similar to the following.  If this is the first time you've accessed your API Management tool, then all the counters on these analytic tiles will be zero.

Before we dive into the details of how to build an API Proxy, it is very important that we first understand two things:

1. The data objects with which we will be working
2. How these data objects are related to each other

Overview of API Management Data Objects

In API Management, you will be working with 4 different data objects.

Systems

The first type of data object is a "System".  A system is simply a logical name for some backend system of record.  Each system you define will act as the provider of backend functionality such as Web Services or OData Services.

API Proxies

An API Proxy is the data object that contains all the functionality to be executed when an external user wants to access the backend service.  Within the API Proxy you can implement all manner of functionality such as checking that the user has not called this API more times that are permitted by their quota, or preventing a denial of service attack with a tool known as a "Spike Arrest", or translating the incoming request into a SOAP XML payload, or performing your own custom written functionality, etc etc etc...

To be honest, the development of an API Proxy is where 99% of your development effort will go.  You can think of the API Proxy as the heart of API Management.

Each API Proxy represents the interface to a single backend service,  You cannot create an API Proxy that is a mashup of data received from different backend services.  If you want to do that, then you should look at HCP's OData Provisioning service and not here in API Management - this is the wrong tool for that particular job.

Products

Now this is where the fun starts (as if we aren't having fun already...)

It is not possible for an external user to consume an API Proxy directly.  In order for your API Proxy to be visible to the outside world, you must first add it to a data object known as a "Product".  The purpose of a Product is to group proxies together into units that represent all the services needed to perform some larger unit of business functionality.

You should think of a Product as The unit of API exposure

The important thing to understand here is that in addition to an Product being able to contain multiple API Proxies, one API Proxy can be added to multiple Products.  This results in the formation of something called a many-to-many hierarchy, like this:

So remember: one API Proxy can be added to multiple Products, and one Product can contain multiple API Proxies.

Either way, if you do not add an API Proxy to a Product, then no external user will be able to consume that API Proxy - it will remain completely hidden from view.

Applications

Finally, we come to the last data object known as an Application.

We must be very careful to understand what is meant here by the use of the term "application", because in the context of API management, the term "application" does not carry the conventional meaning.

The conventional meaning for the term "application" is a unit of software with which a user interacts in order to perform some business task.

In the context of API Management, an "application" is the unit of API consumption.  In other words, if you, as the developer of some external business application wish to consume the API Proxies exposed through the various Products, you must declare your usage of those Products by the creation of this data object known as an "application".

In other words, in API Management, an "application" represents one user's subscription to a specific set of Products.  If a different user wishes to subscribe to the same set of Products, then they must create their own application.  This is how API Management is then able to manage the usage of APIs and keep track of things like quotas.

As we've already seen with API Proxies and Products, there is a many-to-many relationship between Products and Applications.  One Application can contain multiple Products, and one Product can be consumed through multiple Applications.

Two Different Perspectives: Development and Consumption

As was described above, there are two different tools used for the development and consumption of API Proxies.

If you are the developer of an API Proxy, then you use the API Portal and are concerned with creating the data objects outlined below.

However, if you are the developer of some front end application such as an iPad app, then you will be looking at the API Proxies from the perspective of a consumer, not a developer; therefore, you will use the Dev Portal and be concerned with the data objects outlined below.

In the next document, we will look in overview at the development of each of these data objects: Systems, API Proxies, Products and Applications

Chris W

I am wondering if Success Factors integrates with 3rd party applications that support Learning Technology Interoperability (LTI). We are currently using Success Factors as our performance management/learning management tool, and are thinking about adopting Adobe Connect to host our online classes. We would like the two programs to work together, and I have been told by Adobe that this is only possible if Success Factors supports LTI. Please let me know if this is possible. Thanks in advance for your help.

Hello,

We currently use SAP for performance/learning management and are considering adding Adobe Connect to facilitate our distance learning. We would like the two to integrate and communicate with each other. Adobe has informed me that if SAP utilizes LTI (learning tools inoperability) then it should work. SAP customer service was unable to confirm this and so I am hoping someone in this group might know. Thank you in advance. 

Hi all, just a quick question, does the SAP API Management implements any queuing mechanism, i.e. if an end-point is offline there is a retry mechanism?

Kind Regards

Silvio Canha

Recap of Part 2

In Part 2 of this Introduction to SAP API Management, we looked in overview at the sequence of steps needed to:

1. Create a System
2. Expose backend services from that system as API Proxies
3. Group one or more API Proxies together into a Product (remember, the Product represents the unit of API Exposure)
4. Subscribe one or more Products by creating an Application (remember, an Application represents the unit of API Consumption)

Now we will take something of a sideways steps and do some preparatory work in order to allow API Proxies to be consumed through the SAP Web IDE.  The steps described here are one-off configuration steps and once completed, do not need to be repeated.

Meanwhile, back in the HCP Cockpit...

In order for the Web IDE to be able to consume API Proxies created in API Management, we must set up two HCP Destinations.  One destination will be used by Web IDE at design time, and the other will be used at runtime.

So log on to your HCP Account and select Destinations from the menu on the left.

The first destination that needs to be created will be the one used by Web IDE at design time, and will connect to your API Management Dev Portal.  In other words, the Web IDE design time tools need to be able to connect to the same Portal used when consume an API Proxy.

Alternatively, this destination could connect Web IDE to some public API service such as the SAP API Hub.  In this example however, we will concentrate on connecting Web IDE to your own API Management Dev Portal through which your API Proxies are exposed for consumption.

The name you give to this Destination is not particularly important, but whatever name you choose should reflect the fact that it connects Web IDE's design time tools with your API Management (APIM) Dev Portal.

In this example, I'll call the destination Web_IDE_to_APIM_Designtime; however you are free to choose any name you consider suitable.

At this point, you might be thinking "if the actual name of the Destination is not important, then how is Web IDE able to identify the correct destination?"

This identification is done by means of the additional properties assigned to the Destination; but before we get to that detail, we must obtain the other property values needed for this destination.

HCP Destination for use by Web IDE at design time

The design time HCP destination needs the following property values:

If we were to stop at this point, we would have a perfectly valid HCP Destination, but it would be of no use whatsoever, because we have not added the vital Additional Properties:

Now add the following two properties:

As you have probably worked out, the first parameter makes this HCP destination visible to Web IDE, and the second tells Web IDE that this particular system is a source of API Proxies that can be used by the template wizards.

HCP Destination for use by Web IDE Applications at runtime

As with the design time portal, you are free to choose any name you like for this destination.  In this case, we will use the name APIM_Endpoint_Trial since this the communication endpoint for external apps when connection API Management running on an HCP Trial account.  Again, choose whatever name make sense for you situation.

To find the URL of this particular destination requires a little explanation.  In this case, we are not creating an HCP destination dedicated to invoking a single API Proxy; instead, we want the URL that gives us access to all our published API Proxies.  In our case, this is simply the hostname prefix used to access any one of our API Proxies.

To find this value, connect to your API Management API Portal and select Test from the hamburger menu in the top left.  Select any Proxy name from the left side menu and then copy the protocol, hostname and port number from URL shown near the top of the screen.

Exactly as described for the design time HCP destination, if we were to stop at this point, this HCP Destination would be valid, but useless as far as Web IDE is concerned.

We need to add the following additional properties:

Some Interesting Background

When Web IDE is started, one of the configuration files your browser receives is simply called listDestinations.  This is a JSON file that contains the names of all HCP destination where the WebIDEEnabled property is set to true.  For example, it might look something like this:

So based on the contents of this static file, we can understand how Web IDE knows which destinations it can look at in order to find API Management proxies.

However, we must also understand that this file is static!  This means that if you create a new HCP destination whilst Web IDE is running, you must restart Web IDE in order for it to receive a new copy of this listDestinations file.

Now that this preparatory configuration has been done, in the next document, we can look at how to consume an API Proxy using the template wizard in Web IDE.  As was mentioned in Part 2, whenever you create an Application, you are subscribing to one or more Products.  Every Application is assigned a randomly generated security token known as an "Application Key" or "API Key".

Whenever you wish to call a backend service exposed as an API Proxy, you must (almost) always provide this security token as part of the HTTP request.  I say almost always have to supply it because API Management imposes no technical requirement for an API Proxy to check for the presence of the API Key in the request.  However, it is usual for such a check to be made.  One situation in which a check for an API Key is not needed, is if you were to offer a free service to the public such as sunset and sunrise times for a given GPS location etc.

So next, let's now look at how this API Key value can be supplied when invoking an API Proxy.

Part 4 - Supplying the API Key at Runtime

Chris W

Recap of Part 1

In part 1 of this series, we looked at three things:

1. The origins of why an API Management solution is needed in the first place
2. How SAP has chosen to implement their solution
3. The 4 basic data object that act as the building blocks from which API is exposed to the outside world.

In this document, we will build on that knowledge and look in overview at the tools used to create and maintain these data     objects.

In order to help us keep track of where we are in the big scheme of things, I will use the diagram on the right as a roadmap, in which we will start at the bottom, and work our way up using first the API Portal for proxy development, then switch to the API Portal for proxy consumption.

Creating a System

At this point in the development process, we are acting as a Proxy Developer, therefore we must use the API Portal.

From the hamburger menu in the top left, select the Configure option.

In the bottom right corner, there is a Create menu. Click here to create your new System.

All we're doing here is creating a logical name by which a backend system can be identified within the API Management framework.

Another important point to understand here is that perhaps surprisingly, the creation of a System is not mandatory.

If you are wanting to access a backend system that exposes its functionality through OData services, this it is useful to create a System.

The creation of Systems is also useful for reusability. Once you have created a System, you can access any service from that backend system using nothing more than the System name created here, and the relative path to the particular service of interest.

When creating a system, you should supply three different blocks of information:

1. The connection information to the actual server. This includes the host name, port number and an optional path prefix.  For instance, if you are creating a System to represent an ABAP backend, then you will probably want to add the path prefix of "/sap/opu/odata" in order to restrict access to only the resources exposed from this path.
2. Authentication. If supplied, the hard coded userid and password will be used by the API Portal's design time tools when you come to consume services from this backend system.
3. Lastly, the Catalog URL (if supplied), will allow the API Management design-time tools to invoke the special CATALOGSERVICE OData service. This is a special OData service provided as standard with all ABAP systems, and its purpose is to list all the OData services exposed by this ABAP system. Within this service is an OData collection called ServiceCollection that lists all the available OData services.
   
   As was mentioned above, this configuration is optional; however, if you do not supply it, then when we arrive at the next step of creating an API Proxy that points to an OData service, the design time tools will not be able to query the backend system and present you will a list of available services.  In this case, you will need to know the full path name to the OData service yourself.

Creating an API Proxy

We now come to the part where all the work takes place. Creating API Proxies is the heart of API Management, and this is where you will spend the bulk of your time.

From the hamburger menu in the top left, select Manage.

A new API Proxy is created by clicking on the Create menu in the bottom right corner.

At this point, you have the option of either creating an API from scratch, or importing one.

Should you wish to import an API, you must first have exported the API from some other SAP API Management system. (An exported API consists of a ZIP file within which the various parts of the API have been dumped as XML files).

Assuming you want to create an API Proxy from scratch, you will need to provide all the initial details yourself.

Pointing to the Backend System

As was mentioned above, when you create an API Proxy, you can specify that you want to consume a service exposed by some backend system for which you have already created a System. The name of the System is then chosen from the drop-down list called "API Provider". However, this is not the only way of doing it. Alternatively, you can leave the API Provider entry set to NONE, and then enter the full URL to the service. This second approach is sometimes used if you wish to consume something like a public Web Service (SOAP).

Either way, using the information supplied in both the API Provider and URL fields, the tool for creating the API must be able to fully identify the required service.

Also note that if you select a System from the API Provider drop-down list, then a new button will appear to the right of the drop-down called "Discover".

Remember what was mentioned above about the Catalog URL? Well, here's where that configuration is used. If you supplied a Catalog URL when you created the System (or API Provider), then you will now be able to click on the Discover button and see a list of all the OData services available in that System.

Alternatively, if you did not supply a Catalog URL, then the Discover button will not do anything.

It's important to understand that this "Discover" feature is designed only to work against backend systems that provide a specific CatalogService OData service.

Naming the API Proxy

Once the URL of the backend service has been defined, you can now give the API proxy a name and a description.

The API Base Path field is important to understand. This field holds the URL used when the API Proxy is consumed by the external user.

This URL must be unique across all the API Proxies you create. That said, if you wish to create two different API Proxies that both point to the same backend service, then this is perfectly possible as long as you use two different values for the API Base Path.

The point at which we now find ourselves is that although we have created an API Proxy, this proxy is quite passive, providing no additional functionality when invoked. Nonetheless, we will stop here in the discussion of creating API Proxies for two reasons: the first being that this current document is just an overview of the available API Management tools, and the second being that the development of an API Proxy is large and detailed topic that must be discussed     individually.  Such as discussion will follow in due course.

Creating a Product

Now that we have an API Proxy (albeit one that adds no value), we can now add this Proxy to Product in order to expose it to the outside world.

As was said in the first document, the Product is the unit of API Exposure.  In other words, if you want your Proxy to be exposed to the outside world, you must first add it to this data object called a Product.  Although there are no hard and fast rules here, it is typical to create a Product that contains all the API Proxies related to one type of business task or process.

By selecting "Product" from the tab menu in the "Manage" screen, you can add or remove API Proxies from the Product.

Remember that a Product can contain many API Proxies, and that the same API Proxy can belong to many Products.

Since we have added the API Proxy to the Product, this API Proxy is now visible to the outside world. We have now finished all the tasks required of an API Proxy developer, and we must now change hats and look at these proxies from the perspective of a frontend app developer.

Discovering the Available API Proxies

Now that we have switched personas from an API Proxy Developer to a frontend app developer, we are no longer interested so much in the internal workings of the API Proxy, but rather being able to consume that proxy from within the larger scope of an external business application.

In addition to switching personas, we must also switch API Management tools.  Up till now, we have done all the work in the API Portal, but now we need to switch to the Dev Portal.  Return to the API Management service via your HCP account cockpit and select "SAP API Management Dev Portal".

You are now taken to a screen that looks similar to the API Portal, but here you have no ability to create or change API Proxies.

From the hamburger menu, select the Discover option and you will now see a list of all the available Products. By selecting a Product, you can see a list of all the API Proxies it contains, which in turn, takes you to a test tool for each service exposed by the API Proxy.

Consuming API Proxies

When you have found the Product or Products you want, select the Consume option from the hamburger menu. Now by clicking on the Create option in the bottom right of the screen, you can create your own Application.

Remember that the term "Application" is not being used in the normal sense of a unit of software with which a user interacts     in order to perform some business task. Instead here, the term Application means the set of Products to which you have     subscribed for the purposes of building some client application. So, in one sense the API Management term "Application"     does potentially refer to the unit of business software more traditionally referred to as an application, but even if this is true, the reference is only indirect.

Once you have added as many products to your Application as you require and saved it, you will be given an Application     Key. This is a randomly generated string that serves to uniquely identify your specific usage of the selected Products.

When you create an Application, you are creating a unit of API Subscription. This unit of subscription is then identified by its Application Key, and this very must typically be supplied each time a call to an API Proxy is made.

In the next document, we will take a look at creating the necessary HCP Destinations in order for you to be able to consume API Management Proxies using the SAP Web IDE.

Part 3 - Preparing HCP Destinations for use by SAP Web IDE

Chris W

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?