Salesforce Customer 360 Platform は、すべての個々の Salesforce テナント インスタンス(「組織」とも呼ばれる)に強力なマルチテナント メタデータ駆動アーキテクチャを提供します。このアーキテクチャの基本ドキュメントでは、Salesforce Platform の基盤となるアーキテクチャで、プラットフォーム上に構築されたソリューションのアーキテクチャに関する主要な考慮事項を作成する領域の概要を説明します。

Salesforce Platform でアーキテクチャを設計するときに理解すべき重要な領域が 3 つあります。

• トランザクション
• Metadata Versus Data
• プラットフォーム API

Salesforce Platform では、コード実行やデータベース操作によってトランザクションをインスタンス化できます。Salesforce で設計するための基本的な能力は、プラットフォームでテナントの取引をどのように定義して制御するかを理解することです。すべてのテナントのリソースを維持するために、Salesforce では、トランザクションごと、および組織ごとに計算されるすべてのテナントに制限を設けています。

Salesforce はトランザクション レベルで、コード実行とデータベース トランザクションの個々のインスタンスが共有コンピューティング リソースを独占しないように、PfR と実行制限を設定します。Salesforce は、組織全体で、エディションと機能種別に基づいて制限を設定します。組織の共有制限には、組織内のすべてのトランザクションの API 使用量のローリング計算も含まれます。これには API 制限が適用されます。

Salesforce Platform でのトランザクションの 2 つの主要な部分 (実行コンテキストとデータベース操作) についてもう少し詳しく見てみましょう。

Salesforce は、実行コンテキストの概念に基づいてトランザクション制限を計算します。Salesforce アプリケーションの場合、これは 1 つの Salesforce 組織内でのカスタムコードの実行に限定されないことを理解しておくことが重要です。実行コンテキストは、プラットフォームランタイムエンジンと、特定のテナントのランタイムエンジンで使用できるすべてのコードに基づいています。つまり、テナントの組織内で定義されたカスタムコード、その組織でインストールされたパッケージのコード、Salesforce Platform サービスに含まれるコードのすべてがトランザクションをインスタンス化できます。プラットフォームは、さまざまな種類の Apex コードを区別し、それらの区別に基づいてガバナ制限を計算します。

Apex トランザクション制限の詳細については、『 Apex 開発者ガイド 』を参照してください。

トランザクションにデータベース操作が含まれる場合、組み込みの実行順序によって、組織の設定とコードのさまざまな部分の動作が決まります。Salesforce アプリケーションで実行順序を正しく使用する方法を理解する鍵は、この動作によって Salesforce アプリケーションに提供される堅牢なデータの整合性を理解することです。

プラットフォームでは、データベース操作の状態のコンテキスト変数がトリガーコンテキスト変数の形式で公開されます。これらのトリガー コンテキスト変数は、Salesforce 組織のすべてのデータベース トランザクションのランタイム状態を説明するものであることを理解しておくことが重要です。この変数は、カスタム Apex トリガーがその組織内で定義されているかどうかに関係なく記述されます。Salesforce フローなどの宣言型ツールで使用できます。

Salesforce では、実行順序で説明されているトリガー動作が正常に完了した後、最終的な処理が完了するまで、データはコミットされません (または、データトランザクションは確定されません)。つまり、コンテキストの前または後のデータトランザクション中に致命的なエラーや不適格な動作が発生すると、プラットフォームによってトランザクション内のすべてのデータ操作がロールバックされます。要求されたレコードデータの変更はデータベースにコミットされず、コミット後ロジックは実行されません。(Apex では、セーブポイントとロールバック動作をより詳細に制御できるようにデータベースメソッドが公開されています)。

Salesforce アーキテクチャで避けるべき主要なアンチパターンは、プラットフォームの組み込みの実行順序をショートカットまたは置き換えることです。

これらの組み込みデータ整合性動作のロジックについての詳細は、「Inside and Out Engineering ブログのトランザクション。

Salesforce 組織内でカスタマイズおよび拡張する方法を選択する場合、Salesforce Platform の観点から何がデータとみなされ、何がメタデータとみなされるかを理解することが重要です。このデータ/メタデータの区別の背後にある基盤となるアーキテクチャについての詳細は、「プラットフォーム マルチテナント アーキテクチャの基本」ドキュメントを参照してください。

この区別は、アーティファクトを Sandbox 開発環境にコピーするかどうか、他の環境に移行する方法、パッケージに含めるかどうかなど、アプリケーションの開発ライフサイクルのさまざまな側面に影響します。

次の表に、アプリケーションライフサイクルの主要な部分に関連するデータとメタデータのパフォーマンスの簡単な比較を示します。

この区別はかなり明白です。たとえば、Salesforce 組織の個々のレコードはデータです。組織のさまざまな sObject はメタデータです。

組織設定機能では、区別がより複雑になる可能性があります。主要な例として、カスタム設定とカスタムメタデータ型があります。どちらの機能でも、実行時に簡単に利用できるように組織内の情報を設定し、データベースレコードと同様の方法で操作および管理することができます。どちらの機能も、コードと自動化で疎結合で柔軟性の高い設計パターンを実現することを目的としています。ただし、カスタム設定はデータとして組織に保存され、カスタムメタデータ型はメタデータとして保存されます。

メタデータであるかどうかは、メタデータカバー率レポートに表示されるかどうかで判断できます。このレポートでは、特定のメタデータ種別の主要な開発およびリリース動作についても説明します。

多くの Salesforce Platform API があります。Salesforce Platform API では、さまざまなデータ形式とプロトコル、さまざまな操作種別とタイミングがサポートされます。Salesforce 組織のデータを操作できる API もあれば、特定の組織のメタデータを操作できる API もあります。大量のトランザクションを処理するために特別に構築された API もあれば、そうでない API もあります。Salesforce は、リリースのたびにすべての Salesforce Platform API のバージョン番号を更新します。

健全なアプリケーションアーキテクチャの重要な部分は、アプリケーション開発者が特定の使用事例に適切な API (および API バージョン) を使用することです。Salesforce 組織の組み込み API 制限を考慮する必要があります。これらの制限の多くは、エディションと機能の有効化によって決まります。Salesforce Platform API では、下位互換の使用がサポートされます。つまり、新しい API バージョンがリリースされても、特定のバージョンの実装は安定性と一貫性が維持されている必要があります。新しい API バージョンから新規または変更された機能を組み込む場合、新しい API バージョンへの参照をアップグレードする前にアプリケーションのリファクタリングが必要になることがあります。

Salesforce Platform API の種類は多数あり、Salesforce API バージョンのスピードも速いため、Salesforce API を使用するアプリケーションのライフサイクルは非常に複雑になります。アプリケーションの Salesforce Platform API 参照の定期的な評価を計画し、計画された API メンテナンスサイクルに優先順位を付けて、アプリケーションを予測どおりに適切に実行し続ける必要があります。