Study APIC
Study APIC
cover
Front cover
Notebook
Create, Secure, and Publish APIs with IBM
API Connect 10
Course code WD515 / ZD515 ERC 2.0
IBM Training
Individually Licensed to Kapil Jain
August 2021 edition
Notices
This information was developed for products and services offered in the US.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM
representative for information on the products and services currently available in your area. Any reference to an IBM product, program,
or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent
product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's
responsibility to evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this
document does not grant you any license to these patents. You can send license inquiries, in writing, to:
IBM Director of Licensing
IBM Corporation
North Castle Drive, MD-NC119
Armonk, NY 10504-1785
United States of America
INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND,
EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some jurisdictions do not allow disclaimer of express or implied
warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein;
these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s)
and/or the program(s) described in this publication at any time without notice.
Any references in this information to non-IBM websites are provided for convenience only and do not in any manner serve as an
endorsement of those websites. The materials at those websites are not part of the materials for this IBM product and use of those
websites is at your own risk.
IBM may use or distribute any of the information you provide in any way it believes appropriate without incurring any obligation to you.
Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other
publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any
other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of
those products.
This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible,
the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to
actual people or business enterprises is entirely coincidental.
Trademarks
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corp., registered in many
jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM
trademarks is available on the web at “Copyright and trademark information” at www.ibm.com/legal/copytrade.shtml.
© Copyright International Business Machines Corporation 2020, 2021.
This document may not be reproduced in whole or in part without the prior written permission of IBM.
US Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
TOC
Contents
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Agenda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii
TOC Example three (3 of 3): Map multiple API calls into a response . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-26
Example four (1 of 2): Transform SOAP to REST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-27
Example four (2 of 2): What is the message payload? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-28
Example five: Validate properties in an HTTP message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-29
Example six: Store message payload in API analytics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-30
Example seven: Redact specific fields from the response body to obfuscate sensitive data . . . . . . 5-32
5.4. Changing the version of an API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-33
Changing the version of an API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-34
Change an API version (1 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-35
Change an API version (2 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-36
Change an API version (3 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-37
Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-38
Review questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-39
Review answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-40
Exercise: Assembling message processing policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-41
Exercise objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-42
Unit 13. Subscribing and testing APIs in the Developer Portal . . . . . . . . . . . . . . . . . . . . . . . . . . 13-1
Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-2
Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-3
13.1. Role of the application developer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-4
Role of the application developer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-5
Role of application developers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-6
Application developer versus API developer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-7
Self-registration on the Developer Portal (1 of 5) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-8
Self-registration on the Developer Portal (2 of 5) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-9
Self-registration on the Developer Portal (3 of 5) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-10
Self-registration on the Developer Portal (4 of 5) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-11
Self-registration on the Developer Portal (5 of 5) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-12
13.2. Creating an application and subscription in the Developer Portal . . . . . . . . . . . . . . . . . . . . . . . . . 13-13
Creating an application and subscription in the Developer Portal . . . . . . . . . . . . . . . . . . . . . . . . . . 13-14
Creating an application and subscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-15
Create an application in Developer Portal (1 of 4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-16
Create an application in Developer Portal (2 of 4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-17
Create an application in Developer Portal (3 of 4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-18
Create an application in Developer Portal (4 of 4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-19
Subscribe an application to a product plan (1 of 6) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-20
Subscribe an application to a product plan (2 of 6) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-21
Subscribe an application to a product plan (3 of 6) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-22
Subscribe an application to a product plan (4 of 6) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-23
Subscribe an application to a product plan (5 of 6) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-24
Subscribe an application to a product plan (6 of 6) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-25
Approval requests (1 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-26
Approval requests (2 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-27
Approval requests (3 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-28
13.3. Testing an API in the Developer Portal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-29
Testing an API in the Developer Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-30
Testing an API in the Developer Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-31
Testing an API in the Developer Portal (1 of 6) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-32
Testing an API in the Developer Portal (2 of 6) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-33
Testing an API in the Developer Portal (3 of 6) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-34
Testing an API in the Developer Portal (4 of 6) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-35
Testing an API in the Developer Portal (5 of 6) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-36
Testing an API in the Developer Portal (6 of 6) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-37
Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-38
Review questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-39
Review answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-40
Exercise: Subscribing and testing APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-41
Exercise objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-42
TMK
Trademarks
The reader should recognize that the following terms, which appear in the content of this training
document, are official trademarks of IBM or other companies:
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International
Business Machines Corp., registered in many jurisdictions worldwide.
The following are trademarks of International Business Machines Corporation, registered in many
jurisdictions worldwide:
Bluemix® Cloudant® DataPower®
DB™ Express® IBM API Connect™
IBM Bluemix™ IMS™ Notes®
Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both.
Windows is a trademark of Microsoft Corporation in the United States, other countries, or both.
Java™ and all Java-based trademarks and logos are trademarks or registered trademarks of
Oracle and/or its affiliates.
UNIX is a registered trademark of The Open Group in the United States and other countries.
LoopBack® and StrongLoop® are trademarks or registered trademarks of StrongLoop, Inc., an IBM
Company.
Social® is a trademark or registered trademark of TWC Product and Technology, LLC, an IBM
Company.
Other product and service names might be trademarks of IBM or other companies.
pref
Course description
Create, Secure, and Publish APIs with IBM API Connect 10
Duration: 5 days
Purpose
This course teaches you how to configure a newly built API Connect V10 environment. You are
taught how to configure a catalog with the gateway, portal, and analytics services and set up the
environment for API development. You then define API interfaces according to the OpenAPI
specification. You build SOAP and REST based APIs along with a GraphQL API. You assemble
message processing policies and define client authorization schemes, such as OAuth 2.0, in the
API definition. You verify the proper sequencing of policies in the assembly tester and further test
your APIs in the new Test tab and Local Test Environment. After building and testing your APIs,
you publish them and make them available on the Developer Portal. You manage all aspects of the
provider organization in the API Manager user interface to create, publish, version, and retire API
artifacts such as products, plans and APIs themselves. You also learn how to manage consumer
organizations who use the APIs that are made available on the Developer Portal. You learn how to
add members to the consumer organization that provides access to the APIs on the Developer
Portal. You learn how the layout of the Developer Portal can be customized. Finally, you call the
APIs on the secure gateway and you view the graphs and metrics of API usage.
Audience
This course is designed for API developers: software developers who define and implement API
operations
Prerequisites
• Basic understanding of web services and protocols
• Basic understanding of application programming
• Conceptual knowledge of APIs
• Basic understanding of Red Hat Linux
Objectives
• Configure services in Cloud Manager for an on-premises installation of API Connect
• Create a catalog and Developer Portal
• Create consumer and provider organizations
• Create, test, and publish SOAP, REST, and GraphQL APIs
• Create message processing policies that transform API requests and responses
Contents
• Unit 1: Introduction to IBM API Connect V10
• Unit 2: Managing catalogs and organizations
• Unit 3: Defining APIs in API Manager
• Unit 4: Defining a REST API in API Manager
• Unit 5: Assembling message processing
• Unit 6: Declaring client authorization requirements
• Unit 7: Creating an OAuth 2.0 provider
• Unit 8: Testing and debugging APIs
• Unit 9: Creating a GraphQL API and testing with the Test tab
• Unit 10: Testing an API with the Local Test Environment
• Unit 11: Publishing and managing products and APIs
• Unit 12: The product lifecycle
• Unit 13: Subscribing and testing APIs in the Developer Portal
• Unit 14: API Analytics
• Unit 15: Customizing the Developer Portal
pref
Agenda
Note
The following unit and exercise durations are estimates, and might not reflect every class
experience.
Day 1
(00:15) Course introduction
(01:30) Unit 1. Introduction to IBM API Connect V10
(01:00) Exercise 1. Reviewing the API Connect development and runtime environments
(01:00) Unit 2. Managing catalogs and organizations
(02:00) Exercise 2. Managing catalogs and consumer organizations
(01:30) Unit 3. Defining APIs in API Manager
(01:30) Exercise 3. Defining an API that calls an existing SOAP service
Day 2
(01:00) Unit 4. Defining a REST API in API Manager
(01:30) Exercise 4. Defining a REST API from a target service
(01:00) Unit 5. Assembling message processing policies
(02:30) Exercise 5. Assembling message processing policies
(01:00) Unit 6. Declaring client authorization requirements
Day 3
(01:00) Unit 7. Creating an OAuth 2.0 provider
(01:30) Exercise 6. Implementing OAuth 2.0 security
(00:30) Unit 8. Testing and debugging APIs
(01:00) Exercise 7. Introduction to the Test tab
(01:00) Unit 9. Creating and testing a GraphQL API
Day 4
(03:00) Exercise 8. Creating and testing a GraphQL API
(01:00) Unit 10. Testing an API in the Local Test Environment
(02:00) Exercise 9. Testing an API in the Local Test Environment
(00:45) Unit 11. Publishing and managing products and APIs
(00:45) Exercise 10. Define and publish an API product
(02:00) Unit 12. The product lifecycle
pref
Day 5
(00:45) Exercise 12. Subscribing and testing APIs in the Developer Portal
(01:15) Exercise 11. Managing and approving API Products
(01:00) Unit 13. Subscribing and testing APIs in the Developer Portal
(01:00) Unit 14. API Analytics
(01:15) Exercise 13. Calling an API on the gateway and monitoring API usage
(01:00) Unit 15. Customizing the Developer Portal
(01:30) Exercise 14. Customizing the Developer Portal
Uempty
Overview
This unit explains the scope and purpose of IBM API Connect V10 from the perspective of an API
developer and cloud administrator. You review the key capabilities of API Connect. You examine
the nature of an on-premises cloud and how the cloud is configured in the API Cloud Manager user
interface. You review the different gateway types for securing and managing APIs. You also learn
how to manage security, configure the cloud topology, register services and set up organizations
and catalogs for an API Connect installation.
Uempty
• Describe how API Connect manages APIs through the entire API lifecycle
• Describe the use of the Cloud Manager user interface to administer the cloud topology and
resources
• Describe the different gateway types for securing and managing APIs
Uempty
Uempty
This slide displays acronyms that are used throughout this unit. It is important that you
understand these acronyms and the key concepts that are discussed in the following slides.
Uempty
Uempty
Uempty
1.1. Overview of APIs and API Management
Uempty
Overview
w off APIss
and
d APII
Management
• An API is a public persona for a company or a product, where the API exposes business
capabilities and services. APIs form a bridge for interactions between services, such as
mainframe and databases and customer-facing services. APIs enable organizations to share
information with external developers, business associates, and other teams within the same
organization.
• APIs allow you to expose some functions of a program or service in a managed and secure
environment. API providers can share portions of their code with developers but do not have
to release everything for new applications and services to be developed. APIs from different
providers are be combined by developers to create new applications as well.
• A high-quality API facilitates the development of applications by allowing different
functionalities to be created independently while offering a complete set of capabilities for
development.
Uempty
What is an API?
• What is an API?
An application programming interface is
WebApp
a collection of remote service operations that you Appliance Mobile
Device
make available to API consumers
In IBM API Connect, the API is a collection of Tablet
• The term “application programming interface (API)” is used in many areas of software
development. In the context of IBM API Connect, an API is a collection of service operations
that you make available on a network.
• In IBM API Connect, the API is a collection of REST service operations.
• Representation State Transfer (REST) is an architectural style that uses a simple set of
HTTP-based operations, such as GET, POST, PUT, and DELETE.
• API Connect also supports calling XML-based web services, which are another architectural
style.
• The clients that call these API operations are known as API consumers. The organization that
makes a set of services available is the API provider.
• The API gateway is between the API consumer and the API provider. This gateway server or
network appliance authorizes and regulates requests to the posted API services. It enforces a
set of rules, or services policies, that define how API consumers can access the API.
Uempty
Classification of APIs
Partner
Private
Public
Uempty
API Examples
Partner
Private
Public
Uempty
Uempty
Once your APIs are externalized, you can explore new ways to use them to help drive revenue. In
addition to making it easy to implement a simple tiered monthly access model, API management
can assist with other revenue-driving models, including models based on transaction fees, zero
fees, and developer payments, as well as indirect revenue drivers like partnerships.
Uempty
The speed To reach new markets Typically, domains refer to In many industries,
driver focuses and obtain new interactions across devices are used
on allowing the customers, you can make multiple lines of business. along with APIs to
business and IT APIs available to other Lines of business can provide new and
organization to enterprises, such as largely work innovative
run at different partners who, through independently but benefit solutions.
speeds. their interaction with by sharing data or the
clients, can generate occasional need to share
additional revenue and data.
new customers for your
enterprise.
Introduction to IBM API Connect 10 © Copyright IBM Corporation 2020, 2021
Uempty
1.2. IBM API Connect V10 overview
Uempty
IBM
M APII Connectt 10
0
overview
Uempty
• IBM API Connect is an integrated API management offering, with capabilities and tooling for
all phases of the API lifecycle. Key steps of the API lifecycle include create, secure, manage,
socialize, and analyze. IBM API Connect Version 10 delivers enhanced capabilities for the
market-leading IBM API management solution. In addition to the ability to deploy in complex,
multi-cloud topologies, this version provides enhanced experiences for developers and cloud
administrators in your organization.
• IBM API Connect has two main focuses: the first is providing best in class API Management
tooling, and the second is having a cloud native solution. This allows users to create, manage,
and secure applications that are deployed across various on-premises and cloud
environments.
Uempty
API Connect uses IBM API manager is an Share your APIs with API analytics is built
DataPower Gateway intuitive user interface application on the Kibana V5.5.1
to provide the that lets you manage developers through a open source analytics
gateway service. IBM APIs for internal use, company-branded and visualization
API Connect provides or to externally portal. Developers can platform, which is
two gateway types, monetize and manage discover and designed to work with
DataPower API services as REST or subscribe to APIs as the Elasticsearch real-
Gateway and SOAP APIs. well as register and time distributed
DataPower Gateway deploy associated search and Analytics
(v5 compatible). applications. Engine.
API Connect has four major components: Gateway, API Manager, Developer Portal, and Analytics.
These four components can be deployed in various hybrid and multi-cloud topologies. The API
Connect components provide a unified user experience across the API lifecycle. Changes in one
stage of the API lifecycle are automatically reflected in the other components of API Connect.
Gateway
• Gateways enforce runtime policies to secure and control API traffic, provide the endpoints
that expose APIs to the calling applications, and provide assembly functions that enable APIs
to integrate with various endpoints. They also log and report all API interactions to the API
Connect Analytics Engine, for real-time and historical analytics and reporting. The following
Gateway is available for use in API Connect: The DataPower Gateway is an enterprise API
Gateway that is built for departments and cross-enterprise usage. This Gateway provides a
comprehensive set of API policies for security, traffic management, mediation, acceleration,
and non-HTTP protocol support. The DataPower Gateway is deployed on a virtual or physical
DataPower appliance and supports multiple catalogs per instance or cluster. The DataPower
Gateway can handle enterprise-level complex integration and supports containers for flexible
runtime management.
• Your API Connect offering (or edition) can include a virtual DataPower Gateway, and support
for a physical DataPower Gateway is also available, subject to certain conditions.
API Manager
• The API Manager provides a user interface that facilitates promotion and tracking of APIs that
are packaged within Products and Plans. API providers can move the Products through their
lifecycle and manage the availability and visibility of APIs and Plans.
• Catalogs and Spaces are created in the API Manager to act as staging targets through which
APIs, Plans, and Products are published to consumer organizations. API providers can stage
Uempty
their Products to catalogs or Spaces, and then publish them to make the APIs in those
Products visible on a Developer Portal for external discovery.
• To control access to the available API management functions, users in the provider
organization can be set up in the API Manager UI with assigned roles and permissions. API
providers can also use the UI to manage the consumer organizations that sign up to access
their APIs and Plans. Additionally, developer communities can be created as a way of grouping
a collection of consumer organizations to whom a particular set of Products and Plans can be
made available.
• The API Manager UI also includes functions to manage the security of the API environment
and provides access to analytics information about API invocation metrics within
customizable dashboard views.
Developer Portal
• The Developer Portal provides a customizable self-service web-based portal to application
developers to explore, discover, and subscribe to APIs.
• When API providers publish APIs in the API Manager, those APIs are exposed in the Developer
Portal for discovery and usage by application developers in consumer organizations.
Application developers can access the Developer Portal UI to register their applications,
discover APIs, use the required APIs in their applications (with access approval where
necessary), and subsequently deploy those applications.
• The Developer Portal provides additional features, such as forums, blogs, comments, and
ratings, for socialization and collaboration. API consumers can also view analytics information
about the APIs that are used by an application or used within a consumer organization.
Analytics
• API Connect provides the capability to filter, sort, and aggregate your API event data. This
data is then presented within correlated charts, tables, and maps, to help you manage service
levels, set quotas, establish controls, set up security policies, manage communities, and
analyze trends. API analytics is built on the Kibana V5.5.1 open source analytics and
visualization platform, which is designed to work with the Elasticsearch real-time distributed
search and Analytics Engine.
Important
All Management appliances in an API Connect cloud must run at the same firmware level as each
other. Gateway appliances can run on different firmware levels to each other, but it is
recommended that all of the Gateway appliances that are run on the same level as each other.
Uempty
Create, assemble,
stage, publish, retire,
API Manager
archive, and version
APIs
Uempty
You configure and manage the servers that comprise your IBM API Connect on-premises cloud by
using the Cloud Manager user interface.
• The first time that you access the Cloud Manager user interface, you are prompted to change
the cloud administrator password and address. The initial password change is already done
for you in the course exercises.
• The default user registry for Cloud Manager is an API Connect internal registry.
• This registry holds the administrator account and any other users that you define to manage
the on-premises cloud.
These Cloud Manager administration tasks are already done on the student image where the
exercises are run.
You can use the Cloud Manager to define the API Connect cloud with these functions:
• Create Provider organizations and invite a user to serve as the owner
• Create and manage user roles and role defaults
• Create availability zones for services
• Register the relevant gateway, analytics, and portal services within availability zones to
securely create, publish, and track APIs.
• Associate an analytics service with a gateway to enable reports for API Events
• Configure resources for user authentication, TLS security, and OAuth providers and make the
resources visible to all or selected provider organizations
• Connect to an existing SMTP mail server and edit templates for system-generated emails
• Set the default gateway service for catalogs
Uempty
You get to perform some of these functions and review the configuration for the on-premises
cloud in the first exercise.
More about consumer and provider organizations is covered in the next unit.
Uempty
• The API Connect infrastructure is either deployed and managed by an IBM team in an IBM
Cloud environment, or it is deployed and managed by the customers in their own dedicated
environment or third-party cloud. There is also the option for having hybrid scenarios, for
example, with the API Connect Reserved Instance Offering, users are able to have their API
Manager and Developer Portal running in the IBM Cloud, but then place remote gateways next
to their back-end services.
• For the exercises in this class, IBM API Connect was deployed to the Kubernetes runtime
environment. The API Connect product is fully installed at the start of the class and students
only need to configure some of the settings in Cloud Manager.
Uempty
Installation considerations
• Stand-alone API Analytics component to scale
independently based on API project growth
• Zero to N portal clusters can be configured to an API Connect
deployment to align with API project growth
• Native install of API Connect toolkit for enhanced user
experience
• V5 to V10 Upgrade through automated migration scripts with
a parallel stack setup that follows modern software practices
• Single Manager Cluster per API Connect Cloud, as it is the
brain of the API Management system
• Manager can span multiple Availability Zones, giving
flexibility in deployment scenarios
• Multiple Portal, Analytics and Gateway Cluster per Cloud,
and are scoped to an Availability Zone
Introduction to IBM API Connect 10 © Copyright IBM Corporation 2020, 2021
To ensure that your IBM API Connect Cloud Functions, your cloud must have the necessary
system requirements to support the installation. During the installation process, the components
of IBM API Connect can be configured to satisfy your requirements.
Uempty
• API Connect V10 can be installed by using the Install Assist installation method.
• The Install Assist tool provides script-based installation into a Kubernetes runtime
environment.
• The Install Assist tool contains the APICUP installation utility program.
• An example of the apiconnect-up installation utility programs is shown.
• Reference the endpoints that are defined in the installation utility program when you register
the Analytics, Gateway, and Portal services in Cloud Manager.
Uempty
1.3. API lifecycle management
Uempty
APII lifecycle
e
management
Uempty
API lifecycle (1 of 2)
With IBM API Connect, you can manage APIs through the API lifecycle.
• Define and import REST or SOAP Create Run
With API Connect, you can perform all of the lifecycle steps in a single integrated offering,
removing the requirement to use multiple API management offerings to obtain the same
capability. API Connect includes the following key capabilities to cover the lifecycle of an API:
• Automated, visual, and coding options that API providers can use to create scalable APIs
• Node.js and Java support for creating microservices applications and APIs with integrated
tooling
• Integrated enterprise grade clustering, management, and security for Node.js and Java
• Lifecycle management and governance for APIs
• Set pricing details in plans to define revenue-producing subscription plans for your APIs
• Access control over APIs for both API providers and consumers by using role-based
permissions, API packaging constructs, and subscription and community management
• Customizable, self-service portals for publishing APIs for discovery and use
• Runtime enforcement of built-in and user-defined policies, and mechanisms to secure,
control, and optimize API traffic
• API usage analytics for both API providers and consumers, with runtime and historical
reporting on usage patterns and performance metrics
Uempty
API lifecycle (2 of 2)
• Create and run APIs
Develop and write the API definition and implementation and test the API. C reate Run
• Manage APIs
Create and manage self-service portals that expose the API-to-API consumers.
Monitor the set of rules and conditions that govern the API to ensure it is fulfilling its intended purpose
and adjust if necessary.
Retire and archive the API when appropriate.
• Socialize APIs
Socializing the APIs means that the APIs can be browsed and tested on the Developer Portal.
• Analyze APIs
The analytics that are provided with API Connect provide you with visibility into API usage.
Uempty
▪ Catalogs separate APIs according to their state in development or production.
▪ Spaces can be used to group APIs by development group or line of business.
▪ You review or update API versions and lifecycle events through the API Manager web
interface. You share and make your APIs available to consumers on the Developer Portal.
▪ Analyze API usage data to gain visibility and insight
• Socialize APIs
▪ You socialize your APIs by using a Developer Portal. Socializing the APIs means that the
APIs can be browsed and tested on the Developer Portal. For your application developers,
the Developer Portal provides a highly customizable website to review, subscribe, and test
APIs.
▪ The Developer Portal is based on Drupal, which is a free and open source platform that you
can use to manage the content of your website. The Developer Portal that is part of the API
Connect software includes blogs, forums, and ratings for APIs as part of the standard
offering.
▪ Developers can create client applications after they are authorized to sign on to the
Developer Portal. Developers can use a set of developer community tools to share
information. Application developers can browse available APIs, view the API details, and
test API operations. Application developers can also register applications, generate API
keys, and view analytics on API usage.
• Analyze APIs
▪ The analytics that are provided with API Connect provide you with visibility into API usage.
▪ Retrieve API analytics in a dashboard view, based on the Elastic Stack open source
project.
▪ API providers can retrieve API analytics in a customizable dashboard view that displays
visualizations that include API call volumes, error rates, and response times. Provider
analytics can be viewed from the API Manager user interface. Consumer API analytics can
be viewed from the Developer Portal.
Uempty
This slide depicts the workflow that is associated with the development, management,
socialization, and use of APIs in API Connect.
• The top portion of the workflow depicts the overall development of the API.
▪ Create & Run, Manage & Socialize
• The bottom portion depicts the runtime use of the API.
▪ Deploy, Secure APIs
• The left portion of the workflow includes users of API Connect to build and manage their APIs.
▪ API Developer
▪ API Product Manager
• The right portion of the workflow depicts Developers and users of the APIs.
▪ Application Developer
▪ Application User
Uempty
1.4. Configuring the cloud topology
Uempty
Configuring
g the
e
cloud
d topology
Uempty
The API Connect Cloud is a collection of services that make up an API Connect installation,
including configuration information and metadata.
• The API Management service maintains the runtime configuration of the API Connect Cloud:
the servers, the API, the plans, and products.
• The API Gateway secures runtime access to APIs. It enforces a set of message processing
policies against API requests.
• The API Connect Toolkit is a set of development tools that run on the API Developer’s
workstation. It can stage, publish, and test APIs in the API Connect Cloud.
• The Developer Portal is a repository for published API definitions, plans, and products.
Application developers register apps that use APIs on the portal.
• The Analytics Service (not shown) provides visibility into API usage.
Uempty
• When you install IBM API Connect, you define an on-premises cloud. To determine the
topology of appliances for this cloud, consider the number of Management and Gateway
services that are required to address your API needs.
• The Gateway provides the enforcement point for runtime policies to control API traffic.
• The Management layer embodies the capability for organizations to define, manage, expose,
and control APIs.
• At least one Management service and one Gateway service are required to create a cloud
capable of running the API Connect solution.
▪ It’s in the management layer where you create, manage, and run your APIs.
• Not shown in the figure is the consumer organization components that include the Developer
Portal.
• IBM API Connect has a range of installation and management options that range from
on-premises through hosted services that run on the public IBM Cloud architecture.
• IBM API Connect is an on-premises, single, or multi-organization, cloud-based solution.
• The on-premises solution runs in-house on the customer's network, hardware, and software
infrastructure.
• The on-premises cloud can be a combination of new and existing physical appliances and
virtual appliances or can be entirely composed of virtual appliances.
Uempty
• A default availability zone is created during installation that includes a Management service.
• An availability zone is a logical or physical set of data centers that contain one or more API
Connect services. Availability zones provide redundancy and failover in the event of network
issues.
• The management service is the control point. Within each availability zone, you can configure
extra components for scalability
Uempty
The diagram shows the infrastructure and organizations for an API Connect on-premises cloud.
1. The API Manager user interface provides authorized access to the APIs, Products, and plans
and related linked services capability for the API provider.
2. The Developer Portal provides access for consumer organizations to the Products, plans, and
APIs that are published by an API provider organization to a catalog.
3. The Cloud Manager user interface provides access for authorized users to administer the
servers and user registries that make up the cloud infrastructure.
Uempty
Stand-alone topology
• Non high-availability (HA), single instance deployment
Gateway
• Single instance of each component that is defined for a non-HA instance
deployment
• Non-HA deployment suitable for small projects and workloads
Analytics
• HA deployment is recommended for larger projects and workloads, instance
running critical applications
• One API Management cloud with Single Instance of each component
• Can be deployed on the same physical machine or can be a hybrid Manager
cloud setup instance
Portal
instance
• Depending on what you want to use your API Connect cloud for, consider the topology that
you want to implement.
• For small projects, install a single instance of each component by specifying the deployment
mode of dev in the Install Assist YAML file. The other mode option is standard.
• The stand-alone topology was used to create the environment for the course exercises.
Uempty
1.5. Registering services in Cloud Manager
Uempty
Registering
g servicess
in Cloud
d Manager
Uempty
Uempty
• In the Cloud Manager, you configure an email server from the Resources > Notifications
option.
• You must configure an email server in Cloud Manager.
• Email notifications are sent for invitations for members to join a provider organization or a
consumer organization. The member joins the organization by responding to the activation link
that is sent in the email message.
• In the example on the page, the smtp server is configured as the email server.
Uempty
• In Cloud Manager, the Cloud Settings option in the navigation menu is used to configure the
cloud environment.
• From the Endpoints option, you can view the endpoints that are configured for the cloud
environment.
Uempty
1.6. Configuring the DataPower Gateway
Uempty
Configuring
g the
e
DataPowerr Gateway
• Before registering a Gateway service in Cloud Manager, the DataPower API Connect Gateway
Service must either be installed as a subsystem in your Kubernetes cluster or enabled on the
DataPower appliance.
• This section provides a high-level overview of the DataPower Gateway service. API Connect is
built on top of IBM DataPower. Courses on DataPower are offered as part of the IBM
Automation Education. For more courses on DataPower, refer to the IBM Automation
Education Course Information Page: https://ibm-learning-skills-dev.github.io.
Uempty
Consumer Provider
organizations organizations
Business
nes
ss
partners
ners API Gateway
(IBM
( DataPower Gateway)
t )
• Business partners and application developers (left side) use the Developer Portal to access
APIs by API programmers (right side) that develop APIs in the product.
• Business partners and application developers (left side) consume APIs and are members of
consumer organizations.
• API programmers build APIs and are members of provider organizations. API programmers
socialize and productize their APIs for consumers on the Developer Portal.
Uempty
AP gateway types
IBM API Connect provides two gateway types, DataPower API Gateway and DataPower
Gateway (v5 compatible)
IBM API Connect provides two gateway types, DataPower API Gateway and DataPower Gateway
(v5 compatible).
• DataPower API Gateway:
▪ The DataPower API Gateway is a new gateway that is designed with APIs in mind, and with
the same security focus as DataPower Gateway (v5 compatible).
▪ The DataPower API Gateway was built and optimized for the cloud. Consider to use this
gateway if you are running applications in a public or private cloud and want to use them as
APIs.
• DataPower Gateway (v5 compatible):
▪ Available with IBM API Connect for a number of years
▪ Broad range of policies
▪ More flexible when custom policies are required
▪ DataPower Gateway (v5 compatible) has been available with IBM API Connect for a
number of years. This gateway provides a broad range of policies that are built into the API
Connect API assembly, including transformations, security policies, logic, and
GatewayScript.
▪ Consider that use this gateway if you need custom policies or you have complex API
assembly requirements.
• The DataPower API Gateway is used in the course exercises.
Uempty
Uempty
Uempty
• The DataPower Gateway is available in multiple form factors, including cloud, physical or
virtual appliance, Linux-based, and as a Docker image.
• All the DataPower form factors provide the same level of robustness and scalability.
• The Docker form factor has some limitations.
• The DataPower Gateway for Developers on Docker is targeted to developers that want to
perform local testing with a DataPower Gateway.
Uempty
• Describe how API Connect manages APIs through the entire API lifecycle
• Describe the use of the Cloud Manager user interface to administer the cloud topology and
resources
• Describe the different gateway types for securing and managing APIs
Uempty
Review questions
1. True or False: API Connect enables both the creation of APIs and the full lifecycle
management of APIs.
Uempty
Review questions
3. Which capability can you find in the DataPower Gateway (v5 compatible) but not the
DataPower API Gateway?
a. GatewayScript support
b. Rate limiting
c. Message transformation
d. Custom user-defined policies
Uempty
Review answers
1. True or False: API Connect enables both the creation of APIs and the full lifecycle
management of APIs.
The answer is True.
Uempty
Review answers
3. Which capability can you find in the DataPower Gateway (v5 compatible) but not the
DataPower API Gateway?
a. GatewayScript support
b. Rate limiting
c. Message transformation
d. Custom user-defined policies
The answer is D.
Uempty
Exercise: Reviewing the API Connect development and
runtime environment
Figure 1-46. Exercise: Reviewing the API Connect development and runtime environment
In this exercise, you test that you can access the Internet and that your private domain name
service is working. You review and validate that the Kubernetes runtime environment and API
Connect processes are running. Then, you sign on as the administrator to the Cloud Manager user
interface and review the cloud topology
Uempty
Uempty
Overview
Users in consumer organizations subscribe to products, plans, and APIs that you create in API
Connect. In this unit, you learn how to define a catalog and Developer Portal in API Manager. You
see where the Developer Portal user registry is defined. You then create a consumer organization
in the API Manager and review the Developer Portal user interface.
Uempty
Uempty
Uempty
2.1. Overview of organizations and catalogs
Uempty
Overview
w off
organizationss
and
d catalogs
Managing
M
Ma
Mana
ana
ag
giing
ng ccatalogs
atta
allog
gs a
an
and
nd o
or
organizations
rga
gan
niiza
attiio
onns © Copyright IBM Corporation 2020, 2021
Uempty
Production
catalog
Published plans and APIs
Consumer organization
Test
Sandbox development
catalog
Developers
Developer Portal
Users'
apps
API developers
• To become available to consumers, APIs must be staged and published to a catalog. A catalog
has an associated developer portal.
• After you create and test APIs, you publish one or more plans to expose the plan and API
resources on the Developer Portal.
Uempty
Organizations (1 of 2)
• Users can belong to one or more organizations
ƒ Users work on the APIs or applications that belong to the organization
• Provider organization
ƒ These organizations own APIs and associated plans
ƒ Defines members who can work on products, plans, and APIs
ƒ Members in the provider organization work mainly with the developer toolkit and the API Manager
user interfaces
ƒ Pre-configured roles are set in Cloud Manager
ƒ Initial provider organization is defined in Cloud Manager
ƒ Consumer organization
ƒ Members in these organizations use the APIs by creating applications that call the APIs
ƒ Pre-defined default roles are set in Cloud Manager
ƒ Initial consumer organization for a catalog is defined in API Manager
The providers and the consumers of APIs can be categorized into different roles.
• An API or software developer in the organization is responsible for implementing the API
operations. The API developer uses the API Connect Toolkit to develop, test, and publish
APIs, applications, plans, and products.
• The API product manager or organization owner is the owner of a provider organization. This
role is responsible for the review and approval of lifecycle changes within the API Manager
web user interface.
• The application developer (or app developer) builds an application that uses published APIs.
The app developer subscribes to APIs in the Developer Portal.
• The application user uses the application and its associated APIs that the app developer
creates.
Uempty
Organizations (2 of 2)
• APIs and Products are owned by a
Provider provider organization. They exist as
organization authored artifacts visible in the API
Products Sandbox catalog Manager. To become available to
Plans APIs
Portal consumers, APIs must be deployed to a
catalog and published to some or all
Deployed Products and APIs
organizations. A catalog has an associated
developer portal and runtime capability.
• A provider organization can have multiple
Users Portal
Portal
catalogs such as a sandbox catalog and a
Development catalog development catalog.
Apps
• Apps are registered to consume APIs via a
Deployed Products and APIs
selected plan, which determines the API
quota.
Apps Users
Consumer organization • A provider organization can have apps
that consume APIs from another provider.
Uempty
2.2. Creating a catalog
Uempty
Creating
ga
catalog
Managing
M
Ma
Mana
ana
ag
giing
ng ccatalogs
atta
allog
gs a
an
and
nd o
or
organizations
rga
gan
niiza
attiio
onns © Copyright IBM Corporation 2020, 2021
• APIs must be deployed to a catalog, and then published to organizations to become available
to consumers
• You can create multiple catalogs in a single installation
• Catalogs are useful for separating Products and APIs that you want to test before you publish
to an organization
Uempty
Catalogs
• Provider organizations can create separate deployment targets that are called catalogs for
testing and production
• Each catalog:
Is included in the path of a specific API endpoint
Has its own Developer Portal
• A default development catalog named “Sandbox” is provided
Used for testing
• A catalog is a staging target
The URL for API calls and the Developer
Portal is specific to a particular catalog
• While developing and maintaining APIs, members of a provider organization can create
separate deployment targets called catalogs for testing and production. Each contained
catalog is associated with a specific Developer Portal and endpoints. The URL for API calls and
the Developer Portal are specific to a particular catalog.
• By default, a development catalog is provided for you.
• The development catalog is named Sandbox.
• Other catalogs are added by the organization owner.
• In the exercise at the end of this Unit, you have an opportunity to configure the Staging
catalog.
Uempty
Create a catalog
• Sign in to API Manager as the owner of the provider organization
Select Manage catalogs from the Home page
To add a catalog:
1. Sign in to API Manager as the owner of the provider organization.
2. Select the Manage catalogs tile from the home page. Then, click the Add icon to create a
catalog. Complete the fields in the dialog, by giving the catalog a name.
3. Then, click Create.
4. The catalog is added and is displayed as a tile in the list of catalogs from the Manage page.
Uempty
From the Manage navigation in API Manager, select the catalog that you want to configure. Then,
select Settings.
• From the Overview tab, there are toggles for setting production mode, spaces, and application
lifecycle.
• By default, the new catalog is a development catalog.
• To use the catalog in production, set the Production Mode slider control to the On position,
then click Confirm.
• In a development catalog, staging and publishing actions are forced, meaning that if you
republish a previously published Product, it is overwritten without warning.
Uempty
Spaces
• You can partition your catalog into spaces
• Each Space is used by a different API provider development team
Each team manages their APIs independently
• Coordinated offering on the Developer Portal
Products API Developer Portal
development team
Catalog
Stage APIs
Retail Space
Stage APIs
Wholesale Space
• A catalog can be partitioned into multiple spaces that can be leveraged by different groups of
users. A space has its own set of management capabilities for product lifecycle, developers,
and subscriptions.
• Spaces can be set from the Overview tab in the Manage catalog page.
Information
The Staging catalog does not use spaces in the course exercises.
Uempty
Uempty
• You can create a custom gateway URL when you configure the catalog in API Manager.
• If you want to achieve custom branding for APIs that are deployed to API Connect, you can
specify a custom gateway URL.
• Specify a custom URL for your enterprise in the API Endpoints field of the catalog settings.
• Endpoints in the Developer Portal are displayed with the custom name. You must configure a
DNS entry that maps the custom name to the default name.
• Ensure that the same custom gateway URL is not applied to multiple catalogs.
Uempty
• Each Availability Zone contains one or more Portal services. The Portal service provides a
developer portal that is used by application developers to discover APIs and onboard
consumers. An email server must be configured and set as the email server for the cloud
before registering a portal service.
• When you create a portal, and no user registry is configured in the settings for the catalog, API
Manager automatically creates a separate local user registry for the portal.
• The portal local registry stores members of consumer organizations.
• The API Manager local registry stores members of the provider organization.
Uempty
2.3. Creating a consumer organization
Uempty
Creating
ga
consumerr
organization
Managing
M
Ma
Mana
ana
ag
giing
ng ccatalogs
atta
allog
gs a
an
and
nd o
or
organizations
rga
gan
niiza
attiio
onns © Copyright IBM Corporation 2020, 2021
Uempty
If you have permission to manage developers, you can create consumer organizations.
The Developer Portal must be enabled and configured in API Manager before you perform this
task.
Create the consumer organization from the Consumer Organizations menu after you have
selected the catalog in API Manager.
In the Create Consumer Organization dialog box, type:
• Title
• Name
• User registry
• Owner information
If New User is selected, specify:
• Username
• Email address
• First name
• Last name
• Password
Then, click Create.
The consumer organization is added to the list of consumer organizations for the catalog.
Uempty
• The owner can sign on to the Developer Portal with the username and password credentials
that were provided during the creation of the consumer organization
Managing catalogs and organizations © Copyright IBM Corporation 2020, 2021
Uempty
The consumer organization owner can sign on to the Developer Portal. When the owner is signed
in, the owner can manage the developer organization from the Developer Portal and does not use
the API Manager user interface. There are tools in the Portal to manage the consumer
organization. Next, you see some of the capabilities that the consumer organization owner has on
the Developer Portal.
Uempty
• After signing on to the Developer Portal, the consumer organization owner can access the
manage organization menu from the menu drop-down.
• From this menu, owners can manage their own consumer organization.
• For development catalogs, the owner can also create a new organization.
• More about the Developer Portal is covered later in the next topic.
Uempty
• The owner of the consumer organization can add members to the consumer organization with
the Invite panel. Those members can then access the Developer Portal and use the APIs that
have been made available to the consumer organization.
• Results: The member is added to the consumer organization with a status of pending, and an
email is sent to the member with the subject line: “Invitation to an API consumer organization
in the catalog_name developer portal". The member must click the link that is provided to
activate their account and complete the setup.
Uempty
• The owner of the consumer organization can view or edit the members of the organization in
the Developer Portal. The member that was invited responds to the email invitation and joins
the consumer organization by signing on to the Developer Portal.
• The member status is changed to Active in the list of members.
Uempty
• When the owner of a consumer organization invites a member to join the organization, the
member is assigned a role. The default roles that the owner can assign are administrator,
developer, or viewer. In the previous slides, the role of developer is assigned.
• The default roles for a consumer organization are defined in Cloud Manager.
Uempty
2.4. Creating a Developer Portal
Uempty
Creating
ga
Developerr
Portal
Managing
M
Ma
Mana
ana
ag
giing
ng ccatalogs
atta
allog
gs a
an
and
nd o
or
organizations
rga
gan
niiza
attiio
onns © Copyright IBM Corporation 2020, 2021
• The Developer Portal is built on Drupal 8, an open source content management technology. A
good understanding of Drupal 8 concepts and terminology enhances your ability to work with
the Developer Portal.
• As well as enabling application developers to find and use your APIs, the Developer Portal also
provides features such as API analytics, forums, blogs, and rating facilities.
Uempty
• After the catalog is created and a portal service registered, an email is sent to the admin user.
• Respond to the email by selecting the activation link for the admin user in the email message.
Uempty
Uempty
• The portal for the catalog is created and the admin user is signed in.
• The admin user is used to administer and customize the Developer Portal.
Uempty
• The Developer Portal has responsive web pages, and the pages resize according to the
browser width.
• Displayed on the left side of the page is the admin Workbench menu items.
• On the right side of the page are the expanded Manage menu items.
• The administration menu uses the Drupal components of the Developer Portal.
Uempty
2.5. Assigning roles and permissions
Uempty
Assigning
g roless
and
d
permissions
Managing
M
Ma
Mana
ana
ag
giing
ng ccatalogs
atta
allog
gs a
an
and
nd o
or
organizations
rga
gan
niiza
attiio
onns © Copyright IBM Corporation 2020, 2021
Uempty
Uempty
Provider 2 3
organizations
Provide APIs
Provider org Consumer Consumer
owner org owner organizations
Use APIs
V Email
1 server
Cloud
Cloud Clusters User Configuration
Manager of servers registry
administrator
or Identity provider
containers
Cloud
Managing catalogs and organizations © Copyright IBM Corporation 2020, 2021
The diagram shows the sequence for the creation of users in API Connect.
1. The Cloud Administrator is created when the API Connect product is installed. The
administrator signs on to the Cloud Manager user interface to configure the resources and
topology of the on-premises cloud. The administrator creates the provider organization and
assigns an owner.
2. The owner of the provider organization signs on to the API Manager user interface and creates
the members of the provider organization who create APIs, Products, and plans. The owner of
the provider organization creates a consumer organization and assigns an owner.
3. The owner of the consumer organization signs on to the Developer Portal to create members
of the consumer organization and assign roles. Members of the consumer organization use
APIs and create applications and subscribe to Products and plans.
Uempty
• Application developers
Discover APIs on the Developer Portal
Create applications and subscribe to plans
Create web or mobile apps that call Products, plans, and APIs with the key (client ID) provided by the application
• After the owner of the provider organization has created a catalog and configured the portal
settings, the owner saves the changes in API Manager. At this point, the Developer Portal for
the catalog is created.
• The administrator of the Developer Portal activates the portal. The administrator does not
belong to any consumer organization. The administrator is responsible for the customization
of the Developer Portal.
• The owner of the provider organization adds the initial consumer organization and owner from
the Community tab in API Manager.
• The owner of the Developer organization then signs on to the Developer Portal to activate the
account.
• Depending on the permissions set for the Developer Portal in API Manager, the owner of the
Developer organization might be able to add more users (application developers) and
Developer organizations.
Uempty
The administrator of the Developer Portal can assign additional portal-related roles to the
member of the organization.
Uempty
Portal roles
• By using roles, you can fine-tune the security and administration of Drupal
A role defines a group of users that have certain privileges as defined on the permissions page
• Anonymous user: Role that is used for users that do not have a user account or that are not
authenticated
• Authenticated user: This role is automatically granted to all logged in users
• Content author: Role that is used to edit or add content
• Forum moderator: Role that controls access to the portal forums
• Superuser:
Can see all the site content
Automatically assigned to the Administrator
• Administrator:
Manages all other roles
You can use roles to fine-tune the security and administration of Drupal. A role defines a group of
users that have certain privileges as defined on the permissions page. Examples of roles include
anonymous user, authenticated user, moderator, administrator, and other roles. The
administrator can define the names and order of the roles on your site. It is recommended to
order your roles from least permissive (anonymous user) to most permissive (administrator).
By default, Drupal comes with two user roles:
• Anonymous user: This role is used for users that do not have a user account or that are not
authenticated.
• Authenticated user: This role is automatically granted to all logged in users.
Uempty
Members of the consumer organization can have both API Connect roles and Developer Portal
Drupal roles. In the example, the member with an Application Developer role in API Connect also
has a Forum Moderator role in the Developer Portal.
Uempty
Password lockout
• API Connect Local User Registries apply a lockout criteria
• Repeated unsuccessful login attempts can lock your account
• Length of time that you are locked out of using the account is based on the number of
consecutive failed attempts
Length of time increases as the number of consecutive failed attempts increases
Locks you out for 15 seconds after five consecutive failed attempts
Locks you out for 32 minutes after 12 consecutive failed attempts
• External user registries, such as LDAP, might enforce their own lockout criteria
Uempty
Uempty
Review questions
1. Provider organizations can create separate deployment targets for testing and production.
These targets are called:
Catalogs
Permissions
Roles
User registries
2. True or False: If you do not explicitly configure a user registry in the API User Registries
settings of the Manage catalog page in API Manager, then a local user registry is created
when the portal is created.
Uempty
Review answers
1. Provider organizations can create separate deployment targets for testing and production.
These targets are called:
Catalogs
Permissions
Roles
User registries
The answer is A.
2. True or False: If you do not explicitly configure a user registry in the API User Registries
settings of the Manage catalog page in API Manager, then a local user registry is created
when the portal is created.
The answer is True.
Uempty
This exercise shows you how to manage consumer organizations through the API Manager and
Developer Portal web interfaces. You review the role of the provider organization owner in
creating a consumer organization. You also learn how to manage members and configure member
roles and permissions in the Developer Portal.
Uempty
Uempty
Overview
This unit provides an overview of APIs and API types. It describes the structure of an API
definition and how to create a new API definition in API Manager. It explains the role of the
DataPower gateway in exposing existing web services. It also covers how to edit and test an API
definition in API Manager. Options for defining SOAP APIs are covered in more detail.
Uempty
Uempty
Uempty
3.1. Overview of APIs and API types
Uempty
Overvieww off
APIss and
d APII
types
Defining
Defi
De fini
fining
gAAPIs
PIss iin
PI nAAPI
PI M
PI Manager
an
anag
a er
er © Copyright IBM Corporation 2020, 2021
Uempty
API definition
Document that describes API operations
API application
API Software that implements API operations
• An API is a set of functions that provide some business or technical capability and are called
by applications by using a defined protocol. Applications are typically mobile or web
applications, and they use the HTTP protocol.
• The OpenAPI API definition specifies the interface of a REST API in a standard,
vendor-neutral, and language-neutral way. With a properly specified API definition, software
developers and applications can discover and understand the capabilities of the service
without access to the implementation source code, extra documentation, or inspecting
network traffic.
• IBM API Connect uses OpenAPI API definitions as the API interface format. You can import
API definitions that other editors create, or export API definitions.
Uempty
API types (1 of 2)
An API definition is composed of paths, and can be one of the following types:
• REST is a simple set of HTTP-based interactions, found in web applications
You map functions to web resource paths
Applications call API paths with HTTP methods, such as GET and POST
Applications exchange data with an API in JSON or XML
Can work with plain text, XML, HTML, and JSON
Codified in the OpenAPI (swagger) definition
• SOAP is an enterprise integration standard and specification for XML-based message exchange
You map functions to SOAP operations
A standards-based web services access protocol that has been around for a long time
Applications call API operations in an XML-based SOAP message format
Applications exchange data in XML
Language, platform, and transport independent
Codified in the Web Service Description Language or WSDL
Defining APIs in API Manager © Copyright IBM Corporation 2020, 2021
Uempty
API types (2 of 2)
• GraphQL
GraphQL is an open-source data query language for APIs. GraphQL was developed by Facebook in
2012 before being publicly released in 2015.
GraphQL gives an application client greater control over what data it retrieves in an API request when
compared with a REST API request.
IBM API Connect enables you to create a GraphQL API proxy definition that proxies a backend
GraphQL server, and to define rate limiting controls that reflect the amount of data that is returned
from the server by a request to the GraphQL API.
Uempty
3.2. Structure of the API definition
Uempty
Defining
Defi
De fini
fining
gAAPIs
PIss iin
PI nAAPI
PI M
PI Manager
an
anag
a er
er © Copyright IBM Corporation 2020, 2021
The next two slides display the parts of an API and an API operation. The next topic covers where
this information can be edited in API Manager.
Uempty
Base path • The web route that identifies the API /InventoryService
• It appears immediately after the host
name
• This chart describes the functional parts of an OpenAPI definition file. The host entry lists the
API server name or IP address. In API Connect, you can provide an environment property that
the API gateway resolves at run time. If you omit this property, the host defaults to the API
gateway address.
• The base path entry displays the web route immediately after the API. The purpose of the
base path is to separate the operations in this API from other APIs on the same server.
• The consumes and produces entries explain how to interpret the data in the HTTP request
message and response message. For example, a web form has a media type of text/html. If
the API application returns a JSON object in the response message body, the message has a
media type of application/json.
• The OpenAPI definition file also stores environment-specific variables, which are known as
properties. For example, the target-url can be specified for all the operations of the API. In
the example, the target-url is specified as an actual URL address. Properties can be specified
as API Connect context variables that start with a $ sign.
Note
The target-url is the URL of the API service that is called. The operation paths are appended to
the target-url to define the proxy endpoint.
It is important to distinguish between the proxy endpoint that is the back-end service that is
called from the gateway. Client applications call the API at the gateway endpoint. The gateway
routes or proxies the call to the proxy endpoint that is defined by the target-url.
Uempty
Uempty
3.3. Creating a SOAP API in API Manager
Uempty
Creatingg a SOAP
P
APII in
n APII
Manager
Defining
Defi
De fini
fining
gAAPIs
PIss iin
PI nAAPI
PI M
PI Manager
an
anag
a er
er © Copyright IBM Corporation 2020, 2021
• You can create API definitions by using the API Manager or the command-line interface in IBM
API Connect.
• This unit covers how to create a SOAP proxy from a WSDL document. In the exercise at the
end of this unit, you get an opportunity to create this type of API.
• The next unit covers REST APIs and the OpenAPI specification in more detail. OpenAPI
(Swagger 2.0) is used to create language-independent APIs that proxy to existing back-end
implementations.
Uempty
OpenAPI 3.0
• API from existing REST service
Create a REST proxy API from a REST service
• API from existing SOAP service
Create a SOAP proxy API from a SOAP service
OpenAPI 2.0
Create a REST proxy API from a SOAP service
• New API
SOAP
Create an OpenAPI definition from scratch
• Import API
Import an existing OpenAPI definition
API 3.0
Open
Defining APIs in API Manager © Copyright IBM Corporation 2020
Uempty
2
InventoryService
Publish the API SOAP service
definition to the
gateway through
the API Manager
1
Define a SOAP
API with the InventoryService
operations in the API definition
existing service
API Manager
• Traditional enterprise applications rely on the SOAP specification to remotely bind and invoke
services. SOAP services rely on another standard to describe its interface: the Web Services
Description Language (WSDL) document. In this scenario, you can specify an OpenAPI
definition based on an existing WSDL document.
• Looking forward, you might want to modernize an existing SOAP service and provide a REST
API. In this scenario, you must specify an OpenAPI definition and policy assemblies to convert
a call from REST to a SOAP request.
• In this scenario, your organization wants to expose an existing SOAP service at the API
gateway. The goal is to forward API requests as-is to the SOAP service. In other words, you
want to build a proxy for a SOAP service.
• In the API Manager web application, build a new OpenAPI definition that is based on a SOAP
interface. You can create a SOAP API from scratch, but the most straightforward method is to
create a SOAP proxy from an existing WSDL service in the API Manager web user interface.
When you use this option, the dialog prompts you to import a Web Services Description
Language (WSDL) document as a starting point for the API definition. After you import the
WSDL interface and build the SOAP API definition, you auto-publish the API definition to a
DataPower Gateway in the API Manager. The auto-publish option happens when you make the
API online in the API Manager test feature.
Uempty
1. To test the SOAP API that is hosted at the API gateway, send a SOAP request message to the
gateway. You must use a test client that sends a properly formatted SOAP XML envelope
message in the body of the HTTP request. The test client in the API Manager assembly view
can build such a message for a SOAP API.
2. When the API gateway receives the SOAP request, it validates the message against the input
message and parameters that you defined in the OpenAPI definition file. The proxy policy in
the assembly forwards the request to the actual SOAP service implementation.
Uempty
API Connect provides a web-based graphical environment for developing APIs and products.
• Sign on to API Manager from a browser with your developer user account.
• Click the “Develop APIs and Products” tile to open the Develop page in the browser.
Uempty
• After you click the option to add an API, the page displays a number of options for creating the
API. You can create a REST API definition to proxy an existing REST service. You can create
APIs from an existing WSDL service.
• You can start with an empty OpenAPI definition document with the New OpenAPI option.
• The Existing OpenAPI option imports an OpenAPI document from your workstation or a
remote server.
• You examine some of these options in other units and course exercises.
• To create a SOAP API from a WSDL service, select the From existing WSDL service (SOAP
proxy) option
Uempty
• If you want to immediately use the API after import, select the Activate API option. When you
select the Activate API option, API Connect automatically completes the following actions:
▪ Creates a draft Product, adds the API to the Product, and publishes the Product to the
sandbox catalog so that the API is available to be called. The Product has the title
api_title auto product. This Product is not visible in the Develop view and you cannot
delete it directly. However, if you delete the API the draft Product is deleted together with
the API. The Product is visible in any catalogs to which it is published. If you want to
remove the Product from a catalog, you must do this separately.
▪ Subscribes the sandbox test application to the Product so that you can immediately test
the API in the test environment.
Uempty
3.4. Editing the API definition
Uempty
Editing
g thee APII
definition
Defining
Defi
De fini
fining
gAAPIs
PIss iin
PI nAAPI
PI M
PI Manager
an
anag
a er
er © Copyright IBM Corporation 2020, 2021
• IBM API Manager provides different ways to edit the OpenAPI specification including a Design
view.
• In this course, you use API Manager to create and assemble APIs, and add Products and plans
for these APIs.
• Once you have created a SOAP API as a result of importing the WSDL file, you can use the API
Manager user interface to edit the API.
Uempty
1 5
4
3
The IBM API Connect API Manager user interface provides a range of options for working with
your APIs and Products and managing security.
1. To navigate inside the API Manager user interface, select an icon on the navigation bar on the
left.
2. When you open an API, you can view the Design, Source, or Assemble tabs to develop the API.
3. In the Design view, there is a submenu that allows you to navigate different parts of the API.
4. In the Design view, when you select a section on the left, the details are displayed on the right.
5. In the upper right corner, you can save your API, and log out.
Uempty
This unit covers the Develop option. When you select the Develop option, you are taken to a list of
your APIs. From there, click Add > API.
Uempty
• The Design view of the API in API Manager allows you to navigate the API in a web interface.
• The next nine slides cover an overview of each of these sections.
• In the exercise at the end of this unit, you get an opportunity to review some of these settings.
Uempty
Uempty
Security Description
Use a basic authentication security definition to specify
Basic
a user registry or an authentication URL to be used to
authentication
authenticate access to the API.
Use an API key security definition to specify what
API key
application credentials are required to call an API.
Use an OAuth security definition to specify settings for
OAuth
OAuth token-based authentication for your API.
This slide includes a table displaying the security configurations available for your API.
Uempty
• You cannot apply more than two API key security definitions to
an API.
• You can have at most one API key definition of type client ID
• You can have at most one API key definition of type client secret
• You cannot apply more than one basic security definition to an
API
The following restrictions exist when you apply security definitions to an API:
• You cannot apply more than two API key security definitions to an API.
• If you apply an API key security definition for client secret, you must also apply an API key
security definition for client ID.
• If you require the application developer to supply both client ID and client secret, you must
apply two separate API key security definitions.
• You can have at most one API key definition of type client ID, regardless of whether the client
ID is sent in the request header or as a query parameter.
• You can have at most one API key definition of type client secret, regardless of whether the
client secret is sent in the request header or as a query parameter.
• You cannot apply more than one basic security definition to an API. If you apply a basic
security definition, you cannot also apply an OAuth security definition.
• If you apply more than one OAuth security definition to an API, they must all have the same
client type setting, Public, or Confidential.
• If you apply more than one OAuth security definition to an API, they must have compatible
authentication settings. That is, the value of an authentication property must be the same for
all applied OAuth security schemes that have that property.
• If you apply more than one OAuth security definition to an API, they must have compatible
token refresh and revocation settings. That is, the value of a token refresh property or
revocation property must be the same for all applied OAuth security schemes that have that
property.
Uempty
• When you open the path, the operations for the path are displayed.
• The path is the name of the web resources that appears immediately after the base path, for
example: /InventoryRequest. The path is appended to the target-url property. In REST APIs,
the API path represents the name of the operation. However, SOAP APIs encode the operation
name into the XML SOAP envelope in the HTTP request message. The OpenAPI definition
must capture the same information in the schema definition section.
• A path comprises an HTTP verb and a URL path that, when exposed, is combined with the
base path of the API. By configuring the path, you define how the API is exposed to your
developers.
• In each SOAP API operation, the request and response messages map to the WSDL input and
output message types.
• In the screen capture example, a POST operation is displayed. The HTTP method is always set
to POST for SOAP APIs because SOAP services do not use the other HTTP methods, such as
GET, PUT, or DELETE.
Uempty
• Y
You
ou
• The example in the screen capture displays a request and response for the InventoryRequest
operation.
• The InventoryRequestInput schema is used in the body of the request and is required.
• The InventoryRequestOutput schema is used in the response.
• These schema definitions can be viewed under the Definitions section in the next slide.
Uempty
• You
• In REST APIs, the API path represents the name of the operation. However, SOAP APIs
encode the operation name into the XML SOAP envelope in the HTTP request message. The
OpenAPI definition must capture the same information in the schema definition section.
• In this example, the InventoryRequest operation represents the WSDL operation of the same
name. In the original WSDL document, the InventoryRequest operation accepts a SOAP
request message named “InventoryRequest”. The OpenAPI definition creates a custom
schema type named “InventoryRequest” to represent this data. The InventoryRequestInput
schema type represents the SOAP envelope for the request message. The
InventoryRequestOutput schema type represents the SOAP envelope for the response
message.
• The WSDL operation, input, output, and custom data types correspond to the OpenAPI
schema definitions.
Uempty
Uempty
Uempty
Uempty
Uempty
• Up to this point, you have been viewing the API definition in the Design view. However, API
Manager also supports other views including the Source and Assemble views. In the Source
view, you can view the source of the OpenAPI specification. The Source view displays the API
definition in YAML format.
• The OpenAPI specification supports two API definition file formats: JavaScript object
notation, or JSON, and Yet Another Markup Language, or YAML. IBM API Connect exports API
definitions in the YAML file format.
• The source view displays an OpenAPI definition in the raw text format. You can directly edit
the text version of the OpenAPI definition in the API Manager, or any text editor.
• IBM API Connect also implements a number of extensions to the OpenAPI definition
structure. For example, the x-ibm-name property stores the API name.
The example in the slide shows the first part of the OpenAPI YAML document.
Uempty
Syntax
swagger: '2.0‘
info:
title: InventoryService
description: WSDL File for InventoryService
x-ibm-name: inventoryservice
version: 1.0.0
schemes:
- https
basePath: /InventoryService
produces:
- application/xml
consumes:
- text/xml
securityDefinitions:
clientID:
type: apiKey
name: X-IBM-Client-Id
in: header
description: ‘’
Security:
- ClientID: []
x-ibm-configuration:
type: wsdl
phase: realized
enforced: true
testable: true
gateway: datapower-api-gateway
cors:
enabled: true
Uempty
Uempty
1
4
2
The API Designer features an assemble view that you can use to create assemblies. With
assemblies, you can readily tailor your APIs to include components such as activity logging and
redaction of specific fields. This view includes a palette, which lists available components, a
property sheet, which is used to configure a component, and a canvas, which is used to arrange
and visualize the assembly’s components. When you create an API definition, IBM API Connect
defines an assembly with one message processing policy: an invoke operation.
1. Test panel provides features to publish and test operations of the API
2. Setup displays the catalog, Product, Plan, and Application relative to the API
3. You can select from multiple operations if the API supports multiple operations
4. The canvas is used to arrange the assembly’s components
5. The target URL is the URL to be invoked in the invoke policy
Due to Cross-Origin Resource Sharing (CORS) restrictions, the assembly test tool cannot be used
with the Chrome or Safari browsers on the macOS Catalina platform.
Uempty
3.5. Testing the API definition
Uempty
Testingg the
e APII
definition
Defining
Defi
De fini
fining
gAAPIs
PIss iin
PI nAAPI
PI M
PI Manager
an
anag
a er
er © Copyright IBM Corporation 2020, 2021
Uempty
• To test the API, click the test icon in the API Manager web application. The test dialog opens.
If you haven’t activated your API, the first time that you test an API, the test dialog prompts
you to make the API online. By selecting this option, you publish the API and its product to the
default gateway of the catalog.
• When the API is published, you can choose the operation that you want to call, provide the
required parameters, and then click the Invoke button. The Invoke action calls the API
operation that is hosted at the gateway.
• For a SOAP proxy policy, the invoke policy forwards the message payload in the assembly flow
to the URL endpoint location. The API gateway can run one invoke policy per flow – you cannot
call multiple invoke policies for SOAP proxies in the same flow.
Uempty
You get an opportunity to test an API in the exercise at the end of this unit.
Uempty
Uempty
Review questions
1. True or False: Use the API Manager user interface to design APIs.
Uempty
Review answers
1. True or False: Use the API Manager user interface to design APIs.
The answer is True. You use the API Manager to define and design APIs.
2. How do you define a SOAP API Definition in API Connect?
Import a WSDL document in API Manager
Create a SOAP API from the assembly palette
Generate a sample with the apic utility
Import a SOAP application in API Designer
The answer is A.
3. Which environment variable represents the endpoint of the API application?
$(host)
$(api.port)
$(target-url)
$(host.url)
The answer is C.
Defining APIs in API Manager © Copyright IBM Corporation 2020, 2021
Uempty
Figure 3-40. Exercise: Defining an API that calls an existing SOAP service
With API Connect, you can define an API from existing enterprise services. In this exercise, you
define an API that calls an existing SOAP service. You use the API Manager feature to create an
API definition from an existing WSDL service. The imported WSDL defines the API paths and
methods that map to SOAP web service operations, and map SOAP message types to API data
types. You test the SOAP API in the test feature of API Manager.
Uempty
Uempty
Overview
This unit describes the options for defining REST APIs in API Manager and examines the API
definition file for an OpenAPI specification. You learn how to define a REST API interface for a
target service endpoint. You examine the role of the extensions that API Connect adds to the
OpenAPI definition and how message processing policies are defined in the API assemble view.
You learn the HTTP methods for REST operations and how to create a GET and POST operation in
API Manager.
Uempty
Uempty
Defining a REST API in API Manager © Copyright IBM Corporation 2020, 2021
Uempty
4.1. Overview of the OpenAPI standard
Uempty
Overview
w off the
e
OpenAPII
standard
Defining
Defi
De fini
fining
gaR
REST
EST AP
ES
EST A
API
PI in
in A
API
PI Manager
PI Man
nag
ag
ger
er
er © Copyright IBM Corporation 2020, 2021
Uempty
Swagger petstore
• The swagger petstore
is a sample pet store
server.
• The site is generated
using Swagger UI.
• The endpoints are:
• pet
• store
• user
Defining a REST API in API Manager © Copyright IBM Corporation 2020, 2021
• Swagger petstore is used in the slides in this unit as the service endpoint for REST operations.
• Swagger petstore is a sample API that simulates a pet shop management server. The API
allows you to access petstore data by using a set of individual calls. Namely, there are three
endpoint groups Pet, Store, and User. It is useful for testing APIs. In the following slides, the
API configuration for the swagger petstore service is discussed.
▪ Swagger petstore is a publicly available API service endpoint that can be used for testing
purposes.
▪ Swagger petstore is a functioning API with real data. Test data in the database is not
consistent.
▪ There is also a version of the pet store that supports the OpenAPI 3.0 specification:
- https://petstore3.swagger.io/
• To ensure data integrity and service reliability, a local version of the swagger petstore website
is run on your student workstation. The petstore website is run in a Docker container. You use
this version to test your petstore REST APIs.
Uempty
• OpenAPI documents describe API operations and paths and are represented in either YAML or
JSON formats
• When you create an API in API Connect, you declare an OpenAPI definition
IBM API Connect extends the Open API specification and adds message processing policies in the
assembly section of the API definition
Defining a REST API in API Manager © Copyright IBM Corporation 2020, 2021
• The OpenAPI Specification (OAS) defines a standard interface description for REST APIs. The
Open API 2.0 specification is a community-driven open specification within the OpenAPI
Initiative, a Linux Foundation Collaborative Project. For more information, see:
https://github.com/OAI/OpenAPI-Specification.
• The definition files that are imported or created in this course conform to the OpenAPI
Specification 2.0 that is identical to the Swagger 2.0 specification.
• For the latest OpenAPI specification, refer to: https://swagger.io/specification/
Uempty
Uempty
Defining a REST API in API Manager © Copyright IBM Corporation 2020, 2021
Uempty
definitions.
securityDefinitions
schemes
• In version 2.0, you
could describe headers produces consumes
components
responses
Defining a REST API in API Manager © Copyright IBM Corporation 2020, 2021
• OpenAPI 3.0 has a newly designed document structure to write and reuse API definitions. A
new object that is called components contains reusable objects such as securityDefinitions,
definitions, parameters, and responses.
• IBM API Connect supports the OpenAPI 3.0 specification, with some limitations. The current
implementation includes complete support for the Berlin Group NextGen PSD2 requirements.
• There is no OpenAPI 3.0 API support with the DataPower Gateway (v5 compatible); OpenAPI
3.0 API support is provided by the DataPower API Gateway only.
• The limitations to the OpenAPI 3.0 support in IBM API Connect are as follows:
▪ User interface limitations
- Some aspects of the OpenAPI 3.0 specification are not currently supported by the user
interface. In such circumstances, use the OpenAPI source directly.
- Validation errors that are identified locally are reflected in the API editor header almost
immediately. However, some validation errors can be identified only by the API
Manager backend and are not reflected until the API is saved; this means that, on
saving an API, some validation errors might appear or disappear.
- The user interface does not currently support referencing a request body component
from the request body of an operation. If you want to reference a request body
component, add the reference to the request body of the operation directly in the
OpenAPI source:
requestBody: $ref:
'#/components/requestBodies/request_body_component_name'
However, the reference is confirmed on the details page for the request body in the
user interface, .
Uempty
- If, in the API Designer user interface, you create and activate an API of the same name
and version as one that has already been activated from the API Manager user
interface, the Edit Rate Limit operation fails.
• Limitations for APIs that are enforced by the DataPower API Gateway
▪ General limitations
- The servers' array cannot contain more than one server.
- The url entry in the servers' array cannot contain variables.
- path objects cannot contain server object overrides.
- Error code wildcarding in response objects is not supported.
- There is no support for converting a WSDL defined SOAP service into an OpenAPI 3.0
API.
▪ Assembly policies
Only the following policies are supported:
- invoke
- jwt-generate
- jwt-validate
- oauth
- throw
- user-security
- The validate and map policies are not supported.
Uempty
4.2. IBM extensions to the OpenAPI standard
Uempty
IBMM extensionss
to the
e OpenAPII
standardd
Defining
Defi
De fini
fining
gaR
REST
EST AP
ES
EST A
API
PI in
in A
API
PI Manager
PI Man
nag
ag
ger
er
er © Copyright IBM Corporation 2020, 2021
Uempty
Defining a REST API in API Manager © Copyright IBM Corporation 2020, 2021
• The OpenAPI specification defines the API definition as strictly an interface file: it describes
the input and output messages for each operation in the API.
• IBM API Connect extends the role of the OpenAPI definition file to several use cases. The API
Gateway server hosts API operations according to the OpenAPI definition file. It also enforces
a set of message processing rules that you define as an assembly extension. The API Manager
reads the lifecycle extension to determine whether an API is ready for deployment to a
staging or production environment. Last, the Developer Portal reads the subscriptions and
testing extension to determine whether application developers can subscribe and test a
published API.
Uempty
Defining a REST API in API Manager © Copyright IBM Corporation 2020, 2021
• The purpose of the lifecycle extension property is to state the current development state of
the API. In the identified state, the API definition and the API implementation are not
complete. In the specified state, the API definition is complete, but the API application is not
yet implemented. In the realized state, both the API definition and API implementation are
complete.
• The remaining options in the lifecycle section control other settings in the API Connect
environment.
▪ The enforced setting determines whether the API gateway enforces the settings in the API
definition. If this setting is disabled, API is not exposed on the gateway.
▪ The testable setting determines whether an application developer can review and test the
API in the Developer Portal. If this setting is disabled, the operation does not appear in the
test client.
▪ The CORS setting determines whether the API supports the Cross-Origin Resource
Sharing scheme. With the CORS scheme, a web server can use web resources on a named
third-party server with a specific set of rules. For more information about this scheme, see:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS
Uempty
4.3. Creating a REST API in API Manager
Uempty
Creatingg a REST
T
APII in
n APII
Manager
Defining
Defi
De fini
fining
gaR
REST
EST AP
ES
EST A
API
PI in
in A
API
PI Manager
PI Man
nag
ag
ger
er
er © Copyright IBM Corporation 2020, 2021
Uempty
Defining a REST API in API Manager © Copyright IBM Corporation 2020, 2021
To create an OpenAPI definition of a REST proxy to an existing target API, start the API Manager
web application. Select the Develop APIs and products tile or select the Develop option from the
side menu. Click Add. Then, select API from the drop-down list. In the Add API page, select the
option to create the API from a target service.
Note
API Manager provides options to create a new OpenAPI or to create APIs from existing REST and
SOAP services. The from target service option makes it easy to create a proxy to an existing REST
service.
Uempty
• When you define an API against a service endpoint, you enter metadata on the API: the name,
description, contact information, and version number for the API definition. The API gateway
does not parse this information: it is kept for documentation purposes. One exception is the
version number: you can configure API Manager to manage versions with API lifecycle
management.
• The base path uniquely identifies this API definition from other API definitions that are hosted
at the gateway. Provide a unique path prefix in this document.
• In the target service URL section, specify the target endpoint for the API definition. The
target endpoint is the network location for the API application that implements the interface.
Uempty
Defining a REST API in API Manager © Copyright IBM Corporation 2020, 2021
Uempty
Defining a REST API in API Manager © Copyright IBM Corporation 2020, 2021
Uempty
Defining a REST API in API Manager © Copyright IBM Corporation 2020, 2021
• Add the schema definition for the response message from the Definitions option of the
Develop page in API Manager.
• Specify the name of the definition and add the properties. Save when completed.
Uempty
Defining a REST API in API Manager © Copyright IBM Corporation 2020, 2021
• You specified the location of the API implementation during the initial creation of the OpenAPI
definition.
• To complete the API definition, you must specify the exact interface for the API. The interface
includes the API paths, HTTP operation, request, and response message for each API
operation.
• Parameters represent input data for the operation. You can also define parameters at the path
level.
▪ The OpenAPI specification defines data types in an API definition
• Type the input parameter name, location, description, and type in the parameters section of
the API operation. When you mark a parameter as required, the API gateway checks that the
parameter exists, and its value has the correct data type. The Located in field determines
where the API operation expects to find the parameters:
▪ Path: A path segment in the URL
▪ Query: Query parameters in the URL
▪ Header: HTTP header
▪ Form data: HTML form in message body
▪ Body: Data in message body
• The next topic in this unit covers more detail around the REST operations GET and POST.
Uempty
Defining a REST API in API Manager © Copyright IBM Corporation 2020, 2021
• After you define the API operations, you must instruct the API gateway to forward requests to
the API application. The policy assembly is a set of message processing instructions that you
define in an IBM extension section of an OpenAPI definition file. In the API Manager web
application, open the assemble view to review the policies. Keep in mind that the policies
apply to all operations that you defined in the API definition file.
• By default, API Manager creates an assembly with one policy: the invoke policy. At run time,
the API gateway makes an HTTP request to the endpoint in the URL field. This policy calls the
remote endpoint with the API operation that the client sent to the gateway. The target-url
context variable is the target endpoint value that you specify in API Manager. The request
path context variable is the API path name for the operation. You can specify the actual
endpoint address in the URL field of the assembly, or you can specify the URL as a combination
of API Connect context variables.
• For more information, see IBM Documentation for API Connect and use the search string “API
Connect context variables”.
Uempty
Defining a REST API in API Manager © Copyright IBM Corporation 2020, 2021
• In API Connect, you can define a set of message processing rules that apply to all operations
in the API
▪ At run time, the API Gateway enforces the policies that you define in the API assembly
view
• You explore more about the concept of message processing policies in a later unit and
exercise
• In the screen capture, an example of a Switch policy is displayed. To add a Switch policy to an
API assembly:
▪ Locate the Switch policy component under the Logic section in the palette
▪ Drag the policy to the canvas
▪ In the properties editor for the Switch policy, select the path to take
• Use the Switch policy to execute one of a number of sections of the assembly based on which
specified condition is fulfilled.
• In the exercise at the end of this unit, you get an opportunity to add a Switch policy to your API
assembly.
Uempty
4.4. Defining REST operations
Uempty
Defining
g REST
T
operations
Defining
Defi
De fini
fining
gaR
REST
EST AP
ES
EST A
API
PI in
in A
API
PI Manager
PI Man
nag
ag
ger
er
er © Copyright IBM Corporation 2020, 2021
The next sequence of pages describes how to use the graphical features of API Manager to define
the path and operations for an OpenAPI definition.
Uempty
Defining a REST API in API Manager © Copyright IBM Corporation 2020, 2021
The most common HTTP methods in a REST architecture are: GET, POST, PUT, and DELETE. This
slide quickly reviews the meaning of each operation in a REST architecture.
• A GET method retrieves the entity that is represented as a resource path on the server. The
operation is safe because it is read-only: it does not change the information on the server. It is
also idempotent: calling a GET method multiple times in succession returns the same value.
• The POST method represents an update to the entity on the server. Since POST methods
change values, it is not a safe operation.
• The PUT method stores the entity in the request message onto the server.
One of the main points of confusion is whether to use a POST or PUT method to create or
update a resource. The main difference between the two methods is that PUT is an
idempotent operation, while POST is not idempotent. For example, you can use PUT to send a
billing request. A PUT operation sends the entire billing record in the message body.
Therefore, the entity on the server is the same every time you call PUT: it is an idempotent
operation. However, this behavior is not ensured with a POST operation.
• The DELETE operation removes an entity on the server. The API implementation marks the
resource as not available: the actual data record can be removed later.
The remaining slides in this section describe how to configure GET and POST operations in API
Manager.
Uempty
GET /pet/petId=98711
Host: https://petstore/swagger.io/v2
Accept: application/json
Defining a REST API in API Manager © Copyright IBM Corporation 2020, 2021
• The GET request retrieves data from a resource. For example, you'd use a GET request to
retrieve a record from a database.
Uempty
Defining a REST API in API Manager © Copyright IBM Corporation 2020, 2021
• You specified the location of the API implementation during the initial creation of the OpenAPI
definition.
• To complete the API definition, you must specify the exact interface for the API. The interface
includes the API paths, HTTP operation, request, and response message for each API
operation.
• In this example, you want to define an OpenAPI definition that describes the GET
/pet/{petId} operation in a target service endpoint. In the first step, define the path in the
API. The REST architecture is built on the concept of resources: a function or data record that
you identify by a URL path.
• In the second step, you define an action, or a verb, that you associate with a path. The actions
represent operations that you perform on the resource. The GET /pet/{petId} operation
retrieves a pet object from the pet store.
Uempty
POST /pet
• This example shows the Host: https://petstore.swagger.io
expected request and Accept: application/json
response messages for {{
"id": 98711,
calling the POST "category": {
operation of the "id": 98711,
"name": "string"
petstore.swagger.io },
website. "name": "98711doggie",
"photoUrls": [
• The "string"
],
petstore.swagger.io "tags": [
website uses the same {
"id": 0,
response body as the "name": "string"
GET /pet/{petId} }
operation. ],
"status": "available"
}}
Defining a REST API in API Manager © Copyright IBM Corporation 2020, 2021
• Both GET and POST methods are used to transfer data from client to server in HTTP protocol
but the GET method carries a request parameter that is appended in the URL string while
POST carries the request parameter in the message body, which makes it a more secure way
of transferring data. The POST request creates a new resource, such as an entry in a database.
• This example shows the expected request and response messages for calling the POST
operation of the petstore.swagger.io website. If you build the API definition from scratch,
you need to know these values.
• The POST /pet operation accepts the input parameters as fields in a JSON object.
• The petstore.swagger.io website uses the same response body as the GET /pet/{petId}
operation.
• Instead of sending the parameters that are appended to the target-url, the parameters are
located in the body of the request message.
Uempty
Defining a REST API in API Manager © Copyright IBM Corporation 2020, 2021
Uempty
Uempty
Review questions
1. What is the host property?
A. It stores the API Gateway server name
B. It stores the API application server name
C. It stores the API Manager server name
D. It stores the API Connect Toolkit host name
2. What is the purpose of the definitions section?
It stores environment-specific values
It stores a list of published APIs in a catalog
It stores a list of HTTP response status codes
It stores type definitions for the message body
3. True or False: An operation combines a path with an HTTP verb, parameters, and
definitions for requests and responses.
Defining a REST API in API Manager © Copyright IBM Corporation 2020, 2021
Uempty
Review answers
1. What is the host property?
It stores the API Gateway server name
It stores the API application server name
It stores the API Manager server name
It stores the API Connect Toolkit host name
The answer is A
2. What is the purpose of the definitions section?
It stores environment-specific values
It stores a list of published APIs in a catalog
It stores HTTP response message parameters
It stores type definitions for message body data
The answer is D
3. True or False: An operation combines a path with an HTTP verb, parameters, and
definitions for requests and responses. The answer is True.
Defining a REST API in API Manager © Copyright IBM Corporation 2020, 2021
Uempty
This exercise covers how to define a REST API interface from a target service. First, you review the
structure of the operations you call in your API on the target service website. Then, you build the
API operations, parameters, and definitions in the API Manager web application. You also publish
and test the API from the API Manager test feature.
Uempty
Uempty
Overview
In the API Gateway, message processing policies log, route, and transform API request and
response messages. This unit explores the concept of message processing policies. You learn
how to define a set of message processing policies in your API definition file with the API
Manager.
Uempty
Uempty
Uempty
5.1. Overview of message processing policies
Uempty
Overvieww off
message e
processing g
policies
Assembling
A
As
sse
se
emb
mb
m bliliing
n m
ng message
essa
essag
ge
epprocessing
rro
oce
cessssin
cess sin
ng po
policies
olilici
cies
cies © Copyright IBM Corporation 2020, 2021
• Policies and logic constructs are pieces of configuration that control a specific aspect of
processing in the Gateway server during the handling of an API invocation at run time.
• Policies are the building blocks of assembly flows, and they provide the means to configure
capability, such as security, logging, routing of requests to target services, and transformation
of data from one format to another. Policies can be configured in the context of an API or in the
context of a Plan.
• You have already used the policies: Invoke and Switch. This unit introduces other message
processing policies that you can use to implement your APIs.
Uempty
• Message processing policies are a set of processing actions that you apply to API operation
request and response messages. You assemble message processing policies as a sequence of
actions in the assembly view of the API Manager web application.
• The API Manager refers to these configured actions as policies. To differentiate this type of
policy against other policies, this course uses the term message processing policy.
• Although you can build conditional logic constructs and APIs calling actions with policies, the
purpose of policies is not to implement API operations. Message processing policies maintain
and enforce the non-functional requirements of an API at the API gateway.
• The API gateway enforces the message processing policies that you define in the API
definition file. In effect, the message policies apply to all operations that you defined in the
API definition.
• The types of message processing policies that you can apply depend on your choice of API
gateway type. A number of policies run only on DataPower API Gateways.
Uempty
Uempty
User-defined policies
• A user-defined policy for the DataPower API Gateway consists of a package containing
configuration details that define the actions of the policy. You publish the package to the
DataPower API Gateway to make it available to APIs that are deployed there.
• There are two types of user-defined policies, catalog scoped user-defined policies and global
scoped user-defined policies:
Catalog scoped user-defined policies
í Catalog scoped user-defined policies are available to APIs only in the catalogs that you specify. Use
a catalog scoped user-defined policy if you want to limit the availability of your policy on a catalog
specific basis. The possible actions of a catalog scoped user-defined policy are limited to the API
Connect built-in assembly policies.
Global scoped user-defined policies
í Global scoped user-defined policies are available to APIs in every catalog in every provider
organization. Use a global scoped user-defined policy in the following situations:
• You want to make your policy available everywhere rather than limiting its availability to specific catalogs.
• Your policy uses a DataPower implementation, where configuration changes are made directly on the
DataPower API Gateway.
Uempty
You publish an API definition, product, and plan to the API Manager. API Manager sends the
message processing policy to the API gateway and configures an API endpoint according to the
API definition.
1. When the API gateway receives an HTTP request, it validates the message against the API
definition.
2. The API gateway also enforces a series of message processing policies that are defined in the
API definition. In the simplest case, the assembly includes one policy: to call the API
implementation.
3. The API provider implementation receives the request. After it processes the request, it sends
an HTTP response back to the API gateway.
4. If the assembly includes message processing policies after the invoke policy, the gateway
runs these policies before the HTTP response message is sent back to the client application.
Uempty
5.2. Using the assembly editor
Uempty
Using
g the
e
assemblyy editor
Assembling
A
As
sse
se
emb
mb
m bliliing
n m
ng message
essa
essag
ge
epprocessing
rro
oce
cessssin
cess sin
ng po
policies
olilici
cies
cies © Copyright IBM Corporation 2020, 2021
Uempty
• The API Manager application writes the policies and logic constructs in the assemble section
of the x-ibm-configuration extension entry of the OpenAPI document when you save the API
definition file.
• The palette includes a number of expandable and collapsible drawers with the labels Logic,
Transforms, Policies, and Security. When expanded, each drawer lists the available
components.
• The content of the palette depends on the gateway type that is selected for the API in the
OpenAPI definition.
Uempty
• The palette lists the configuration constructions that you can place onto the canvas. More
details related to the palette sections are covered later.
• Logic constructs control the message flow across policies. For example, you can set a Switch
with a sub flow for each API operation. Policies represent actions that the API Gateway runs
on a request or response message.
• The canvas represents the assembly flow: a sequence of policy actions that the API Gateway
applies to HTTP request and response messages.
• The open circle represents the incoming API request, and the filled circle represents the
response that you return to the caller. You must have an invoke action that calls the API from
the gateway. The policies to the left of the invoke policy apply to HTTP request messages. The
policies to the right of the invoke policy apply to the HTTP response message.
• Although you have been using the assembly editor in your exercises, this unit covers more
detail around the various policies that can be implemented, and the use cases associated with
them.
• In the screen capture, the petstore API is displayed with a Switch policy and two Invoke
policies.
Uempty
Uempty
The quickest way to find a message processing policy is to enter the policy name into the filter
bar. To find a policy or logic construct on the canvas, type the name in the search bar.
Uempty
In the properties
editor, change the
settings for the
policy action.
The properties editor reveals more settings for the selected policy.
• In this example, the invoke policy is selected. The invoke properties view has a title, a
description, a URL, TLS profile, timeout, and more settings.
• In this example, the URL is set to an actual endpoint address to which the gateway forwards
the request.
Uempty
• The palette includes a number of expandable and collapsible drawers with the labels Logic,
Transforms, Policies, and Security. When expanded, each drawer lists the available
components.
• The content of the palette depends on the gateway type that is selected for the API in the
OpenAPI definition.
Uempty
• Logic constructs change the sequence in which the gateway runs policy actions.
• Policies, Security, and Transforms perform an action on the HTTP message, or an environment
variable.
• You must specify which type of gateway each API uses in the OpenAPI API definition. The two
gateway types are the DataPower API gateway and the DataPower Gateway (v5 compatible).
• Each DataPower Gateway supports its own set of logic, policies, transforms, and security
policies.
• For example, an operation-switch component is supported by the DataPower Gateway (v5
compatible) gateway type. For the DataPower API gateway, the same function is provided by
the switch component. In some cases, the same policy is supported by both gateway types,
but with a different version number.
• These policies are not interchangeable – you must use the correct policy according to the
gateway type.
• The palette shows the available policies according to the gateway type that is specified for the
API in the OpenAPI definition.
• When you modify your API definitions to use a specific gateway type, you must ensure that
each policy and policy version in the API are supported by the gateway type.
Uempty
5.3. Example scenarios for policy assemblies
Uempty
Example e
scenarioss forr
policyy
assemblies
Assembling
A
As
sse
se
emb
mb
m bliliing
n m
ng message
essa
essag
ge
epprocessing
rro
oce
cessssin
cess sin
ng po
policies
olilici
cies
cies © Copyright IBM Corporation 2020, 2021
Uempty
This list introduces separate example scenarios that you can author with API policies and logic
constructs. This list is not exhaustive: policies cover many other message processing scenarios.
1. In the simplest scenario, you proxy all API operations to an existing API implementation.
2. You use an operation-switch construct to select a sequence of policies based on the API
operation. This policy is a case statement that handles different API operations.
3. Map responses from multiple API calls into a single response.
4. Transform REST API requests to a SOAP service request.
5. Validate properties in an HTTP request message.
6. Store the request message payload into API analytics.
7. Redact specific fields from the response body to obfuscate sensitive data.
The following set of slides explains how to handle these scenarios with policies.
Uempty
Figure 5-18. Example one: Forward an API call with the invoke policy
When you create an API definition, API Manager forwards API operations with an invoke policy.
• The URL in the properties view is where the target endpoint URL is specified.
• The URL can be an actual web endpoint address.
• The URL in the invoke properties view can also be specified as an API Manager context
variable, for example, $(target_url).
• In an assembly policy field that supports variable references, such as the properties view, use
the syntax $(variable).
• Variables can also be concatenated, for example:
$(runtime-url)$(request.path)$(request.search).
Uempty
• The switch policy is used to select a case that matches the operation condition when an API
request is received on the API Gateway type.
• You configured this policy in a prior exercise.
Uempty
Figure 5-20. Example three (1 of 3): Map multiple API calls into a response
In this example, you make two consecutive calls to back-end services and then aggregate the
responses into a single response with the map policy.
• You can define several invoke policies in a single assembly flow.
• By default, the return message from the invoke policy overwrites the response message for
the assembly flow.
• To avoid this behavior, save the response from each invoke policy into a different context
variable.
• For example, in the properties dialog for invokeInventory policy, define a context variable
that is named vInventory in the response object variable field.
• Then, in the properties dialog for invokeSold policy, define a context variable that is named
vSold in the response object variable field.
• You can then reference these variables in the mapping policy editor.
On the next page, you see how these context variables are used by the map policy of the
assembly.
You have an opportunity to build this assembly in the exercise at the end of this unit.
Uempty
Figure 5-21. Example three (2 of 3): Map multiple API calls into a response
Uempty
Figure 5-22. Example three (3 of 3): Map multiple API calls into a response
Uempty
• In this example, a SOAP service is called and returns the result as a JSON object in an HTTP
message.
• You have an opportunity to apply this pattern to the previous mock Soap service you used in a
prior exercise.
Uempty
Uempty
Use the validate policy to check whether the message payload matches a defined schema type at
any stage in the message processing sequence.
Uempty
• For a DataPower API gateway, use the Activity Log tab in API Manager Design view to
configure logging preference for the API activity that is stored in Analytics.
• The information that the policy collects is saved in an API event record, a log entry that
captures the metadata in each API execution event.
• Choose whether to save metadata on the invocation URL (activity), the activity and header
(header), or the activity and message payload (payload).
• You can set different settings for normal operation (content) or when an error occurs when the
API is called (content on error).
• You must associate the API Connect analytics feature with the selected gateway type in Cloud
Manager to retrieve the activity log.
• The activity-log policy captures four types of content:
▪ The none setting indicates that no logging occurs.
▪ The activity setting stores the resource URL that the client called. This option is the
default setting for normal operation.
▪ The header setting stores the activity and the request header.
▪ The payload setting stores the activity, the request header, and the request message
body. This option is the default setting for an error event.
• Note: If you set the activity-log level to none, the option disables notifications for application
developers who use your Developer Portal.
Uempty
Note
If the API is defined to use the DataPower API Gateway, then the Activity Log tab in API Manager
replaces the activity-log policy that is defined in the assembly flow for the DataPower Gateway
(v5 compatible) type.
Uempty
Example seven: Redact specific fields from the response
body to obfuscate sensitive data
• Use the redact policy to completely remove or to redact specified fields from the request body,
the response body, or the activity logs.
• You might find this policy useful for removing or blocking out sensitive data (for example,
credit card details) for legal, security, or other reasons.
• With the DataPower API Gateway, the input to the redact policy must be parsed data. One way
to produce parsed data is to use a parse policy before a redact policy in your assembly flow.
• If you want to apply the action to either request or response data, specify a value of
message.body. The actual content to which the action is applied then depends on the
positioning of the redact policy in the overall assembly flow.
Figure 5-27. Example seven: Redact specific fields from the response body to obfuscate sensitive data
You have an opportunity to perform a redaction in the next exercise by using the mapping policy.
Uempty
5.4. Changing the version of an API
Uempty
Changingg thee
version
n off an
n
API
Assembling
A
As
sse
se
emb
mb
m bliliing
n m
ng message
essa
essag
ge
epprocessing
rro
oce
cessssin
cess sin
ng po
policies
olilici
cies
cies © Copyright IBM Corporation 2020, 2021
You can create multiple versions of an API definition and edit the versions independently. As you
continue to develop your APIs, versioning becomes important. As you make changes to some of
the existing APIs in the next exercise, you create new versions first. This section covers how to
version your APIs.
Uempty
You can create a new version of an API from the Develop page of API Manager.
With the APIs tab selected, select the Save as a New Version option for the API for which you
want to create a new version.
Note
Check the provider organization role permissions to verify whether or not the member can create a
new version for the API.
Uempty
• When you save a new version of the API, you are prompted to type the version number. Then,
click Submit.
• The version corresponds to the info.version property value of the API's OpenAPI definition.
The version.release.modification version numbering scheme is recommended, for
example 2.0.0.
Uempty
The new version of the API is saved and is displayed in the list of APIs.
Uempty
Uempty
Review questions
1. True or False: It is not a recommended practice to implement API operations with policies.
2. What is the message payload?
A. The payload is the input parameters of an API operation.
B. The payload is the API request header.
C. The payload is the API parameter list.
D. The payload is a buffer that the policy assembly uses to process or construct an API response
message.
3. Which policy is only available on the DataPower API Gateway type?
Validate.
Switch.
Invoke.
Set Variable.
Uempty
Review answers
1. True or False: It is not a recommended practice to implement API operations with policies.
The answer is True.
2. What is the message payload?
The payload is the input parameters of an API operation.
The payload is the API request header.
The payload is the API parameter list.
The payload is a buffer that the policy assembly uses to process or construct an API response
message.
The answer is D.
3. Which policy is only available on the DataPower API Gateway type? The answer is B.
Validate.
Switch.
Invoke.
Set Variable.
Assembling message processing policies © Copyright IBM Corporation 2020, 2021
Uempty
This exercise explains how to create message processing policies. You define a sequence of
policies in the assembly view of API Manager. You define an API that exposes an existing SOAP
service as a REST API. You also define an API that transforms responses from an existing service
into a defined message format and map multiple invocations into one using the mapping policy.
Uempty
Uempty
Overview
This unit explores how to define client authorization requirements in the API definition. The client
authorization requirements specify which authentication and authorization standards to enforce.
You learn how to configure API keys, HTTP basic authentication, and OAuth 2.0 authorization
schemes.
Uempty
Uempty
Uempty
6.1. Managing authentication and security
Uempty
Managingg
authentication
n
and
d security
Declaring
Decl
De ccllar
arin
ing cl
cclient
lie
enntt authorization
aut
utho
utho
hori
riza
za
zati
attiion
ion
on rrequirements
eq
e qui
qui
uire
emme
ent
ntss © Copyright IBM Corporation 2020, 2021
Uempty
• Registries that are supported in the Cloud Manager and API Manager:
▪ Local user registry
▪ URL authentication
▪ LDAP
• Default user registry is the local user registry that cannot be configured.
• The admin user is unique and always remains in the Cloud Manager local user registry.
• You can add user registries from the Resources > User Registries page in Cloud Manager.
• In the Cloud Manager and API Manager, a registry cannot be changed after a user is invited to
be the owner of a provider organization, even if the invitation is not yet accepted.
• The example that is shown is taken from the Cloud Manager user interface and it displays the
user registries that are configured for Cloud Manager and API Manager.
• In the example, Cloud Manager and API Manager use separate local user registries.
Uempty
Local user registry An internal registry that is stored with API Authentication of
Connect users
LDAP directory Lightweight Directory Access Protocol Authentication,
(LDAP) API security
• By using an enterprise registry such as LDAP, you have access to all the users that are already
defined in the LDAP directory when it is configured in API Connect.
• A local user registry cannot be pre-populated since users can only be added by using Cloud
Manager, API Manager, or the Developer Portal user interfaces.
Uempty
TLS profiles
• TLS profiles are used in API Connect to secure transmission of data through websites
• TLS (Transport Layer Security) certificates ensure that information that you submit is not
going to be stolen or altered
• API Connect provides a Default TLS profile
Uses self-signed certificates
Can be used for development and testing
• In API Connect, TLS profiles are used to secure transmission of data through websites.
• Transport Layer Security (TLS) are cryptographic protocols that provide communications
security over a computer network.
• API Connect might need to transmit data across an untrusted network, for example, when
accessing the Gateway, email server, or LDAP server. TLS provides secure network layer
transportation of data between two parties.
• The course lab environment uses the default TLS profiles that are provided with API Connect.
Uempty
• API Connect provides two types of TLS Profiles: a Default TLS Server and Default TLS Client
Profile. Information regarding the protocol, self-signed certificate, and cipher settings can be
viewed or edited by clicking the relevant profile.
• For production systems, consider replacing the certificates with those created by your
organization or with one from a certificate authority (CA).
Uempty
6.2. API security concepts
Uempty
APII securityy
concepts
Uempty
• To enforce authentication and authorization for your API, define and apply security definitions
in your API definition. Your gateway authenticates users to verify the identity of the client. The
gateway authorizes access to an API operation for clients that you allow.
• This unit discusses how to authenticate and authorize API clients with IBM API Connect. You
must consider other aspects of API security, but API security definitions do not cover those
aspects. For example, API security definitions do not cover encryption and integrity. In API
Manager, you define transport level security (TLS) profiles to specify the keys and certificates
that secure data transmission over a network.
• Last, consider the fact that not every API needs to be secured. Some resources might not
contain sensitive information.
Uempty
The security definitions that you create in an API definition configure the client authentication and
authorization schemes.
Uempty
API key The API key scheme authenticates the API caller
from the client ID and client secret credentials
Uempty
6.3. Identify client applications with API key
Uempty
Identifyy clientt
applicationss withh
APII key
• When you create an API key security definition in an API, you specify the credentials that an
application must provide to identify itself when calling the API operations.
• You can require that, when calling an API operation, an application must provide either a client
ID, or a client ID and client secret; you create an API key security definition to specify a
credentials requirement. If you require that an application must provide both a client ID and
client secret, you must create two API key security definitions, one for each type of
credentials.
Uempty
• The API key uniquely identifies the client application. If you enable clientID as a security
requirement in your API, the client must provide its client ID on every API operation call. In
addition to establishing the client identity, API Connect uses the client ID value for analytics
and to enforce operation quotas.
• The client secret is a unique value that API Connect generates. When a client developer
registers an application, the API Connect Developer Portal creates and provides the client ID
and client secret.
• You can create a new OpenAPI in API Manager and clear the option to Secure using Client ID
during creation. A security definition that is named clientIdHeader with an API Key is still
added to the security definitions for the API. The clientIdHeader security definition defaults
to an API Key type that specifies the Client ID as the unique identifier.
• If you want the API to use the API Key, you must still add it in the Security tab of the Design
view for the API.
Uempty
When the Secure using Client ID option is selected during the creation of the API, the client ID
API Key type is generated into the security definitions for the API.
Uempty
• When the option that is named Secure using Client ID is selected during the creation of the
API, the client ID API Key type is generated into the security definitions for the API.
• The client ID API Key is also enabled on the security tab for the API.
Uempty
You can add the client secret API Key security definition after you create the client ID API Key
security definition. The security definition contains security settings that you enforce to define
access control requirements for the operations in the API, by applying the security definition to an
API.
Uempty
Uempty
• When you enable a security definition, you automatically enable the setting for every
operation in your API.
• You can override this behavior by selecting a specific API operation and changing the security
setting in the API operation.
Uempty
• You cannot apply more than two API key security definitions to an API.
• If you apply an API key security definition for a client secret, you must also apply an API key
security definition for the client ID.
• If you require the application developer to supply both client ID and client secret, you must
apply two separate API key security definitions.
• The API keys are sent in the request header or as a query parameter. Both API keys must
specify the same location, either the header or query parameters.
Uempty
GET https://localhost:4002/api/products
Content-Type: application/json
Accept: application/json
X-IBM-Client-Id: b91e945a-21wf-4869-bb7bay130d
X-IBM-Client-Secret: n29ax9RMn3ai2iasdf92DKSF92asdf
As query parameters:
GET https://localhost:4002/api/products?client_id=
b91e945a-21wf-4869-bb7bay130d
&client_secret=n29ax9RMn3ai2iasdf92DKSF92asdf
Content-Type: application/json
Accept: application/json
Figure 6-20. Example: Client ID and client secret in the message header
• The names of the HTTP headers and the query parameters are the default names that API
Connect sets. You can change the name of these fields in the API key security definitions.
• As the API developer, you choose whether to store API key information as headers or query
parameters. The logical place to put client metadata is in the request message header.
However, if you want to test a simple GET operation, it is easier to specify the client ID and
client secret information as query parameters.
Uempty
6.4. Authenticate clients with HTTP basic
authentication
Uempty
Authenticatee clientss
with
h HTTPP basicc
authentication
Uempty
base64 encoding
• The client writes the HTTP basic authentication information in the HTTP request message
header. The name of the header is Authorization, followed by the keyword basic. The
username and password are separated with a colon. Before the client sends the request
message, it encodes the username, colon, and password with the base64 encoding scheme.
• Keep in mind that this encoding scheme is not encryption – anyone who intercepts the
message can decode the message and retrieve the username and password.
• Base64 is a scheme for encoding binary data as text. The most common use of Base64 is to
encode photo, video, and document attachments to email.
Uempty
The HTTP basic authentication header appears in the start of the request message. The data in the
HTTP message body is specific to the web service operation. The service provider does not use
the message body data during HTTP basic authentication.
Uempty
• Before you set up a basic authentication security definition, you need to configure a user
registry. API Connect supports three types of user registries: Authentication URL user registry,
LDAP user registry, and Local user registry.
• You can also create a user registry that is specific to a provider organization by selecting the
OpenID Connect (OIDC) option. An organization-specific OIDC user registry is used for
onboarding and authenticating Developer Portal users, while a shared OIDC user registry can
be used for onboarding and authenticating Cloud Manager, API Manager, and Developer Portal
users.
• To create a user registry, you can use either API Manager or Cloud Manager.
• When you create a registry in API Manager, it is visible only to your provider organization.
When you create a registry in Cloud Manager, you can make it visible to multiple provider
organizations.
• To set up a user registry in API Manager, click the Resources option from the navigation menu.
▪ Select User Registries. Then, select create.
• You can also authenticate the client username and password with an LDAP user registry.
Specify the name of the user registry profile in this field. You must set up the LDAP user
registry profile separately with the API Manager web interface.
Uempty
3
Declaring client authorization requirements © Copyright IBM Corporation 2020, 2021
The page shows the Create user registry page in the API Manager web application
1. Type a unique title and name for your authentication URL user registry.
2. Type the network endpoint for the authentication service. If the client sent a valid username
and password, the authentication service returns an HTTP status code of 200 OK. Otherwise,
the service returns a 401 Unauthorized status code.
3. Optionally, enter the name of a TLS profile. The Transport Layer Security (TLS) profile contains
the settings and certificates that the API gateway uses to set up an HTTPS connection to the
client application. You must set up a TLS profile separately with the API Manager web
interface.
The user registry is added to the registries on the resources page in API Manager.
Uempty
Uempty
Add basic authentication to the security schemes. The authentication URL can be selected.
Uempty
Apply the basic authentication security to the API from the Security option in API Manager.
Uempty
6.5. Introduction to OAuth 2.0
Uempty
Introduction
n to
o
OAuthh 2.0
Uempty
What is OAuth?
• OAuth defines a way for a client to access server resources on behalf of another party
• It provides a way for users to authorize a third party to their server resources without sharing
their credentials to a third-party application
• It separates the identity of the resource owner (user) from a third-party application that acts
on behalf of the user
• The resource owner specifies which resources the OAuth client can access, and for how long
• The OAuth specification solves a specific problem: how to delegate access rights to a
third-party client that works on behalf of the user. Before OAuth, third-party applications
would ask and store the user’s username and password within the application. This process is
risky, as the server cannot distinguish between the user and the third-party application. One
analogy in the real world is to hand over your house keys to a cleaning service. You must have
a high degree of trust in the client to give them complete access to your home.
• With OAuth, the client does not use your credentials. Instead, an authorization service gives a
temporary pass to the client, so it can do a limited set of tasks in a fixed time period. As the
user, you can tell the authorization service to revoke the temporary pass at any time.
• Although OAuth is more complicated than handing over your credentials to the client, it is a
safer mechanism that gives the user control over the third-party client’s actions.
Information
OAuth separates the role of the client from the role of the resource owner.
The client is issued a different set of credentials than the credentials of the resource owner.
Instead of using the resource owner’s credentials to access a protected resource, the client
obtains an access token, which is a string that denotes a specific scope, lifetime, and other access
attributes.
Uempty
1 2
• Whenever you sign up for a web-based application or a mobile application, you create an
account on the server with a username and password. The process becomes tedious for users
when they sign up for dozens of applications.
• Social networks, such as Facebook and Twitter, already link your identity to a user account.
Therefore, many applications use your social network account to create an account.
• This scenario has four participants: you as the user, the third-party application as a client, the
shared resources on the web, and the authentication service. You want the third-party
application to access some (but not all) of your information from the service. That is, you want
the client to act on your behalf to access resources on the service.
• In this example, the third-party application, the Delivery Tracker, wants to access your
product inventory records from the inventory API. The application opens a new page from the
authorization service. After you log in and allow the application to access the information, the
authorization service grants an access token to the application. At no time does the third-party
application see your use name or password on the authorization service.
Uempty
Take a closer look at the three actors in the OAuth scenario. Alice is the owner of inventory
records. As the user, Alice wants to feed the current inventory records to a package tracker
application. The Delivery Tracker is a third-party client application that wants to access Alice’s
inventory records. Last, the inventory API is a service that securely stores Alice’s records. This
service also manages access to the records from Alice and third-party applications that act on
Alice’s behalf.
The next 10 slides cover the details of this interaction following the sequence:
1. Alice, as the resource owner, requests access to the inventory API from the client application,
the delivery tracker app
2. The OAuth client sends the resource owner a redirection to the authorization service
3. The resource owner authenticates against the authorization service
4. The authorization service returns a web form to the resource owner to grant access
5. The resource owner submits the form to allow or to deny access
6. If the resource owner allows access, the authorization service sends the OAuth client a
redirection with the authorization grant code
7. To access the resource, the OAuth client sends the authorization grant code and other
information to the authorization service
8. If the authorization service verifies the grant authorization information, it returns an access
token to the OAuth client
9. The OAuth client sends the access token to the resource service
10. If the access token is valid for the requested resource, the resource server allows the OAuth
client to access the resource
Uempty
1
Inventory
OAuth Provider
Authorization service
In this scenario, Alice is the owner of inventory records in the inventory API. Alice wants to track
the delivery status of her purchases through the delivery tracker application. Alice is the resource
owner, and the delivery tracker application is an OAuth client application. Alice starts the process
when she selects the “look up your deliveries” option in the delivery tracker application.
Uempty
2 Inventory
OAuth Provider
Authorization service
In the second step, the delivery tracker application requires the resource owner’s authorization
before it can access the owner’s inventory records. Instead of asking Alice directly for her user
credentials, the client application redirects Alice’s request to an authorization service.
Uempty
OAuth Step 3: Authenticate owner with authorization
service
3. The resource owner authenticates against the authorization service
Inventory
OAuth Provider
3
Authorization service
In the third step, the authorization server asks for Alice’s user credentials to verify her identity.
Uempty
OAuth Step 4: Ask resource owner to grant access to
resources
4. The authorization service returns a web form to the resource owner to grant access
Inventory
4 OAuth Provider
Authorization service
Figure 6-36. OAuth Step 4: Ask resource owner to grant access to resources
The authorization service returns a web form to ask Alice whether she grants the OAuth client
access to her resources. That is, does the delivery tracker application have permission to look up
inventory records from the API, on Alice’s behalf?
Uempty
OAuth Step 5: Resource owner grants client access to
resources
5. The resource owner submits the form to allow or to deny access
Inventory
5
OAuth Provider
Authorization service
Figure 6-37. OAuth Step 5: Resource owner grants client access to resources
The resource owner, Alice, submits the web form to allow or deny access to her resources.
Uempty
OAuth Step 6: Authorization service sends authorization
grant code to client
6. If the resource owner allows access, the authorization service sends the OAuth client a
redirection with the authorization grant code
Inventory
OAuth Provider
Authorization service
Figure 6-38. OAuth Step 6: Authorization service sends authorization grant code to client
The authorization service never transmits the resource owner’s username and password to the
OAuth client. Instead, the service sends an authorization grant code: a token that the OAuth client
can use to access Alice’s resources on her behalf.
Uempty
OAuth Step 7: Client requests access token from
authorization service
7. To access the resource, the OAuth client sends the authorization grant code and other
information to the authorization service
Inventory
OAuth Provider
Authorization service
Figure 6-39. OAuth Step 7: Client requests access token from authorization service
• The OAuth client sends three pieces of information to the authorization service: an
authorization grant code, the client ID, and the client secret.
• The API Key (client ID and client secret) identifies the calling application to the resource
service that runs the APIs.
• The Delivery tracker application needs to register with the authorization service, during the
setup of the OAuth process, before any OAuth requests are made.
Uempty
OAuth Step 8: Authorization server sends authorization
token to client
8. If the authorization service verifies the grant authorization information, it returns an access
token to the OAuth client
Inventory
OAuth Provider
Authorization service
Figure 6-40. OAuth Step 8: Authorization server sends authorization token to client
The authorization service verifies the grant authorization information. Then, it returns an access
token to the OAuth client.
Uempty
OAuth Step 9: OAuth client sends access token to resource
service
9. The OAuth client sends the access token to the resource service
9 Inventory
OAuth Provider
Authorization service
Figure 6-41. OAuth Step 9: OAuth client sends access token to resource service
• The client application sends the access token to the resource service.
• The authorization service and the resource service can run on the same server.
Uempty
OAuth Step 10: Resource server grants access to OAuth
client
10. If the access token is valid for the requested resource, the resource server allows the OAuth
client to access the resource
10
Inventory
OAuth Provider
Authorization service
Figure 6-42. OAuth Step 10: Resource server grants access to OAuth client
If the access token is valid for the requested resource, the resource service allows the OAuth
client to access the resources. Only the APIs that were allowed by the resource owner can be
accessed by the delivery tracker application.
Uempty
Uempty
Review questions
1. Which one of the following sentences best describe the client ID?
A. The client ID represents the person who signs on to the web application.
a. The client ID represents the client application.
b. The client ID represents the client application developer.
c. The client ID represents the resource owner.
Uempty
Review answers
1. Which one of the following sentences best describe the client ID?
A. The client ID represents the person who signs on to the web application.
a. The client ID represents the client application.
b. The client ID represents the client application developer.
c. The client ID represents the resource owner.
The answer is B.
Uempty
Overview
This unit examines the OAuth 2.0 provider. In an OAuth 2.0 message flow, the OAuth provider is
an authorization server that issues access tokens to authorized clients. In an API Connect cloud,
you can configure the API gateway to act as an OAuth 2.0 Provider. This unit explains how to
create and configure a Native OAuth Provider in either the Cloud Manager or API Manager
graphical applications.
Uempty
Uempty
Uempty
7.1. What is an OAuth provider?
Uempty
Whatt iss an
n OAuth
h
provider?
Uempty
OAuth Provider
Authorization service
• The OAuth Provider is a security service that authorizes access to API operations.
• Instead of sharing passwords, OAuth uses authorization tokens to verify the identity between
clients and service providers.
Uempty
OAuth
Uempty
Figure 7-6. What are the steps to secure an API with OAuth 2.0?
To secure your API with OAuth 2.0, you must configure two services in IBM API Connect:
1. Create an OAuth 2.0 Provider.
▪ The OAuth 2.0 Provider is a security service that provides the token and authorize API
operations.
▪ You configure the settings for the OAuth 2.0 Provider in the Resources page in either Cloud
Manager or API Manager. When you configure the OAuth Provider in Cloud Manager, the
OAuth Provider can be applied to all provider organizations. When configured in API
Manager, the OAuth Provider is visible to or only selected provider organizations.
▪ The API gateway implements the OAuth 2.0 Provider API operations
2. For each API that you want to secure, declare an OAuth 2.0 security definition
▪ You declare which API operations you want to secure at the API Gateway
▪ You specify how the gateway handles authentication, authorization, and token
management tasks
Uempty
7.2. Create an OAuth provider
Uempty
Create
e an
n OAuth
h
Provider
Uempty
Uempty
• When you configure a Native OAuth Provider, you must first configure the authentication
registry that is used to extract the user credentials and authenticate their identities.
• User authentication is required for the implicit and access code (authorization code) grant
types.
• You can create the authentication registry either in Cloud Manager or API Manager.
• When you create the authentication registry in Cloud Manager, the registry can be used by
multiple provider organizations.
• In the example, an authentication URL user registry is selected.
Uempty
• An Authentication URL user registry provides a simple mechanism for authenticating users by
referencing a custom identity provider.
• Type the URL for the authentication service. API Connect makes a GET call to the URL to
initiate the authentication process. The call includes the username and password is collected
from the user in its authorization header. Either 200 OK or 401 Unauthorized is returned.
Uempty
The registry is added as a registry in Cloud Manager or API Manager and can be referenced by the
provider organization.
Uempty
The next sequence of pages provides an example of how to configure a Native OAuth Provider.
From the Resources page, select the OAuth Providers option. Click Add. Then, select Native
OAuth provider from the list.
Uempty
On the first page of the create Native OAuth Provider, you type the title, description, and base
path. You must also select the gateway type.
Uempty
• In the supported grant types section, select which of the four OAuth flows you want to use.
An OAuth flow is the procedure that client applications follow to request access to a shared
resource. A later slide explains these grant types.
• Select either a public or confidential OAuth client type. A later slide explains the implications
of each client type.
Uempty
Create a scope for the OAuth provider. When the client application requests an access token, it
can specify an access scope. For example, you can create two scopes for your API: one that
authorizes read access to an account, and one that authorizes updates to the account.
Uempty
Configure the settings for collect credentials, authenticate users, and authorize users.
In the example, the authentication URL registry that was created earlier is selected for the
authenticate users' settings.
1. To authenticate the client, the authorization service must extract the client identity. You can
retrieve client credentials from the context variable of a web form or from the HTTP Basic
authentication header.
2. The Authentication setting determines how the authorization service verifies the identity of
the client. In this example, the OAuth Provider sends the extracted client identity to the
authentication URL. If the service at the authentication URL returns a status code of 200, the
OAuth provider proceeds to the next step in the OAuth flow.
3. The Authorization setting determines how the OAuth provider authorizes access to resources.
The Authenticated setting automatically grants access to any authenticated client. You can
set this value to disabled.
Uempty
Uempty
Uempty
• The client type setting defines whether the client application can keep a client password
secret. For example, an access-restricted web server hosts a web application. Nobody except
the system administrator can access the server and see the client password. This scenario is
an example of a confidential client.
• If the same web application runs as a JavaScript application on a web browser, a malicious
user can break into the application and retrieve the password. In this case, the application is
considered a public client because it cannot ensure that it can keep the client password
confidential.
Uempty
To use the Native OAuth Provider, sign on to API Manager and open the catalog where the OAuth
Provider is used.
Uempty
• Enable the Native OAuth Provider and the user registry from the Manage page of the catalog.
• Products and APIs that are published to this catalog can now use OAuth security.
Uempty
7.3. Secure an API with an OAuth 2.0
authorization
Uempty
Secure
e ann APII with
h
an OAuthh 2.0
0
authorization
Uempty
Inventory
• You specify:
Inventory
The name of the OAuth Provider
Published APIs
Which OAuth 2.0 message flow to use Shared resources
The scope that is defined by the OAuth Provider
OAuth
OAuth
OAuth Provider
Authorization service
Uempty
Open the API definition in API Manager. With the Design tab selected, click the Security
definitions option. Click Add.
Uempty
Uempty
Uempty
also becomes
visible and can
be selected.
9. Save the
security settings.
Creating an OAuth 2.0 provider © Copyright IBM Corporation 2020, 2021
Uempty
Uempty
Review questions
1. In API Connect, which OAuth grant type setting represents the identity of the client
application, rather than the resource owner?
a. Implicit
b. Password
c. Application
d. Access code
2. Which of these ways can OAuth scopes be used to define custom access to APIs?
a. Included with the authorization request to the user to approve or deny access to the resource.
b. Limit access tokens to only the scopes the user has approved.
c. Provide different scopes for read or update access to API operations
d. All the above.
Uempty
Review answers
1. In API Connect, which OAuth grant type setting represents the identity of the client
application, instead of the application user?
a. Implicit
b. Password
c. Application
d. Access code
The answer is C.
2. Which of these ways can OAuth scopes be used to define custom access to APIs?
a. Included with the authorization request to the user to approve or deny access to the resource.
b. Limit access tokens to only the scopes the user has approved.
c. Provide different scopes for read or update access to API operations.
d. All the above. The answer is D.
Uempty
In this exercise, you examine two of the three parties in an OAuth 2.0 flow: the OAuth 2.0 provider
and the API resource server. You define a Native OAuth provider to authorize access and issue
tokens. In the case study application, you declare an OAuth 2.0 security constraint that enforces
access control with the OAuth 2.0 provider.
Uempty
Uempty
Overview
Before you publish an API where customers can access it, you need to test it and ensure that it is
defined and implemented correctly. IBM API Connect offers tools for running both simple and
complex tests, in different environments. Up to this point in this course, you have been testing
your APIs by using the Assembly tab so that you can ensure that your APIs are defined and
implemented correctly. This unit covers more extensive testing and debugging options in IBM API
Connect.
Uempty
Unit objectives • Explain the testing and debugging features of API Manager
• Describe what is required to test an API in the Test tab
• Define the steps to test an API in the Test tab
• Explain how to activate an API
• Explain the purpose of the Endpoints tab
Uempty
Uempty
8.1. Activating an API
Uempty
Activating
g an
n API
Uempty
Activating an API (1 of 3)
• After you have created an API definition you can activate it to make it available for testing.
• When you activate an API, API Connect automatically completes the following actions:
Creates a draft Product, adds the API to the Product, and publishes the Product to the sandbox catalog
so that the API is available to be called. The Product has the title api_title auto product. Note that
if you later want to delete the draft Product, you cannot delete it directly; instead, delete the API and
the draft Product is deleted together with the API.
Subscribes the sandbox test application to the Product so that you can immediately test the API in the
test environment.
• To activate an API, you must be assigned a role that has the Product:Manage and
Subscription:Manage permissions. The pre-supplied Developer role has these permissions by
default.
You must activate your API before you can test it.
Uempty
Activating an API (2 of 3)
To activate an API:
1. In the navigation pane, click Develop, then select the APIs tab
2. Click the title of the API that you want to work with
3. Move the activation slider control to the on position
• The API activation will not complete successfully if lifecycle approval is enabled in the
sandbox catalog for the Stage, Publish, or Replace actions. If any such lifecycle approvals are
enabled, then to be able to activate and API they must be disabled.
• To activate an API from the API Designer user interface, you must be connected to a
Management server; API activation is not available with API Designer in offline mode.
• Products that contain an API with a Swagger property by using regex that includes lookahead
assertions, such as "(?" cannot be validated or published. An error message is returned.
• You can also activate an API during the creation process, and on the API test page.
Uempty
Activating an API (3 of 3)
• If you stop an API, the application subscription is deleted, and the auto Product is removed
from the sandbox catalog.
• If you make a change to the API, it is republished automatically. You can also republish a
running API manually by stopping it and then reactivating it.
• The error indicator shows whether there are validation errors in the OpenAPI source for the
API definition. If there are errors, click the arrow for more details.
Uempty
Important:
The fields in the sandbox Sample Application Credentials section
apply to the assembly tool's built-in client application and not to
any application that you created. The credentials that display
here are the default credentials that display in the assembly tool
Test panel's "Identification" section.
Uempty
The assembly tool's Endpoints tab opens a page that displays information for use when you call
APIs externally. This tab displays only when an API's status is Online (the API was activated).
The following values for the API are displayed in the Endpoints tab so that you can copy them and
paste them into calls:
• Base API Endpoint: The URL representing the endpoint of the API that you are editing and
testing. To invoke the API, append one of its supported queries (path and parameters) to this
URL.
• Client ID and Client Secret: The values of the built-in test application's client ID and client
secret. You can invoke APIs externally by providing the application's credentials in the request
header.
• OAuth Token URL: If you specified an OAuth provider in the API's security definition, then this
field displays the URL where you can obtain an access token for calling the API.
• OAuth Auth URL: If you specified an OAuth provider in the API's security definition, then this
field displays the URL where you can submit an access token and receive an authorization
token in exchange. You then use the authorization token when calling the API.
• Rate Limit: If you specified a rate limit on the Security panel when you created the API, the
limit is displayed here for reference. If you did not specify a rate limit, the default rate limit
displays.
Uempty
8.2. Testing options in API Connect
Uempty
Testing
g optionss in
n
APII Connect
Uempty
Uempty
• Up to this point in this course, you have been using the Assembly tab to perform simple testing
of your APIs.
• If you are testing an API that contains references to API properties, only those references that
are defined inside the API assembly are resolved and replaced with their corresponding
values when you invoke the API in the assembly test tool; property references that are defined
outside of the API assembly are not resolved.
• Due to Cross-Origin Resource Sharing (CORS) restrictions, the assembly test tool cannot be
used with the Chrome or Safari browsers on the macOS Catalina platform.
Procedure
By now, you should be familiar with this procedure.
To test an API by using the Assembly tab, complete the following steps.
1. If you are using API Designer, set the mode to Online using the Options menu on the main
page.
2. In the navigation pane, click Develop, then select the APIs tab.
3. Click the title of the API that you want to work with.
4. Click Assemble to open the Assemble view, then click the Test icon.
5. If you are testing the API for the first time and, when you created the API definition, you
selected the Activate API option, your test setup will already be configured, and you can
proceed immediately to the next step to test your API. Otherwise, click Activate API to have
your test setup configured. Note: If you are retesting your API after making changes, click
Republish product to make your changes available.
Uempty
6. In the Operation section, select the API operation that you want to test, then click Invoke. The
API response is displayed in the Response section. Note: If you receive a message relating to
an untrusted certificate, click the link that is provided, accept the certificate, then return to the
test environment and click Invoke again. The message also mentions a lack of CORS support
on the server, but this is just one possible cause for the connection failing.
Uempty
• The next topic covers more details around using the Test tab with REST and SOAP APIs.
• More about how the Test tab is used to test GraphQL queries is covered in a later unit.
Uempty
Uempty
8.3. Using the Test tab to debug your API
Uempty
Using
g the
e Testt tab
b
to debugg yourr API
Uempty
Uempty
Figure 8-16. Prepare your API for debugging with the Test tab
To invoke your API in the Test tab, the following requirements must be satisfied:
The DataPower API Gateway is configured to support the API probe
• To enable the Test tab's trace feature, the DataPower API Gateway must be configured to
support gateway peering and the gateway probe. In a gateway service running in Kubernetes,
the API probe is automatically enabled. In a gateway service running external to Kubernetes,
the DataPower configuration must be added to the application domain supporting API
Connect.
• Check with your administrator to confirm that gateway peering, and the gateway probe are
enabled.
The API uses the DataPower API Gateway
• A gateway exposes APIs to calling applications and provides processing actions that enable
the APIs to integrate with various endpoints.
• API Connect supports two versions of the DataPower Gateway, but you can only debug APIs
that use the DataPower API Gateway. The V5-compatible gateway is not supported. If your
API definition has CORS enabled but you cannot see the Test tab, the API is probably
configured to use the wrong version of the gateway. You can determine which gateway your
API uses by completing the following steps:
a. Log in to API Manager.
b. In the navigation list, click Develop, then select the APIs tab.
c. Click the title of the API you want to test.
d. On the API's Design page, locate the Gateway field and note which option is selected.
Uempty
You can change the gateway selection for an API on the Design page, but you must ensure that
the policies used in the API's process flow are compatible with the new selection.
CORS is enabled in the API definition
• Cross-Origin Resource Sharing support ensures that the API can be accessed from another
domain. CORS support must be enabled for your API to be properly invoked and traced. If your
API uses the API Gateway but you cannot open the Test tab, it's possible that CORS was not
enabled in the API definition. You can enable CORS for your API by completing the following
steps:
a. Log in to API Manager.
b. In the navigation list, click Develop.
c. On the Develop page, click the name of the API you want to test.
d. On the API's Design page, locate the CORS field and select it to enable support.
e. Click Save in the page header.
The API is published in the sandbox catalog with the default Product/Plan
• The Test tab is intended for use with APIs in the built-in sandbox catalog. You can only use the
Test tab to debug APIs that are created with the default Product/Plan and published to the
sandbox catalog.
• When you publish (activate) an API, the API is enabled online and becomes available for use.
You cannot execute an offline API, even for testing purposes. You can set an API online by
completing the following steps:
a. Log in to API Manager.
b. In the navigation list, click Develop.
c. On the Develop page, click the name of the API you want to test.
d. In the Design page header, click Offline to toggle the API to its Online state.
Uempty
• Use the Request section of the page to set up the request URL, the authentication mechanism,
and the request parameters. Complete the following steps to fill in the fields that are needed
for configuring the request.
a. Select an operation and request URL from the list provided.
b. On the Parameters tab, define header, query, and path parameters. An empty row is
provided for you to define parameters; enter the parameter name in the Key field, select
query, header, or path in the Located in field , and supply a string value in the Value field.
As you define a new parameter, a further empty row is added automatically.
Default header parameters and values are provided. For example, if the API has client ID
or client secret definitions that are applied, the corresponding keys are added as header
parameters, with the values preset.
c. If your API definition uses Basic authorization for the security setting, click the
Authentication tab and provide the username and Password that is needed for
authenticating with the user registry. When you invoke the API, API Connect populates a
header by using the provided information. If your API definition does not use Basic
authorization, the Authentication tab is not available.
d. If the operation is POST or PUT, set up the request body.
- Click the Body tab.
- Type the information for the body of the request.
• When your API request is configured, click Send to execute the call.
▪ If a message displays indicating "No Response", the API call cannot be completed.
Possible causes of this problem are as follows:
Uempty
- CORS is not enabled in the API’s definition. Edit the API’s definition and enable CORS.
Then, save the change and publish the API. If you are using your own client app,
remember to subscribe it to the API again after publishing.
- The gateway service URL has an invalid certificate. Follow the instructions to accept
the certificate and continue testing.
- The browser cannot connect to the gateway service
Uempty
media_type/ Specify the type of content that the response headers should use. The default is
Accepts subtype application/json.
If you are using the built-in test application in the sandbox catalog, the value is pre-
X-IBM-
client_ID_val populated automatically. If you are using your own client application, replace the
Client-Id value with the client ID of your application.
If you are using the built-in test application in the sandbox catalog, the value is pre-
X-IBM-
Client_secret_value populated automatically. If you are using your own client application, replace the
Client-Secret value with the client secret of your application
Authorization Bearer access_token Encode the token in base64. API Connect cannot encode the token for you.
Specify the type of content that the response body should use; for example,
Content-Type media_type/subtype application/json or image/png.
The table that is displayed on this slide lists some common header definitions that are used in a
request. You add a Content-Type header definition to a request in the exercise at the end of this
unit.
Uempty
Uempty
Uempty
Unit summary • Explain the testing and debugging features of API Manager
• Describe what is required to test an API in the Test tab
• Define the steps to test an API in the Test tab
• Explain how to activate an API
• Explain the purpose of the Endpoints tab
Uempty
Review questions
1. True or False: The Local Test Environment is used to assemble policies.
2. True or False: An API must be online before it can be tested in the Test tab.
3. Which is not a testing method that is found in API Manager
a. Assembly Tab
b. Source code testing
c. Test Tab
d. Local Test Environment
Uempty
Review answers
1. True or False: The Local Test Environment is used to assemble policies.
The answer is False. The assembly tab is used to assemble policies in an API definition.
2. True or False: An API must be online before it can be tested in the Test tab.
The answer is True. An API must be online before it can be tested in the Test tab.
3. Which is not a testing method that is found in API Manager
a. Assembly Tab
b. Source code testing
c. Test Tab
d. Local Test Environment
The answer is b.
Uempty
• This exercise covers the use of the Test tab to test your APIs. Up to this point in this course,
you have been using the Assembly tab to perform simple testing of your APIs.
• In this exercise, you test APIs you built in prior exercises. As an introduction to the Test tab,
you use the Test tab to test a SOAP API (InventoryService) and REST API (petstore). In a later
exercise, you use the Test tab to test a GraphQL API.
Uempty
Exercise • Use the Test tab to test and debug a SOAP API
objectives • Use the Test tab to test and debug a REST API
Uempty
Overview
This unit describes the process of creating and testing a GraphQL API. You examine the definition
of a GraphQL API, its advantages and disadvantages, and the differences between GraphQL APIs
and REST APIs. You learn how to create a GraphQL API in API Manager. You learn the definition of
a GraphQL schema and how to query a GraphQL API by using queries and mutations. You learn
how to test a GraphQL API by using the Test tab in API Manager.
Uempty
Uempty
Creating and Testing a GraphQL API © Copyright IBM Corporation 2020, 2021
Uempty
9.1. Introduction to GraphQL APIs
Uempty
Introduction
n to
o
GraphQLL APIs
Uempty
Creating and Testing a GraphQL API © Copyright IBM Corporation 2020, 2021
• GraphQL is a static strong-typed query language and a server-side runtime for application
programming interfaces that let clients declaratively specify their data requirements
• GraphQL is not tied to any specific database or storage engine and is instead backed by the
client’s existing code and data
• As a reminder, an application programming interface or API defines business or technical
capability as a set of operations
• Facebook developed GraphQL internally in 2012 before publicly releasing it in 2015
• Facebook needed a data-fetching API powerful enough to describe all of Facebook, yet simple
enough to be easy to learn and used by their product developers
• On 7 November 2018, the GraphQL project was moved from Facebook to the newly
established GraphQL Foundation, hosted by the Linux Foundation
• On 9 February 2018, the GraphQL Schema Definition Language became part of the
specification
• And now today, GraphQL powers hundreds of billions of API calls a day
Uempty
Uempty
• API maintainers have the additional task of writing maintainable GraphQL schema
Uempty
Creating and Testing a GraphQL API © Copyright IBM Corporation 2020, 2021
This page outlines the differences and similarities between REST and GraphQL.
For REST:
• Each request usually calls exactly one route handler function
• You construct the shape of the response yourself
• The data can be gathered by accessing multiple endpoints
• The only way for a client to download data is by hitting endpoints that return fixed data
structures
• REST is the API deployment industry standard for companies
• And API analytics are easier to obtain for REST, due to the limited amount of tooling for
GraphQL
For GraphQL:
• One query can call many resolvers to construct a nested response with multiple resources
• The GraphQL execution library builds the shape of the response to match the shape of the
query
• The application client can request only the data that it needs
• The application client can retrieve multiple related resources in a single request
• Uses a strong type system to define the capabilities of an API
• And all the types that are exposed in an API are written down in a schema by using the
GraphQL Schema Definition Language (SDL)
Uempty
9.2. Building a GraphQL API
Uempty
Building
g a GraphQLL
API
Uempty
Creating and Testing a GraphQL API © Copyright IBM Corporation 2020, 2021
• In API Connect, you can create a GraphQL API definition that proxies a backend GraphQL
server
• You can also define rate limiting controls that reflect the amount of data that is returned from
the server from a request to the GraphQL API
• In this unit, a GraphQL API refers to a GraphQL proxy API since it is created from an existing
GraphQL service
• To create a GraphQL API, click the Develop icon in the navigation pane
• Select the APIs tab, click Add, and then select API
• On the Select API type page, select the OpenAPI 2.0 specification
• Although API Manager provides the option to select the OpenAPI 3.0 specification, a GraphQL
API does not support OpenAPI 3.0
• Select From existing GraphQL service (GraphQL proxy)
• Finally, click Next
Uempty
Creating and Testing a GraphQL API © Copyright IBM Corporation 2020, 2021
• To continue creating the GraphQL API, you specify the API summary in the Info section.
• The API summary refers to the GraphQL API metadata: the title, name, version, and base
path of the API, a description of the API, the GraphQL server URL, and the schema name
• To create a GraphQL API without a GraphQL server URL, you can submit a Schema Definition
Language with the GraphQL API’s specifications. To submit the SDL file, you invoke the error
message by entering an invalid GraphQL server URL. On the Upload schema window, you can
either drag or click to upload the SDL file. This process is further covered in the exercise.
Uempty
Creating and Testing a GraphQL API © Copyright IBM Corporation 2020, 2021
• In the Paths section, select the paths that you want to include to generate into the GraphQL
API
• The path /graphql is already selected and immutable. The /graphql path is the path for
application client requests to API Connect that invoke the GraphQL API
• To allow application clients to send introspection requests for the GraphQL API, select
Support default introspection
• To allow users to test the GraphQL API from a GraphiQL editor in a separate browser tab,
select Enable GraphiQL editor
• You can also select the /graphql/cost path. This path enables application clients to obtain
details of the cost of a request to the GraphQL API before making the actual request. In a
production environment, you should consider carefully the resource implications of making
this path available
• Optionally, you can replace the GraphQL schema that was imported from the GraphQL server
URL by uploading a schema from your local file system.
• If any warnings related to the imported schema appear, you can review them by clicking View
• To replace the GraphQL schema, click Replace. You can then either drag your schema file or
click to select the file from your local file system
• Click Next
Uempty
Creating and Testing a GraphQL API © Copyright IBM Corporation 2020, 2021
• In the Secure section, configure the API security that you require.
• The Secure using Client ID option requires an application to provide a Client ID (API Key).
Selecting this option causes the X-IBM-Client-Id parameter to be included in the request
header for the API
• The CORS selection enables cross-origin resource sharing (CORS) support for your API. It
allows your API to be accessed from another domain
• Optionally, if you want to immediately use the API for further development and testing, select
Activate API.
• Click Next to finalize creating your GraphQL API definition
Uempty
Creating and Testing a GraphQL API © Copyright IBM Corporation 2020, 2021
• The Summary panel displays messages as the definition is created, and the selected security
options and rate limits are enforced. If you selected Activate API, the wizard populates an API
Endpoint URL that you can use in testing
• If you also selected Secure using Client ID, the wizard displays a Client ID and Client Secret
you can use
• To further configure your API, click Edit API
• If you do not want to configure your API, click the Develop link in the breadcrumb trail to
return to the welcome page. You can then move on immediately to another task
Uempty
9.3. Testing a GraphQL API
Uempty
Testing
g a GraphQLL
API
Uempty
Creating and Testing a GraphQL API © Copyright IBM Corporation 2020, 2021
• A GraphQL schema is a description of the data clients you can request from a GraphQL API
• The schema enables automatic code generation, validation and parsing, introspection, and
type safety for your APIs
• A GraphQL schema also defines the queries and mutation functions that the client can use to
read and write data from the GraphQL server
• You specify your client or application UI data requirements in your GraphQL schema
Uempty
Creating and Testing a GraphQL API © Copyright IBM Corporation 2020, 2021
• In GraphQL, you can perform only two types of operations: queries and mutations
• Queries are used to fetch data
▪ They are equivalent to GET calls in REST
• Mutations are used to modify server-side data
▪ They represent the state-changing methods in REST, such as DELETE, POST, PUT, or PATCH
Uempty
Creating and Testing a GraphQL API © Copyright IBM Corporation 2020, 2021
• In the Request section, select the required operation type and endpoint. For example, you can
select a POST or a GET request to the gateway endpoint with /graphql or /graphql/cost
appended to the URL
• On the GraphiQL tab, in the left pane of the editor, supply the query with a query operation or
a mutation operation
• If required, you can supply extra request headers on the Parameters tab
• If your query includes variables, you can supply values for the variables in the Query
Variables pane.
• Click the Execute Query icon in the editor
• The response is displayed in the GraphiQL editor, and the Trace section shows you how the
API call was executed
Uempty
You have completed this unit. Having completed this unit, you should be able to:
• Explain what is a GraphQL API
• Examine the advantages and disadvantages of GraphQL APIs
• Compare and contrast REST and GraphQL
• Describe how to create a GraphQL API
• Explain what is a GraphQL schema
• Define GraphQL API queries and mutations
• Describe how to test a GraphQL API with the Test tab
Uempty
Review questions
1. What is not an advantage of GraphQL?
a. GraphQL calls are handled in a single round trip.
b. GraphQL is introspective.
c. GraphQL does not dictate a specific application architecture.
d. GraphQL shifts much of the work of a data query to the server side.
3. True or False: Queries are used to modify data and mutations are used to fetch data.
Creating and Testing a GraphQL API © Copyright IBM Corporation 2020, 2021
Uempty
Review answers
1. What is not an advantage of GraphQL?
a. GraphQL calls are handled in a single round trip.
b. GraphQL is introspective.
c. GraphQL does not dictate a specific application architecture.
d. GraphQL shifts much of the work of a data query to the server side.
The answer is D.
2. What is a feature of GraphQL that is not a feature of REST?
a. Each request usually calls exactly one route handler function.
b. The data can be gathered by accessing multiple endpoints.
c. All the types that are exposed in an API are written down in a schema using the Schema Definition
Language (SDL).
d. The only way for a client to download data is by hitting endpoints that return fixed data structures.
The answer is C.
3. True or False: Queries are used to modify data and mutations are used to fetch data.
The answer is False. Mutations are used to modify data and queries are used to fetch data.
Creating and Testing a GraphQL API © Copyright IBM Corporation 2020, 2021
Uempty
Uempty
Uempty
Overview
This unit describes the process of testing an API in the Local Test Environment. You learn the
definition and uses of a Local Test Environment, as well as how to start and install the Local Test
Environment. You learn how to test a REST API in the Local Test Environment by using a cURL call.
You learn the definition and uses of a TLS Client profile in the Local Test Environment, as well as
how to create a TLS Client profile.
Uempty
Uempty
Testing an API in the Local Test Environment © Copyright IBM Corporation 2020, 2021
Uempty
10.1.Installing and starting the local test
envionment
Uempty
Installing
g and
d
starting
g the
e Locall
Testt Environment
Uempty
Testing an API in the Local Test Environment © Copyright IBM Corporation 2021
Uempty
Testing an API in the Local Test Environment © Copyright IBM Corporation 2021
Uempty
• Verify that the Local Test Environment is installed and running correctly
./apic-lte-linux_10.0.1.2-ifix2 status
Testing an API in the Local Test Environment © Copyright IBM Corporation 2021
Uempty
Testing an API in the Local Test Environment © Copyright IBM Corporation 2021
Uempty
10.2.Testing an API in the Local Test
Environment
Uempty
Testing
g ann APII in
n
the
e Locall Testt
Environment
Uempty
Testing an API in the Local Test Environment © Copyright IBM Corporation 2021
Uempty
10.3.Creating a TLS client profile in the Local
Test Environment
Uempty
Creating g a TLSS
Clientt profile
e in
n the
e
Locall Testt
Environment
Figure 10-10. Creating a TLS Client profile in the Local Test Environment
Uempty
Testing an API in the Local Test Environment © Copyright IBM Corporation 2021
Uempty
Testing an API in the Local Test Environment © Copyright IBM Corporation 2021
Uempty
• Convert the truststore file from JKS > PKCS12 > PEM
keytool -importkeystore -srckeystore ca-trust -
destkeystore ca-trust.p12 -srcstoretype jks -
deststoretype pkcs12
openssl pkcs12 -in ca-trust.p12 -out ca-trust.pem
Testing an API in the Local Test Environment © Copyright IBM Corporation 2021
Uempty
Testing an API in the Local Test Environment © Copyright IBM Corporation 2021
Uempty
Uempty
Review questions
1. Which is a false statement regarding the Local Test Environment?
a. The LTE is a lightweight API Manager that runs on your local machine.
b. The LTE allows you to rapidly test APIs locally.
c. The LTE is used to test APIs on your local machine while connected to an API Connect management
server.
2. True or False: To prepare an API for testing in the Local Test Environment, you must publish it
to the Sandbox Catalog in the Local Test Environment.
3. True or False: Keystores are repositories containing trusted certificates with verified public
keys and truststores contain matched pairs of public certificates and private keys.
Testing an API in the Local Test Environment © Copyright IBM Corporation 2021
Uempty
Review answers
1. Which is a false statement regarding the Local Test Environment?
a. The LTE is a lightweight API Manager that runs on your local machine.
b. The LTE allows you to rapidly test APIs locally.
c. The LTE is used to test APIs on your local machine while connected to an API Connect management
server.
The answer is C.
2. True or False: To prepare an API for testing in the Local Test Environment, you must publish it
to the Sandbox Catalog in the Local Test Environment.
The answer is True.
3. True or False: Keystores contain matched pairs of public certificates and private keys and
truststores are repositories containing trusted certificates with verified public keys.
The answer is False.
Testing an API in the Local Test Environment © Copyright IBM Corporation 2021
Uempty
Uempty
Uempty
Overview
This unit examines how to package and publish APIs to the API Connect cloud. A product defines
a collection of APIs for deployment. The product contains a plan, which is a contract between the
API provider and API consumer that specifies quality of service characteristics, such as the rate
limit of API calls.
Uempty
Uempty
Publishing and managing products and APIs © Copyright IBM Corporation 2020, 2021
Uempty
11.1.Overview of products and plans
Uempty
Overview
w off
productss andd plans
Uempty
Plan
API
implementation
Data source
Publishing and managing products and APIs © Copyright IBM Corporation 2020, 2021
• Products, plans, and APIs are all represented in YAML files within API Manager.
• Testing the API operations:
▪ You can test your API endpoint operations from the API Manager assembly test feature or
from the Developer Portal for a catalog. The API and product must either be
auto-published by the assembly test feature or explicitly published to the catalog.
Publishing the API and product makes the API callable on the Gateway server. The
application implementation must be started and reachable from the Gateway.
▪ Select the API REST operation that you want to test. Then, call the operation with the test
client that runs on API Manager or the API Developer Portal.
Uempty
Publishing and managing products and APIs © Copyright IBM Corporation 2020, 2021
• You can create plans only within products, and these products are then published in a catalog.
• To make an API available to an application developer, it must be included in a plan
• Multiple plans within a single product are useful in that they can fulfill similar purposes but
with differing rate limits or cost structures.
Uempty
• The API product definition file uses the same file structure as an OpenAPI definition. API
products are specific to the IBM API Connect product and are extensions to the OpenAPI
specification.
• The product definition file can be viewed from the Design view or the Source view in API
Manager.
Uempty
11.2.Adding a product
Uempty
Adding
g a product
Up to this point, products have been automatically created for you by API Manager when you
publish your API. In the last exercise, you created the customer's product when you published the
GraphQL API. The next three slides show the steps to create a product from scratch. Once the
product is added, API definitions can be added to it.
Uempty
Add a product (1 of 3)
Publishing and managing products and APIs © Copyright IBM Corporation 2020, 2021
To add a product in API Manager, open the Develop APIs and Products page.
1. From the APIs and Products page, click the Add icon. Then, select Product.
2. Select New product. Click Next.
3. Type a title, name, and version for the product. Click Next.
Uempty
Add a product (2 of 3)
Publishing and managing products and APIs © Copyright IBM Corporation 2020, 2021
4. Select the APIs that you want to add to the product. Click Next.
5. Select the plan for the product. Click Next.
Uempty
Add a product (3 of 3)
6
7
Publishing and managing products and APIs © Copyright IBM Corporation 2020, 2021
6. Select the option whether to publish the product. Select the visibility and subscribability
options. Click Next.
7. The Summary page is displayed.
8. Edit the product in the Design view to review or change the product definition.
Uempty
11.3.Staging and publishing a product
Uempty
Staging
g andd
publishing
g a product
Uempty
Catalogs
• Catalogs are useful for separating products and APIs for testing and production
• The URLs for API calls and the Developer Portal are specific to a particular catalog
• By default, a sandbox catalog is provided
Used for testing
• Organization owners create more catalogs
Production catalog for hosting APIs that
are ready for use
Publishing and managing products and APIs © Copyright IBM Corporation 2020, 2021
Uempty
Stage a product
• Staging a product makes the product and associated APIs visible to the catalog. From within
the catalog, the product can be managed through the lifecycle states.
Publishing and managing products and APIs © Copyright IBM Corporation 2020, 2021
• The stage action creates a snapshot of the product and its associated APIs and makes them
visible on the catalog.
• Stage is the first lifecycle state that is managed from within the catalog.
• When in the staged state, the product is not yet visible or subscribable to developers on the
Developer Portal.
• More about staging a product to a development catalog is covered in the next unit.
Uempty
Publish a product
• Click the options icon in the row with the product that you want to publish.
Then, click Publish
• You publish the product and its associated APIs from the list of APIs and Products page in the
Develop option of API Manager.
• Click the list of options ellipsis in the product row. Then, select Publish.
• You can publish a product without first going through the stage lifecycle state.
• Publishing a product makes it visible on the Developer Portal. The API also becomes callable
on the API gateway.
• You publish the product and its associated APIs from the list of APIs and Products page in the
Develop option of API Manager.
• To publish a product:
▪ Select publish on the list of options.
▪ On the publish product page, select the target catalog from the drop-down list.
▪ Optionally select to publish to a specific gateway service.
▪ Click Publish.
▪ The product is published.
• More about publishing a product to a development catalog is covered in the next unit.
Uempty
Publishing and managing products and APIs © Copyright IBM Corporation 2020, 2021
• The list of published products is displayed on the products page for the catalog.
Uempty
• In the Plans window, you can view the APIs that are included in the product.
Publishing and managing products and APIs © Copyright IBM Corporation 2020, 2021
Uempty
11.4.Managing products
Uempty
Managing
g products
Uempty
Deprecate Archive
Publishing and managing products and APIs © Copyright IBM Corporation 2020, 2021
Uempty
Publishing and managing products and APIs © Copyright IBM Corporation 2020, 2021
• If you publish a product to a sandbox catalog and change it in API Manager, you can publish
the same version of the product. Publishing the same version to the sandbox catalog
overwrites the existing published product with the newer published version.
• When you work with APIs and products on the sandbox catalog, API Connect assumes that
you are working in development mode. The changes that you make to these artifacts overwrite
the earlier versions when you publish them to the sandbox catalog.
Uempty
Publishing and managing products and APIs © Copyright IBM Corporation 2020, 2021
Uempty
Publishing and managing products and APIs © Copyright IBM Corporation 2020, 2021
• You can manage the lifecycle states of a published product from the Manage option in API
Manager. Click the catalog to open it. The list of published products is displayed.
• Changes to the product lifecycle state can be made from the options ellipsis for a particular
product.
• The options from the Manage menu for published products in API Manager includes the
lifecycle options to deprecate or retire the product and to edit the visibility and subscribers.
• Other selections include replacing or superseding an existing product.
Uempty
Publishing and managing products and APIs © Copyright IBM Corporation 2020, 2021
Uempty
• Confirm removal
• The product is deleted from the catalog and now exists as a draft
Publishing and managing products and APIs © Copyright IBM Corporation 2020, 2021
Uempty
Publishing and managing products and APIs © Copyright IBM Corporation 2020, 2021
• By default, the catalog owner and administrator have all permissions to manage products in
the sandbox catalog. Other roles have view permissions by default.
• You can edit and customize the permissions for lifecycle changes from the roles option of the
settings tab in API Manager.
Information
In this course, you use the user with an owner role to manage the products and APIs in API
Manager.
Uempty
Uempty
Review questions
1. Which of these statements are true?
a. A product can be published to selected communities of application developer organizations
b. Plans within the product can be used to tailor access and visibility further
c. APIs become accessible when a product is published and made visible on the Developer Portal
d. All of the above
Publishing and managing products and APIs © Copyright IBM Corporation 2020, 2021
Uempty
Review answers
1. Which of these statements are true?
a. A product can be published to selected communities of application developer organizations
b. Plans within the product can be used to tailor access and visibility further
c. APIs become accessible when a product is published and made visible on the Developer Portal
d. All of the above
The answer is D.
Publishing and managing products and APIs © Copyright IBM Corporation 2020, 2021
Uempty
This exercise examines how to publish APIs with plans and products. You create a product and a
plan and deploy the product in API Manager.
Uempty
Uempty
Overview
This unit explains the concept of the Product lifecycle. The lifecycle management feature controls
the staging of a Product version to a catalog. Lifecycle management continues through publishing
to make the Product version available to your application developers. The lifecycle governance
eventually controls retiring and archiving of the Product and APIs.
Uempty
Uempty
Uempty
12.1.Managing catalog roles and permissions
Uempty
Managing g catalog
g
roless and
d
permissions
Uempty
Note
Default roles for provider and consumer organizations are set in Cloud Manager.
The cloud administrator can add other custom roles by clicking the Add icon for the provider
organization from the Default Roles page.
Uempty
The roles that are defined in Cloud Manager for a provider organization are inherited in API
Manager. The owner of the provider organization can edit these roles and change permissions.
Uempty
• Permissions for performing actions on lifecycle events are pre-set for each role. These
permissions can be viewed in API Manager.
• The example on the page shows that the Developer role has permission to view, stage, and
manage Products in the provider organization. The Developer role can also perform many
lifecycle changes related to product approval.
• The organization owner can change permissions by clicking the Edit ellipsis icon for the
particular role.
Uempty
• You can display the members and their roles for a catalog in API Manager. Open the catalog,
then select the Members option.
• The example in the figure displays the owner of the catalog and provider organization.
Uempty
12.2.Managing product lifecycles
Uempty
Managing g productt
lifecycles
Uempty
Deprecate Archive
• You were introduced to this slide in the prior unit. In this unit, product lifecycles are covered in
more detail.
• Here you see a lifecycle for products and their contained plans and API operations as they
move through the different states.
• The whole lifecycle of products, plans, and APIs occurs in the context of a catalog.
• Except for the authoring step, all the actions involve state changes to products, plans, and API
operations within a particular catalog.
• When you first create the API in the draft API status, the API and its associated product exist
independently of the catalog. The Develop page in API Manager keeps all the APIs and
products in the “draft” status of the figure.
• The next step is that you stage the product and its contained API resources to the catalog.
• You then publish the product to make it visible on the Developer Portal for that catalog.
• When a product is moved to the deprecated state, the plans in the product are visible only to
developers whose applications are currently subscribed. No new subscriptions to the plan are
possible.
• A product version in the retired state cannot be viewed or subscribed to, and all of the
associated APIs are stopped.
• Product versions in the archived state are similar to ones in the retired state. However,
archived product versions are not displayed by default on the products view of the API
Manager.
Uempty
• Some lifecycle state changes happen differently in production versus development catalogs.
• When the Production Mode option is Off under the Settings tab for a particular catalog, staging
and publishing actions are forced.
• For the sandbox catalog and other development catalogs, this means that the existing product
version is overwritten without warning when the Stage or Publish actions are invoked in API
Manager.
• The sandbox catalog can be used for development and testing purposes only. There is no
Production Mode option for the sandbox catalog.
• When publishing a product version to a production catalog, you should create a new product
version if the original product version is already in the published state.
Uempty
• After the product is created, it is visible on the Products tab from the Develop page. The
product can be managed from the manage list of options icon.
• From this view, you can move the products through their lifecycle.
• The actions that are available from the manage menu icon change according to the current
state of the product.
Uempty
12.3.Staging a product to a development catalog
Uempty
Staging
g a productt to
o
a developmentt
catalog
Uempty
• Creates a snapshot
of the product
Snapshot is taken of
the product definition
and the OpenAPI
definition
Updates that you
make to the product
or API are not
reflected in the
staged version
• When you stage a product, you create a specific version of the product on a target catalog.
• A catalog is a deployment target and behaves as a logical partition of the gateway and
Developer Portal. When you stage a product, a snapshot or a definitive copy of the product is
created.
• Since it is a snapshot, any updates you make to a product, are not reflected in the staged
version.
• Staging a product that is defined in the Develop page in API Manager is straightforward.
• Select the product version. Then, from the list of options select Stage.
Uempty
• Select the target catalog where the product is to be staged from the drop-down menu.
• The Staging catalog that is selected in the example is defined as a development catalog. The
sandbox catalog is also a development catalog.
Uempty
• After the product is staged, you can see its state from the Manage page for the catalog.
• If you remove a product from the staged state, it is removed from the catalog and the product
goes back to the draft state in the Develop area of API Manager.
• The product or API details can be edited and changed. Then, the product can be staged again.
Uempty
12.4.Publishing a product to a development
catalog
Uempty
Publishingga
productt to
oa
developmentt
catalog
Uempty
Uempty
Uempty
Clicking the Publish button publishes the product and makes it available on the Developer Portal
or moves it to a published pending state if approval is required.
Uempty
Published Products are visible when the developer is signed on to the Developer Portal.
Non-authenticated users see Products with visibility set to public.
Uempty
12.5.Lifecycle actions for published products
Uempty
Lifecycle
e actionss forr
publishedd products
Uempty
Uempty
• Deprecating a product prevents new developers from subscribing to the plans in this product,
without hiding it from existing subscribers.
• A product owner might deprecate a product in anticipation of the next version release but is
forced to keep a previous release for clients that have not yet adopted the new features or are
unwilling to upgrade their code in the short term.
Uempty
• The Retire operation moves a product version from the Published to the Retired state.
• Before a published product version can be removed from a catalog, it must first be retired.
• You can retire a published or deprecated product by using the Manage icon in API Manager.
• When a product is retired, all associated APIs are taken offline, and any subscriptions become
inactive.
Uempty
• In the example, you intend to remove version 1.0.0 of the Smart Product product from the
Staging catalog.
• The product version is already in the retired state. From the manage icon, select Delete. Then,
click Delete in the confirmation dialog.
• The product version is removed from the catalog.
Uempty
• When testing is completed for an API, the containing product version is staged to the catalog
to create a specific snapshot of that product.
• API Developers should make feature enhancements to a new version of the product and its
API resources.
• You can create versions of Products and APIs at any time.
• Before a product can be published, you must first stage that product to a catalog.
• A staged product that is not published is not visible to the users on the Developer Portal.
• Creating new versions of Products and APIs before they are staged and published to a
production catalog is a recommended practice.
Uempty
12.6.Versioning APIs and products
Uempty
Uempty
• API versioning was covered in a prior unit. When you create a new version of an API, you can
decide to leave it in the current product or move it to a new one.
• If you want to publish a modified API to a production catalog, you must create a new version
of the API. You cannot publish an API to a production catalog if there is already a published
API with the same name and version.
Uempty
• The steps to change the version of a product are the same as to change the version of an API.
• Select the Products tab. Then, from the list of options for the API, select Save as a New
Version.
Uempty
When you save a new version of the product, you are prompted to type the version number. Then,
click Submit.
As with APIs, the version.release.modification version numbering scheme is recommended,
for example 2.0.0.
Uempty
• The new version of the product is saved and is displayed in the list of Products.
• The next step is to open the product in the editor and add the new version of the API to the
product.
Uempty
Figure 12-31. Add the later version of the API to the product (1 of 3)
• To assign the latest version of the API to the product, start by opening the recently created
product version with the editor in API Manager.
• With the product open in the editor, select the APIs tab. Then, click the Edit button to display
the APIs that are associated with the product version.
Uempty
Figure 12-32. Add the later version of the API to the product (2 of 3)
• The list of APIs that are assigned to the product are displayed.
• Deselect the older API version 1.0.0 and select the newer API version 2.0.0.
• Save the changes.
Uempty
Figure 12-33. Add the later version of the API to the product (3 of 3)
The newer API version is now assigned to the product version and is displayed in the list of APIs.
Uempty
Uempty
The dialog box that is displayed when you choose to replace an existing product version carries
out the following actions:
• The replacement product will be published.
• The same visibility and subscriber settings of the original product version will be used.
• The subscribers will be migrated.
• The product that is being replaced will be retired.
Uempty
The dialog prompts you to select the plans that are supported in the replacement plan. You can
select multiple plans in the dialog if there are multiple plans to choose from.
Uempty
• The slide shows the results from the publish with replace feature of API Manager.
• The original product version is retired, and the new product version and plan are published or
in the pending publishing state if approvals are required
• The subscribers are migrated from the original plan to the plan that is associated with the later
product version.
Uempty
Note
The Smart Product product 1.0.0 and 2.0.0 are reused in this example. The two Products are reset
to the staged and published states respectively at the start of the process.
Uempty
Choose the product that is superseding the published version from the list of Products.
Uempty
Verify the product that is being superseded and each plan within the product that is to be
migrated.
Uempty
When you supersede a product with another product, the following actions are taken:
• The superseding product is published.
• The same visibility, subscriber, and gateway enforcement settings from the original product
are used for the superseding product.
• The original product is moved to the Deprecated state. When a product is deprecated,
application developers that are already subscribed to the product can continue to use it, but
no new developers can subscribe to the product.
Subscribers of the product version are not automatically migrated. This means that the
subscribers will still use the deprecated product until they subscribe to the new product version.
Uempty
The superseding product version is displayed on the landing page of the Developer Portal.
Uempty
12.7.Migrating app subscribers to new product
versions
Uempty
Migratingg app
p
subscriberss to
o new
w
productt versions
Uempty
Subscriptions
• An application must subscribe to a plan
A plan is a collection of API operations and any rate limits that might apply
• An application plan subscription allows the application to call API resources by the plan
• Application developers create applications in the Developer Portal. Then, the developers
subscribe their applications to one or more plans by using the Developer Portal.
• Applications are generated with a client ID that can be used to authorize the application to call
the API operations. The plan that the application subscribes to can restrict the number of API
calls the application can make during a time period.
• To manage application subscriptions in the API Manager UI, a user must be assigned a role
that has the Subscriptions > Manage permission.
Uempty
Uempty
Important:
Customers cannot be migrated automatically from a free plan to a
paid plan. To move your customers from a free plan to a paid
plan, you can supersede the product with a new product and set a
migration target to the paid plan. The customers then select a
button to migrate and must enter their credit card information
before the process is complete.
The product lifecycle © Copyright IBM Corporation 2020, 2021
Uempty
Uempty
• To give subscribers the option to move to a different product but without affecting the original
product:
• You can use the Set Migration Target option in the catalog on a product that isn't being deprecated or
superseded.
The product lifecycle © Copyright IBM Corporation 2020, 2021
Uempty
12.8.Managing subscriptions
Uempty
Managingg
subscriptions
Uempty
An authenticated user can unsubscribe an application from a product and plan in the Developer
Portal.
1. The application is unsubscribed from the product and the plan by selecting the Unsubscribe
option.
2. A confirmation dialog is presented.
3. The application displays that there are no current subscriptions.
Uempty
• Members of provider organizations who have permission can create subscriptions from the
API Manager user interface. Open the catalog. Then, select the Applications tab from the
Manage option.
• From the Applications page for a catalog, select Create Subscription from the options list for
the application.
Uempty
In the Create Subscription dialog in API Manager, select the product and plan for the application
subscription. Then, click Create Subscription.
Uempty
Verify that the subscription is created for the application by signing on to the Developer Portal and
viewing the subscriptions for the application. You see that the application is subscribed to the
product and uses the default plan.
Uempty
• Approvals for lifecycle state changes are configured in the Settings for the catalog. Go to
Settings, then click the Lifecycle Approvals tab.
• The page displays the lifecycle states that require approval. In the example, only the Publish
option requires approval. Click the Edit button to configure approvals for other lifecycle state
changes.
Uempty
• When the Edit button is clicked from the Lifecycle Approvals page, a dialog is displayed where
you can enable or disable lifecycle approvals.
• If approval is required for a product management operation, an approval request is sent, and
the product version moves to the pending state. When the request is approved, the operation
is completed.
Uempty
If approvals for product lifecycle changes are enabled for a catalog, then an attempt to change the
lifecycle state of a product results in an approval request being sent. This request is displayed on
the Tasks tab of the catalog, from where the request can be approved or declined. The authority
to approve product lifecycle state changes is restricted to users in specified roles.
Uempty
Uempty
Review questions
1. True or False: An application must subscribe to a plan before it can be used.
2. Which of these statements is true about lifecycle changes in a development catalog?
a. Staging and publishing actions overwrite the existing version.
b. The system automatically resolves any staging or publishing conflicts.
c. All predefined roles can stage and publish API Products.
d. A and B
e. All of the above.
Uempty
Review answers
1. True or False: An application must subscribe to a plan before it can be used.
The answer is True.
2. Which of these statements is true about lifecycle changes in a development catalog?
a. Staging and publishing actions overwrite the existing version.
b. The system automatically resolves any staging or publishing conflicts.
c. All predefined roles can stage and publish API Products.
d. A and B.
e. All of the above.
The answer is D.
In the API Manager Settings for a catalog, select Roles to edit the permissions for the catalog
Uempty
This exercise shows you how the product lifecycle is managed in API Manager. You review
product and API availability and visibility settings and create a plan. You configure lifecycle
settings and approval settings for a catalog. You examine how to define a user for the provider
organization. You manage product and API versions. You publish artifacts to the Staging catalog,
and then review and approve the lifecycle stage for a published product.
Uempty
Uempty
Overview
This unit explores the application developer user experience. In the API Connect architecture, the
application developer creates an application that calls published APIs. To use APIs, an application
developer creates an account in the Developer Portal. This unit explains how the application
developer subscribes to a plan and tests API operations.
Uempty
Unit objectives • Explain the role of application developers in calling published APIs
• Describe the Developer Portal self-registration process for
development catalogs
• Explain how to add an application in the Developer Portal
• Describe the role of client ID and client secret for application
identification
• Describe how to subscribe to an API plan
• Describe the subscription approval process
• Explain the test client features in the Developer Portal
Uempty
Subscribing and testing APIs in the Developer Portal © Copyright IBM Corporation 2020, 2021
Uempty
13.1.Role of the application developer
Uempty
Role
e off the
e
applicationn
developer
Uempty
Subscribing and testing APIs in the Developer Portal © Copyright IBM Corporation 2020, 2021
• Application developers use the Developer Portal to discover and use APIs. API developers
create and publish APIs. API developers belong to provider organizations.
• Application developers belong to consumer organizations.
• When API providers publish APIs, they can restrict visibility of the APIs to one or more
consumer organizations or make the APIs visible to public or authenticated users.
• When you created the Ordinal consumer organization in an earlier exercise, you took on the
role of the owner and invited an application developer to the organization.
Uempty
API developer
• An API developer in the provider organization might add a client ID security requirement to
the API
• The application that is registered to use the API must then provide a client ID to successfully
call the API
• An API developer is a member of a provider organization
Subscribing and testing APIs in the Developer Portal © Copyright IBM Corporation 2020, 2021
Questions
Why might the API developer enforce the client ID requirement for an application to access the
API?
Answers:
1. To restrict API access to authorized applications or users.
2. To reset the client ID to exclude errant application usage.
3. For analytics, to monitor and track API usage by a particular client.
You created an API Developer role in the last exercise and invited them to the Think organization.
In the next series of slides, self-service sign on is covered.
Uempty
Subscribing and testing APIs in the Developer Portal © Copyright IBM Corporation 2020, 2021
• Developers can sign up to the Developer Portal without requiring an invitation from the API
provider. Enable the self-service onboarding in the API Manager interface settings for the
catalog. The Developer Portal then includes a link to create an account.
• The self sign-up process is generally only enabled for sandbox development catalogs so that
application developers can easily register, view, and subscribe to APIs.
Uempty
Subscribing and testing APIs in the Developer Portal © Copyright IBM Corporation 2020, 2021
The “Sign up” page is shown in two parts. The user creates an account with a username, email
address, given name, family name, and a consumer organization name.
Uempty
Subscribing and testing APIs in the Developer Portal © Copyright IBM Corporation 2020, 2021
• An email notification is displayed. An email message is sent to the email address that was
specified during account creation.
• When the email is opened, a link is displayed in the body of the email message. Clicking the
link address activates the user account on the Developer Portal.
Uempty
Subscribing and testing APIs in the Developer Portal © Copyright IBM Corporation 2020, 2021
The account is activated on the Developer Portal. The user can sign on to the Developer Portal
with the same credentials that were specified during account creation.
Uempty
Subscribing and testing APIs in the Developer Portal © Copyright IBM Corporation 2020, 2021
Uempty
13.2.Creating an application and subscription in
the Developer Portal
Uempty
Creating
g an
n
application
n andd
subscription
n in
n the
e
Developerr Portal
Uempty
• Business partners
and application
developers use the
Developer Portal to
access APIs and
products.
Subscribing and testing APIs in the Developer Portal © Copyright IBM Corporation 2020, 2021
As discussed, an application developer creates an application to use a product and its associated
APIs.
Uempty
Subscribing and testing APIs in the Developer Portal © Copyright IBM Corporation 2020, 2021
The Create new App link is available on the Apps tab on the Developer Portal.
Uempty
Subscribing and testing APIs in the Developer Portal © Copyright IBM Corporation 2020, 2021
Uempty
Subscribing and testing APIs in the Developer Portal © Copyright IBM Corporation 2020, 2021
• When an API operation is called, you can require that an application must provide either a
client ID, or a client ID and client secret.
• The identification requirements for calling an API are specified in the API security definitions
in API Manager.
• These requirements include supplying a client ID, client ID and client secret, or none.
• Click the Show option to show the API key and secret. Copy and save these values for APIs
that require an API key and secret.
Uempty
Subscribing and testing APIs in the Developer Portal © Copyright IBM Corporation 2020, 2021
Uempty
Subscribing and testing APIs in the Developer Portal © Copyright IBM Corporation 2020, 2021
• The available APIs link is at the end of the application subscriptions page.
• Clicking the available APIs link takes you to the list of Products and their associated APIs.
Uempty
Subscribing and testing APIs in the Developer Portal © Copyright IBM Corporation 2020, 2021
Click the link for the product to open the product and view the list of APIs and plans.
Uempty
Subscribing and testing APIs in the Developer Portal © Copyright IBM Corporation 2020, 2021
Uempty
Subscribing and testing APIs in the Developer Portal © Copyright IBM Corporation 2020, 2021
Uempty
Subscribing and testing APIs in the Developer Portal © Copyright IBM Corporation 2020, 2021
Uempty
Subscribing and testing APIs in the Developer Portal © Copyright IBM Corporation 2020, 2021
Uempty
Approval requests (1 of 3)
• If you go to the application in the Developer
Portal, you see that the subscription is
pending approval.
Subscribing and testing APIs in the Developer Portal © Copyright IBM Corporation 2020, 2021
Uempty
Approval requests (2 of 3)
• From the Manage page for the catalog, click the vertical ellipses
• The subscription request can be approved or declined
Subscribing and testing APIs in the Developer Portal © Copyright IBM Corporation 2020, 2021
The API product owner can approve the subscription request in API Manager from the Tasks page
of the catalog.
Uempty
Approval requests (3 of 3)
• Verify that the application is subscribed to
the plan in the Developer Portal
Subscribing and testing APIs in the Developer Portal © Copyright IBM Corporation 2020, 2021
• The page shows that the application is subscribed to the gold plan for the think-product.
• The application can now call and test APIs.
Uempty
13.3.Testing an API in the Developer Portal
Uempty
Testing
g an
n APII in
n
the
e Developerr Portal
Uempty
x-ibm-configuration:
testable: true
enforced: true
cors:
enabled: true
Subscribing and testing APIs in the Developer Portal © Copyright IBM Corporation 2020, 2021
• For an API to be tested on the Developer Portal, the definition file for the API to be tested
must include the statements:
x-ibm-configuration:
testable: true
enforced: true
cors:
enabled: true
• Notice that the security requirements are also specified in the YAML source file.
• In the example, a call to the API requires the application to authenticate with a client ID.
Uempty
Subscribing and testing APIs in the Developer Portal © Copyright IBM Corporation 2020, 2021
• If the testable option is enabled for an API, then the API can be tested on the Developer
Portal.
• After the product is selected, select the API that you want to test from the list of APIs.
Uempty
Subscribing and testing APIs in the Developer Portal © Copyright IBM Corporation 2020, 2021
Select the API operation that you want to test in the Developer Portal.
Uempty
Subscribing and testing APIs in the Developer Portal © Copyright IBM Corporation 2020, 2021
The details for the POST /pet operation is displayed on the page.
Uempty
Subscribing and testing APIs in the Developer Portal © Copyright IBM Corporation 2020, 2021
The Developer Portal automatically inserts the client ID that gets generated when the application
was created.
Uempty
Subscribing and testing APIs in the Developer Portal © Copyright IBM Corporation 2020, 2021
Click Generate to generate a request based on the pet schema defined in the API specification.
Complete the required parameters for the operation, then click Send.
Uempty
Subscribing and testing APIs in the Developer Portal © Copyright IBM Corporation 2020, 2021
Examples of the request and response messages are shown on the page.
Uempty
Unit summary • Explain the role of application developers in calling published APIs
• Describe the Developer Portal self-registration process for
development catalogs
• Explain how to add an application in the Developer Portal
• Describe the role of client ID and client secret for application
identification
• Describe how to subscribe to an API plan
• Describe the subscription approval process
• Explain the test client features in the Developer Portal
Uempty
Review questions
1. True or False: Self-registration can be disabled for the Developer Portal of a development
(sandbox) catalog
2. Which one of the following options is required to enforce subscription approvals on the
Developer Portal?
a. Lifecycle approvals must be enabled
b. Self-service onboarding must be enabled
c. Approvals for product lifecycle state changes must be enabled
d. Approvals must be enabled for the plan to which the application subscribes
Subscribing and testing APIs in the Developer Portal © Copyright IBM Corporation 2020, 2021
Uempty
Review answers
1. True or False: Self-registration can be disabled for the Developer Portal of a development
(sandbox) catalog.
The answer is True.
2. Which one of the following options is required to enforce subscription approvals on the
Developer Portal?
a. Lifecycle approvals must be enabled
b. Self-service onboarding must be enabled
c. Approvals for product lifecycle state changes must be enabled
d. Approvals must be enabled for the plan to which the application subscribes.
The answer is D.
Subscribing and testing APIs in the Developer Portal © Copyright IBM Corporation 2020, 2021
Uempty
In this exercise, you learn about the application developer experience in the Developer Portal. You
review the consumer organization that is created for you. You sign on to the Developer Portal as
the owner of the consumer organization. You review the published products and APIs. You
register an application that uses the product and APIs. You review the client ID and client secret
values, subscribe to an API plan, and test operations from an API product. Finally, you test all the
APIs from a web-based consumer application
Uempty
Uempty
Overview
This unit describes the API analytics features in IBM API Connect. API analytics is built on the
Kibana open source analytics and visualization platform. You review some default dashboards
and visualizations that are provided with the API Connect analytics service
Uempty
Uempty
Uempty
14.1.API analytics overview
Uempty
APII analyticss
overview
Uempty
API analytics
• API Connect provides the capability to filter, sort, and aggregate your API event data
The data is then presented within correlated charts, tables, and maps
Help you manage service levels, set quotas, establish controls, and analyze trends
• The data for analytics is collated from API events that are logged when API operations are
called on the gateway
• The analytics server provides analytic functions that collect and store information about APIs
and applications
• API Connect provides the capability to filter, sort, and aggregate your API event data. This
data is then presented within correlated charts, tables, and maps to help you manage service
levels, set quotas, establish controls, and analyze trends.
• The data for analytics is collated from API events that are logged when API operations are
called on the gateway.
• The analytics service provides analytic functions that collect and store information about APIs
and applications.
• The analytics service, gateway service, and portal service are configured in Cloud Manager.
The analytics service is also associated with a gateway service in the Cloud Manager user
interface.
• You can disable all analytics collection by unassociating the analytics service from the
gateway.
Uempty
• API analytics in API Connect is built on the Kibana open source analytics and visualization
platform, which is designed to work with the Elasticsearch real-time distributed search and
Analytics Engine.
• The Elasticsearch engine performs logging, indexing, and analysis of log and metric data.
• Data is retrieved from indexed data for all API events
• The Analytics Service is deployed separately from API Manager. The Analytics Service is built
on-top of Elastic Stack and performs the following tasks:
▪ Storing API event logs as they are processed from the Gateway Service
▪ Processing API event logs from the gateway
▪ Providing visualizations of the aggregated metric data from the API events so that API
providers can better understand their APIs’ health and consumption
▪ Surfacing the API calls’ raw log data to help developers debug
▪ Unloading API event records to target locations, for example, Splunk, Syslog, Kafka, and
HTTP
Uempty
• Catalogs act as deployment targets through which APIs (in their containing plans and
Products) are staged and published to consumer organizations.
• The IBM API Connect syndication feature provides a way for you to partition a catalog into
multiple deployment targets (or Spaces) through which separate groupings of APIs (in their
containing Plans and Products) can be staged and published. Each Space can be allocated to a
separate group of users who need to manage their Products independently, and the analytics
data in each Space is scoped to those Products only. For information about enabling Spaces in
a catalog, see IBM Documentation.
Uempty
14.2.Where to view API analytics
Uempty
Wheree to
o view
w APII
analytics
Uempty
• Access is controlled
through the roles and
permissions that are
assigned to the
members of the
provider or consumer
organizations
• Access to the analytics data, and to the analytics functions, can be managed by using catalogs
in the API Manager user interface.
• You can view predefined or customized analytics information for your API Connect catalogs
within dashboards.
• API Manager users in the provider organization can be assigned the following access to the
Analytics component for a catalog:
▪ A role that has the Analytics > View permission for a catalog: These users can view the
analytics data that is generated that is for the APIs in the catalog within dashboards,
export dashboard data in its raw format or as event records and apply filters to the data
shown within the dashboards.
▪ A role that has the Analytics > Manage permission for a catalog: These users have an
implicit View permission. Additionally, they can complete the following actions:
- Create, edit, and delete dashboards.
- Create, edit, delete, export, and import the charts, tables, and maps.
Uempty
Mouse-over provides
additional details
You can view analytics for APIs in the Developer Portal at the application and organization levels.
The information is displayed in dashboard views that show the analytics metrics in the form of
visualizations, represented as charts.
Information
The analytics service uses the Client ID (apiKey) to map the application to the APIs that are called
on the gateway. No analytical data is available in the Developer Portal for applications that use
APIs where no security is configured.
Uempty
From the Developer Portal, you can view interactive analytic information for all the APIs within an
organization.
Uempty
• You can view predefined or customized analytics information for your IBM API Connect
catalogs within dashboards.
• If spaces are enabled in your catalogs, you can also view predefined or customized analytics
information for your API Connect spaces within dashboards.
Uempty
14.3.Dashboards and visualizations
Uempty
Dashboardss andd
visualizations
Uempty
• API Connect analytics provides some preconfigured dashboards to view common analytics
data.
• A list of dashboards is displayed when you open the default dashboards page for the first time.
These dashboards provide examples of the data that you can view when using the analytics
dashboards. You can use these dashboards as they are or clone them to customize them to
your needs.
• Descriptions of the default dashboards:
▪ API Default Includes general information about your APIs.
▪ Catalog Default Includes general information about the most used Products in your
catalog. An example of this dashboard is presented on the next slide.
▪ Monitoring Latency Provides information about the amount of time that elapses after the
API request is submitted and the transfer of data begins.
▪ Monitoring Status Provides information about monitoring the status of your API. An
example of this dashboard is presented later in this presentation.
▪ Portal Default Provides information about the API requests to APIs in the Developer
Portal.
▪ Product Default Provides information about the Products.
Uempty
Mouse-over provides
additional details
Uempty
Uempty
Visualizations
• Preconfigured visualizations provide some common ways to view analytics data
• Visualizations apply a series of search criteria to the indexed data and then graphically present
the results in a convenient format for analysis or review.
• A list of visualizations is displayed when you open the visualization application page for the
first time, or when you select Visualize in the application selector on the Analytics page.
Uempty
API calls per day is one of the default visualizations that is provided with API Connect analytics.
Uempty
Visualization filters
• Filter by time period
To apply a time filter and auto-refresh rate, complete the following steps:
1. From the dashboard, click the Time Picker icon.
2. From the Time Picker, use one of these options to set a time filter:
▪ Quick Select this option to choose a predefined value such as Today, Yesterday, This
week, or Last n minutes.
▪ Relative Select this option to specify a start time that is relative to now; for example, 20
seconds, minutes, hours, days, weeks, or months ago, optionally rounded to the specified
unit of time. The date and time that corresponds to your relative selection is displayed
before the fields. Click Go.
▪ Absolute Select this option to specify a precise time range. Either use the calendars to
select a From and To date, or enter the values directly into the fields by using the date and
time format that is specified underneath the fields. Click Go.
3. Additionally, if you want to specify a frequency at which the data should automatically be
refreshed in your visualizations, click Auto-refresh and then select a predefined refresh
interval.
4. If you set an auto-refresh interval as described in the previous step, click the auto-refresh
value, which is displayed next to the Time Picker icon, to confirm your settings and close the
time selection panels. If you did not set an auto-refresh interval, close the Time Picker panel
by clicking within the box where the Time Picker icon is located. The search query is
resubmitted as you make your selections and the visualizations in the dashboard are
automatically refreshed to show the matching data. The specified quick, relative, or absolute
filter setting is shown with the Time Picker icon. If set, the auto-refresh interval is shown with
Uempty
the Time Picker icon, together with a Pause icon that can be used to pause auto-refresh if
required.
Uempty
The visualization of the top 5 APIs overall by daily usage displays a graph of the 5 APIs that get the
most calls daily.
Uempty
• Status codes (detailed) lists the status codes for the API calls.
• You can hover over the different areas of the pie chart to display the metrics for the different
status codes.
• The legend can be toggled to be displayed or hidden.
• By clicking on a status code, you can set the color that represents it in the pie chart.
• When the selector switch in the lower left corner on the pie chart is clicked, the table with the
different status codes and their count is displayed.
Hint
The selector switch can be difficult to find. You can use the Ctrl+ and Ctrl-key combinations to
increase or decrease the text size to make it more visible.
Uempty
When the selector switch on the pie chart is clicked, the table with the different status codes and
their count is displayed. Clicking the selector switch from the table returns you to the pie chart.
Uempty
14.4.Creating visualizations
Uempty
Creatingg
visualizations
To create visualizations, you must either be the owner of the API provider organization or be
assigned a role that has the Analytics > Manage permission for the selected catalog or Space.
Uempty
Create visualizations (1 of 7)
• You can create visualizations from the default visualizations
Click Create new visualization from the Visualize page
Create your own analytical graphs from the API Manager Analytics Visualize tab by clicking the
Create new Visualization icon.
Uempty
Create visualizations (2 of 7)
• Select from one of the available visualization types
Select from one of the available visualization types such as Data Table.
Information
Creating your own visualization from a visualization type such as Area chart or Line chart requires
some knowledge of the underlying data indexes and the type of metrics and bucket types that you
want to display on the X- and Y- axis.
Uempty
Create visualizations (3 of 7)
• Select the index for the search
The default API Connect search index is used in the example
Choose the index that is used by the search. In the example, the default API Connect index is
used.
Uempty
Create visualizations (4 of 7)
• Configure Data and Options
• Configure any changes that you want to make to the Data and Options for the visualization.
• Then, click Save.
Uempty
Create visualizations (5 of 7)
• Give the visualization a title
• Then, save the configured visualization
Uempty
Create visualizations (6 of 7)
• The new visualization is displayed in the visualizations list
• Select the newly
created visualization
in the Visualization
Filter
Uempty
Create visualizations (7 of 7)
• The new visualization is displayed on the page
Uempty
14.5.API events and records
Uempty
Uempty
• An API event is logged each time an API operation is invoked, and an event record is
generated for each API event in the gateway server.
• The API event record contains information about the API call and the content of the record
depends on the logging policy that is set for the operation.
• The API event records are stored by the Analytics component of API Connect.
Uempty
• You can use the activity-log policy to configure your logging preferences for the API event
details that are stored in the Analytics component. By default, invocation details are logged if
an API call is successful, and invocation, header, and payload (message body) details are
logged if an API call results in an error code. To override these default settings and change the
level of detail that is included in the API event record, you can add the activity-log policy to
your API assembly and then configure the policy's properties. For example:
▪ To include details about the request body or response body in the API event record for a
successful API call, you can add an activity-log policy to the associated API operation and
set the content type to payload.
Restriction: The payload logging feature is disabled for IBM Cloud instances that are
hosted in the Frankfurt region. The requirements for storing Sensitive Personal
Information (SPI) are more restrictive in that region, so the payload information cannot be
saved.
▪ To include details about the HTTP request headers or HTTP response headers in the API
event record for a successful API call, you can add an activity-log policy to the associated
API operation and set the content type to either header or payload.
▪ To include client_geoip and gateway_geoip fields in the data, ask your Kubernetes
administrator to configure the Kubernetes ingresses/cluster to include the
X-Forwarded-For header in the data that is collected by the DataPower Gateway and
passed to APIC Analytics.
• When setting the mode for the logging, specify one of the following values:
▪ Gather-only: gather all analytics data and write it to the log context variable, which
populates the API event record on completion of the API execution.
Uempty
▪ Send-only: perform the following actions:
- Read the data from the log context variable.
- Truncate all message payloads and convert to a textual representation.
- Send the data to the analytics server.
▪ Gather-and-send; perform a gather-only operation, immediately followed by a send-only
operation.
If you use the Send-only or Gather-and-send option, data is buffered and sent to the
analytics server in batches according to the time interval configured for the Analytics Endpoint
on the DataPower API Gateway.
Uempty
14.6.Exporting data from visualizations
Uempty
Exportingg data
a from
m
visualizations
Uempty
You can export visualizations so they can be imported by other IBM API Connect users, or into
other catalogs on your system.
Uempty
Choose to save the file, which is named export.json by default, or open it with an application that
is configured for your browser.
Uempty
The example shows the JSON file for API calls opened in the editor.
Uempty
• The event data that is generated and collected in your API Connect on-premises deployment
can optionally be forwarded to external third-party systems for storage and analysis.
• API Connect supports the offload of API analytics data to the following third-party systems:
HTTP, Elasticsearch, Apache Kafka, and Syslog. You can configure a custom certificate for
connecting to the third-party target, enable a message queue to ensure that no data is lost
during outages, and define filters to refine data that will be stored.
• You typically configure data offloading while deploying the Analytics subsystem.
Uempty
Uempty
Review questions
1. True or False: The Portal service captures API events.
2. True or False: All visualizations that you create are added to a list of saved visualizations and
can be used in any dashboard.
Uempty
Review answers
1. True or False: The Portal service captures API events.
The answer is False.
The Gateway service captures API events.
2. True or False: All visualizations that you create are added to a list of saved visualizations and
can be used in any dashboard.
The answer is True.
Uempty
Exercise: Calling an API on the gateway and monitoring API
usage
Figure 14-41. Exercise: Calling an API on the gateway and monitoring API usage
In this exercise, you test the operations for the APIs in the petstore product. To do this, you use
the test feature in the Developer Portal. You run a script to generate API calls and review the API
analytics capabilities for both the consumer and provider organizations.
Uempty
Uempty
Overview
As the administrator, you can change the appearance and layout of the Developer Portal. This unit
describes the customization options that are available to you. You learn how to customize the
Developer Portal through the administration menu and examine the options for using themes and
sub-themes on the Developer Portal.
Uempty
Uempty
Uempty
15.1.Developer portal overview
Uempty
Developerr portall
overview
Uempty
It is recommended that you understand the various Drupal concepts and terminology that is
referenced throughout the Developer Portal.
Uempty
API Connect uses IBM API manager is an Share your APIs with API analytics is built
DataPower Gateway intuitive user interface application on the Kibana V5.5.1
to provide the that lets you manage developers through a open source analytics
gateway service. IBM APIs for internal use, company-branded and visualization
API Connect provides or to externally portal. Developers can platform, which is
two gateway types, monetize and manage discover and designed to work with
DataPower API services as REST or subscribe to APIs as the Elasticsearch real-
Gateway and SOAP APIs. well as register and time distributed
DataPower Gateway deploy associated search and Analytics
(v5 compatible). applications. Engine.
• This page shows the components and capabilities of the IBM API Connect solution.
• The Developer Portal enables API providers to build a customized developer portal for their
application developers.
Uempty
• Authenticated users
Create applications
Manage subscriptions
• Portal administrators
Import custom themes
Customize layout and menus
Set permissions
Customizing the Developer Portal © Copyright IBM Corporation 2020
• Owners of a consumer organization can manage their communities and view analytics from
the Developer Portal.
• Authenticated Portal users who are granted permission, can create applications and, manage
subscriptions.
• Portal administrators can customize the Developer Portal.
Uempty
Developer Portal
• The Developer Portal provides application developers and consumer organization owners with
a set of tools to find, subscribe, and test APIs in the API Connect cloud
• Self-service,
customizable developer
portal for API users,
application registration,
and subscription
• API discovery and
socialization
• The API Connect Developer Portal provides a complete content management, and
customizable developer portal for your APIs.
• The Developer portal provides application developers and consumer organization owners with
a set of tools to find, subscribe, and test APIs that are built in the API Connect cloud.
Uempty
• Any Products that are published with a visibility option of "Public" are displayed if the user
click the API Products tab of the Developer Portal. The user does not need to sign on to the
Developer Portal to view these Products and APIs.
• Products that are published with visibility options other than "Public" are not visible on the
portal for unauthenticated users.
• You can have visibility set to “Public” and Subscribability set to “Authenticated”. In this case,
the Products are visible on the public interface of the Developer Portal, but only authenticated
users can subscribe to use the Product and APIs.
Uempty
• The administration menu is displayed when the admin user logs in to the Developer Portal.
• The menu is displayed either as a drop-down enabled responsive menu or the menu is
displayed horizontally along the top of the Developer Portal on an expanded page.
• Responsive web pages are mobile-friendly, and they change according to the page size.
Uempty
15.2.Developer portal members and roles
Uempty
Developerr portall
memberss and d roles
Uempty
• You can get a list of members that are defined on the Developer Portal by selecting the People
option from the administration Manage menu.
• By default, members are defined with a role of authenticated user.
• You can define additional roles for a user on the Developer Portal by selecting the member,
then selecting a role from the Action options submenu.
Information
From the standpoint of the default roles for the consumer organization, members are classified as
administrators, owners, developers, or viewers in the settings for the catalog. The roles defined by
the portal administrator are Drupal roles for managing the content that is provided in the
Developer Portal.
Uempty
Portal roles
• By using roles, you can fine-tune the security and administration of Drupal
A role defines a group of users that have certain privileges as defined on the permissions page
• Anonymous user: Role that is used for users that do not have a user account or that are not
authenticated
• Authenticated user: This role is automatically granted to all logged in users
• Content author: Role that is used to edit or add content
• Forum moderator:
Role that controls access to the portal
forums
• Administrator:
Manages all other roles
• Superuser:
Access to all content
• You can use roles to fine-tune the security and administration of Drupal. A role defines a group
of users that have certain privileges as defined on the permissions page. Examples of roles
include: anonymous user, authenticated user, moderator, administrator, and other roles. The
administrator can define the names and order of the roles on your site. It is recommended to
order your roles from least permissive (anonymous user) to most permissive (superuser).
• The superuser role is assigned by default to the admin user when a Developer Portal site is
enabled in the API Manager.
• By default, Drupal comes with two user roles:
▪ Anonymous user: This role is used for users that do not have a user account or that are not
authenticated.
▪ Authenticated user: This role is automatically granted to all logged in users.
Uempty
• An authenticated user can see products that are published with “Authenticated user” in API
Manager.
• In the example, the user is signed on to the Developer Portal and two products are displayed
with the API Products tab selected.
Uempty
15.3.Introduction to Drupal
Uempty
Introduction
n to
o
Drupal
Uempty
Powered by Drupal
• Drupal is a free, open source web content management tool for content, community, and
commerce
LAMP (Linux, Apache, MySQL, and PHP) software
• Customizable platform
• Supports responsive websites to deliver optimal visitor experiences from any device
• Flexible content architecture
Admin interface
Display only the content appropriate for each display with Views
Customizable menus
• Content authoring
Authentication and permissions for editing workflows and content
• The Developer Portal is based on the open source Drupal 8 content management software
Customizable
Customizing the Developer Portal © Copyright IBM Corporation 2020
Uempty
Drupal modules
• A module (usually PHP and CSS) is a software component that makes up or extends Drupal
features and function
• “Core”
Files and modules that are included with a Drupal version or download
• “Contributed”
Modules or themes that are not part of the Core Drupal product
Available for separate download from the modules or themes of Drupal.org download site
• You can extend your Developer Portal site by installing custom modules that you created, and
also installing contributed modules from the Drupal 8 community
You must have administrator access to complete this task
You can extend your Developer Portal site by installing custom modules that you created and
installing contributed modules from the Drupal 8 community. You must have administrator access
to complete this task.
Uempty
Disable modules
• You can disable an entire module in the Developer Portal to improve performance, or remove
functionality
You must have administrator access to complete this task
• With the Manage option selected on the administration menu, select Extend. Then, select
Disable module
• The list of
modules is
displayed
Select the
module to be
disabled
Click Disable
• You can disable an entire module in the Developer Portal if you want to improve performance
or remove functionality. You must have administrator access to complete this task.
• With the Manage option selected on the administration menu, click Extend. Then, select
Disable module.
• From the list of installed modules, select the module to be disabled. Then, click Disable.
Uempty
Status report (1 of 2)
• Reports menu option of the admin menu
• Displays the Drupal version of the Developer Portal
Important information when importing or creating a custom theme
Theme should match the Drupal version
The status report gives an overview of the Developer Portal parameters and any problems that are
detected with the installation. It might be useful to paste this information into support requests
that are filed with IBM API Connect or drupal.org support forums.
Uempty
Status report (2 of 2)
• There might be Drupal
updates for your
installation.
• Drupal updates cannot
be manually installed
and can only be
addressed through fix
packs or a new
installation.
Uempty
15.4.Creating a custom theme
Uempty
Creating
g a custom
m
theme
Uempty
Drupal themes
• A theme is a collection of templates, configuration files, and asset files (JavaScript, CSS,
images, fonts) which together determine the appearance of a site
• Contains elements such as headers, block layouts, and icons
• A theme is a collection of templates, configuration files, and asset files (JavaScript, CSS,
images, fonts) which together determine the appearance of a site.
• Adminimal is a popular administration theme for Drupal.
Uempty
Subthemes
• Subthemes are just like any other theme, with one difference:
The subtheme inherits resources from the parent theme
You can then override specific resources to configure your required customizations
• The Developer Portal comes with a default API Connect theme
Directly editing the API Connect theme is not permitted or supported, as edited versions of these files
are overwritten when product fixes or upgrades are installed
• Create a custom subtheme of the standard API Connect theme that the Developer Portal uses
by default
Your custom subtheme CSS file needs to contain only the changes or overrides that you want to make
from the default theme
• Drupal 8 subthemes are just like any other theme, with one difference: they inherit resources
from the parent theme.
• The Developer Portal comes with a default API Connect theme.
• Directly editing the API Connect theme is not permitted or supported, as edited versions of
these files are overwritten when product fixes or upgrades are installed.
• The way to create a custom theme is to create a custom subtheme of the standard API
Connect theme that the Developer Portal uses by default.
▪ A subtheme inherits the parent theme's resources, and this means that your custom
subtheme CSS file needs to contain only the changes or overrides that you want to make
from the default theme.
▪ The CSS file can contain as little or as many updates as you like.
Uempty
Uempty
• Click the List tab from the settings menu to see thumbnail icons of the enabled themes.
• You can select an administration theme in the dialog box by scrolling down when the List tab
of the settings is selected.
• You can choose to use the default scheme to use the same theme as the rest of the site, or you
can use a different theme for the appearance of the content when working with the
administration of the Developer Portal.
Uempty
Theme creation
Enable a theme in one of these ways:
• Identify and use a theme that is provided by the Drupal community at
drupal.org/project/project_theme
• You can use themes to control the appearance of your Developer Portal site.
• You can install a new theme from the administration Manage menu by selecting the option
Appearance. Then, select Install new theme.
• When you go to the drupal.org website, you can discover themes by using the search filter.
For example, you can search for administration themes on the Drupal site. The Adminimal
theme is one of the administration themes.
• Themes that you import should match the Drupal version.
Note
You can import a different administration theme and replace the Seven administration theme.
Directly editing or replacing the API Connect theme entirely is not permitted or supported, as
edited versions of these files are overwritten when product fixes or upgrades are installed.
Uempty
Generate a subtheme
• Generate a subtheme of the
latest Developer Portal theme
from the administration
Manage menu item.
• Select Appearance. Then,
select Generate subtheme
Give the subtheme a name
Select the subtheme type: CSS
or SCSS
Choose one of the IBM-
supplied templates for the
theme
• Generate a subtheme of the latest Developer Portal theme from the administration Manage
menu item and give it a name. From the administration Manage menu, select Appearance.
Then, select Generate subtheme.
• Provide a name for the subtheme. Select the subtheme style type. The choices are CSS or
SCSS. Select one of the IBM-supplied color templates for the subtheme. Then, click Generate.
Uempty
• Download the generated subtheme from the Developer Portal and then expand the archive.
• A subtheme inherits all the settings of its parent scheme, unless the settings are overridden.
• Overwrite any style specifications in the subtheme with the customizations that you require.
• Style changes can be made to the overrides.css file in the CSS folder in the expanded archive.
• Refer to the Drupal documentation for creating a subtheme at:
https://www.drupal.org/docs/theming-drupal/creating-sub-themes
• When customizations are completed, create an archive file that is ready for uploading to the
Developer Portal.
Uempty
• You can install a theme from the Appearance > Install new theme option of the
administration menu.
• In the example, the theme is uploaded from an archive file.
Uempty
Uempty
• The newly added them is enabled. You can now set the theme as the default theme in the
Developer Portal.
• When the theme is set as the default, the custom theme becomes the theme that is used by
the Developer Portal.
Uempty
• How the site logo is used depends on the settings for your theme.
• If the changes don't appear immediately in your browser, clear your browser's cache and
reload the page.
Uempty
Uempty
Review questions
1. True or False: Public APIs are displayed on the public interface and on the interface for
authenticated users of the Developer Portal.
2. True or False: Themes that you import should match the Drupal version
Uempty
Review answers
1. True or False: Public APIs are displayed on the public interface and on the interface for
authenticated users of the Developer Portal.
The answer is True.
2. True or False: Themes that you import should match the Drupal version.
The answer is True.
Uempty
This exercise shows you the customization options in the Developer Portal. You sign in to the
Developer Portal with a Portal administrator account, add and configure a Drupal subtheme, and
review some of the standard features of the Developer Portal.
Uempty
Uempty
Overview
This unit provides a summary of the course, explains how the course objectives were met and
where to obtain further information.
Uempty
Unit objectives • Explain how the course met its learning objectives
• Identify IBM credentials that are related to this course
• Locate resources for further study and skill development
Uempty
Uempty
Course • Perform advanced testing of APIs by using the Test tab and the
Local Test Environment
objectives
• Define products and plans in API Manager
• Stage, publish, version, migrate, deprecate, and retire products and
APIs
• Manage member roles and permissions in the Developer Portal
• Create an application and subscribe to a plan
• Review API analytics in the Developer Portal
• Review analytics dashboards and visualizations in API Manager
• Customize the Developer Portal
Uempty
Uempty
Uempty
Additional resources (1 of 5)
• IBM Integration Community
Learn about API Connect, App Connect, IBM
MQ, DataPower, Aspera, Event Streams, and
Cloud Pak for Integration
https://community.ibm.com/community/user/i
ntegration/home
Uempty
Additional resources (2 of 5)
• IBM Cloud Education course information
View and download course materials and
course corrections.
http://ibm.biz/CourseInfo
• IBM Developer
IBM's official developer program offers access
to software trials and downloads, how-to
information, and expert practitioners.
https://developer.ibm.com/
Uempty
Additional resources (3 of 5)
• IBM Training
Search the IBM Training website for courses
and education information.
https://www.ibm.com/training
• Learning Journeys
Learning Journeys describe a recommended
collection of learning content to acquire skills
for a specific technology or role.
https://www.ibm.com/training/journeys/#tab-
ibm-cloud
Uempty
Additional resources (4 of 5)
• IBM Redbooks
IBM Redbooks are developed and published by
the IBM International Technical Support
Organization (ITSO). Redbooks typically provide
positioning and value guidance, installation and
implementation experiences, typical solution
scenarios, and step-by-step "how-to" guidelines.
http://www.redbooks.ibm.com/
• IBM Documentation
IBM Documentation (also known as IBM Docs) is
the primary home for IBM product
documentation.
https://www.ibm.com/docs/en
Uempty
Additional resources (5 of 5)
• IBM Marketplace
Learn about IBM offerings for Cloud, Cognitive,
Data and Analytics, Mobile, Security, IT
Infrastructure, and Enterprise and Business
Solutions.
https://www.ibm.com/products
Uempty
Unit summary • Explain how the course met its learning objectives
• Identify IBM credentials that are related to this course
• Locate resources for further study and skill development
Uempty
Course completion
You have completed this course:
Create, Secure, and Publish APIs with IBM
API Connect V10
backpg