OpenShiftを利用したSAP S/4HANAと他システムとのデータ連携

レッドハット　ソリューションアーキテクト石倉です。

この記事は、RED HAT BLOG のブログ記事、Integrating SAP with other applications using Red Hat OpenShift の翻訳記事です。

S/4HANA を始めとする SAP 社が提供するアプリケーションのランドスケープは、グローバル企業の機能を維持するために非常に重要で、その為に高度に複雑化する傾向があることはよく知られています。
一因としては、一般的な SAP インストールベースのアプリケーションがそもそも多数ある (ERP、BW、GRC、SCM、CRM など) だけでなく、SAP アプリケーションが通常、他の多くのサードパーティアプリケーションとの連携が必要となり、全体として企業内で大規模なエコシステムを構成するためです。

SAP ランドスケープには、人事(HR)、財務(FI)、サプライチェーン、顧客管理(CRM)、ビジネスウェアハウス、その他の多くの幅広いデータが含まれており、ランドスケープ全体で、これらのデータを取り扱う 1 つのアプリケーションセットになっていると言えます。
そのため、アプリケーション開発者やアーキテクトにとって、SAP ランドスケープが保持する資産(データ)とそれに接続する必要のあるアプリケーションとの間のインテグレーションを定義する場合に、管理が非常に困難になるという異質性が生じます。

上記インテグレーションを作成して利用するための従来型のアプローチは、常に ESB (Enterprise Service Bus) または EAI (Enterprise Application Integration) パターンに基づいていました。
インテグレーションプラットフォームは ESB、EAI 両方のモデルに従って作成できますが、インテグレーションが抽象化出来ない点が 1 つの大きな問題です。
これにより、各種アプリケーション向けに再利用可能なコンポーネントを実装することが非常に難しくなり、その結果、移植性も保守性も低くなり、非常にアドホックな実装になります。
SAP の歴史的なインテグレーションプラットフォームである SAP PI/PO (以前の SAP XI) は、ESB および EAI のパターンに従っています。

ESB および EAI パターンは、その性質上、クラウドベースのアプリケーションとのやり取りにはあまり適していません。
クラウドネイティブなデプロイは明らかに現在の開発スタイルのトレンドであるため、企業が自社のアプリケーションを SAP バックボーンとインテグレーションする方法を見直す必要があります。
さらに、マイクロサービスはよりモジュラーアプローチを提供するため、広く採用されています。
また、プロセスがより小さい部品に分割されるため、そのうちの 1 つに障害が発生すると、プロセス全体が停止します。

これらのことはすべて、再利用性、抽象化、一般化、および高移植性の方向性に向かっている事を示しています。
また、これらの特性は、インテグレーションのための API ファーストのアプローチに含まれています。
API ファーストのアプローチでは、実行する必要のある関数を呼び出す API を最初に定義し、それが完了したら、実際のコードを記述します。
このモデルは、一連の API のみが提供されるため、開発者とユーザーにとって非常に便利です。
実装の詳細は抽象化されており、アプリケーションまたは記述中のコードからの呼び出しを記述するだけで済みます。
そのため、プラットフォーム間の移植性が向上するため、オンプレミスまたは最初に作成された場所とは異なるクラウドでインテグレーションを使用する場合に、再定義をする必要はありません。

2027 年までに SAP S/4HANA に移行する必要があることを考えると、API ファーストのアプローチに基づく統合プラットフォームを使用することの重要性はさらに大きくなります。
その根拠の 1 つは、"コアをクリーンに保つ" 必要があることです。
つまり、コアにカスタムコードは作成しないようにするということです (これまで SAP のバージョンアップを面倒なものにしていた原因です)。
これを実現するには、顧客はすべての独自のデプロイメント (カスタムコード) を外部に移動する必要がありますが、 (別の場所で作成された新しいデプロイメントは) SAP コアに接続してデータを交換する必要があります。

S/4 HANA への移行をまだ実行していないお客様でも、SAP からカスタムコードを抽出し (抽出してみると、ほとんどの場合、既に使用されなくなっているか、コード内に多数の無駄な部分が見つかると思います)、外部に移動することでメリットが得られます。
事前にこれらの対応を行うと、移行プロセスが大幅に高速化され、プロジェクトリスクが軽減されます。

図 1 は、SAP 向けの API マネジメントプラットフォームを作成するべき理由と、その概要図を示しています。

サテライトシステム (周辺システム) は、SAP からのデータを使用するさまざまなアプリケーションをホストします。
また、サテライトシステム (周辺システム) は、 SAP システムのデータ構造の詳細を知る必要はありません。

ソリューションの実装

Red Hat OpenShift をベースとしたインテグレーションプラットフォームにより、お客様はすべてのレガシーアプリケーションを OpenShift に移行し、Red Hat OpenShift クラスターですべての新しいデプロイを行うことができます。
これは、現在のもう 1 つのトレンドである、アプリケーション開発のモダナイゼーションの必要性とも一致しています。

Red Hat Integration は、SAP アプリケーションと非 SAP アプリケーションの統合を可能にする一連のテクノロジーを提供します。
このブログで紹介するソリューションで使用される主なテクノロジーは Red Hat Fuse です。
Red Hat Fuse は Apache Camel に基づいており、 SAP の主要なプロトコル (RFC、OData、iDocs など) が使用できる特定のコンポーネントを備えています。
また、SAP の機能とデータ構造を API として公開し、さまざまなサードパーティアプリケーションで使用されるフォーマットと SAP で使用されるフォーマットとの間の構造変換を実行できます。

もう 1 つの主要コンポーネントは、API ゲートウェイとして機能する Red Hat 3scale API Management で、SAP と連携する必要があるアプリケーション群の単一の窓口になります。
IT ランドスケープ全体で必要なすべての API をインベントリとして保持し、Role Based Access Control (RBAC) 機能により、API の使用許可があるアプリケーションのみが API を呼び出せるようにします。
また、各 API の使用状況を追跡することもできます。

図2：Red Hat Fuse と Red Hat 3Scale によるインテグレーションイメージ

API マネジメントプラットフォームのユースケースご紹介

API ベースのインテグレーションプラットフォームで実現できるいくつかのシナリオをご紹介します。

ケース 1：発注書 (PO) の詳細情報を取得するなど、SAP 内で Function を実行する必要があるアプリケーションでの利用例

アプリケーションは API ゲートウェイに接続し、API を使用して PO の詳細を取得するように要求します。
アクセスが許可されている場合、API ゲートウェイ (Red Hat 3Scale) は、アプリケーションから受け取ったパラメーターを使用して API Call をデータインテグレーションコンポーネント (Red Hat Fuse) に転送します。
データインテグレーションコンポーネントは、アプリケーションからの要求を SAP 向けのフォーマットに変換し、SAP システムへのRemote Function Call (RFC) 接続を行います。
PO を取得するプロセスは、Business API (BAPI) を実行することによってトリガーされます。
その後、情報は API ゲートウェイを介して要求元のアプリケーションに送り返されます。

ケース 2：SAP バックエンドのデータ構造に直接アクセスする必要があるアプリケーションでの利用例

最初に、API ゲートウェイに接続し、必要な API を呼び出します。
アプリケーションが API の使用を許可されている場合、要求はデータインテグレーションに渡され、次に要求元のアプリケーションがデータにアクセスしようとしている SAP クライアントへのアクセス許可があるか、追加のセキュリティチェックを実行します（このチェックを実装するために、認証テーブルを持つ追加データベースが Red Hat Openshift にデプロイされています）。
チェック後、クエリは OData 形式に変換され、SAP に送信されます。データが取得されると、データインテグレーションは API ゲートウェイを経由して要求元のアプリケーションにデータを送り返します。

もう一つの興味深いユースケースは、SAP BW システムのビジネスインテリジェンス用データを頻繁に利用するアプリケーションです。
この種のシステムで使用されるクエリは高負荷であり、パフォーマンスの問題を引き起こす可能性があるため、SAP バックエンドの処理ボトルネックを回避するためにキャッシュ機能を実装することが良い解決策となります。

ケース 3：ソース (非SAP) とターゲット (SAP) のアプリケーション間のファイル/メッセージ操作での利用例

このシナリオではよりシンプルな実装にするために、API ゲートウェイは使用していません。
また、アプリケーションは Red Hat Integration に付属する JDBC/ODBC コネクタを使用し、Python OData ライブラリ（GitHub - SAP/python-pyodata: Enterprise-ready Python OData client）を使用して SAP システムに直接接続できるようにしています。
アプリケーションがコネクタにリクエストを送信すると、まずリクエストされたデータが Red Hat OpenShift クラスターに展開されたキャッシュデータベース（PostgreSQL）にすでに存在するかどうかを確認します。
もしそうであれば、アプリケーションに直ちにデータを送り返し、そうでなければ、クエリーは OData 形式で SAP システムに送信されます。
そして、その結果を DB に格納し、アプリケーションに送り返します。

ケース 4：可搬性が低く、アドホックなファイル交換処理のレガシーバッチ操作を Red Hat Fuse に置き換える利用例

この例では、サードパーティアプリケーションや SAP は、従来のように限られたワークフローにしか使えない複雑なロジックを使用する必要はありません。
Red Hat Fuse が必要なすべてのファイル操作を処理するので、サードパーティアプリケーションや SAP は、それぞれのアプリケーション独自のフォーマットで互いにファイルを送受信することができます。

図6：Red Hat FuseのAPIを利用して変換された請求書を処理するバッチ処理の例

まとめ

SAP と非 SAP アプリケーションの統合は、まだレガシー SAP システムを利用していて SAP S/4HANA への移行を準備しているお客様にとっても、すでに移行を完了したお客様にとっても、非常に重要なテーマです。
どちらの場合も、SAP バックエンドは他の多くのアプリケーションと相互に連携する必要があり、その数は時間とともに急速に増加していくため、より柔軟で俊敏な方法で展開する必要があるとともに、管理が容易であらゆる種類のインテグレーションを提供できるプラットフォームが必要とされています。

Red Hat Integration on OpenShift は、これらのシナリオを網羅的にカバーします。
SAP と非 SAP アプリケーション間のインテグレーションを実現する方法を提供し、API に基づいているため、再利用可能でメンテナンスが簡単です。
更に、SAP に接続する必要のあるすべてのアプリケーションを開発・実行するためのプラットフォームを提供し、DevOps の方法論にそったクラウドネイティブな手法やマイクロサービスの利用を可能にします。
これにより、企業はアプリケーションの開発サイクルを短縮し、より柔軟な対応が可能になります。