アーキテクチャと役割

アーキテクチャの概要

Version:

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

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

Sitecoreは、次の3つの主要な製品で構成されています。

Sitecoreエクスペリエンスマネージャー (XM)
Sitecore Experience Platform (XP) (英語)
Sitecore Experience Commerce (XC)

各Sitecoreコンポーネントには、多数の論理エンティティが含まれており、これらのエンティティと多数のクラウドサービスを組み合わせてSitecoreプラットフォームの全機能を形成します。

大事な

ここで示す役割は論理的なものであり、物理サーバ、仮想サーバ、データベース・サーバ、検索エンジンを表すものではありません。一部の論理ロールは、トポロジ内の1つの物理エンティティに結合できます。

Sitecoreエクスペリエンスマネージャー

XMは、XPのWebコンテンツ管理(WCM)コアを指します。XMには、コンテンツの作成、管理、パーソナライゼーション、および公開に関連する機能が含まれています。これは、論理ロールのサブセットで構成されます。

Sitecoreエクスペリエンスプラットフォーム

XPは、XMをxConnectおよびxDBが提供するマーケティングおよびカスタマーインテリジェンス機能と組み合わせて、多数のサーバーの役割とストレージメカニズムを追加で導入します。

xConnectは、xDBと、HTTPS経由でエクスペリエンスデータを収集および検索する信頼できるクライアント、デバイス、またはインターフェイスとの間に位置する一連のサービスに付けられた名前です。
xDBは、エクスペリエンスデータを保存および処理するサービスとストレージロールのコレクションに付けられた名前です。xDBの外部にあるクライアント (Content Managementサーバーなど) は、xConnectを使用してxDBデータの読み取りと書き込みを行う必要があります。

次の図は、XPによって追加される論理ロールの一覧です。

XPの役割は、XMのコンテンツ管理、パーソナライゼーション、配信機能を拡張し、クロスチャネルエクスペリエンス、顧客およびビジネスの洞察を可能にし、実用的な顧客情報を収集し、顧客のエクスペリエンスを形成する際のコンテキストを提供する機能を備えています。

次の図は、XPに含まれるすべての論理ロールを示しています。

Sitecore Experience Commerce(サイトコアエクスペリエンスコマース)

シングルテナンシーとマルチテナンシー

XCは、シングルテナンシーとマルチテナンシーの両方に対して、すぐに使用できます。

シングルテナンシー設定では、コンテンツ配信ロールによって提供される単一のWebサイトまたはストアフロントがあります。

このストアフロントは、コマースエンジンを呼び出し、設定されたエンティティとビジネスロジックにアクセスします。

マルチテナンシー設定では、Content Deliveryロールに複数のストアフロントを格納でき、エンジンで複数のエンティティおよびビジネスロジック構成をホストできます。

言い換えれば、単一のコンテンツ配信エンジンとコマースエンジンを持ち、ユーザーインターフェイスだけでなくコマースエンジンでも完全に調整された機能を備えた多数のサイトをホストできます。

ポリシー、環境、ストレージの役割

XCには、次の2つのストレージロール(またはデータベース)があります。

グローバルデータベース – エンジンの役割がどのように機能するかを制御するすべてのグローバル構成データ (ポリシーと環境) を格納します。
共有環境データベース – コマースデプロイメントのメインデータストア。カタログデータ、顧客レコード、価格情報、設定したプロモーションなど、サイトで使用されるすべてのコマースデータと、インストールされているさまざまなプラグインで作成された機能を強化する一般的なエンティティとリストが保存されます。

ポリシーは、コマースエンジンの個々の機能またはプラグインの機能を定義し、影響を与える設定のグループです。

ポリシーは、名前が付けられ、バージョン管理可能な変数データセットであり、エンジンの柔軟性と構成可能性を高めるのに役立ちます。これらはGlobalデータベースのポリシーストアに格納され、大量にキャッシュされます。

XCの環境は、エンジンへの呼び出しの処理方法に影響を与えるポリシーのコレクションです。つまり、ストアフロントが任意の機能についてコマースエンジンを呼び出すと、適切な環境が識別され、エンジンによって提供される機能に影響が及びます。

環境では、1つのサービスインスタンスで個別の機能をホストできます。

つまり、渡される環境変数によって、エンジン関数に対する同じ呼び出しを非常に異なる方法で行うことができます。たとえば、一般向けのショップ環境を使用して製品の詳細を要求すると、パフォーマンスを向上させるためにキャッシュから読み取られる可能性がありますが、管理向けのオーサリング環境を使用すると、データベースから直接データが取得される可能性が高くなります。

通常、ポリシーと環境は、ブートストラップと呼ばれるプロセスを使用して、デプロイの一部として変更します。

ブートストラップ

ブートストラップとは、変更された一連の設定をコマースシステムに読み込み、データモデルや機能を変更するプロセスです。

環境とポリシーは、開発またはDevOpsプロセスの一部として、構成ファイル (特にJSONファイル) で作成および管理します。

XCを再構成してブートストラップするには、開発者またはシステム管理者は、まず新しい設定に依存するすべてのエンジンロールを停止し、次に変更されたJSON設定ファイルをDevOpsロールにデプロイし、その後、PostmanなどのREST APIツールを使用して、DevOpsロールでブートストラップREST呼び出しをトリガーします。ブートストラップは、PowerShellスクリプトなどを使用して、継続的デプロイの一部として実行することもできます。

JSON構成はディスク上のファイルから読み取られ、環境とポリシーのデータはグローバルデータベースに保存されます。ブートストラップが成功すると、システムは新しい構成で実行され、開発者またはシステム管理者にメッセージが返されます。エンジンの役割が再び開始されると、グローバルデータベースから新しい設定が読み取られます。

また、DevOpsロールを使用して、システム内のインデックスの再構築など、他のメンテナンスおよびデプロイタスクをトリガーすることもできます。ブートストラップ・コマンドと同様に、これは手動のRESTコールまたはスクリプトを介して実行できます。インデックスを再作成すると、Shared Environmentsデータベースからデータがロードされ、適切なインデックスが再設定されます。

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