跳转至

Install a Developer Console application with Marketplace（通过 Marketplace 安装开发者控制台应用程序）

Use Marketplace to package and install Developer Console applications across Foundry environments. You can package an application or its code repository:

  1. Application packaging: Package a developer console application together with its metadata and OAuth client. This is the recommended approach for shipping deployed websites using Production and Singleton products. Note that for cases where a website asset doesn't exist, you can still ship the OAuth client using this approach. See Packaging and installing a Developer Console application for details.
  2. Source code packaging: Package a website code repository without a Developer Console application. This is the recommended approach for templatized applications and when creating a different Developer Console application on the destination environment. See Packaging and templating Developer Console associated source code for details.

Packaging both an application and its source code may be useful when bootstrapping an OAuth client without an existing website. In this case, you may want to modify the application code post-installation and publish a website that uses the installed OAuth client. This workflow is uncommon for production applications because the installed application always matches the latest website assets (if they exist), so the source code is effectively ignored.

:::callout{theme="warning"} Ontology entity API names are not automatically remapped during installation. This applies to both application and source code installations. This means that an installed application may break if it uses API names that don't exist in the destination ontology. See Handling API name changes for strategies to manage API name consistency across environments. :::

Packaging and installing a Developer Console application

A packaged application includes:

  • Website assets: The static files and content security policies for applications with generated website assets (see website hosting). DevOps packages the latest deployed version of the website asset by default and falls back to the latest undeployed asset version if no deployed assets exist on the source.
  • Application metadata: Name, description, and configuration.
  • OAuth client: Client type, grant types, redirect URLs.
  • Resource restrictions: Ontology SDK and Platform SDK resources.

Packaging an application in DevOps

In Foundry DevOps, add a Developer Console application as an output of a product. Developer Console applications have two types of dependencies:

  1. Ontology entities (and their dependencies) and Compass projects in the application's restrictions.
  2. Parameter inputs that need to be defined as part of the installation. These include subdomains for website hosting and security markings.

Adding a Developer Console application as an output in DevOps.

Installing an application

Installing an application from Marketplace automatically creates the Developer Console resource and configures OAuth. Learn more about installing products. In some cases, you will need to take manual steps during installation:

  • In Bootstrap mode, Marketplace may automatically rewrite Ontology API names to avoid collisions within the same Ontology. For example, if installing an object type API_NAME=Truck and there already exists an object type API_NAME=Truck in the destination Ontology, Marketplace may rename the installed object type Truck_1. This has the potential to break installed applications that reference objects by API names. When installing Ontology entities alongside an application, select Always install source Ontology API names during installation. This preserves the original API names rather than prefixing or modifying them, ensuring application code continues to work.

Always install source Ontology entity API names toggle in Marketplace.

  • When the packaged application uses subdomain hosting, a new subdomain is defined as part of Marketplace installation. This generally requires an additional approval, often from an Information Security Officer. Post installation to approve the subdomain, navigate to the Website hosting page in Developer Console. The website will not be accessible until this approval is granted.

The website hosting domain parameter input during Marketplace installation.

Upgrading an application

To update an installed application as part of a Marketplace product:

  1. Update the application in the source environment.
  2. If updating website assets, deploy in Developer Console first. DevOps will package the most recent deployed website asset.
  3. Create a new product version in Foundry DevOps.

Application parameters remapping

For applications with built website assets, Marketplace automatically maps application parameters during installation. The following values are replaced with target environment equivalents:

For automatic mapping to work, an application must read these values from meta tags in index.html rather than the application packaged code itself. Applications created with @osdk/create-app ↗ v2.1.3+ or VS Code workspaces in Foundry are configured this way by default.

:::callout{theme="warning"} Unlike website parameters, Ontology API names are not automatically remapped during installation. See Handling API name changes for strategies to manage API name consistency across environments. :::

Updating existing applications

Applications created before @osdk/create-app ↗ v2.1.3 require code changes to enable automatic configuration replacement. Add the following meta tags to index.html:

<meta name="osdk-clientId" content="%VITE_FOUNDRY_CLIENT_ID%" />
<meta name="osdk-redirectUrl" content="%VITE_FOUNDRY_REDIRECT_URL%" />
<meta name="osdk-foundryUrl" content="%VITE_FOUNDRY_API_URL%" />
<meta name="osdk-ontologyRid" content="%VITE_FOUNDRY_ONTOLOGY_RID%" />

Then update the client initialization to read from these meta tags:

import { createClient, type Client } from "@osdk/client";
import { createPublicOauthClient, type PublicOauthClient } from "@osdk/oauth";

function getMetaTagContent(tagName: string): string {
    const elements = document.querySelectorAll(`meta[name="${tagName}"]`);
    const element = elements.item(elements.length - 1);
    const value = element ? element.getAttribute("content") : null;
    if (value == null || value === "") {
        throw new Error(`Meta tag ${tagName} not found or empty`);
    }
    if (value.match(/%.+%/)) {
        throw new Error(
            `Meta tag ${tagName} contains placeholder value. Add ${value.replace(/%/g, "")} to your .env files`,
        );
    }
    return value;
}

const foundryUrl = getMetaTagContent("osdk-foundryUrl");
const clientId = getMetaTagContent("osdk-clientId");
const redirectUrl = getMetaTagContent("osdk-redirectUrl");
const ontologyRid = getMetaTagContent("osdk-ontologyRid");

export const auth: PublicOauthClient = createPublicOauthClient(
    clientId,
    foundryUrl,
    redirectUrl,
);

export const client: Client = createClient(foundryUrl, ontologyRid, auth);

Add the Ontology RID to the .env files:

VITE_FOUNDRY_ONTOLOGY_RID=<ri.ontology.main.ontology.your-ontology-rid>

:::callout{theme="warning"} These code changes are specific to TypeScript OSDK 2.0. If you are using OSDK 1.x, first migrate to OSDK 2.0. :::

Custom workshop widget integration

Custom workshop widgets deploy similarly to Developer Console applications. See Add a widget set to a Marketplace product.

Limitations

  • Confidential client secrets: Confidential clients can be packaged, but require manual intervention in the destination environment to generate a new secret. You can generate a new secret in Developer Console by navigating to OAuth & restrictions and selecting Rotate secret.
  • No standalone OAuth clients: Standalone OAuth clients cannot be packaged and deployed with Marketplace. Use unrestricted applications instead.
  • No version-pinned functions: All functions in an application's OSDK must use the latest version to be packaged. Applications with pinned function versions are not currently Marketplace compatible. This limitation is likely to change in a future release.

Packaging and templating Developer Console associated source code

You can package application source code as you would any other code repository. Unlike with application packaging, configuration parameters like Ontology RID and Redirect URL are not remapped in the source code. This means that when source code is shipped together with an application, the application website will function correctly on the destination environment but the source code files still contain the original environment's parameters.

Templatization (Beta)

:::callout{theme="warning"} Templatization is experimental and treats any {{}} syntax as a template variable, including patterns already present in the code. For example, JSX inline styles like style={{color: 'red'}} will be incorrectly interpreted as template inputs. Review the codebase for existing double-brace patterns before enabling templatization. :::

For source code only installations, you can templatize your application so that parameters are rewritten automatically on install. Templating typically makes sense in Bootstrap mode when:

  • Running a bootcamp or workshop in which all developers need to bootstrap their code with a preconfigured OSDK application.
  • Providing an example for users to kickstart their work.
  • Enforcing a set of UI standards for all React projects.
  • Providing a React template that uses a shared set of Ontology resources.

To templatize an application:

  1. Add handlebars to variables in code (for example, {{my_variable}}) that will need to be rewritten during install.
  2. In DevOps, add the relevant code repository and enable source code templating in the repository configuration menu.

The OSDK source code templatization settings in DevOps.

  1. For custom parameters, Marketplace will prompt the user to provide values for these parameters and will resolve them during installation. Reserved parameters will be automatically replaced on install.
  2. When installing the template from Marketplace, a new repository and a linked Developer Console application will be automatically created for the user. When using this package for bootstrapping, the Bootstrap option must be selected during installation.

When using handlebar parameters, the application will fail CI checks due to type checks. This means that you cannot package website assets – which deploy after CI checks pass - together with templatized code.

:::callout{theme="warning"} We recommend not using parameters for Ontology API name mappings. Applications with many templatized API names become difficult to maintain and debug. For complex deployments, define Ontology resources as inputs so installers provide matching resources. Templates work best for simpler variable substitutions. See Handling API name changes for recommended strategies. :::

Reserved parameters

In addition to custom parameters, TypeScript OSDK applications have the following reserved parameters which automatically resolve to their respective values during installation:

Variable Example value Files that may reference these parameters
{{FOUNDRY_HOSTNAME}} yourdomain.palantirfoundry.com .env, .npmrc, foundry.config.json
{{APPLICATION_CLIENT_ID}} 1564cead075af0e23eb1799ac0f6381f .env
{{APPLICATION_PACKAGE_NAME}} osdk-sample-app-20 package.json, code files referencing the package
{{APPLICATION_RID}} ri.third-party-applications.main.application.7ebc94b7-bad3-45a9-a063-d7fc0ccd2873 foundry.config.json
{{REPOSITORY_RID}} ri.stemma.main.repository.35d25ea4-973d-4112-a7d3-04c31efa1875 .npmrc, settings.sh
{{ONTOLOGY_RID}} ri.ontology.main.ontology.00000000-0000-0000-0000-000000000000 .env

Note the following constraints for reserved parameters:

  • Your application package name must not include @ or a trailing /sdk.
  • The OSDK version in package.json must be set to latest or 0.1.0 for the template to work out of the box when installed.

Handling API name changes

OSDK references Ontology entities by API name. This means that the entities used by an installed Developer Console application (or application code) must have identical API names between the source and destination Ontologies for the application to work.

This behavior is different than most Foundry applications which reference resources using non-human-readable RIDs that are mapped between enrollments. For example, a Workshop application that references an object type with rid=X may be rewritten, on deployment, to reference an object type with rid=y. In contrast, compiled OSDK application assets and raw OSDK code are intended to be human readable and identical between source and destination repositories.

To ensure entity API name consistency, where possible, you should package and install both Ontology resources and the application. Ontology resources should be product outputs together with the Developer Console application (or outputs to a second product deployed alongside the first). That way, Marketplace creates resources in the destination Ontology with the same API names as the source, preventing breaks. When installing Ontology entities, select Always install source Ontology API names to preserve the original names.

There are four strategies for handling API name conflicts, divided into two categories:

When packaging Ontology with the application: If an object type already exists in the destination Ontology with the same API name, Marketplace will apply an installation prefix, which risks breaking OSDK code. To avoid this, use fully qualified names or separate spaces.

When not packaging Ontology with the application: If the destination environment already has the required Ontology resources, reference them directly. Use interfaces when the source and destination object types are intentionally different but share a common structure. If the objects are identical but have different names, modify API names manually to match across environments.

Fully qualified names

To prevent conflicts when packaging the Ontology, use fully qualified API names when defining Ontology entities on a source environment. Fully qualified API names include a namespace prefix that makes them globally unique across Ontologies. As long as an application is deployed once per Ontology, that is, a Singleton product, fully qualified names guarantee no API name conflicts.

Configure fully qualified names in Ontology Manager.

Use separate spaces

For multi-organization or development lifecycle workflows, using distinct spaces is another way to remove API name conflicts. API name uniqueness is only enforced at the space level. Each space maps one-to-one with an Ontology, so users can think of this as Ontology-level uniqueness.

Interfaces

Sometimes, conflicting API names actually represent two implementations of the same interface. In these cases, consider rewriting application code to use interfaces rather than concrete object types.

For example, consider an application that uses the medicine object type in the source Ontology, but the destination environment has a vaccine object type instead. This can be simplified by representing medicine as an interface rather than an object type. The medicine interface would then be deployed as part of the Marketplace product, and, in the destination Ontology, vaccine would implement medicine. This approach has the advantage of human-readable code, clarity about the abstraction at build time, and sensible ontological classification on the destination environment.

In other words, building applications on interfaces rather than object types guarantees that application code is legible and often eliminates the need to map objects altogether.

Modify API names manually

When the source and destination have identical objects with different API names, you will need to manually edit API names to match between environments. Changing API names has the potential to break other applications or functions that reference those entities, so proceed carefully.

中文翻译

通过 Marketplace 安装开发者控制台应用程序

使用 Marketplace 在 Foundry 环境中打包和安装开发者控制台应用程序。您可以打包应用程序或其代码仓库：

  1. 应用程序打包： 将开发者控制台应用程序与其元数据和 OAuth 客户端一同打包。这是使用生产环境和单例模式产品交付已部署网站时的推荐方法。请注意，如果网站资产不存在，您仍可通过此方法交付 OAuth 客户端。详见打包和安装开发者控制台应用程序。
  2. 源代码打包： 打包网站代码仓库而不包含开发者控制台应用程序。这是模板化应用程序以及在目标环境创建不同开发者控制台应用程序时的推荐方法。详见打包和模板化开发者控制台关联的源代码。

在引导模式下，同时打包应用程序及其源代码可能有助于为尚无网站的 OAuth 客户端进行初始化。在这种情况下，您可能希望在安装后修改应用程序代码，并发布一个使用已安装 OAuth 客户端的网站。这种工作流在生产环境应用程序中并不常见，因为已安装的应用程序始终匹配最新的网站资产（如果存在），因此源代码实际上会被忽略。

:::callout{theme="warning"} 本体实体 API 名称在安装过程中不会自动重新映射。这同时适用于应用程序和源代码安装。这意味着，如果已安装的应用程序使用了目标本体中不存在的 API 名称，则可能会出错。请参阅处理 API 名称变更了解跨环境管理 API 名称一致性的策略。 :::

打包和安装开发者控制台应用程序

打包的应用程序包括：

  • 网站资产： 包含已生成网站资产的应用程序的静态文件和安全策略（参见网站托管）。DevOps 默认打包最新已部署版本的网站资产，如果源环境中没有已部署的资产，则会回退到最新的未部署资产版本。
  • 应用程序元数据： 名称、描述和配置。
  • OAuth 客户端： 客户端类型、授权类型、重定向 URL。
  • 资源限制： Ontology SDK 和 Platform SDK 资源。

在 DevOps 中打包应用程序

在 Foundry DevOps 中，将开发者控制台应用程序添加为产品的输出。开发者控制台应用程序有两种依赖类型：

  1. 应用程序限制中的本体实体（及其依赖项）和 Compass 项目。
  2. 需要在安装过程中定义的参数输入。这些包括网站托管的子域和安全标记。

在 DevOps 中将开发者控制台应用程序添加为输出。

安装应用程序

从 Marketplace 安装应用程序会自动创建开发者控制台资源并配置 OAuth。了解更多关于安装产品的信息。在某些情况下，您需要在安装过程中执行手动步骤：

  • 在引导模式下，Marketplace 可能会自动重写本体 API 名称以避免同一本体内的冲突。例如，如果安装了一个对象类型 API_NAME=Truck，而目标本体中已存在一个对象类型 API_NAME=Truck，Marketplace 可能会将安装的对象类型重命名为 Truck_1。这可能会破坏那些通过 API 名称引用对象的已安装应用程序。在安装本体实体与应用程序时，请在安装过程中选择始终安装源本体 API 名称。这将保留原始 API 名称，而不是添加前缀或修改它们，从而确保应用程序代码继续正常工作。

Marketplace 中的“始终安装源本体实体 API 名称”开关。

  • 当打包的应用程序使用子域托管时，新的子域会在 Marketplace 安装过程中定义。这通常需要额外的审批，通常来自信息安全官。安装后，要批准子域，请导航至开发者控制台中的网站托管页面。在获得批准之前，网站将无法访问。

Marketplace 安装过程中的网站托管域参数输入。

升级应用程序

要作为 Marketplace 产品的一部分更新已安装的应用程序：

  1. 在源环境中更新应用程序。
  2. 如果要更新网站资产，请先在开发者控制台中部署。DevOps 将打包最近部署的网站资产。
  3. 在 Foundry DevOps 中创建新的产品版本。

应用程序参数重新映射

对于具有已构建网站资产的应用程序，Marketplace 会在安装过程中自动映射应用程序参数。以下值将被替换为目标环境的对应值：

要使自动映射生效，应用程序必须从 index.html 中的 meta 标签读取这些值，而不是从应用程序打包的代码本身读取。使用 @osdk/create-app ↗ v2.1.3+ 或 Foundry 中的 VS Code 工作区创建的应用程序默认已按此方式配置。

:::callout{theme="warning"} 与网站参数不同，本体 API 名称在安装过程中不会自动重新映射。请参阅处理 API 名称变更了解跨环境管理 API 名称一致性的策略。 :::

更新现有应用程序

在 @osdk/create-app ↗ v2.1.3 之前创建的应用程序需要进行代码更改才能启用自动配置替换。在 index.html 中添加以下 meta 标签：

<meta name="osdk-clientId" content="%VITE_FOUNDRY_CLIENT_ID%" />
<meta name="osdk-redirectUrl" content="%VITE_FOUNDRY_REDIRECT_URL%" />
<meta name="osdk-foundryUrl" content="%VITE_FOUNDRY_API_URL%" />
<meta name="osdk-ontologyRid" content="%VITE_FOUNDRY_ONTOLOGY_RID%" />

然后更新客户端初始化以从这些 meta 标签中读取：

import { createClient, type Client } from "@osdk/client";
import { createPublicOauthClient, type PublicOauthClient } from "@osdk/oauth";

function getMetaTagContent(tagName: string): string {
    const elements = document.querySelectorAll(`meta[name="${tagName}"]`);
    const element = elements.item(elements.length - 1);
    const value = element ? element.getAttribute("content") : null;
    if (value == null || value === "") {
        throw new Error(`Meta tag ${tagName} not found or empty`);
    }
    if (value.match(/%.+%/)) {
        throw new Error(
            `Meta tag ${tagName} contains placeholder value. Add ${value.replace(/%/g, "")} to your .env files`,
        );
    }
    return value;
}

const foundryUrl = getMetaTagContent("osdk-foundryUrl");
const clientId = getMetaTagContent("osdk-clientId");
const redirectUrl = getMetaTagContent("osdk-redirectUrl");
const ontologyRid = getMetaTagContent("osdk-ontologyRid");

export const auth: PublicOauthClient = createPublicOauthClient(
    clientId,
    foundryUrl,
    redirectUrl,
);

export const client: Client = createClient(foundryUrl, ontologyRid, auth);

将本体 RID 添加到 .env 文件中：

VITE_FOUNDRY_ONTOLOGY_RID=<ri.ontology.main.ontology.your-ontology-rid>

:::callout{theme="warning"} 这些代码更改特定于 TypeScript OSDK 2.0。如果您使用的是 OSDK 1.x，请先迁移到 OSDK 2.0。 :::

自定义 Workshop 小部件集成

自定义 Workshop 小部件的部署方式与开发者控制台应用程序类似。请参阅将小部件集添加到 Marketplace 产品。

限制

  • 机密客户端密钥： 机密客户端可以打包，但需要在目标环境中手动干预以生成新密钥。您可以在开发者控制台中导航至 OAuth 和限制并选择轮换密钥来生成新密钥。
  • 无独立 OAuth 客户端： 独立的 OAuth 客户端无法通过 Marketplace 打包和部署。请改用无限制应用程序。
  • 无版本锁定函数： 应用程序 OSDK 中的所有函数必须使用最新版本才能打包。具有锁定函数版本的应用程序目前不兼容 Marketplace。此限制可能在未来的版本中发生变化。

打包和模板化开发者控制台关联的源代码

您可以像打包任何其他代码仓库一样打包应用程序源代码。与应用程序打包不同，源代码中的配置参数（如本体 RID 和重定向 URL）不会被重新映射。这意味着，当源代码与应用程序一起交付时，应用程序网站在目标环境中可以正常运行，但源代码文件仍然包含原始环境的参数。

模板化（Beta）

:::callout{theme="warning"} 模板化是实验性功能，会将任何 {{}} 语法视为模板变量，包括代码中已有的模式。例如，像 style={{color: 'red'}} 这样的 JSX 内联样式将被错误地解释为模板输入。在启用模板化之前，请检查代码库中是否存在现有的双花括号模式。 :::

对于仅安装源代码的情况，您可以对应用程序进行模板化，以便在安装时自动重写参数。模板化通常在引导模式下有意义，当：

  • 运行训练营或工作坊时，所有开发者需要使用预配置的 OSDK 应用程序引导其代码。
  • 为用户提供示例以启动其工作。
  • 为所有 React 项目强制执行一套 UI 标准。
  • 提供使用共享本体资源集的 React 模板。

要对应用程序进行模板化：

  1. 在代码中为需要在安装时重写的变量添加 Handlebars 语法（例如 {{my_variable}}）。
  2. 在 DevOps 中，添加相关的代码仓库，并在仓库配置菜单中启用源代码模板化。

DevOps 中的 OSDK 源代码模板化设置。

  1. 对于自定义参数，Marketplace 将提示用户为这些参数提供值，并在安装过程中解析它们。保留参数将在安装时自动替换。
  2. 从 Marketplace 安装模板时，系统会自动为用户创建一个新的仓库和一个关联的开发者控制台应用程序。当使用此包进行引导时，必须在安装过程中选择引导选项。

使用 Handlebars 参数时，应用程序会因类型检查而无法通过 CI 检查。这意味着您无法将网站资产（在 CI 检查通过后部署）与模板化代码一起打包。

:::callout{theme="warning"} 我们建议不要对本体 API 名称映射使用参数。具有许多模板化 API 名称的应用程序将难以维护和调试。对于复杂的部署，请将本体资源定义为输入，以便安装者提供匹配的资源。模板最适合简单的变量替换。请参阅处理 API 名称变更了解推荐的策略。 :::

保留参数

除了自定义参数外，TypeScript OSDK 应用程序还具有以下保留参数，这些参数在安装时会自动解析为其各自的值：

变量 示例值 可能引用这些参数的文件
{{FOUNDRY_HOSTNAME}} yourdomain.palantirfoundry.com .env, .npmrc, foundry.config.json
{{APPLICATION_CLIENT_ID}} 1564cead075af0e23eb1799ac0f6381f .env
{{APPLICATION_PACKAGE_NAME}} osdk-sample-app-20 package.json, 引用包的代码文件
{{APPLICATION_RID}} ri.third-party-applications.main.application.7ebc94b7-bad3-45a9-a063-d7fc0ccd2873 foundry.config.json
{{REPOSITORY_RID}} ri.stemma.main.repository.35d25ea4-973d-4112-a7d3-04c31efa1875 .npmrc, settings.sh
{{ONTOLOGY_RID}} ri.ontology.main.ontology.00000000-0000-0000-0000-000000000000 .env

请注意保留参数的以下约束：

  • 您的应用程序包名称不得包含 @ 或尾随的 /sdk。
  • package.json 中的 OSDK 版本必须设置为 latest 或 0.1.0，以便模板在安装后开箱即用。

处理 API 名称变更

OSDK 通过 API 名称引用本体实体。这意味着已安装的开发者控制台应用程序（或应用程序代码）所使用的实体在源本体和目标本体之间必须具有相同的 API 名称，应用程序才能正常工作。

此行为与大多数 Foundry 应用程序不同，后者使用非人类可读的 RID 引用资源，这些 RID 在注册环境之间进行映射。例如，一个引用对象类型 rid=X 的 Workshop 应用程序在部署时可能会被重写为引用对象类型 rid=y。相比之下，编译后的 OSDK 应用程序资产和原始 OSDK 代码旨在具有人类可读性，并且在源仓库和目标仓库之间保持一致。

为确保实体 API 名称的一致性，在可能的情况下，您应该同时打包和安装本体资源以及应用程序。本体资源应与开发者控制台应用程序一起作为产品输出（或作为与第一个产品一起部署的第二个产品的输出）。这样，Marketplace 会在目标本体中创建与源本体具有相同 API 名称的资源，从而防止中断。在安装本体实体时，选择始终安装源本体 API 名称以保留原始名称。

有四种处理 API 名称冲突的策略，分为两类：

当与应用程序一起打包本体时： 如果目标本体中已存在具有相同 API 名称的对象类型，Marketplace 将应用安装前缀，这可能会破坏 OSDK 代码。为避免这种情况，请使用完全限定名称或使用单独的空间。

当不与应用程序一起打包本体时： 如果目标环境已具有所需的本体资源，请直接引用它们。当源和目标对象类型有意不同但共享共同结构时，请使用接口。如果对象相同但名称不同，请手动修改 API 名称以跨环境匹配。

完全限定名称

为防止打包本体时发生冲突，请在源环境中定义本体实体时使用完全限定的 API 名称。完全限定的 API 名称包含一个命名空间前缀，使其在整个本体中全局唯一。只要应用程序每个本体只部署一次，即单例模式产品，完全限定名称就能保证不会发生 API 名称冲突。

在本体管理器中配置完全限定名称。

使用单独的空间

对于多组织或开发生命周期工作流，使用不同的空间是消除 API 名称冲突的另一种方法。API 名称唯一性仅在空间级别强制执行。每个空间与一个本体一一对应，因此用户可以将其视为本体级别的唯一性。

接口

有时，冲突的 API 名称实际上代表同一接口的两种实现。在这些情况下，请考虑重写应用程序代码以使用接口而不是具体的对象类型。

例如，考虑一个在源本体中使用 medicine 对象类型的应用程序，但目标环境有一个 vaccine 对象类型。这可以通过将 medicine 表示为接口而不是对象类型来简化。然后，medicine 接口将作为 Marketplace 产品的一部分部署，并且在目标本体中，vaccine 将实现 medicine。这种方法具有代码人类可读、构建时抽象清晰以及在目标环境中进行合理的本体分类等优点。

换句话说，基于接口而非对象类型构建应用程序可以保证应用程序代码清晰易读，并且通常可以完全消除映射对象的需要。

手动修改 API 名称

当源环境和目标环境具有相同对象但 API 名称不同时，您需要手动编辑 API 名称以在环境之间匹配。更改 API 名称可能会破坏引用这些实体的其他应用程序或函数，因此请谨慎操作。