CData Software Blog

クラウド連携のCData Software の技術ブログです。

ArcESBでCDataコネクタのデータ連携をバッチで実行する方法

ArcESBではCDataのADOドライバによるサービス接続を実装した「CDataコネクタ」を使用できます。 例えば下図はSanSanの名刺データ(Bizcards)をSalesforceの取引先(Account)へコピーするフローです。 SanSanとSalesforceへの接続はCDataコネクタを使用しています。

f:id:urabe_shintaro:20200220171923p:plain

通常、CDataコネクタは複数レコードに対して1件ずつ処理を行います。 例えば上記フローで名刺データが5件ある場合、下図に示すように1件ごとに送信データ(XML)が生成され個別に送信されます。

f:id:urabe_shintaro:20200220172023p:plain

受信側も5回送られた送信データをそれぞれ受信します。

f:id:urabe_shintaro:20200220172055p:plain

このときのデータフローの概略を下図に示します。

f:id:urabe_shintaro:20200220180708p:plain

数十件のデータであれば問題ありませんが、数千件のデータを送付すると膨大な時間がかかります。 このような問題への対応として、複数のレコードを1つのデータにまとめて処理する方法を説明します。 尚、バッチ送信の方法はArcESBのバージョンごとに異なりますのでご注意ください。

入力コネクタ:バッチ送信の設定 (V21)

送信コネクタの「Advanced」タブを開き、「Max Records」に「-1」を設定してください。

f:id:urabe_shintaro:20211111103827p:plain

入力コネクタ:バッチ送信の設定 (V20)

送信コネクタの「Setting」タブにある「Mapping」セクションの「Output」を開きます。 マッピング</>ボタンをクリックし、「Mapping Editor」ウィンドウを開きます。

f:id:urabe_shintaro:20200220172411p:plain

この画面では送信するデータ(XML)のテンプレートを編集することができます。

f:id:urabe_shintaro:20200220172432p:plain

ちなみにテンプレートは以下のファイルに定義されています。 このファイルを直接書き換えても構いません。

C:\Program Files\ArcESB\workspaces\<ワークスペース名>\<コネクタ名>\Templates\Output\<テーブル名>.xml

このテンプレートのテーブル定義に対し、以下のように「batchResults="true"」という属性を追記します。

f:id:urabe_shintaro:20200220172612p:plain

「Save」をクリックして画面を閉じてください。 これで設定は完了です。

バッチ送信の確認

データを送信すると、下図のように1つの送信データが生成されて送信されます。 送信データの中を見ると、複数のレコードが<Items>の中にリスト化されていることが確認できます。

f:id:urabe_shintaro:20200220172638p:plain

出力コネクタ:バッチ更新の設定

上で示した設定によりバッチでデータを生成すると、バッチ処理に対応したコネクタでの処理性能の改善が見込めます。 ここからは受信側のCDataコネクタをバッチ処理に対応させるための設定方法を説明します。

CDataコネクタで複数レコードを更新すると1件ずつ更新処理が実行されます。 例えば下記のログは冒頭に示したフローのSalesforceコネクタで5件のレコードを含むデータを受信し、Accountテーブルへ挿入した時のログです。

f:id:urabe_shintaro:20200220172908p:plain

Insert文とそれに伴うSOAPリクエストが5回発生していることが分かります。 このままだと送信側のバッチ処理でデータをまとめられたとしても、受信側がボトルネックとなり全体の性能が低下してしまいます。

f:id:urabe_shintaro:20200220181022p:plain

これを1回のリクエストで済ませるにはバッチ入力サイズを設定します。 受信コネクタの「Advanced」タブにある「Batch Input Size」に1回の入力で更新するレコード数を設定します。 例えばここでは100と設定します。これは1回のリクエストで最大100レコードを更新することを意味します。

f:id:urabe_shintaro:20200220172945p:plain

この設定で実行したログを見てみます。 バッチ処理するための一時テーブル(Temp)を作成していること、Insertおよびリクエストが1度だけ実行されていることが確認できます。

f:id:urabe_shintaro:20200220173019p:plain

以上で示した設定により、複数レコードの更新を一度のリクエストで処理できるようになります。

f:id:urabe_shintaro:20200220181302p:plain

ただし、受信側のサービスにリクエストデータのサイズ制限がある場合はそのサイズを超えないよう注意してください。