HomeDocumentationProduct UpdatesProduct Roadmap
User Docs
Request DemoWebsite

Manifest File and Schema

Manifest file for microservice discovery and the manifest schema.

Suggest Edits

🚧

Early Adopter Release

This feature is currently in early adopter release and may not be available to all customers.

You can set up microservice discovery by following the configuration-as-code approach, which involves using a manifest file to define each microservice's characteristics and metadata. The manifest file is stored in a version-controlled repository, typically alongside the source code of the microservice. For detailed information, see Microservice Discovery in Your CI/CD Pipeline.

Manifest File

📘

Note

A manifest file can only describe one microservice. Each repository can contain multiple manifest files.

For monorepos, we recommend storing one manifest file per microservice within the monorepo.

Here's an example SAP LeanIX manifest file:

version: 1
metadata:
  name: disputes-service-v1
  externalId: disputes-service-v1
  description: |
    A microservice responsible for payment disputes.
    This service handles payment transaction disputes and is an integral part of our payment ecosystem.
  type: Backend  
  repository:
    url: https://example.com
    path: /path/to/repo
    status: active
    visibility: private

  applications:
    - factSheetId: fa787383-7233-4896-8fad-c1f1bef30dd2

  tags:
    - tagGroupName: Domain
      tagNames:
        - Payments

    - tagGroupName: Location
      tagNames:
        - AWS-EU1
        - AWS-EU2

  teams:
    - factSheetId: 63eda74c-57f7-4768-b1c9-3b2813b11504
    - factSheetId: afd1ee0f-095b-4c68-88f6-d3628070ce18

  resources:
    - name: Disputes Process Flow
      type: documentation
      url: https://myorg.atlassian.net/wiki/spaces/disputes
      description: Disputes process flow and diagrams

Manifest Schema

The following sections detail the attributes supported by the manifest file.

Version

The version of the manifest file schema is specified in version. Currently, only version 1 is supported.

Metadata

The metadata section of the manifest file defines the characteristics of your microservice.

AttributeRequiredDescription
nameYesThe name of the microservice.
externalIdYesThe unique identifier of the microservice in the external system. It must be globally unique, ensuring that multiple microservices don't share the same external ID.
descriptionNoThe description of the microservice.
typeNoThe type of the microservice. It must match one of the values in the lxMicroserviceType field predefined in the meta model configuration, such as backend, ui, or data. If no type is passed, the default value backend is used.
repositoryNoThe details of the repository where the microservice is hosted, including url, path, status, and visibility.

We recommend a set of guidelines for formatting service names, especially for popular vendors. This uniform formatting helps maintain consistency and makes it easier to manage and locate services. The out-of-the-box Git integrations will follow this external ID schema. By adhering to this convention, you won't need any migration effort once we support that Git system.

ProviderFormatExample
GitHub{organization}/{repo-name}/{servicename}acme/banking-portal/payment-engine
GitLab{group}/{repo-name}/{servicename}acme/banking-portal/payment-engine
Bitbucket{workspace}/{repo-name}/{servicename}acme/banking-portal/payment-engine
Azure{organization}/{repo-name}/{servicename}acme/banking-portal/payment-engine

Applications

Microservices play a crucial role in supporting business applications. They are essentially small, independent services that work together to run a complex application. Each microservice is a self-contained unit that performs a unique function within the broader application ecosystem.

The applications section is necessary to establish the correct association between the microservice and the corresponding business applications. Microservices can be linked to multiple business applications, so you can provide multiple different business application fact sheets.

AttributeRequiredDescription
factSheetIdYesThe IDs of business application fact sheets.
nameYesThe names of business application fact sheets, corresponding to the display names.

📘

Note

If you supply both factSheetId and name attributes, factSheetId takes precedence.

Tags

In the tags section within the manifest file, you can assign tag groups and tags to your microservice. To learn more about tags, see Tags.

AttributeRequiredDescription
tagGroupNameNoThe name of the tag group to assign to the microservice.
tagNamesNoA list of tags from the tag group to assign to the microservice.

Teams

In the teams section within the manifest file, you can define the teams that own the microservice. Team is a subtype of organization fact sheets. For additional information about subtypes, see Organizations Fact Sheet Subtypes.

AttributeRequiredDescription
factSheetIdYesThe IDs of team fact sheets, showing the owning teams.
nameYesThe names of team fact sheets, corresponding to the display names.

📘

Note

If you supply both factSheetId and name attributes, factSheetId takes precedence.

Resources

In the resources section within the manifest file, you can define the resources associated with your microservice. For more information, see Storing Resources on Fact Sheets.

AttributeRequiredDescription
nameYesThe name of the resource.
typeYesThe resource type. You can find a list of supported resource types in the API documentation.
urlNoThe URL of the resource.
descriptionNoThe description of the resource.

Repository

The repository section within the metadata part of the manifest file provides details about the repository hosting the microservice.

AttributeRequiredDescription
urlYesThe URL of the repository hosting the microservice code.
pathNoThe path within the repository hosting the microservice code.
statusNoThe status of the repository, indicating whether it's ACTIVE or ARCHIVED.
visibilityNoThe visibility of the repository, specifying whether it's INTERNAL, PRIVATE, or PUBLIC.

📘

Note

Ensure that the tag groups, applications, and teams that you want to associate with your microservice exist in your SAP LeanIX workspace.

Updated 2 days ago