Introduction

Sentinet Web Application and its Administrative Console provides the means to publish services and APIs in the Sentinet hierarchical Repository, and to place them under comprehensive design-time and run-time and management described in details throughout this document in all previous chapters.

Sentinet Administrative Console Users often have a requirement to select a group of specific virtual services and APIs (even from the different folders of the hierarchical Sentinet Repository) and publish them "publicly" as API Product(s) with all the supporting documentation, tutorials, code and message samples.

Different kind of API users (different from the Sentinet Administrative Console users), called "Developer Users" (or simply "Developers"), can discover published API Products and their APIs, self-register and subscribe for API Products' usage and collect real-time monitoring and historical analytical data from their own usage of APIs offered to them. Developers get this experience by using Sentinet Developer Portal Web Application.

Relationships between Developer Portal entities, and associated workflows that manage these relationships are described in this chapter.

Important

Any or all Developer Portal entities and their relationships can be managed from the Sentinet Administrative Console by the Sentinet Administrative Console users. A typical workflow includes administrative management of only specific workflow steps, while other steps are typically managed by the Developer Portal users from the Developer Portal itself. In this particular respect, you can think about Sentinet Administrative Console as a means for Sentinet Users to be able to do everything “on behalf” of Developer Portal users.

Only Sentinet Administrative Console users with access to the root of the Sentinet Repository can have access to the Developer Portal entities’ management.

There are 5 Developer Portal entities that Sentinet manages. Their short description is below:

  1. API Product -- a collection of one or more virtual services that make up an API Product.

    Note

    A virtual service can be part of one or more API Products, which means the relationship between virtual services and API Products is many-to-many. This is unlike relationship between virtual services and Repository folders, when a virtual service can be placed in only one Repository folder.

  2. Consumer -- represents an organization, a company or some other group of people that will share the same Consumer account in the Developer Portal. As an example, you can think of a Consumer account as your business partner's account created by a business partner company which consumes your API Product(s).

  3. Developer User -- a user of a Consumer account in the Developer Portal. A Consumer account may have more than one user with different access rights.

  4. Subscription -- a subscription is a consent between API Provider (Sentinet Administrative Console Users) and API Consumer (Developer Portal Consumer account) to access an API Product. A Subscription is a relationship between Consumer account and an API Product. A Consumer account can have one or more Subscriptions to the same API Product, as well as many Subscriptions to different API Products.

  5. Application -- is an associative entity(s) that Developer Users create for their Subscriptions in order to consume API Products via these Subscriptions. When Consumer "application" calls API(s) in API Product they typically submit an API Key that identifies both API Consumer and his specific Subscription. Sometimes API Consumers may want to differentiate their own consumer "applications" that make calls to the same API. In this case they use different API Key(s) for the same subscription, where each API Key is linked to its own "application". Effectively, an Application is just an alias for the relationship between Subscription and an API Key. Up to two alternative API Keys can be assigned to a single alias (Application). For example, a Developer Portal user registers two applications of the same Subscription, and he names them Order Web Portal and Order Processing Engine. These are two different applications of a Consumer account where each of them will call the same API Product via the same Subscription. Developer Portal user wants to differentiate (for example, for business analytical purpose) how his two different applications consume the same provider API(s), so he creates two applications for the same subscription, and uses two different pairs of API Keys when calling API(s) from his applications. In this example, Order Web Portal and Order Processing Engine are just two aliases for different pairs of API Keys.

Schematically relationships between Developer Portal entities are shown on the diagram below.

Schematic relationships between Developer Portal entities
Figure. Schematic relationships between Developer Portal entities

Certain properties of the virtual services’ and API Products’ properties will be exposed by the Developer Portal. These properties are service version friendly Name, Description, Attachments, Key Tags and Description Tags.

The following description fields in the Sentinet Administrative Console can be populated with text entered in markdown language, in which case these fields will be shown in the Developer Portal formatted with proper HTML tags (for example: bold fonts, hyperlinks, etc.):

  • Service version Description
  • Virtual service version operation’s Description
  • Virtual endpoint Description
  • Swagger::Operation Description Tag of a virtual operation
  • API Product Description

API Product markdown
Figure. Example of an API Product with its description entered in the markdown language.