この文章�� Salesforce 機械翻訳システムを使用して翻訳されました。詳細はこちらをご参照ください。
英語に切り替える

Force.com 移行ツールガイド

Force.com 移行ツール
Force.com 移行ツールのインストール
Force.com 移行ツール の使用
一般的な移行の問題
用語集
PDF

一般的な移行の問題

メタデータの移行時および変更のリリース時には、一般的な問題がいくつか発生する可能性があります。これらの問題は、3 つのカテゴリに分類できます。
  • メタデータ — 特定のメタデータコンポーネントを処理する場合の特殊な考慮事項
  • 接続 — 組織への接続や結果のポーリングを行う場合の問題
  • テストおよびコードカバー率 — リリース前の Apex のテスト

一般的なメタデータの問題

最も一般的なメタデータの問題として、次のようなものがあります。
  • 標準オブジェクトのカスタム項目の取得 — package.xml でワイルドカード記号を使用してすべてのオブジェクトを取得する場合、標準オブジェクトや標準オブジェクトのカスタム項目は取得されません。標準オブジェクトのカスタム項目を取得する場合は、「プロジェクトマニフェストの作成」を参照してください。
  • プロファイルまたは権限セットと項目レベルセキュリティ — 取得したプロファイルまたは権限セットの内容は、retrieve 要求の他の内容に応じて異なります。たとえば、カスタムオブジェクトに含まれている項目の項目レベルセキュリティは、プロファイルまたは権限セットと同時に返されます。詳細は、『メタデータ API 開発者ガイド』の「Profile」および「PermissionSet」を参照してください。
  • パッケージについて — パッケージは、複数の組織で共有したり Force.com AppExchange で配布したりできるようにするため、関連コンポーネントをバンドルするために使用されます。管理パッケージとは、インストーラ組織内のアップグレード可能なパッケージを指します。管理パッケージは、一部のコンポーネントがロックされている未管理パッケージとは異なり、アップグレードが可能です。どのパッケージにも含まれないメタデータコンポーネントには、sf:retrieve および sf:deploy の unpackaged 属性を使用してアクセスできます。
  • ワークフロー — .workflow ファイルは、オブジェクトに関連付けられた、WorkflowAlert、WorkflowFieldUpdate、WorkflowOutboundMessage、WorkflowRule、WorkflowTask など、個々のワークフローコンポーネントのコンテナです。すべてのワークフローを取得するには、次の XML を package.xml に含めます。
    1<types>
2    <members>*</members>
3    <name>Workflow</name>
4</types>
  • オブジェクト定義に依存するコンポーネントの取得またはリリース — メタデータコンポーネント CustomField、Picklist、RecordType、Weblink、および ValidationRule の定義は、特定のオブジェクトに依存します。つまり、package.xml ではコンポーネント名をドットとオブジェクト名で修飾する必要があります。また、ワイルドカード記号は使用しないでください。詳細は、「プロジェクトマニフェストの作成」を参照してください。
  • 個人フォルダ — ユーザの個人フォルダは、レポートとドキュメントのいずれもメタデータ API では公開されません。レポートまたはドキュメントを移行するには、公開フォルダに移動する必要があります。

接続の問題

最も一般的な接続の問題として、次のようなものがあります。

  • 要求のタイムアウト — メタデータを取得またはリリースする場合、要求は非同期で送信されます。つまり、応答はすぐに返されません。このコールは非同期であるため、Force.com 移行ツールがタイムアウトになった場合でも、サーバで deploy() が完了するまで処理されます。リリースに成功すると、変更がサーバにコミットされます。タイムアウト後にリリースに失敗した場合、サーバからエラーメッセージを取得する方法はありません。このため、タイムアウトエラーを受け取った場合は、pollWaitMillis および maxPoll パラメータを調整することが重要です。
    • pollWaitMillis — 取得/リリース結果を取得するまで待機するポーリング間隔の時間 (ミリ秒単位)。デフォルト値は 10000 ミリ秒 (10 秒) です。実行時間の長いプロセスの場合は、この値を増やして、1 日の API 制限にカウントされるポーリング要求の合計数を削減します。
    • maxPoll — 中止されるまでのポーリング試行回数。デフォルト値は、200 です。[pollWaitMillis (10000)] のデフォルト値と組み合わせると、Force.com 移行ツールにより、タイムアウトになる前にサーバプロセスを完了するための時間が合計 2,000 秒 (33 分) 取られます。合計時間は、各ポーリング間の待機時間が 10 秒で、200 回のポーリング試行として計算されます。

    これらのパラメータにはデフォルト値があるため、パラメータを指定する必要はありません。ただし、指定ターゲットにこれらのパラメータが存在しない場合があります。これらのパラメータを追加するには、ターゲット定義に含めます。次に例を示します。

    1<sf:retrieve 
2  username="${sf.username}"
3  password="${sf.password}"
4  sessionId="${sf.sessionId}"
5  serverurl="${sf.serverurl}"
6  retrieveTarget="retrieveUnpackaged"
7  unpackaged="unpackaged/package.xml"
8  pollWaitMillis="10000"
9  maxPoll="100"/>

    メモ

  • ユーザ名、パスワード、セキュリティトークンが無効か、ユーザがロックされています - このエラーは、build.properties でログイン情報に問題があることを示します。
    • ユーザ名 — このアカウントのユーザ名が正しいことを確認します。Sandbox インスタンスに接続する場合は、Sandbox 名がユーザ名に付加されます。たとえば、本番ユーザ名が foo@salesforce.com であり、いずれか 1 つの Sandbox 名が bar の場合、Sandbox ユーザ名は foo@salesforce.com.bar になります。
    • パスワード — このアカウントのパスワードが正しいことを確認します。セキュリティトークンは、パスワードの最後に付加されます。
    • セキュリティトークン — セキュリティトークンは、パスワードに付加される 25 桁の文字列です。セキュリティトークンをリセットするには、個人設定の [私のセキュリティトークンのリセット] ページに移動します。
    • ロックアウト — 組織へのログインに何度も失敗すると、一時的にロックアウトされることがあります。接続の失敗回数およびロックアウト期間は、組織の設定によって異なります。システム管理者にロックの解除を依頼するか、ロックアウト期間が経過するまで待機します。
    • Sandbox と本番の接続の不一致 — build.properties のすべての接続認証情報が正しい場合、URL の不一致が考えられます。サーバ URL は、Sandbox 環境と本番環境では異なります。本番環境の場合、build.properties の sf.serverurl 値は https://login.salesforce.com になります。Sandbox 環境の場合、値は https://test.salesforce.com になります。
  • プロキシ設定 — プロキシ経由で接続する場合は、Ant プロキシ設定手順に従う必要があります。

Apex のテスト

本番組織にリリースするときに実行するテストを指定しないと、組織の名前空間内のすべての単体テストが実行されます。Apex をリリースする前に、次の条件を満たす必要があります。
  • Apex コードの少なくとも 75% が単体テストでカバーされており、かつすべてのテストが成功している。
    次の点に注意してください。
    • 本番組織に Apex をリリースするときに、組織の名前空間内の各単体テストがデフォルトで実行されます。
    • System.debug へのコールは、Apex コードカバー率の対象とはみなされません。
    • テストメソッドとテストクラスは、Apex コードカバー率の対象とはみなされません。
    • Apex コードの 75% が単体テストでカバーされている必要がありますが、カバー率を上げることだけに集中すべきではありません。アプリケーションのすべてのユースケース (正・誤両方の場合や単一データだけでなく複数データの場合) の単体テストを作成するようにしてください。このような多様なユースケースのテストコードを実装することが 75% 以上のカバー率につながります。
  • すべてのトリガについて何らかのテストを行う。
  • すべてのクラスとトリガが正常にコンパイルされる。

実行するテストを指定すると、リリースのコードカバー率計算が若干異なります。「リリースでのテストのサブセットの実行」を参照してください。

Salesforce は次の事項のテストを作成することをお勧めします。
単一操作
単一のレコードが適切かつ予測どおりの結果を生成することを確認するテスト。
一括操作
トリガ、クラス、拡張にかかわらず、すべての Apex コードが 1 件から 200 件のレコードについて呼び出されます。単一レコードのケースだけでなく、一括ケースについてもテストする必要があります。
ポジティブ動作
予測される動作がすべての予測される順列で行われること、つまりユーザがすべてを正しく入力し、制限を超えないことを確認するテスト。
ネガティブ動作
将来の日付を追加できない、負の数量を指定できないなどの制限がアプリケーションに存在する場合があります。ネガティブケースについてテストし、制限内のポジティブケースと同様、エラーメッセージが適切に生成されることを確認する必要があります。
制限ユーザ
コード内で使用する sObjects へのアクセス権限が制限されているユーザが予測どおりの動作を行えるかどうかを確認するテスト。つまり、コードを実行できるかどうか、エラーメッセージを受信するかどうかを確認します。

条件演算子および 3 項演算子は、ポジティブブランチとネガティブブランチの両方が実行されない限り、実行されたとはみなされません。

メモ

詳細は、『Apex 開発者ガイド』の「Apex のテストについて」を参照してください。