テックブログ

データ連携で開発者が気をつけたい5個のこと

「データ連携」という言葉を聞くと、苦い思いをしたことがある人は少なくないでしょう。多くの場合、新しいシステムを構築する際には、既存のシステムと何らかの形でデータの連携が必要になるでしょう。

Salesforce上に新たに、在庫管理をするシステムを構築します。在庫管理には顧客情報も含むとしましょう。既存の顧客、出荷、経理などのシステムに対する片方向あるいは、双方向のデータ連携が必要になることを想像してみてください。どのようなことに注意をしていけばいいでしょうか。今回は、データ連携で考慮したい5個のポイントをまとめたいと思います。

integration

1. データ連携の方法

言うまでもないですが、「どのデータをどのシステムへ(どうやって)連携するか」という点は、最初に定義しなければなりません。具体的には:

  • どのオブジェクトのどのデータを連携するか。
  • 連携の契機はなにか。
  • 連携の頻度はどの程度か。1日1回の夜間バッチや、リアルタイム(SFDCで変更されたデータを即時で相手先システムへ連携する)か。
  • 1回の連携でのデータ量はどのくらいか。
  • どのような形式で連携するか。

という点が挙げられます。

「どのような形式で連携するか」という点はもう少し説明が必要でしょう。連携先のシステムが公開しているAPI等を使用して、「連携する側が連携する先のシステムに(直接的に)データを書き込むこと」もできますが、この方法だけではありません。DBや、ファイル、SFDCに定義したオブジェクトに連携するデータを蓄積し、連携側が取得(バッチ起動、定期的なポーリングなど)するという方法もあります。

 

2. データ型と値の定義

システムが異なれば、同じ状態を管理するにしても、それを表現するコード体系が異なることが一般的でしょう。例えば、Salesforceでは、優良顧客度を表すコードを01, 02, 03.., 10のように、選択リストで数値形式2桁で管理しているとします。一方、既存の顧客システムでは文字列型で管理しているか、1,2,3...,10のように数値形式で管理されているとします。このような場合、単純に、Salesforceの値を既存顧客システムへ連携しようとしても、正しいデータ連携ができません。不幸なことにデータ連携の仕組みを作成した後に、想定外のデータにより、(顧客システムで)想定外のエラーが発生する、ということもあるかもしれません。

データ連携を行う際にはコード値の相違、そして誰が(どのシステムが)変換を行うか、という点を明確に定義をすることが重要です。注意しておきたいデータ型についてまとめておきましょう。

  • 数値形式で表現しているコード値。01,02の形式なのか、1, 2の形式なのか。
  • あり/なしのコード値。(あり, なし)が、(1, 0)なのか、(1, 2)なのか。
  • Boolean型。単純に二択(true or false)なのか、三択(true, false or 未選択/未入力)なのか。
  • 日付形式。DateやTimestamp型で定義されることが一般的ですが、システムにより表現形式が異なることが多いです。また古いホストシステム等では、文字型のyyyyMMdd形式やyyyyMMdd HHmmssで格納されている場合もあります。

 

3.  データの順序保障

連携データに順序の制御が必要な場合、連携先のシステムへデータを書込してもよいかどうかの判断が必要になります。例えば在庫管理システムの顧客情報を連続して2回更新したとします。リアルタイム連携でかつ、更新が発生した時点のスナップショットを連携データとしている場合、順序制御が考慮されないと、「古いデータで新しいデータを更新する」という問題が発生します。

このような問題を回避するための有効な手段としては、データを書き込む際に、タイムスタンプやシーケンス番号など新旧を判断できる情報を手がかりとして、書き込むべきか、捨てる(書き込みしない)べきかを判断します。

また、親子関係がある連携データを扱う場合も、順序保障を考慮する必要があるといえます。

 

4.  疎結合性

データ連携される側が常に稼働をしていれば、システム停止時の考慮は不要ですが、定期的なメンテナスによりシステムを停止することがあります。あるいは、処理能力の問題で大量のデータ連携を一度に行うことができないかもしれません。それにより、自システムの処理が滞ってしまうことは、避けなければなりません。

極力相手先のシステムに依存しない方法、例えば、直接相手先と接続するのではなく、DBやファイル等の中間レコードを介してデータを連携させることで、この問題を回避することができるでしょう。重要なのは、「他システムの稼働状況に、自システムが影響を受けない」ことを考慮することです。

 

5.  エラー発生時のリトライ

何らかのエラーが発生した場合、リトライにより復旧を試みます。通信や過負荷の問題であれば、リトライすることで正常に連携できる可能性があります。

しかしながら、

  • 相手先システムがダウンしている(ので、何度やってもダメ)
  • 連携データが不正で相手側システムがそれを受け入れることができない (データ型の不一致/範囲外の値など)
  • 連携データをUpdateしたいが、更新対象のレコードが存在しない

などの理由により正常にデータ連携できない場合があります。

発生したエラーに応じて、処理の継続要否を判断することが必要です。

  • エラーとなった連携データは別途復旧することとし、それを除外して処理を継続する
  • その時点で処理を終了する(投入済みのデータは、そのままとする or 削除する)

またデータ連携はシステムの裏側(=画面系ではなくバッチ的)で行われることがほとんどです。処理を追跡できるログメッセージを出力し、問題発生時に何が原因であるかを調査できるように準備することも重要です。

 

まとめ

5個のトピックを掲載しましたが、それ以外にも、双方向連携の場合にどのシステムのデータをマスタとするかなど、考慮したい点はまだまだあります。

また、連携の規模が大きくなる場合は、EAIなどのデータ連携基盤を導入することも重要な考慮点と言えます。多くのEAI製品は、上記問題点を比較的容易に解決できる手段を提供してくれます。また、GUIによるマッピング、ロジック(フロー)制御が可能であり、アダプタと呼ばれる接続システム固有の処理を行ってくれるモジュールも提供されています。

次回はこれらを踏まえて、実際にデータ連携を行ってみましょう。

 


イベント開催のお知らせ

『トップコーダーオープン TCO15 in Tokyo』

アピリオは、競技プログラミングとハッカソンを含むオンサイトイベントを7月18日(土)に開催します。詳細情報および参加登録はこちらをご覧ください。

 

Appirio