はじめに
これまでにCloud IntegrationのiFlowの移送をする方法について、調査してきました。
- GitHub Actionsを使って移送
- Integration SuiteのGit管理機能とCI/CDの組み合わせ
もっとも一般的なのは、Cloud Transport Management Service (CTMS) を使用して移送する方法だと思います。Cloud Integrationのアーティファクトを移送する場合、Content Agent Service (CAS) を使用してMTARアーカイブの形式にしてから移送します。このために多数のDestinationを作成する必要があり、どれが何のために必要なのか把握するのも大変です。
マニュアルで設定する手順：
https://help.sap.com/docs/cloud-integration/sap-cloud-integration/creating-http-destinations-and-transport-route-cloud-foundry
そのような初期設定を自動で実施してくれて、移送管理用のUIも提供するアプリケーションがあります。それがCloud Integration Delivery Orchestratorです。
Cloud Integration Delivery Orchestratorの概要
リポジトリ：https://github.com/SAP/cloud-integration-delivery-orchestrator
SAP社が提供するオープンソースのBTPアプリケーションで、CTMS + CASでの移送のための初期設定、コンテンツの移送、デプロイが可能です。自分のCloud Foundry環境にデプロイして使います。
素のCTMSでは移送（ターゲットテナントにインポート）して終わりですが、Cloud Integration Delivery Orchestratorでは以下が可能です。
- デプロイ（アーティファクトが実行可能な状態になる）
- 環境間の差分比較
本ブログではCloud Integration Delivery Orchestratorをセットアップして使うまでの手順を紹介します。
関連SAP Communityブログ
- Set Up a Governed SAP Cloud Integration Delivery Flow — Now Open Source — 概要、BTPへのデプロイ、主要な機能
- There Is No "Delivery" in SAP Cloud Integration — エクスポート、インポート、デプロイが別ツールで行われる現状と、Cloud Integration Delivery Orchestratorが解決できること
- See What Changed in an SAP Cloud Integration iFlow Before Moving It to Another Tenant — 移送時のレビューのため、GitスナップショットとGitHub Appによる同期を利用したBPMNによる視覚的な差分比較
リポジトリやブログには具体的な手順は書かれていなかったため、Claude Codeにソースを読み込ませ、指示をもらいながら人間（私）が設定しました。
初期設定
ステップ：
- Gitリポジトリのクローンとデプロイ
- ロールコレクションの割り当て
- CTMSのDestinationを作成
- CTMSで移送ルートを作成
- CTMSとの接続
- CPIテナントとの接続
- CTMSのターゲットノードのDestinationを更新
- Delivery Ruleの作成
1. Gitリポジトリのクローンとデプロイ
Gitリポジトリからプロジェクトをクローンします。
git clone https://github.com/SAP/cloud-integration-delivery-orchestrator.git
cd cloud-integration-delivery-orchestrator
このプロジェクト自体にソースは含まれず、Dockerイメージを使用してデプロイする形になっています。元となるUIとバックエンドのプロジェクトは以下にあります。
バックエンド：https://github.com/SAP/cloud-integration-delivery-orchestrator-srv
UI：https://github.com/SAP/cloud-integration-delivery-orchestrator-ui
example.mtaextファイルをコピーしてyour-landscape.mtaextを作成します。デプロイ先環境によって変える値を設定するためです。
cp example.mtaext your-landscape.mtaext
your-landscape.mtaextを以下のように設定します。今回はトライアルアカウントを使用するため、PostgreSQLのサービスプランとXSUAAのredirect-urisを変更しました。
_schema-version: "3.1.0"
ID: cloud-integration-delivery-orchestrator-customer
extends: cloud-integration-delivery-orchestrator
parameters:
app-host-prefix: "mio-cidorch-trial" # ルートが一意になるようにする
docker-image: "ghcr.io/sap/cloud-integration-delivery-orchestrator:latest"
db-service-plan: "trial" # PostgreSQLのサービスプラン
resources:
- name: cloud-integration-delivery-orchestrator-uaa
parameters:
config:
oauth2-configuration:
redirect-uris:
- https://*.cfapps.us10-001.hana.ondemand.com/** # us10-001 へのリダイレクトを許可する
以下のコマンドでビルド、デプロイします。
mbt build
cf deploy mta_archives/cloud-integration-delivery-orchestrator_1.0.0.mtar -e your-landscape.mtaext
2. ロールコレクションの割り当て
デプロイが完了すると以下のロールコレクションが登録されます。今回はDelivery Orchestrator Administratorを割り当てました。
| Role Collection | Who | Access |
|---|---|---|
| Delivery Orchestrator Administrator | Platform administrators | Full access — manage tenants, rules, system config |
| Delivery Orchestrator Operator | DevOps engineers | Create/execute delivery requests, trigger version compare |
| Delivery Orchestrator Viewer | Stakeholders | Read-only access to all views |
アプリケーションにアクセスすると、以下の画面が表示されます。
3. CTMSのDestinationを作成
BTPコックピットでアプリケーションからCTMSにアクセスするためのDestinationを登録します。名前は何でもよく、接続情報はCTMSのサービスインスタンス（サービスキー）から取得します。追加プロパティは不要です。
4. CTMSで移送ルートを作成
CTMSのLandscape Wizardで移送ノードと移送ルートを作成します。Destinationは後続のステップで自動生成されたものを設定するので、この時点では指定しません。 Content Typeを指定するとDestinationが必須になるので、指定しない状態にしておきます。
今回はIntDevとIntTestの2ランドスケープとしました。
5. CTMSとの接続
アプリケーションでSystem Configurationのタイルをクリックします。
Configureをクリックします。
前のステップで登録したDestinationを入力して保存します。
6. CPIテナントとの接続
このステップは、移送元、移送先のテナントの分実施します。
6.1. Cloud Foundryとの接続
CPI Tenantsのタイルをクリックします。
Createをクリックします。
CF API EndpointにCloud FoundryのAPIエンドポイントを入力して、Loginをクリックするとブラウザが開きます。そこでパスコードをコピーし、CF Passcodeに貼り付けます。そのあとCF Org、CF Spaceをドロップダウンから選択します。
Cloud Integration Delivery OrchestratorはDestination登録に必要なサービスインスタンスやサービスキーの作成をCFのAPI経由で実施するので、ここでログイン情報を設定しています。
6.2. ブートストラップ
同じダイアログのBootstrapタブを開きます。ここはウィザードになっていて、ボタンを押すと次のステップに進みます。
TMS Source NodeにCTMSで作成したノードを設定し、Verify & Registerをクリックします。
※Source Nodeと書かれていますが、移送先のCPIテナントの場合はターゲットノードを指定します。
I have configured Routes - Refreshをクリックします。続いてConfirm Routes - Mark Readyをクリックします。
Run Inspectをクリックします。ブートストラップの前提条件がチェックされます。
Applyをクリックします。これにより、ブートストラップのジョブが起動します。
完了すると、以下のように作成されたサービスキーやDestinationが表示されます。
ターゲットのテナントについても同様に設定を行い、以下の状態になりました。ID列に設定された番号が、テナントの識別子になります。
ブートストラップ完了後、ソースのサブアカウントに以下のDestinationが作成されました（TMSのDestinationは最初にマニュアルで作成したもの）。
それぞれのDestinationが何に使われるか、SAP Communityのブログにわかりやすい図があったので紹介します。
CPIDELIVERY_PIR_Xだけ図に出てきませんが、これはCloud Integration Delivery OrchestratorがCloud Integrationにコンテンツを取得しにいくための宛先です。
7. CTMSのターゲットノードのDestinationを更新
CTMSのターゲットノードを以下のように更新します。
Content Type: Multi-Target Application
Destination: CPIDELIVERY_CAS_X ※XにはターゲットテナントのIDを指定
8. Delivery Ruleの作成
Delivery Ruleとは、移送対象を選択する際の条件のようなものです。対象のテナント、およびアーティファクトのバージョン番号のパターンを指定します。また、その組み合わせごとに承認を必要とするか、Jiraと連携するかを指定します。
Delivery Ruleのタイルをクリックします。
以下の項目を設定します。
| 項目 | 設定値 | 備考 |
|---|---|---|
| Name | 任意の名前 | |
| Version Paterns (regex) | 対象とするアーティファクトのバージョン。(例：1.0.*) | ワイルドカードはパッチバージョンでのみ許可される |
| Included Tenants | 移送ルートにあるテナントを全て選択 | ソース→ターゲットの順に選択する必要がある |
| Active | On | |
| Skip Approve | On | 自分自身で作成したDelivery Requestは承認できないため、一人で試す場合は常にOn |
| Require Jira | Off | Jiraとの連携をする場合はOn |
Delivery Requestを作成後にDelivery Ruleを変更すると、既存のDelivery Requestにも反映されます。
移送
以下では移送のためのステップについて説明します。
ステップ：
- Delivery Requestを作成
- 対象のアーティファクトを選択
- 承認（オプション）
- インポートを実施
- デプロイを実施
1. Delivery Requestを作成
Delivery Requestsのタイルをクリックします。
Createをクリックします。ダイアログでDelivery Ruleを選択します。
移送対象のパッケージを選択します。
パッケージ名を展開し、移送対象のアーティファクトを選択します。ここではDO_Test_1というiFlowが対象です。Confirmをクリックして確定させます。
2. 承認（オプション）
今回は承認をスキップする設定にしたので、Skip Approvalをクリックして次に進めます。
3. インポートを実施
Delivery Flowが表示されます。ターゲットテナント（以下ではTest）のImport Onlyをクリックしてインポートします。これにより、ターゲットテナントにiFlowが登録されます。
4. デプロイを実施
ターゲットテナントのDeploy Onlyをクリックしてデプロイします。これで、ターゲットテナントのiFlowが実行可能状態になります。
差分比較の機能
移送、デプロイだけでなく、テナント間の差分を比較できるのがこの機能の売りです。以下では、バージョン比較とBPMNによる差分比較を紹介します。
バージョン比較
テナント間でアーティファクトのバージョン比較ができる機能です。この機能では、1.0.0のようなバージョン番号による比較ができます。中身の違いは次のセクションで説明するBPMNによる差分比較で見ます。
Version Compareタイルをクリックします。
Trigger Scanをクリックして各テナントの情報を取得します。
環境間でバージョンに差がある場合は、以下のように表示されます。
タイルをクリックすると詳細を確認できます。以下では、dev環境でのバージョンが1.0.1で、test環境が1.0.0のため差異として認識されています。
差分を移送したい場合、画面右上のCreate Delivery RequestボタンからDelivery Requestを作成することができます。
BPMNによる差分比較
Delivery Requestの中で、BPMNによる視覚的な差分比較を行うことができます。そのためには以下の事前設定が必要です。
ステップ：
- 比較用のGitリポジトリを作成
- Gitリポジトリの設定（GitHub Appをインストール）
1. 比較用のGitリポジトリを作成
差分比較はGitHubのリポジトリに作成されたブランチ同士で行われます。このための空のリポジトリを用意します。
2. Gitリポジトリの設定（GitHub Appをインストール）
System Configurationを開き、Git Repositoryセクションの鉛筆マークをクリックします。
Authentication MethodにGitHub Appを選択し、GitHub Base URL (https://github.com) を入力します。Register GitHub Appをクリックします。
ブラウザが立ち上がるので、**Create GitHub App for ...**をクリックします。
Installをクリックします。
アクセスを許可するリポジトリ（1.で作成したリポジトリ）を選択してInstallをクリックします。
System Configurationの画面に戻ります。Enabledにチェックを入れ、Saveで保存します。
裏では、github-app-delivery-orth-...というDestinationが自動で登録されています。
Delivery Requestでの差分の見え方
Code Compareタブをクリックすると、差分取得のためGitにソースが同期されます。
以下はソースコードでの比較（Text Diff）です。
Visual Diffをクリックすると、差分がiFlowのエディタのような形式で表示されます。緑が追加、黄色が変更、赤が削除された箇所です。
図の変更箇所をクリックすると、新旧の値が表示されます。
全体的に黄色（変更）になっているのは、要素を追加したときにソース（XML）の内部的な値が全体的に変わったためのようです。既存の要素（HTTPS Sender Adapter）の値のみ変更した場合は、以下のようになりました。
使った感想
このツールは、開発者がすでに知っているフロー（移送依頼作成、インポート、デプロイ）にUIプラスαの機能をつけたものなので使い方がわかりやすかったです。面倒な初期設定を自動化してくれるのもありがたい。
一方で、Delivery Ruleという独自の概念は、正直いらないのではと思いました。Delivery Ruleで移送対象のバージョンを指定しますが、ワイルドカード(*)を指定できるのはパッチバージョンのみ。ということは、機能追加でマイナーバージョンが上がるたびにルールを定義しなければなりません。しかも、パッケージに含まれるアーティファクトによってバージョンは違うので、パッケージごと移送したいのに一部のアーティファクトが対象外になるということが起こりえます。
もしDelivery Ruleが合わないのであれば、「初期設定を自動化してくれるツール」と割り切って、そこだけ使うのもありかと思います。
2026/10/17更新
Delicery Ruleのバージョンの各ポジションにワイルドカードの指定ができるようになりました。
5.2.*, 5.*.*, *.*.* のようなパターンが許可されます。