- SAP Managed Tags:
This blog is motivated by an interview that I gave to Jon Reed, which resulted in the following blog: Evaluating SAP’s Apigee API partnership. Questions regarding SAP Gateway vs Integration Gateway vs SAP API Management have been raised in the forum of that blog, as well as by customers and partners during the last couple of weeks. Therefore I'd like to take the opportunity to address them and other related topics here.
In order to structure this blog I created the following figure to point out the four layers that I see in a "composite" App or API centric world. In addition I have laid out how SAP's solutions map to this layers.
As few disclaimers regarding this figure:
- This is a labs preview and therefore shows items from the product roadmap as well as existing implementation.
- In order to keep it simple I'm deliberately not showing a few things, like:
- Tools for app developers, design time tools for API developers and tools for app/API administrators (be assured they exist however)
- Other SAP applications (e.g. SFSF) that already come with OData/SOAP services and therefore don't necessarily need an API implementation layer
- Generic containers (e.g. node.js) on the API Run Time layer which could be used to build an API from scratch (again, be assured that we are looking into that)
- I'm subsuming the databases which contain the actual data under the applications in the API Runtime layer
- And last, but not least, I'm pretty sure there are many ways to draw this picture differently and maybe even more clearly, but my focus here is to visualize things in a manner which a) is app/API centric and b) answers the SAP Gateway vs Integration Gateway vs SAP API Management question.
I think the top and bottom layer are fairly self explanatory so I'll not spend too much time elaborating on them. I will mention though, that whenever one wants to expose OData/REST via SAP Gateway or Integration Gateway there is a need to install some ABAP component for the back-end enablement (for more information please read the following blog: SAP Gateway Deployment Options in a Nutshell).
... and now on to the two crucial layers.
API Implementation (optional):
With the launch of SAP Gateway in 2011, SAP took the first step toward providing tools and capabilities that expose SAP data using standards-based REST and OData protocols for all business functions across SAP Business Suite and SAP Business Warehouse (SAP BW).
As many of you already know, SAP Gateway since then has been widely adopted by SAP customers, partners as well as other SAP solutions - most prominently SAP Fiori. What maybe not so many of you know is, that before SAP Gateway was implemented, SAP developed "Concept Gateway", a set of architecture guidelines and qualities outlining how to build a "Gateway" to SAP data. "Concept Gateway" was carefully developed to follow the principles of timeless software. The reason for creating this was that SAP wanted to make sure that any SAP data can be exposed in a uniform way irrespective of the underlying data source, so that it can be consumed by any UI technology. In addition, SAP decided to expose its data in OData format based on REST/JSON.
Now, why am I bringing this up? Because it is important to understand that Integration Gateway has been built following the principles of "Concept Gateway". This means that it follows the exact same guidelines and contains the same qualities as SAP Gateway. The main differences in Integration Gateway are:
- It is built in Java not ABAP
- It is not a product but a reusable software component, currently shipped only with SMP 3.0, but might be shipped with other products in future
- It allows for service federation, meaning one can compose services based on other OData/Rest or SOAP services as well as JPA or JDBC.
One of the key qualities of "Concept Gateway" is the Service Catalog. As the name indicates it is the catalog where one puts all services created. This means that services being created with SAP Gateway can be exposed via Integration Gateway or can be reused and federated to bigger services by combining them with data from a non-SAP system for example. This also works the other way around, in that it is possible to expose services created in Integration Gateway via SAP Gateway (as long as the federation capabilities are not used of course).
Last, but not least: Why did I put the word "optional" in this layer? Because there are several applications (e.g. SFSF) which are already exposing OData or SOAP services. If this is the case there is no need to implement APIs they are already part of the solution and no gateway is needed. In this case API proxies can be generated right away (see next section).
API Management and Provisioning:
Once a service has been implemented, of course it can be consumed right away if a developer knows the URL. Still, this is not the goal one should have.
Defining and implementing a service is clearly a huge investment, and while businesses, which have started building services with SAP Gateway, can be assured that SAP put a lot of effort in making sure that this investment is secured, what about afterwards? One critical need is the ability to see in real-time what is happening with the service, and if necessary modify access behaviors via governance tools.
SAP API Management can be seen to be a blanket layer between the consumption layer, and the generation layer, mediating communication between these two layers. An API Proxy is created for each service, containing embedded control and security policies in the API Proxy. These proxies can be consumed directly, or combined in to a Product, and exposed via the “Developer Portal” section of the API Management platform, to be consumed by whatever final App is desired. This then allows the SAP API Management layer to:
- Monitor all traffic bi-directionally between Apps and Services, generating useful near real-time analytics to maintain a clear picture of system status and needs.
- Grant the ability to monetize services through fine-grain access controls such as quota policies, and specific API Keys assigned to the developer/customer/user.
- Browse the Service Catalog from “Concept Gateway” to quickly determine what is available and generate Apps desired from any existing service.
- Allow for on-the-fly governance over system access. Policy control is updated in real-time directly from the API Proxy, without disturbing the backend services.
This complements the SAP Gateway and Integration Gateways functionality of exposing back-end data. But it does not require businesses to acquire SAP Gateway or Integration gateway if they already have existing SOAP or REST services created. You can see from the image I created that these existing services can also utilize all the same functionality I described for SAP Gateway and Integration Gateway.
I hope that with this it has become somewhat clearer how these three technologies are separate, but complimentary in their functions.
If you happen to be at TechEd&&d-code in Vegas next week and want to learn more please drop by our pod or to one of hour sessions: Sneak Peek into the World of SAP API Management and Gateway at TechEd && d-code in Vegas.
Thanks,
Joav
______________________________
Disclaimer
This blog outlines our general product direction and should not be relied on in making a purchase decision. This blog is not subject to your license agreement or any other agreement with SAP. SAP has no obligation to pursue any course of business outlined in this blog or to develop or release any functionality mentioned in this blog. This blog and SAP's strategy and blog future developments are subject to change and may be changed by SAP at any time for any reason without notice. This document is provided without a warranty of any kind, either express or implied, including but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. SAP assumes no responsibility for errors or omissions in this blog, except if such damages were caused by SAP intentionally or grossly negligent.
3 Comments
