|
Name
|
Unique and meaningful name of the digital interface. Enter a descriptive name that reflects the purpose of the interface.For example, a Customer Management application might expose multiple digital interfaces, such as:
- Customer Profile API — provides customer identity and profile information
- Customer Order Service — supports order creation and status updates
Even though all interfaces are provided by the same application, each interface represents a different interaction contract and can be consumed independently by multiple applications.
|
|
Number
|
Number of the digital interface. This field is automatically generated with the DINTF prefix and can’t be edited.
|
|
Provider Business Application
|
Name of the provider business application that provides, manager, and owns the interface.**Note:** This attribute can be empty if there is no business application in your repository. If you are using open interfaces such as Weather or Financial Service, you are only aware of the interface and track it without a related business application.
|
|
Provider company
|
Name of the provider company.
|
|
Interface Type
|
Type of API used by the interface. This field helps to track whether the API is Public or Open.**Note:** For Public or Open APIs, there won’t be any Provider Business Application unless the Organization exposes it as an open interface.
Use the following options:
- Open API
- Partner API
- Internal API
Public or Open APIs are available to anyone and can be used without any restrictions or license agreements.
Internal or Private APIs are available to authorized \(technical\) users only and can be used without any usage restrictions and regulations.
Partner APIs are available to authorized partners of an API provider. Usually, these APIs have special terms and conditions for usage.
|
|
Parent
|
Name of the parent interface.Often, interfaces are bundled or part of a composition. Because you can reference a digital interface on the digital integration, use the parent interface. The digital interfaces related to the parent interface are listed in the related list of the interface.
|
|
Version
|
Version of the interface. This field helps you to track which digital integrations are using which version of an interface.
|
|
Life Cycle Stage
|
Life cycle stage of the interface. Use the following options:- Ideation
- Design
- Deploy
- Operational
- End of Life
|
|
Life Cycle Stage Status
|
Life cycle stage status of the interface. Each of the main life cycle stages can have one or more life cycle stage statuses. For example, a digital Interface in the operational stage might change status over time from In Use to In Maintenance to Pending Retirement. Use the following options:- Ideation: Under Evaluation, Pilot
- Design: Chartered, Design, Build
- Deploy: Test
- Operational: In Use, In Maintenance, Pending Retirement
- End of Life: Retired, Obsolete
|
|
Model ID
|
Model ID of the interface. This field helps you to track the interface model.This is a reference to the Application Model table where you can manage your own variants of API models or types. For example, Table API, Attachment API, Aggregate API, and Process APIs. This optional field can be used to track the interface model. Depending on your use case, you can add new models and model categories.
|
|
Description
|
Description of the digital interface. Provide the high-level design aspects of the interface. You can provide the details such as how the digital interface adds value, how it should be designed, and how it’s intended to be used.
You can also describe different changes and capabilities according to version of the interface. It helps the Application owners and Architects to decide which interface version they want to use.
|