｢Side by Side開発｣をBTPにて実施するメリット

# はじめに

本記事は「[SAP Side by Side開発の基本的なことまとめ](https://qiita.com/Yanagawa_Yoshihisa/items/4dd3694800576e094b0a)」の1項目の説明をなります。全体を把握した方はまずはそちらをご確認下さい。

また、本記事は概要把握や個人とトライアル利用の参考として、まとめたものなので、プロジェクトでの利用の際は、SAP社への問合せの実施や正式情報である[Help Portal](https://help.sap.com/docs/)を活用して下さい。

# ｢Side by Side開発｣をBTPにて実施するメリット
｢****[S/4HANAにおける追加要件の実装手段の整理](https://qiita.com/Yanagawa_Yoshihisa/items/b324316ef3c3ac9ff0d9)****｣にて、｢**Side by Side開発**｣の実施プラットフォームとしては、BTPとそれ以外に大別できると説明させて頂きました。当然それを知ると、その使い分けに関して興味をもつ方もおられると思います。そこで本記事では、｢Side by Side開発をBTPにて実施するメリット｣について説明させて頂きます。

私としてはBTP上にて、｢**Side by Side開発**｣をするメリットは大きく分けて3つあると考えます。

- SAP製品との接続を前提とした開発ツールが利用可能
- SAP製品のビジネスプロセスを前提とした事前定義が利用可能
- ｢Cloud Connector｣を利用しオンプレミス系のシステムとの接続が可能

それでは1項目づつ説明していきましょう。

# SAP製品との接続を前提とした開発ツール

（テクニカルな表現のタイトルを避けたかったため、このように表現をつかいましたが、IT的な表現を用いると、SDK(Software Development Kit)やフレームワークのことです）

まず、前提として、これらはBTPをカスタム開発の基盤として活用する場合に当てはまります。（BTP上でのアプリケーション開発・稼働とIaaSサーバ上でのアプリケーション開発・稼働の対比をイメージして下さい。）

カスタム開発をする際に、工数削減やリスク軽減のためにも、記述するコードの量は少ない方がよく、何度も実行される表現は共通化・パッケージ化することはカスタム開発における常識だと思います。この共通化の観点から、BTP上でアプリケーションを動作させ、SAP社の製品に接続させることを前提とした開発ツール（SDKやフレームワーク）がSAP社から提供されています。

これにより、SAP製品との接続の設定、認証の設定、APIコールなどの共通化され、BTPの方が開発工数を削減できるとともに、不具合を発生させるリスクを軽減します。
具体的な技術要素としては、｢**SAP Cloud SDK**｣のようなSDKや、｢**SAP Cloud Application Programming Model(CAP)**｣となります。

# SAP製品のビジネスプロセスを前提とした事前定義
まず、前提として、これらはBTPをIntegrationやワークフローなどのPaaS基盤として活用する場合に当てはまります。（BTPをEAIとして利用する場合と、他のEAIツール（DataSpider等）を利用する場合の対比をイメージして下さい。）

こちらはPaaS上での何らかの開発を実施する際に、そのひな形となるような事前定義があらかじめ準備されているという利点です。

例えば、SAPの得意先マスタとセールスフォースの同種のマスターの連係をEAI上で定義しようとすると、双方のデータIFに関わる構造を定義し、SAPのマスタとセールスフォースのマスタの項目を見比べた上で、マッピングの定義やデータ変換の定義をする必要があります。

このような作業の工数を削減するために、汎用のデータ連係に関しては、SAP社が事前定義を提供しており、開発する際は、それらをそのまま利用する（もしくは一部をカスタマイズして利用する）ことが可能です。

これらの対象となる製品はデータ連係基盤である｢**SAP Integration Suite**｣やワークフロー基盤である｢**SAP Build Process Automation**｣になり、その事前定義は「**[SAP API Business Hub](https://api.sap.com/)**」に公開されています。

# ｢Cloud Conector｣を利用したオンプレミスシステムとの接続
｢Cloud Conector｣という製品を利用することにより、オンプレミスシステムのようなプライベートネットワークにあるシステムとBTP間の接続を簡便かつセキュリティリスクを低減するかたちで実現することができます。

一般的にS/4HANAのような基幹システムにおいては、データの漏洩やシステム停止は絶対に避けなければならなく、インフラ・ネットワーク的に安全な場所にあります。それゆえに外部システムからインターネット経由でアクセスする際は、ネットワーク的な考慮が必要になります。（踏み台サーバやDMZ等を構築する必要があります）それらには別のケイパビリティを有するエンジニアが必要で技術的なハードが上がるため、それをさけるために｢Cloud Conector｣を経由した、アーキテクチャをSAP社はリリースしました。

簡単に説明すると、オンプレミス側のネットワーク領域に｢Cloud Connector｣をインストールし、最低限のポート開放等のネットワーク設定を実施した上で、｢Cloud Connector｣に接続先のBTPの情報を入力し接続します。これにより、BTP上で接続先の｢Cloud Connector｣が出現し、そこを宛先として各種のデータ連係処理が可能になります。

かなり説明は簡便にしたため詳しくは[こちら](https://help.sap.com/docs/CP_CONNECTIVITY/cca91383641e40ffbe03bdc78f00f681/e54cc8fbbb571014beb5caaf6aa31280.html?locale=en-US)をご確認下さい。

これらに類似するのですが、オンプレミスシステムではなく、SAP社のクラウド製品との接続においても、接続確立のための仕組みが準備されているため、ネットワーク構築の工数削減やセキュリティリスクの低減を行うことができます。

# Side by Side開発をBTPにて実施するデメリット
最後にデメリットに関しても簡単に言及します。対象製品が広く、比較対象製品も多岐に渡るため、比較はしづらいのですが、全体の傾向として2点を押さえる必要があると思います。

1つ目として、単純な機能比較でだけでいうと、領域のトップ製品は当然BTPよりも高機能になる傾向にあります。（データ連係で言えば、｢Informatica｣の方が、ワークフローであれば｢ServiceNow｣が高機能だと個人的には思います。）

2つ目としては、マネージドサービスであるがゆえに、インフラ的・非機能要件的な自由度は制限されます。ゆえに、厳格なパフォーマンス要件や稼働要件がある場合には、要件対応の難易度が高くなる傾向にあります。

# まとめ
今回は機能面にフォーカスを当てて、メリットを整理しました。これらは機能的な観点から良い要素・悪い要素を整理したものです。｢****[S/4HANAにおける追加要件の実装手段の整理](https://qiita.com/Yanagawa_Yoshihisa/items/b324316ef3c3ac9ff0d9)****｣でもお伝えさせて頂いたように、しっかりと技術を理解し、ユースケースや組織状況応じた判断をして頂ければと思います。
また、こんなメリットもあるのではという点はコメントを頂ければと思います。