開発者向けのドキュメント

開発者向けのドキュメント

SitecoreAIビルド構成

日本語翻訳に関する免責事項

このページの翻訳はAIによって自動的に行われました。可能な限り正確な翻訳を心掛けていますが、原文と異なる表現や解釈が含まれる場合があります。正確で公式な情報については、必ず英語の原文をご参照ください。

環境のSitecoreAIビルド構成はxmcloud.build.jsonファイル内で定義されています。このファイルには、ホスト編集、ビルドターゲット、その環境のXMインスタンスに展開するシリアライゼーションモジュールなどの設定が含まれています。

ヒント

PLAYを参照できます! xmcloud.build.jsonファイルの動作例はSummitプロジェクトリポジトリにあります。

XM Cloudは現在SitecoreAIとなっています

一部のコード例、画像、UIラベルは、エンジニアリング資産の更新中もXM Cloudを使用している場合があります。

ビルド構成オブジェクトの構造は以下の通りです:

{
  "deployItems": {
    "modules": []
  },
  "buildTargets": [],
  "renderingHosts": {
    "<key>": <value>
  },
  "transforms": [],
  "postActions": {
    "actions": {
      "<key>": <value>
    }
  },
  "authoringPath": <value>
}

以下の表はビルド構成オブジェクトのプロパティを示しています:

名称	概要
deployItems	どのシリアライゼーションアイテムモジュールを展開するかを定義できます。これはsitecore.jsonファイルで定義されたシリアライズ構成に似ています。ローカルで働く際に配置するものを制限するのに便利です。ここで定義されたすべてのモジュールは、Items as Resources(IAR)ファイルに変換されます。役割はサポートしていません。ロールをデプロイする必要がある場合は、SCSモジュールのデプロイメントアクションを使ってください。重要ビルド設定にdeployItemsを含めない場合、sitecore.jsonファイルのmodulesプロパティのすべてのメンバーはIARファイルに変換されます。 IARファイルを直接削除・改変することはできません。既存の項目を上書きする必要がある場合は、次の展開の一環として行う必要があります。例えば: `"deployItems": { "modules": [ "Foundation.", "Feature.", "Project.*" ] }`
buildTargets	どのプロジェクトやソリューションを作るかを定義できます。例えば: `"buildTargets": [ "./src/CM/Platform.csproj", "./src/CM/Root.sln" ],` この構成はmsbuildコマンドへの引数の渡し方に影響を与えます: `msbuild .\src\platform\Platform.csproj /p:Configuration=$env:BUILD_CONFIGURATION /m /p:DeployOnBuild=true /p:PublishProfile=Local`
renderingHosts	レンダリングホストの位置や、それらがマッピングするサイトの位置を設定できます。キーがunique site nameであり、その値がサイトに関する情報を含むキー-値ペアで構成されています。
transforms	XDTパスをターゲットパスにマッピングするアイテムの配列です。 XDT変換を処理する場所へのワイルドカード付きで完全適格パスを指定することができます。
postActions	展開プロセスの展開段階後に実行される操作。
authoringPath	注記このプロパティは、オーサリング環境と編集ホストを別々にデプロイできるベータ機能で作成された環境にのみ影響します。オーサリング環境コードの相対的なパスを指定できます。これにより、編集ホストとオーサリング環境コードが同じリポジトリを共有している場合、オーサリング環境コードの変更が自動的に編集ホストの再デプロイを引き起こしたり、その逆を誘発したりしません。デフォルト値は ./authoringです。

ホストレンダリングの設定オプション

ビルド設定ファイルでレンダリングホストを定義できます。各定義はunique site nameをサイトに関する情報にマッピングします。

例えば:

  "renderingHosts": {
    "xmcloudpreview": {
      "path": "./src/rendering",
      "nodeVersion": "16.3.19",
      "jssDeploymentSecret": "super-secret-value",
      "enabled": true,
      "type": "sxa",
      "buildCommand": "build",
      "runCommand": "next:start"
    }
  }

以下の表は、サイト情報の設定に使用するプロパティを説明します。

名称	種類	概要
path	string	xmcloud.build.jsonファイルからアプリのソースコードへの相対的な経路です。通常はルートフォルダからの相対パスです。 XM Cloudは現在SitecoreAIとなっています一部のコード例、画像、UIラベルは、エンジニアリング資産の更新中もXM Cloudを使用している場合があります。
nodeVersion	string	ホストレンダリング用の特定のNode.jsバージョン。ホストやスターターが使用するNode.jsのメジャーバージョンとContent SDKが使うバージョンは一致しなければなりません。
jssDeploymentSecret	string	32文字以上のランダム生成文字列。デプロイシークレットは、アプリケーションがSitecoreインスタンスにアイテムをデプロイすることを許可する共有シークレットです。scjssconfig.jsonファイルにdeploySecretの値を入力します。
enabled	boolean	サイトを有効にする。デフォルト: false。
type	string	レンダリングホストの種類。許容値: "jss" または "sxa"。デフォルト: "jss" 注記 SXAサイトはSXAテンプレートから作成され、アイテムベースの構成が使われます。JSSサイトはJSSテンプレートから作成され、ファイルベースの構成を使用します。
buildCommand	string	package.jsonファイルからコマンドをビルドして実行します。デフォルト: "build"
runCommand	string	package.jsonファイルからコマンドを実行して実行してください。デフォルト: "next:start"

重要

startCommandは非推奨され無視されています。代わりにbuildCommandとrunCommandを使いましょう。

XDT変換

XDT変換をサポートするには、フォルダまたはXDTのソースファイルおよび設定宛先ファイルへの完全限定パスを指定する必要があります。

変換は完全に構築された解で起こります。

パスは構築されたコードのウェブルートに対して相対的でなければなりません。例えば、XDTのソースファイルがsrc/platform/xdtsフォルダにあると仮定すると、変換パスを次のように設定できます:

  "transforms": [
    {
      "xdtPath": "/xdts/<some-transforms>/",
      "targetPath": "/<somewhere>/"
    },
    {
      "xdtPath": "/xdts/<trasforms-at-the-root>/",
      "targetPath": "/"
    },
    {
      "xdtPath": "/xdts/web.config.xdt",
      "targetPath": "/web.config"
    }    
  ]

注記

各変換のxdtPathプロパティの価値は、プロジェクトファイルの整理方法によって異なります。この例では、プロジェクトがSitecoreが提供する基礎テンプレートに基づいており、変換が /src/platform/xdts/ フォルダにあると仮定します。XDTファイルの定義方法については、web.config変換のドキュメントを参照してください。

展開後の行動

デプロイメントプロセスのafter the deployment stageを実行するpost actionsと呼ばれる様々な操作を設定できます。

ビルド構成には、要件に合わせてカスタマイズできるデフォルトのアクションが含まれています。これらはpostActionsオブジェクトのactionsプロパティを用いて定義され、以下が含まれます:

CMウォームアップ。
SCSモジュールの展開。
スキーマ集団。
インデックス変更。
出版。

注記

ポストアクションは設定ファイルに表示される順に順に実行されます。したがって、投稿アクションを設定する際は、アクションの順序を変更しないことを強くお勧めします。

以下の例で示された順序により、SCSモジュールを展開した場合、それらは公開されます。そして、インデックスは再インデックスする前に入力されていること。

投稿アクション構成は以下の構成です:

"postActions": {
  "actions":{
    "warmUpCm": {
      "urls": []
    },
    "scsModules": {
      "modules": []
    },
    "populateSchema": {
      "indexNames": []
    },
    "reindex": {
      "indexNames": []
    },
    "publish": {
      "path": "",
      "languages": [],
      "itemIds": [],
      "targets": [],
      "republish": true,
      "publishSubItems": true
    }
  }
}

CMウォームアップアクション

warmUpCmアクションのurlsプロパティで相対的なURLの配列を定義することで、さまざまなSitecoreAIページをウォームアップできます。

例えば:

"warmUpCm": {
  "urls": [
    "/sitecore/shell",
    "/sitecore/shell/Applications/Content%20Editor.aspx?sc_bw=1",
    "/sitecore/client/Applications/Launchpad",
    "/sitecore/client/Applications/ControlPanel.aspx?sc_bw=1"
  ]
}

SCSモジュール展開アクション

注記

Sitecoreコンテンツシリアライズの詳細については、「 Sitecoreコンテンツシリアライズの設定」をご覧ください。

scsModulesアクションを使ってSitecore Content Serialization(SCS)モジュールをSitecoreインスタンスにデプロイできます。

scsModulesアクションの構造は以下の通りです。

"scsModules": {
  "modules": ["Module1","Module2"]
}

スキーマ集団の行動

管理されるスキーマ集団を特定のインデックスに制限するには、populateSchemaアクションのindexNamesプロパティでインデックス名のリストを定義できます。

空配列は利用可能なすべてのインデックスの母集団となります。

例えば:

"populateSchema": {
  "indexNames": []
}

リインデックス作業

reindexアクションのindexNamesプロパティでインデックス名のリストを定義することで、特定のインデックスにリインデックスを制限できます。

空の配列は利用可能なすべてのインデックスの再インデックス化につながります。

例えば:

"reindex": {
  "indexNames": []
}

出版の行動

publishアクションを使って公開操作を設定できます。

publishアクションの構造は以下の通りです。

"publish": {
  "path": "",
  "languages": [],
  "itemIds": [],
  "targets": "",
  "republish": true,
  "publishSubItems": true
}

publishアクションを使ってアイテムを公開する場合、パブリッシュアクション内のpublishSubItemsプロパティを定義することで、そのサブアイテムの公開を制御できます。このプロパティが含まれていない場合、サブアイテムはデフォルトで公開されます。

許可される値は以下の通りです:

true - サブアイテムが公開されます。
false - サブアイテムは公開されません。

以下の例では、/sitecore/content/Homeのサブアイテムは公開されていません:

"publish": {
  "path": "/sitecore/content/Home",
  "languages": [],
  "itemIds": [],
  "targets": [],
  "republish": true,
  "publishSubItems": false
}

アクション後のタイムアウトを変更してください

各ポストアクションのデフォルトのタイムアウトは30分です。場合によっては、リインデックスすべきアイテムが多数ある場合など、デフォルトのタイムアウトを上書きする必要があるかもしれません。

デフォルトのタイムアウトは、Post Actions構造でtaskTimeOutプロパティを定義することで変更できます。

以下の例では、アクション後のタイムアウトが45分に変更されます:

"postActions": {
  "actions":{
    ...
  },
  "taskTimeOut": "00:45:00"
}

この記事を改善するための提案がある場合は、お知らせください!