注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。

高度なワークフロー

ベータ版

SuperRepo は開発のベータ版段階にあり、お使いのエンロールメントでは利用できない場合があります。開発が活発に進められている間は、機能が変更される可能性があります。

リポジトリを SuperRepo にするには、各コンポーネントの種類とパスからなるプロジェクト構造を宣言する foundry.yml ファイルをルートに配置する必要があります。このファイルでは、出力アーティファクト（Marketplace 製品）や、複数の出力を宣言することもできます。

複数の製品を追加する

foundry.yml 設定ファイルには、トップレベルの components リスト、または各製品内に components キーを持つトップレベルの products リストのいずれかを記述できます。複数製品の設定では、各製品内に bundle キーを宣言して、出力アーティファクトを定義します。次の例を確認してください。

Copied!1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
products:
  - components:
      - type: ONTOLOGY
        path: ./ontology
      - type: APP
        path: ./app
    osdkOutput: ontology/osdk-output
    apiNamespace: com.palantir.ontology
    bundle:
      name: "operations-console"
      description: "example description"
      mavenCoordinate: "com.example:operations-console"
      installMode: SINGLETON

  - components:
      - type: ONTOLOGY
        path: ./analytics/ontology
      - type: APP
        path: ./analytics/app
    osdkOutput: analytics/ontology/osdk-output
    apiNamespace: com.palantir.analytics
    bundle:
      name: "analytics-console"
      description: "example description"
      mavenCoordinate: "com.example:analytics-console"
      installMode: SINGLETON

複数製品の設定を使用する場合は、すべての Foundry CLI コマンドに --product <bundle name> オプションを渡して、実行対象の製品を指定します。

ファイルから製品を削除せずにパッケージ化済みの出力から除外するには、その製品に includeInBundle: false を設定します。このオプションを省略した場合、デフォルトは true です。

複数製品の SuperRepo をバンドルする

単一製品の SuperRepo は、foundry bundle --project-version <VERSION> という1つのコマンドでパッケージ化されます。このコマンドは複数製品の設定を受け付けません。foundry.yml で複数の製品を宣言している場合、コマンドの実行に失敗し、代わりに以下の2つのサブコマンドを使用するよう案内されます。

複数製品の SuperRepo は、2段階でバンドルします。

製品ごとに foundry bundle product --product <bundle name> --project-version <VERSION> を1回実行します。実行するたびに、その製品のパッケージ化済みの出力が build/<bundle name>/blockset.zip に書き込まれます。--project-version は実行ごとに指定するため、同じリポジトリ内の製品にそれぞれ独立したバージョンを設定できます。
foundry bundle store を実行して、これらの出力を build/store.zip にまとめます。このコマンドはバージョン引数を受け取りません。別の場所にストアを書き込むには、--output を渡します。まだバンドルされていない製品がある場合、コマンドの実行に失敗し、期待されるパスと、その出力を生成するために必要な foundry bundle product の呼び出しが表示されます。

foundry deploy では、どちらの段階も自動的には実行されません。このコマンドはストアがすでに存在することを前提としており、存在しない場合は実行に失敗します。デプロイ前にバンドルしてください。

SuperRepo を再構成する

製品内のコンポーネントは自由に移動できます。たとえば、./ontology を ./platform/ontology に移動する場合は、3個のマニフェストキーを変更します。

Copied!1
2
3
4
5
6
7
8
9
10
11
 components:
   - type: ONTOLOGY
-    path: ./ontology
+    path: ./platform/ontology

 imports:
-  - ontology: ontology/external-imports/ontology-full-metadata.json
+  - ontology: platform/ontology/external-imports/ontology-full-metadata.json

-osdkOutput: ontology/osdk-output
+osdkOutput: platform/ontology/osdk-output

シードデータを定義する

プレビュー中、foundry はローカルの埋め込みオントロジーサーバーを起動します。このサーバーは、SuperRepo のオントロジーコンポーネント内で定義またはインポートされたタイプを認識します。ただし、エンロールメントのオントロジーには接続されていません。そのため、オブジェクトタイプのインスタンスはエンロールメントから取得されるものではなく、ローカルでのみ存在し、有効です。オブジェクトに関連付けられた作成アクションを呼び出して手動でオブジェクトを作成するか、SuperRepo の自動シード機構を利用できます。

シードデータは、ONTOLOGY コンポーネント内にある TypeScript ファイルのディレクトリです。ローカルプレビューサーバーは、Nx など、プロジェクトで選択したオーケストレーションフレームワークが指定するコマンドライン引数を通じて、このディレクトリを検出します。

コンパイルされるのはトップレベルの .mts ファイルのみで、ファイル名の並べ替え順に処理されます。そのため、デモテンプレートではファイル名に 001-、002-、003- という番号が付けられています。各ファイルは createSeed 呼び出しをデフォルトエクスポートします。seed.add の第1引数は、オブジェクトタイプ用に生成された SDK 定数であり、主キーを含む、null を許容しないすべてのプロパティが必須です。主キーは、ディレクトリ全体を通して、同じオブジェクトタイプ内で一意である必要があります。seed.link 関数は seed.add が返す参照を受け取り、リンクの両端は同じ呼び出し内で登録されている必要があります。

Copied!1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
import { seller, superproduct } from "@ontology/sdk";
import { createSeed } from "@osdk/seed-helpers";

export default createSeed((seed) => {
  const charger = seed.add(superproduct, {
    pk: "prod-004",
    title: "USB-C 100W GaN Charger",
    price: 5900,
    newPrice: 4720,
    description: "Compact 100W USB-C GaN wall charger",
  });
  const halcyon = seed.add(seller, {
    pk: "seller-003",
    name: "Halcyon Desk Co.",
  });
  seed.link("charger-seller-link", charger, "sellers", halcyon, "superproducts");
});

実行するたびに新しいローカルデータベースが使用されるため、起動のたびにシードファイルが再適用され、ローカルサーバーを通じて編集したオブジェクトは再起動時に破棄されます。

オーケストレーションフレームワークを変更する

foundry create コマンドは Nx を設定しますが、CLI は nx.json ファイルも project.json ファイルも読み取りません。そのため、SuperRepo と Foundry CLI は、選択するオーケストレーションフレームワークに依存しません。デフォルトのテンプレートでは、広く使用されている Nx を採用しています。Nx から移行するには、project.json ファイル内の Foundry CLI 呼び出しを別のシステムに移します。

移行中は、すべての Node インストールを foundry run-with-auth でラップする必要があります。このコマンドは FOUNDRY_HOSTNAME と FOUNDRY_TOKEN を注入するため、.npmrc ファイルでこれらの環境変数を使用できます。

コンテンツセキュリティポリシー

アプリケーションがほかのオリジンのリソースを使用する場合、Foundry が製品用に管理する Web サイトのコンテンツセキュリティポリシー（CSP）で、それらのオリジンを許可する必要があります。許可しない場合、ブラウザーがリクエストをブロックします。contentSecurityPolicyAdditions キーで追加項目を宣言します。

Copied!1
2
3
contentSecurityPolicyAdditions:
  img-src:
    - tile.openstreetmap.org

各キーは標準の CSP ディレクティブ名で、各値は https://api.example.com や 'self' など、許可するソースのリストです。有効なディレクティブ名は、connect-src、frame-src、img-src、media-src、script-src、style-src、font-src、frame-ancestors です。

contentSecurityPolicyAdditions は製品ごとのキーで、components および bundle と同じ階層に宣言し、製品に APP コンポーネントがある場合にのみ適用されます。そのため、単一製品の foundry.yml では、上記のようにファイルのトップレベルにこのキーを配置します。複数製品の設定では、複数の製品を追加するセクションの説明に従い、このキーを必要とする各製品内に宣言します。

プラットフォーム API プロキシ

アプリケーションは一般的に、オントロジー SDK を通じて Foundry のプラットフォーム API にアクセスします。SuperRepo のローカルプレビューサーバーは、これらのプラットフォーム API の一部を実装していますが、すべてを実装しているわけではありません。たとえば、プラットフォーム API の LLM プロバイダープロキシを使用するには、Foundry エンロールメントにアクセスする必要があります。

SuperRepo のプレビューでは、次の例のように foundry.yml ファイル内にトップレベルの platformApiProxy キーを定義することで、API 呼び出しをリモートの Foundry インスタンスにプロキシできます。

Copied!1
2
3
4
5
6
platformApiProxy:
  passthrough:
    - path: /api/v2/admin/users/getCurrent
      methods: [GET]
    - path: /api/v2/llm/proxy/openai/v1/responses
      methods: [POST]

これらのパスを宣言すると、プレビューサーバーは、上記のパスとメソッドに対するオントロジー SDK クライアントからのリクエストに応答します。これらのリクエストは、Foundry CLI のインストール時にエクスポートしたトークンではなく、foundry login によって保存された資格情報を使用して、Foundry エンロールメントにプロキシされます。プロキシされたリクエストが認可エラーで失敗するようになった場合、保存されたトークンの有効期限が切れている可能性が高いため、foundry login refresh を実行して再認可してください。

platformApiProxy の設定はデプロイ済みの製品には影響せず、プレビュー中にのみ有効です。

←

PREVIOUSデプロイ / 初回デプロイの準備

NEXT今後の予定

→