Integration BuilderをSalesforce Developer Editionで試してみるで試しに作ってみたモジュールの構成を確認してみます。
確認環境
Personal Environment(Version 11.13.0 (Build 31107))
Service Studio (Version 11.11.12)
Integration BuilderはSaaS：https://integrationbuilder.outsystems.com/
ドキュメント
Structure of generated integrations
アーキテクチャ
Salesforceで試しに作ってみたConnectorの構造をまとめてみました。
Integration Manager
最初にIntegration Builderをセットアップするときにインストールする、標準部品。
認証関係を処理する仕組みを提供する。
図中では、IM_SalesforceConnection_CSしか表示していないが、他の種類のコネクタ用の認証処理用モジュールも含んでいる。
Salesforce Connector
IntegrationBuilderで作ってみたSalesforce用コネクター部品のアプリケーション。
Salesforceに直接接続する機能を提供するDRVモジュール（Library）と、DRVが提供するActionをラップして内部接続先への認証も処理するActionをユーザーアプリケーションに提供するISモジュール（Service）で構成される。
ユーザーモジュール
利用側アプリケーション・モジュールのこと。
このモジュールが利用するのはISモジュールのActionだけにする。
アーキテクチャ設計の資料から
まず、モジュール名のDRVやISというサフィックスについて。
アーキテクチャ設計の資料（Naming Conventions for Modules）に該当する部分があります。
DRV（Driver）「Integration with different systems that perform the same type of operation」。同じ種類の処理をする異なるシステムに接続する部品。
IS（Integration Services）「Technical wrapper to consume and normalize an external service」。外部サービスを利用し、標準化するための技術的なラッパー部品という意味ですね。
この構成については、Transparency Serviceというアーキテクチャ設計パターンがあります。
リンク先の図を確認してみてください。
例として、顧客情報が2種類のERPと1種類のSaaSに分散しているときに、DRVを3種類それぞれに用意し、ISを1つ用意する。そしてISが統一したインターフェースを提供、受け取った値をチェックして適切なDRVに処理をルーティングする、というパターン。
パターンの構成が同じなので、この設計パターンを参照して、IntegrationBuilderで生成されるモジュールの役割と名前が決められているように見えます。
IntegrationBuilderの場合、コネクターアプリケーションが自動生成されるので2階層にする必要性は薄そうに見えますが……。
設定によっては、生成されたモジュールを手動でメンテナンスできるので、そのためかもしれません。
提供される操作
CRUDと検索条件を渡して合致するデータの件数を返すCount、及び検索条件を渡して合致するデータを返すSearchの操作が提供されている。
Available Server Actions in an integrationによると、以下の6つの操作が、とりこんだデータの種別ごとに作成される（データソースによっては一部操作に対応しないこともある）。
- Create
- Get
- Update
- Delete
- Count
- Search