OutSystemsでエンタープライズアプリケーションを構築する際、避けて通れないのが「外部システム（ERP、CRMなど）との連携」です。OutSystems自体がデータの正本（System of Records）を持たず、外部にあるデータを扱う設計パターンをECS（External Core Service）パターンと呼びます。
試験では「大量のデータがあるが検索を高速にしたい」「更新の順序を保証したい」といったシナリオに対し、どのECSバリエーションを適用すべきかが頻繁に問われます。今回は、これら全パターンを詳細に解説します。
1. ECSパターンの基本構造
ECSパターンの核心は、「Core Service（_CS）」が利用者に提供するインターフェースを変えずに、背後の取得ロジックを隠蔽することにあります。
| モジュール | 役割 |
|---|---|
Integration Service（_is） |
外部APIをラップし、OutSystems内のデータ構造（正規化）に変換します。 |
Core Service（_CS） |
利用側にはこのモジュールがサービスを提供します。ここにキャッシュ用のエンティティを持つかどうかが、バリエーションの分かれ目です。 |
2. ECSパターンの主要バリエーション一覧
| パターン名 | データの持ち方 | 特徴・メリット | 適したユースケース |
|---|---|---|---|
| Direct Integration | キャッシュなし | 常に最新データ。外部への負荷・遅延は高い | データが秒単位で変化し、複製が許されない場合 |
| Cold Cache（Summary） | 概要のみ保存 | 検索・一覧表示を高速化。詳細は都度取得 | 全データは膨大だが、詳細は特定時のみ必要な場合 |
| Batch Sync | 全件同期 | 定期的な一括更新。OutSystemsの全機能を利用可能 | データ更新頻度が低く、高い検索性が必要な場合 |
| Lazy Load | 参照時に保存 | 必要な時だけ取得してキャッシュ（Read-through） | データの特定範囲のみが頻繁に参照される場合 |
| Real-time Sync | 即時同期 | 外部からのコールバックで即座に更新 | 常に最新の概要（車両位置など）を一覧したい場合 |
| Transparency Service | 複数ソース | 複数システムの差異を統合APIで隠蔽 | 国内・海外などデータソースが分散している場合 |
以下では各パターンの詳細を解説します。
① Direct Integration（直接統合）
キャッシュを一切持たず、データが必要な時に都度外部APIを呼び出します。
| メリット | データが常に最新 |
| デメリット | 外部システムへの負荷が高く、検索やマッシュアップ（結合）が困難 |
| 使い所 | データが秒単位で激しく変化し、複製が許されない場合 |
② Cold Cache Summary Data（サマリーデータのキャッシュ）
検索や一覧表示に必要な項目（名前、区分など）のみをOutSystems側のエンティティに保存（キャッシュ）します。
| ポイント | 詳細データはキャッシュせず、1件表示の時にのみ外部へ直接取りに行きます。 |
| 使い所 | 全データが膨大だが、実際に詳細まで見られるのはその10%程度という場合 |
③ Cold Cache with Batch Sync（バッチ同期）
タイマーを使用して、定期的に外部からデータを一括取得してキャッシュを更新します。
| 重要ルール | 更新時はまず外部システムを同期的に更新し、成功してからキャッシュを更新する「Write-throughポリシー」を適用します。 |
| 使い所 | データ変更頻度が低く、OutSystems側で高速な検索・ソートを行いたい場合 |
④ Lazy Load Details（詳細データの遅延読み込み）
「詳細データ」が必要になったタイミングでキャッシュを確認し、なければ外部から取得して保存します（Read-through caching）。
| 運用 | キャッシュに有効期限を設定したり、外部の最終更新日時を比較してリフレッシュを判断します。 |
3. 【難関】リアルタイム同期と特殊パターン
⑤ Real-Time Sync（リアルタイム同期）
外部システム側からOutSystemsへ「変更があった」ことを通知（コールバック）させ、即座にキャッシュを更新します。
| Queued Real-time Sync | 大量の変更がある場合、インバウンドキューに入れて並行処理させます。 |
| Ordered Real-time Sync | 順序が重要な場合、Light BPTとシーケンス制御を用いて到着順序を保証します。 |
⑥ Transparency Service（透明性サービス）
複数の外部システム（例：国内顧客はERP1、海外顧客はERP2）にデータが分散している場合、上位の _IS が適切なドライバ（_DRV）を呼び分けるパターンです。
| メリット | 利用側はデータがどこにあるかを意識せずに済みます。 |
⑦ Hot Cache（ホットキャッシュ）
単なる複製ではなく、複数のテーブルの結合結果や複雑な計算結果を「事前に処理（Digest）した状態」で保存する、超高速アクセス専用のパターンです。
4. 試験対策：パターンの覚え方「3つの軸」
試験問題で迷ったら、以下の3つのキーワードで絞り込んでください。
| # | キーワード | 選ぶべきパターン |
|---|---|---|
| 1 | データの鮮度 | 常に最新が必要なら「Direct」または「Real-Time Sync」 |
| 2 | データ量と検索性 | 検索を速くしたいなら「Cold Cache Summary」 |
| 3 | 更新の順序 | 順序保証が必要なら「Ordered Real-time Sync」 |
📝 頻出ポイント
同期ロジックが複雑な場合は _Sync モジュールを分離することが「コードの独立性」の観点から強く推奨される、という点も試験頻出です。
第3回のまとめ
✅ この回のポイント
- Write-throughポリシー：同期パターンでの更新時は、まず外部システムを更新し、成功後にローカルキャッシュを更新します。
- Ordered Real-time Sync：並行処理による順序逆転を防ぐには、インバウンドキューとLight BPTを活用します。
- _Sync モジュールの分離：同期ロジックを独立させることで、コアサービスのライフサイクルを守ります。
コメント