導入
Salesforce Customer 360 Platform は、個々の Salesforce テナント インスタンス (別名「組織」)に、強力なマルチテナントのメタデータ駆動型アーキテクチャを提供します。このアーキテクチャの基本ドキュメントでは、Salesforce プラットフォームの基盤となるアーキテクチャが、プラットフォーム上に構築されたソリューションのアーキテクチャに関する重要な考慮事項となる領域の概要を説明します。
Salesforce プラットフォームでアーキテクチャを設計する際に理解しておくべき重要な領域が 3 つあります。
- 処理(Transactions)
- メタデータとデータ
- プラットフォーム API
処理
Salesforce プラットフォームでは、コードの実行やデータベース操作によってトランザクションをインスタンス化できます。Salesforce でアーキテクチャを構築するための基本的な能力は、プラットフォームがテナントのトランザクションをどのように定義および制御するかを理解することです。すべてのテナントのリソースを維持するために、Salesforce はトランザクションごとおよび組織ごとに計算された制限をすべてのテナントに課します。
トランザクション レベルでは、Salesforce はガバナーと実行制限を設定して、コード実行の個々のインスタンスとデータベース トランザクションが共有コンピューティング リソースを独占しないようにします。組織全体のレベルでは、Salesforce はエディションと機能タイプに基づいて制限を設定します。組織全体の制限には、 API 制限対象となる、組織内のすべてのトランザクションにわたる API 使用量のローリング計算も含まれます。
Salesforce プラットフォームでのトランザクションの 2 つの重要な部分である実行コンテキストとデータベース操作を詳しく見てみましょう。
実行コンテキスト
Salesforce は、実行コンテキストの概念に基づいてトランザクション制限を計算します。Salesforce アプリケーションの場合、これは単一の Salesforce 組織内でのカスタム コードの実行に限定されないことを理解することが重要です。実行コンテキストは、プラットフォーム ランタイム エンジンと、特定のテナントのランタイム エンジンで使用可能なすべてのコードに基づいています。これは、テナントの組織内で定義されたカスタム コード、その組織にインストールされたパッケージからのコード、および Salesforce プラットフォーム サービス内に含まれるコードがすべてトランザクションをインスタンス化できることを意味します。プラットフォームはさまざまな種類の Apex コードを区別し、それらの区別に基づいてガバナ制限を計算します。
Apex トランザクション制限の詳細については、Apex 開発者ガイドを参照してください。
データベース操作
トランザクションにデータベース操作が含まれる場合、組み込みの実行順序によって、組織の設定とコードのさまざまな部分がどのように動作するかが規定されます。Salesforce アプリケーションで実行順序を正しく使用する方法を理解するための鍵は、この動作が Salesforce アプリケーションに提供する堅牢なデータ整合性を理解することです。
プラットフォームは、データベース操作の状態のコンテキスト変数をトリガー コンテキスト変数の形式で公開します。カスタム Apex トリガがその組織内で定義されているかどうかにかかわらず、これらのトリガ コンテキスト変数は、Salesforce 組織内のすべてのデータベース トランザクションの実行時状態を記述することを理解することが重要です。これらは、Salesforce Flow などの宣言型ツールで使用できます。
Salesforce では、実行順序で記述されたトリガー後の動作が正常に完了するまで、データはコミットされません (データ トランザクションもファイナライズされません) 。これは、コンテキスト前またはコンテキスト後に発生するデータ トランザクション中に致命的なエラーまたは不適格な動作が発生すると、プラットフォームがトランザクション内のすべてのデータ操作をロールバックすることを意味します。レコード データへの要求された変更はデータベースにコミットされず、コミット後のロジックは実行されません。(Apex はデータベースメソッドで開くを公開して、セーブポイントとロールバック動作をより細かく制御できるようにします。)
Salesforce アーキテクチャで避けるべき重要なアンチパターンは、プラットフォームの組み込みの実行順序動作を短縮または置き換えようとすることです。
これらの組み込みのデータ整合性動作の背後にあるロジックの詳細については、Salesforce エンジニアリング ブログのInside and Out: Transactionsを参照してください。
メタデータとデータ
Salesforce 組織内でカスタマイズおよび拡張する方法を選択する場合、Salesforce プラットフォームの観点から、データと見なされるものとメタデータと見なされるものを理解することが重要です。このデータ/メタデータの区別の背後にある基盤となるアーキテクチャの詳細については、プラットフォーム マルチテナント アーキテクチャの基礎に関するドキュメントを参照してください。
この区別は、アプリケーションの開発ライフサイクルの多くの側面に影響を与えます。たとえば、成果物をサンドボックス開発環境にコピーするかどうか、他の環境に移行する方法、パッケージリンクの一部にできるかどうかなどです。.
次の表は、アプリケーション ライフサイクルの重要な部分に関連するデータとメタデータのパフォーマンスを簡単に比較したものです。
| 行動 | データ | メタデータ |
|---|---|---|
| 本番環境からサンドボックス環境にコピー | いいえ* | はい |
| メタデータ API による移行 | いいえ | はい** |
| データロードによる移行 | はい | いいえ |
| パッケージに含めることができます | いいえ | はい** |
| データ ストレージの制限にカウントされます | はい | いいえ |
*フル コピーおよび部分コピー サンドボックスでは、本番環境からのデータ レプリケーションが可能です。
**一部のメタデータ タイプは、メタデータ API やパッケージでは使用できません。メタデータ カバレッジ レポートリンクで例外を見つけることができます。
場合によっては、この区別はかなり明白です。たとえば、Salesforce 組織の個々のレコードはデータです。組織内のさまざまなsObjectはメタデータです。
組織設定機能に関しては、区別がより複雑になる可能性があります。主な例は、カスタム設定とカスタム メタデータ タイプです。これらの機能の両方を使用すると、実行時に簡単に利用できるように組織内の情報を構成し、データベース レコードと同様の方法で操作および管理できます。どちらの機能も、コードと自動化で疎結合の非常に柔軟な設計パターンを可能にすることを目的としています。ただし、カスタム設定はデータとして組織に保存され、カスタム メタデータ タイプはメタデータとして保存されます。
メタデータ カバレッジ レポートリンクに表示されるかどうかを確認することで、何かがメタデータであるかどうかを判断できます。このレポートでは、特定の種類のメタデータの主要な開発および展開の動作についても説明します。
プラットフォーム API
多くのSalesforce プラットフォーム APIリンクを新しいウィンドウで開くがあります。Salesforce プラットフォーム API は、さまざまなデータ形式とプロトコル、さまざまな操作の種類とタイミングをサポートしています。一部の API では、Salesforce 組織内のデータを操作できますが、他の API は特定の組織内のメタデータとの操作をサポートしています。大量のトランザクションを処理するために特別に構築された API もあれば、そうでない API もあります。Salesforce は、リリースごとにすべてのSalesforce Platform APIのバージョン番号を更新します。
健全なアプリケーション アーキテクチャの重要な部分は、アプリケーション開発者が特定のユース ケースに対して適切な APIリンク (および API バージョン) を確実に使用できるようにすることです。Salesforce 組織の組み込みAPI 制限を考慮する必要があります。その多くは、エディションと機能の有効化によって決まります。Salesforce プラットフォーム API は下位互換性のある使用法をサポートしています。つまり、新しい API バージョンがリリースされても、特定のバージョンの実装は安定性と一貫性を持って動作する必要があります。新しい API バージョンから新しい機能または変更された機能を組み込む場合は、新しい API バージョンへの参照をアップグレードする前に、アプリのリファクタリングが必要になる場合があります。
アプリケーションの異なる Salesforce プラットフォーム API と、Salesforce API バージョンの更新により、Salesforce API を使用するすべてのアプリケーションのライフサイクルが大幅に複雑化します。アプリケーションの Salesforce プラットフォーム API リファレンスの定期的な評価を計画し、計画されたAPIメンテナンスサイクルに優先順位を付けて、アプリケーションを予測通りに適切に実行し続ける必要があります。