初期データ移行の勘所

はじめに

Force.comにアプリケーションを構築し運用開始が目前に迫る中、初期データ移行が思わぬ足枷になり、リリース直前にプロジェクトがバタついた経験がありませんか？プロジェクトでは、新たに開発するアプリケーションの機能やそのテストにどうしても注力しがちですが、「もっとしっかり準備しておけば良かった！」となりがちな、初期データ移行について今回は書いてみたいと思います。

初期データ移行の検討

大量のマスタやトランザクションを保持する基幹システムやコールセンター、受発注ポータルサイトなど、システム規模の大きい初期データ移行は十分な現行調査・計画・体制を整える必要があります。 また、初期データ移行を考える上での検討はストレージの使用量やパフォーマンスを考えるうえでも欠かせません。

  • 本当に移行すべきデータはどれか？
  • 移行時にデータのクレンジングは必要であるか？
  • 移行する場合でも古いデータを含む全件のデータ移行が必要であるか？
  • 古いトランザクションデータは専用オブジェクトに移行した方が良いのではないか？

また、Excelなどにより小規模に運用していた仕組みの場合、正規化されていないデータ構造をForce.comに移行する必要が生じます。Force.com上の正規化したスキーマ構成に合わせるためのデータ加工が必要となりますが、データ加工に必要なスキルをユーザが持ち合わせていない場合もあります。特に移行時にデータの参照関係を構成するためのデータ加工につまずくケースは多いようです。

なぜ初期データ移行が難しいのか？

1. 移行計画／設計がプロジェクト終盤に実施される

プロジェクトでは、新たに開発する機能やそのテストにユーザも開発者も注力しがちになります。特に開発工程において開発規模が当初想定より増大したようなケースでは顕著です。その結果、移行計画／設計が開発終盤に実施となるケースもあるでしょう。

しかし初期データ移行は、現行システムの保守担当ユーザや開発ベンダーとの調整、移行リハーサルするための環境構築、大量データを移行した結果として開発中のアプリケーションに及ぼす影響調査、移行を実施するための作業手順の整理、データ移行に係る時間予測とタイムスケジュール化、コンティジェンシープランの合意など、初期データ移行に関わる関係者は多く、必要タスクも多岐に渡ります。

そのため、移行計画／設計はプロジェクトの初期段階から検討・実施することが重要です。

2. 現行システムの詳細仕様がわからない

初期データ移行では、最初のステップとして移行対象のデータを現行システムから移行データとしてCSV形式などでエクスポートします。

最初にエクスポートする必要があるものの、現行システムの内部仕様に熟知したエンジニアがいない、現行システムは改修に改修を重ねたがドキュメントが改訂されておらず、現行のデータベース構造がわからないといった理由から、移行したいデータはあるものの、それをどこから、どのようにエクスポートしたらよいかわからないといった点があげられます。 このような困ったことにならないかを遅くとも移行計画時には確認しておきましょう。

3. 誰がインポート用にデータ加工する？

移行データは最終的にForce.comに設定したスキーマに合わせた形式のCSVファイルなどを用意します。このスキーマ定義に合わせた形式へのデータ加工の主たる担当を誰が担うのかは、しばしば課題となります。

現行システムからForce.comのスキーマに合わせた形式でCSVファイルをエクスポート可能であれば、移行作業の負担は大きく軽減されるでしょう。しかし、現行システムはリプレースされる側のシステムであるため、新システム側が期待する形式へのデータ加工に積極的に関与してもらえないケースがあるのも事実です。

このような場合、現行システムのほぼ生データに近いデータを、Force.comのスキーマに合わせた形式にデータ加工する必要が生じます。このデータ加工かかる工数は、現行システムからの移行対象テーブル数やスキーマの違いにより大きく変動し、スケジュールや工数にインパクトを与えるため注意しましょう。

4. サンプルデータは早めに入手できる？

初期データ移行のサンプルデータはデータ移行の品質を向上する上で、早めの入手が望ましいでしょう。

移行仕様として、現行システムと新システムのスキーマおよび項目マッピングを作成していたとしても、現行システム側と新システム側で認識の相違により、想定と異なるデータが提供されることはあります。

また、そのような事態が生じたため、再度現行システム側にサンプルデータ提供を依頼した結果、再提示に1～2週間かかった場合、スケジュールに大きな影響を及ぼすことになります。

移行設計で考慮するポイント

環境構築および結果確認するための順序

初期データ移行を行うための環境構築および結果確認するための順序は重要です。初期データ移行を行う上で、オブジェクトの設定情報をSandboxから本番環境に移行するのは当然ですが、レコードの所有者設定に必要なユーザやそれに付随したロール／プロファイル設定、共有ルールの設定と適用、Apexトリガや項目自動更新による値設定の有無、自動採番項目に値を設定する場合のテキスト型への一時的なデータ型変更などを、初期データ移行および結果確認を行う一連のタスクとして、どういう順序で環境構築および結果確認していくかを考慮します。

移行結果の検証方法

移行結果の検証では、移行結果件数および項目マッピングの検証を通常実施することと思います。Force.comにインポートするCSVファイルとForce.comのスキーマが1対1の関係であれば、Force.comにインポートを行った結果件数とCSVファイルの件数一致および項目マッピングの検証は比較的容易でしょう。（Force.comに移行結果を確認するレポートを作成し、ある期間や取引先毎の件数や合計値を確認するのも良い方法です）

一方、CSVファイルの1レコードから複数オブジェクトや複数レコードをインポートする必要がある場合、結果件数の検証でさえ複雑になります。このような場合、初期データ移行を行った結果、正常に移行されたかをどのように検証するかを移行設計時に十分検討する必要があります。

移行用外部ID項目の設定

Force.comで参照関係の構成を持つオブジェクトをインポートする場合、Force.comが採番するIDで参照関係を構成する必要があります。例えば、注文ヘッダと注文明細をインポートするとし、現行システムでは注文番号をキーに注文明細は注文ヘッダに関連付くとします。

後述する移行用外部ID項目を使用せずにインポートする場合、最初に注文ヘッダをインポートします。次にForce.comにインポートした注文ヘッダの注文番号とIDをエクスポートします。そして、注文明細が持つ注文番号をForce.comのIDに変換し、注文明細をインポートする手順となります。

この注文番号をIDに変換した上でインポートする点が、複雑でありエクスポートするために余計な時間がかかることにもなります（トランザクション系など多くのマスタとの参照関係を持つ場合、より複雑になります）。この問題を解決する方法として、移行用に外部ID項目を追加する方法があります。 注文ヘッダが持つ注文番号を外部IDに設定し、注文明細をインポートする際に注文番号を外部IDでマッピングする設定を行うことにより、Force.comが内部でIDに自動変換を行ってくれます。

外部IDを使う

監査項目に対する値の設定

Force.comには監査項目と呼ばれる項目（作成日、作成者、最終更新日、最終更新者）があります。監査項目はForce.comが自動設定を行う項目のため、ユーザが任意に値を設定することはできません。しかし初期データ移行の場合、現行システムが持つ同様な項目をそのままの値で設定したいケースが生じます。

このような移行要件がある場合には、セールスフォース・ドットコム社にリクエストすることにより、監査項目に対しレコードのINSERT時に限り値の設定を許可してもらうことができます。この許可は、あくまでレコードのINSERT時のみであり、レコードのUPDATEでは設定することはできません。また、レコードのINSERT時であっても監査項目に値の設定が許可されないオブジェクトがある点も注意しましょう。

【監査項目に値の設定ができるオブジェクト】
- Account
- Opportunity
- Contact
- Lead
- Case
- Case Comments
- Task
- Event
- Idea
- Idea Comments
- Campaign Members
- Custom Objects
※Attachment、DocumentなどINSERTであっても監査項目に対して値の設定ができないオブジェクトがある点に注意
※UPDATEでは常に監査項目に値の設定ができない点に注意

Bulk APIの使用

初期データ移行で大量のデータをインポートする場合、Bulk APIを使用します。従来のSOAP APIと比較してより良いパフォーマンスを発揮します。 Bulk APIはその処理モードに「並列モード」と「逐次モード」があり、並列モードの方がよりパフォーマンスを発揮します。ただし、競合ロックが発生するケースがあるため、必要に応じて逐次モードも検討します。

なお、Bulk APIは24時間あたりのジョブ数制限（2000件）があります。そのため、データ移行を実施する上でジョブ数をどの程度消費するかは事前に確認する必要があります。初期データ移行でジョブ数の不足が想定される場合、セールスフォース・ドットコム社に上限を一時的に上げてもらうリクエストをするとよいでしょう。

その他考慮事項として、Bulk APIのパフォーマンスはベストエフォートのため、移行リハーサルと本番移行時で所要時間が大きく変わる可能性がある点です。そのため、移行スケジュールは余裕を持って計画するとよいでしょう。

移行先は書込み可能なオブジェクトか？

Force.comには項目変更履歴という、ユーザがレコードに対して編集した結果を履歴として自動的に保存する仕組みがあります。現行システムでも同様な仕組みがあり、現行システムが持つ項目変更履歴をForce.comに移行したいという要求が出る可能性があります。しかし、項目変更履歴はレコードの追加ができないオブジェクトであるため、仮に移行が必要となった場合には、別途カスタムオブジェクトを用意して、現行システムの項目変更履歴はそちらに移行するといった対応が必要になります。

※レコードの追加が可能かを確認する場合、オブジェクトのDescribeを取得し、Creatableを確認します。

添付ファイルの移行

Force.comにはレコードに対してメモ＆添付と呼ぶ機能により、画像やWord、Excel、PDFなどのファイルを添付する機能があります。データ移行にあたり、これらのファイルも移行したい要件はあるでしょう。この時、メモ＆添付に添付できるファイル容量は5MBまでの制限があります。移行対象のファイルが容量制限に収まるかを事前に確認しましょう。

※同様にドキュメントも5MBまでの容量制限があります。

※5MBを超えるファイルを扱えるコンテンツという機能もあります。（使用可能なライセンスが必要です。）

Apexトリガ／入力規則／ワークフロールールの無効化

初期データ移行で特に大量のデータをインポートする場合、非常に時間がかかるケースがあります。　移行時のパフォーマンスを発揮するうえで、インポート時に不要なApexトリガや入力規則、ワークフロールールを無効化することが可能であるかを検討します。また、共有ルールも移行時のパフォーマンスに影響を及ぼします。共有ルールは移行後の設定で再計算することができるため、移行後に設定することも検討すると良いでしょう。

※入力規則やApexトリガでデータのチェックを行っている場合、それを無効にすることにより不正なデータがインポートされる可能性が生じます。そのような例外データの混入を許容しないよう注意しましょう。

【初期データ移行におけるApexトリガの扱い】
Apexトリガを初期データ移行時に無効化するという方法以外に、カスタム表示ラベルやカスタム設定を参照するなどし、特定の条件下でApexトリガのビジネスロジックをスキップするようにあらかじめコーディングしておく方法も有効です。
初期データ移行時にApexトリガを動作させる場合、Apexトリガがバルク処理に対応しているかは重要です。
Apexトリガがバルク処理に対応していないコーディングでは、ガバナ制限に抵触しインポートが失敗してしまいます。詳しくは、ApexトリガのレビューポイントのBlogをご覧ください。
※Apexトリガがバルク処理に対応しておらず修正が困難な場合、インポート時のバッチサイズを小さくすることで対処しますが、この場合パフォーマンスは劣化します。
また、Apexトリガを動作させて初期データ移行する際に、監査項目に値設定しているオブジェクトに対して
UPDATEを行っているかの確認も忘れず行います。UPDATEを行っている場合、監査項目の最終更新日、最終更新者は初期データ移行を行ったユーザで上書きされてしまいます。

自動採番項目への値設定

初期データ移行時に、Force.comで自動採番型に設定した項目に対して値を設定したいケースもあるでしょう。この場合、初期データ移行前に、自動採番型をテキスト型に変更してインポートを実施し、インポート実施後に再度自動採番型に戻します。

ただし、ApexトリガやApexクラスから自動採番項目を参照している場合、データ型の変更ができません。初期データ移行時に、Apexトリガによる値設定を想定するケースと自動採番項目への値設定を行うケースが混在する場合には移行手順に注意が必要になります。

ごみ箱から削除

初期データ移行では、リハーサル等により「データのインポート＆インポートデータの削除」を繰り返し実施する場合があるでしょう。ここで注意したいのは、インポートデータの削除です。インポートデータを特に意識なく削除した場合、その削除レコードはごみ箱に蓄積されます。

本番環境に大量データのインポート＆削除を繰り返し実施した結果、一時的にごみ箱に大量データが保持される結果となり、本番稼働時に削除を繰り返したオブジェクトを参照するクエリのパフォーマンスが劣化するという思わぬ事態が起こりえます。そのため、インポートデータを削除する際には、ごみ箱に入れることなく物理削除するBulk APIの(※1)HardDeleteオプションを有効にして削除すると良いでしょう。

※1 プロファイルのシステム管理者権限「Bulk API の物理削除」が有効なプロファイルを持つユーザでHardDeleteオプションを有効にして実施する必要があります。 削除済みデータが与える影響については、SOQLクエリのパフォーマンスチューニングのBlogが参考になります。

おわりに

初期データ移行はプロジェクト終盤の重要な局面になり、その準備や移行ツール開発に苦労するケースは多いと思います。そういった苦労が少しでも軽減されると幸いです。