iFlowをGitにpushしてCI/CDのSAP Integration Suite Artifactsパイプラインでデプロイ

はじめに

今年の7月に、Cloud IntegrationのiFlowをGitで管理できるようになりました。テナントと接続済みのリポジトリを選択して、iFlowをPushしたり、Pullしたりすることができます。

この機能を紹介したブログ
によれば、Git連携は「共同開発、変更の追跡、ストレージ、バックアップ、リカバリ」目的だということです。これを使って別のテナントにiFlowをPullしてくることも可能ですが、移送管理はメインの目的ではないと思われます。

一方、BTPのContinuous Integration and Delivery（以下、CI/CD）のパイプラインにはSAP Integration Suite Artifacts 2.0というパイプラインが用意されています。このパイプラインはGitリポジトリに格納されたiFlowを取得し、指定したテナントにアップロード、デプロイすることができます。

両者をつなぐことで、Gitへプッシュ→CI/CDでデプロイということが可能になるのではないかと考えました。

やりたいこと

いずれの方法も管理するのは個別のiFlowであり、パッケージに含まれるスクリプトやValue Mappingなどは対象になりません。iFlowが他のアーティファクトに依存している場合は、まずパッケージそのものをターゲットの環境にインポートしておく必要があります。

機能間のギャップ

Cloud IntegrationのGit管理機能は、1つのリポジトリに複数のiFlowを格納します。以下の例ではTest_FlowというiFlow1本のみですが、複数のiFlowを格納したときは、フォルダが複数できます。便宜上、この構成を「構成①」と呼びます。

構成①

Test_Flow
├── META-INF
│   └── MANIFEST.MF
├── src
│   └── main
│       └── resources
│           ├── scenarioflows
│           │   └── integrationflow
│           │       └── Test Flow.iflw
│           ├── parameters.prop
│           └── parameters.propdef
├── .project
├── metainfo.prop
└── README.md

一方、CI/CDサービスのパイプラインは、iFlowをダウンロードしてzipを解凍したものがリポジトリのルートにある状態を要求します。すなわち、1リポジトリ1 iFlowという構成です。この構成を「構成②」と呼びます。

構成②

.
├── META-INF
│   └── MANIFEST.MF
├── src
│   └── main
│       └── resources
│           ├── scenarioflows
│           │   └── integrationflow
│           │       └── Test Flow.iflw
│           ├── parameters.prop
│           └── parameters.propdef
└── metainfo.prop

このままだと、Cloud IntegrationでGitにpushしたiFlowをそのままCI/CDで使うことができません。

Cloud IntegrationからpushしたiFlowをそのままCI/CDで使うには

CI/CDのIntegration Suite Artifacts 2.0のパイプラインは以下のステップになっています。

1. Upload: リポジトリのコンテンツをルートレベルでpackage.zipにまとめてターゲットテナントにアップロードする
2. Deploy: アップロードしたiFlowをデプロイする
3. Integration Test（オプション）: デプロイしたiFlowを呼び出す

構成①の形式のままだと、Uploadステップで以下のエラーになります。

Integration flow project must contain a manifest file.

Cloud IntegrationのAPIはルートレベルにMETA-INF/MANIFEST.MFというファイルを期待していますが、それがないためエラーになっているのです。

そこで、UploadステップのAdditional Commandで、対象のiFlowが格納されたフォルダを指定してpackage.zipファイルを作成するようにしました。

python3 -c "import shutil; shutil.make_archive('package','zip','{iFlowのテクニカルID}')"

この結果、Cloud IntegrationのGit連携機能とCI/CDパイプラインを橋渡しすることができました。

設定手順

1. iFlowをGitにpushするための設定

参考：https://help.sap.com/docs/integration-suite/isuite-integrations-and-apis/integrating-with-github

1.1. リポジトリを作成

mainブランチがある状態のリポジトリを作成します。

1.2. PATを準備

GitHubでPersonal Access Token (PAT) を作成します。
設定パス：Settings > Developer Settings > Personal Access Tokens > Fine- Grained Tokens

パーミッションに以下を設定します。

1.3. Integration Suiteにリポジトリを登録

Settings > Git Accessより、リポジトリを登録します。（Addボタンが非活性ですが、画面右下のEditボタンを押すと活性になります）

リポジトリのURLとPATを指定します。

Addしたあと、画面右下のSaveをクリックして保存します（忘れやすいので注意）。

1.4. iFlowをpush

作成したiFlowのActionsより、Git Pushをクリックします。

初回はリポジトリとブランチを選択します。コミットメッセージとPATは毎回指定します。

1つのテナントのiFlowは1つのブランチのみにpushできます。

pushした結果、リポジトリにiFlowが格納されます。iFlowのテクニカルIDでフォルダが作成されます。

2. CI/CDでの設定

2.1. SAP Process Integration Runtimeのサービスインスタンス・キーを作成

ターゲットテナントで、SAP Process Integration Runtime（プラン：api）のサービスインスタンスを作成します。その際、以下のロールを割り当てます。

• WorkspacePackagesEdit
• WorkspaceArtifactsDeploy
• MonitoringDataRead

2.2. ターゲットテナントでパッケージを作成

Cloud IntegrationのパッケージはCI/CDで作成されないので、事前に作成する必要があります。

2.3. パイプラインの設定

Integration Suite Artifacts 2.0のパイプラインを設定します（リポジトリはすでにCI/CDに登録済み）。

パイプラインにIntegration Suite Artifacts 2.0を選択します。

Statges > Connection DetailsでデプロイするFlow IDとDesign Time Authenticatinonを設定します。

Flow IDはiFlowのテクニカルなIDで、リポジトリにアップロードされたフォルダ名から確認できます。

Design Time Authenticatinonはターゲットテナントへの認証情報です。検索ヘルプボタンのダイアログで+をクリックしてその場で作成することができます。2.1.で作成したサービスキーのJSONを貼り付けて作成します。

Statges > Uploadでデプロイ先のPackage IDとFlow Nameを指定します（Package IDは事前に作成したものを指定）。

さらに、Additional Commands > Run First in Stageに以下のスクリプトを指定します。冒頭で述べたように、このステップがGitに格納されたiFlow別のフォルダをzipにするために必要です。

python3 -c "import shutil; shutil.make_archive('package','zip','{iFlowのテクニカルID}')"

Statges > Deployは、スライダーをOnにするだけです。これにより、ターゲットテナントでiFlowがデプロイされ、実行可能な状態になります。

パイプラインが正常に実行されると、ターゲットのテナントにiFlowが登録・デプロイされます。

この仕組みの使いどころ

cTMSを使用して移送ルートを構築済の場合、この仕組みを使う必要はありません。また、この仕組みはiFlowのみが対象であり、パッケージそのものや、パッケージに含まれる他のアーティファクトはGit管理および移送ができません。
一方で、Cloud Integrationの中で頻繁に変わりうるものといえばiFlowなので、そこだけCI/CDにしておくことは意味のないことではないと思います。したがって、この仕組みが合いそうなのは以下のようなケースではないかと考えます。

• cTMSを使っていない
• iFlowの数が少ない
• 頻繁に変わるiFlowがあり、バージョン間の差分比較やロールバックを可能にしたい

ブランチ運用はどうなるか？

iFlowをGit管理する機能では、1つのテナントのiFlowは1つのブランチのみにpushできます。このため、「機能追加のために別ブランチを切って開発」ということができません。これを踏まえると、「開発環境ではdevelopブランチにpushし、開発が完了したらmainにマージする。移送はmainブランチから実施する」という運用が考えられます。

さらに、開発、検証、本番というランドスケープの場合、develop、test、prodのようにブランチを分けることも考えられます。これにより、各ブランチにあるソースと実際の環境のソースが一致します。

Gitから直接pullという手段もあるが、CI/CDは必要か？

Cloud Integrationには、GitリポジトリからiFlowをインポートしたり、更新したiFlowをpullしたりする機能もあります。これを使えば、CI/CDはなくてもよさそうです。CI/CDのメリットがあるとすれば、「mainブランチへのマージをトリガに、自動的にアップロード&デプロイまでできる」ところだと思います。