Applications overview

Applications in the Platform represent the digital systems of an organization and serve as the fundamental units for the consumption and provisioning of digital products. They are the point where producers and consumers meet: producers expose their digital products through an application, and consumers use the digital products of others through their own applications. Each Application can act as:

• Consumer: An entity that subscribes to digital products to use their services.

• Provider: An entity that exposes digital products to be consumed by other applications.

The same application can play both roles at the same time.

Applications are associated with a Group within an Organization, allowing governance and role-based access control. Each application has two key stakeholders:

• Application Owner: Responsible for functional and business aspects of the application.

• Application Developer: Manages the technical implementation and maintenance of the application.

Applications are scoped to a specific Organization, so each user can only create them in the context of Organizations which he is a member of. Tenant Owners are the only ones exempt from this rule, thus they can create Applications everywhere.

How applications are used

• In the workspace, producers and consumers create and maintain their applications, with their environments, use cases and subscriptions.

• In the App Catalog, users can browse the published applications of the ecosystem and see which digital products each of them provides or consumes.

• When subscribing to an API Product, the consumer chooses the application that will use it. The subscription, the credentials (Key Set) and, if enabled, the client IP addresses all belong to that application. See Subscription Management and Network.

What each user can see and do with applications depends on the roles and profiling configured by the administrator.

Application lifecycle

When an organization wants to govern its applications step by step, each application follows a lifecycle divided into macro-states, each containing one or more sub-states:

• Concept: all applications are born in this state where all information is collected. Applications in this state are not yet visible in the App Catalog. The default sub-states are:

  • Draft: this is the initial state when you first CREATE an application

  • Proposed: when all required fields have been filled and your application is ready to be validated by a supervisor or a functional responsible, you can PROPOSE it

  • Rejected: A proposed application that has been rejected for any reason.

• Published: When a proposed application gets ACCEPTED it means that it is ready to begin exposing services and/or consuming services provided by others. Once they reach this state applications are visible in the App Catalog. The default sub-states are:

  • Activating: a transitional state in which the Platform performs synchronization operations.

  • Activation Error: something went wrong while the Platform tried to perform synchronization operations with an API Gateway and/or automatic pipelines. You can check the error and then RETRY.

  • Active: Once it has reached this state the application can expose and/or consume digital products.

  • Suspending: transitional state in which the Platform performs synchronization operations.

  • Suspension Error: something went wrong while the Platform tried to perform synchronization operation with an API Gateway and/or automatic pipelines. You can check the error and then RETRY.

  • Suspended: the application is frozen. It is still available on the Gateway and its subscriptions required are active but any subscription to its exposed APIs is Suspended.

⚠ Note: Activating, Activation Error, Suspending and Suspension Error sub-states are expected and relevant only if the Platform is integrated with an API Gateway and/or automatic deploy pipelines.

• Retired: when an application is dismissed, meaning that it will no longer expose or consume digital products, you can retire it. This state has no sub-states. When retiring an application:

  • all its exposed APIs will be automatically retired so they will no longer be usable

  • any subscriptions to the above-mentioned APIs will be revoked

  • any subscription of the retired application to APIs exposed by other providers gets revoked as well

Application Fields

The following table summarizes all the default fields of an Application, specifying how the value(s) are to be inserted and any checks performed on the value(s).