Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Showing results for 
Search instead for 
Did you mean: 
kyoneo
Advisor
Advisor

はじめに


本ブログではSAP Business Technology Platformで利用可能なSAP Event Meshの概要と、簡単なデモをご紹介いたします。本ブログをお読みいただくことで、SAP Event Meshが非同期な通信を実現する仕組みと、その利用方法をご習得いただけます。また、ご紹介する手順はトライアル環境でもお試しいただくことが可能です。

前提知識


前提知識がなくても、本ブログの内容はご理解いただけるようになっています。プログラミングを行う手順もございません。

目次





    1. SAP Event Meshとは

      1. 概要

      2. 仕組み



    2. デモ準備

      1. バッキングサービスのセットアップ

      2. キューとトピックの作成

      3. サービスキーの作成



    3. デモ

      1. クレデンシャル情報のセット

      2. トピックへの送信

      3. キューからの取り出し






1. SAP Event Meshとは


1-1. 概要


SAP Event Mesh(Event Mesh)は、SAP Business Technology Platform(SAP BTP)が提供するバッキングサービスの1つで、SAPの製品やサービス、サードパーティのアプリケーションと非同期な連携を実現するためのメッセージブローカーを提供するフルマネージドサービスです。



Event Meshを利用することで、以下のようなメリットがあります。

イベント駆動型アーキテクチャの実現


Event Meshを用いたシステム連携は、すべてメッセージブローカーを経由したイベントドリブン方式の通信(非同期通信)になります。つまり、送信元のシステムの責務はそのブローカーにメッセージを送ることとなり、送信先の状態を気にする必要がなくなります。リクエストリプライ方式(同期通信)と比較すると、連携システム同士の依存性の削減のほか、応答性の向上にも効果があります。さらに、Event Meshなどのメッセージングサービスでは送信されたメッセージがブローカーに一時的に(連携先が受け取るまで)保存されるため、高い弾力性も保持します。

SAP Event Meshを活用し、システム同士が非同期に連携するイベント駆動な設計を実現することで、システムが疎結合となり、拡張性や保守性の向上にも寄与します。

規模に応じたスケーラブルな設計の実現


送信元から送信されたメッセージを保存するキューがブローカー側にあるため、連携先のシステムはリソースの使用率などに応じた独立したスケーリングが容易に実現できます。

1-2. 仕組み


Event Meshが提供するメッセージブローカーには"キュー"と"トピック"が含まれていて、この2つの仕組みを用いて非同期なメッセージのやり取りを実現します。

キュー


キューは送信先のシステムと一対一で対応するコンポーネントで、送信元から送られたメッセージを順番に保管する役割を持ちます。送信先のシステムがリクエストすることで、First-In First-Outでメッセージを送ります。送信先のシステムがリクエストするまでキューはメッセージを溜め続け、取り出された順から削除していきます。

Queue

トピック


トピックは送信先と一対多で対応するコンポーネントで、送信元からメッセージが送られると、それをアクティブな受信者に対してパブリッシュする役割を持ちます。トピック自身はメッセージを保持しないため、何かしらの理由でパブリッシュ時に非アクティブだった受信者はメッセージを受け取ることができません。

Topic

キューサブスクリプション


Event Meshではトピックにキューを紐付けたキューサブスクリプションを組むことができます。これにより、1つの送信側システムに対して複数の送信先システムに対応した、非同期で信頼性の高いシステム連携を実現します。

Queue Subscription

 

トピックへのメッセージの送信、キューからの取り出しはAMQP、MQTT、REST APIなどのプロトコルで実行することができます。

2. デモ準備


早速、Event Meshをデモをしてみたいと思います。今回はアプリケーションからの連携は行わず、Postmanを用いてAPIを叩いて、メッセージが非同期でやり取りされる仕組みをご紹介します。

2-1. バッキングサービスのセットアップ


SAP BTP cockpitにアクセスし、Service Marketplaceから”Event Mesh”で検索し、サービスが見つかったら画像のようにCreateをクリックしてください。

※もしService MarketplaceでEvent Meshが見つからない場合は、サブアカウントにEntitlementを追加してください。(Entitlementの追加方法はこちらのブログポストのStep1. – Step8.をご参照ください。)


ここから先は商用アカウントとトライアルアカウントで手順が異なるため、ご利用のアカウントに対応する手順をご覧ください。

商用アカウントでの手順


インスタンス/サブスクリプション作成画面が表示されます。ここでPlanを選択すると、インスタンス用プランとしてのdefault、サブスクリプション用プランとしてのstandardの2つがあることが分かります。defaultプランはメッセージブローカーを提供するサービスインスタンスを、standardプランはGUIでメッセージブローカーの管理が可能なダッシュボードを提供します。Event Meshの利用には両方必要となるので、どちらも作成します。



サービスインスタンス作成


まずはサービスインスタンスを作成します。Planでdefaultを選択すると入力欄が出てくるので、作成先のスペース名とお好きなインスタンス名を入力してください。(インスタンス名は後述するemnameを意識した名前をつけると後で管理しやすいかもしれません。)


インスタンスパラメータの設定画面が出てくるので、以下のように入力します。<>がついている部分は後述のパラメータの説明をご覧いただき、任意の名前を入れてください。
{
"emname": "<messageclientname>",
"namespace": "<region>/<applicationNamespace>/<uniqueID>",
"version": "1.1.0",
"options": {
"management": true,
"messagingrest": true,
"messaging": true
},
"rules": {
"queueRules": {
"publishFilter": [
"${namespace}/*"
],
"subscribeFilter": [
"${namespace}/*"
]
},
"topicRules": {
"publishFilter": [
"${namespace}/*"
],
"subscribeFilter": [
"${namespace}/*"
]
}
}
}

パラメータはそれぞれ以下のような意味を持ちます。パラメータのより詳細な意味を知りたい方はこちらのSAP Helpをご覧ください。

  • emname:作成するメッセージブローカーを一意に特定するための名前です。前述のインスタンス名がSAP BTP上でインスタンスを一意に特定するための名前であるのに対して、こちらは前述の管理用ダッシュボード上で使われる名前になります。

  • namespace:キューやトピックに外部からアクセスする際に用いる名前空間です。以下のガイドラインに従って設定する必要があります。

    • サブアカウント内でユニークであること。

    • 3つのセグメントから成ること。(例:a/b/c)

    • (推奨)"<region>/<applicationNamespace>/<uniqueID>"の構成に従うこと。

      • region:"default"が推奨とされています。

      • application namespace:mycompany.myapp.mysubappのようなトップドメインを除いた名前空間が推奨になります。

      • uniqueID:インスタンス間でユニークになるような数字にします。





  • options:メッセージブローカーの機能の有効化設定になります。

    • management:管理用APIへのアクセスを許可します。(初期値:false)

    • messagingrest:REST APIを用いたメッセージの送受信を許可します。(初期値:false)

    • messaging:メッセージングプロトコル(AMQP、MQTT)を用いたメッセージの送受信を許可します。(初期値:true)



  • rules:キューとトピックに対して送受信システムからのアクセスを許可するかどうかを設定します。フィルタ条件に合致するキュー、フィルタは外部からのアクセスが許可されます。上記の設定例では、ワイルドカードで全てのキュー、トピックに対してアクセスが許可されています。


パラメータを入力したら、Createをクリックしてください。


以上でインスタンス作成は完了です。

サブスクリプション


Event Meshのインスタンス/サブスクリプション作成画面に移動し、今度はサブスクリプションを作成します。standardプランを選択してCreateをクリックするだけでOKです。


以上で商用アカウントでのバッキングサービスの準備は完了です。

トライアルアカウントでの手順


商用アカウントと異なり、インスタンス/サブスクリプション作成画面でPlanを選択すると、インスタンス用プランとしてdefaultプランではなくdevプランが用意されています。devプランでは細かいパラメータの指定ができず、管理用ダッシュボードもサービスインスタンスから直接アクセスする形になります。


インスタンスパラメータの設定画面では、以下のように入力します。ご覧の通り、namespaceやrulesの指定はできないようになっています。


Createをクリックしてサービスインスタンスを作成したら、トライアルアカウントでのバッキングサービスの準備は完了です。

2-2. キューとトピックの作成


作成したサービスインスタンス(メッセージブローカー)に対して、キューとトピックを作成します。ダッシュボードからGUIを用いて作成できるほか、Management APIを叩いて作成することもできます。本ブログではダッシュボードで作成する方法をご紹介します。Management APIについて知りたい方はこちらのドキュメントをご参照ください。

※Management APIを実行するには後述のサービスキーに記載のURLとクレデンシャル情報が必要になるため、先にサービスキーを作成してください。

ダッシュボードへのアクセス


商用アカウントの場合は作成したサブスクリプションから、トライアルアカウントの場合はサービスインスタンスからダッシュボードにアクセスできます。

(2022/6/29追記)

ダッシュボードへのアクセスには以下のロールが必要になりますので、あらかじめユーザに追加しておいてください。

  • Enterprise Messaging Administrator


商用アカウント画面




トライアルアカウント画面



 

ここからは商用アカウントでの画面を用いて解説を続けます。ダッシュボードにアクセスすると作成したメッセージブローカー(サービスインスタンス)が並んでいるMessage Clientsページが現れ、その中に先ほど作成したメッセージブローカーが確認できます。


※Message Clientsはメッセージブローカーと同じ意味になります。

キューの作成


上記のMessage Clientsページで対象のメッセージブローカーをクリックすると詳細ページに飛びます。Queueタブに移動し、Create Queueをクリックして、キュー作成画面を開きます。



キュー作成画面ではキュー名に任意の名前を入力して、後はデフォルトのままCreateをクリックしてキューを作成してください。


キューが作成されたことが確認できます。


キューの作成は以上です。

トピックの作成


トピックは前述のキューサブスクリプションを作成する手順の中で、キューと紐づける形で作成します。

先ほど作成したキューからQueue Subscriptionsをクリックします。


トピック作成画面が開くので、トピック名を入力してトピックを作成します。トピック名は画像のようにnamespaceを含めた形で入力してください。


Addをクリックするとキューに紐づく形でトピックが作成されたことが確認できます。


以上でトピックの作成と、キューサブスクリプションの作成は完了です。

テスト


作成したキューとそれに紐づくトピックに対してダッシュボードからテストを行うことができます。Testタブに移動すると、テスト画面が現れます。



Publish Messages側には送信先のトピックとそのメッセージ、Consume Messages側にはメッセージを取り出すキューを指定します。画像のように先ほど作成したトピックとキューを指定してください。Publish Messageをクリックするとトピックにメッセージが送信され、Consume Messageをクリックすると、キューからメッセージを取り出します。


Consume Messages側でトピックに送信したメッセージが受け取れたので、トピックとキューが問題なく連携できていることが分かります。


このように、step-by-stepで確認しながら開発を進めていくことができます。

2-3. サービスキーの作成


キューとそれに紐づくトピックのテストまで実行したので早速デモ、といきたいところですが、最後の準備としてサービスキーの作成を行います。アプリケーションをEvent Meshを連携させる場合はサービスインスタンスをバインドさせるだけでOKですが、次のデモではPostmanを使って外部からAPIを叩くため、サービスキーが必要になります。

SAP BTP Cockpitから作成したサービスインスタンスを選び、Create Service Keyをクリックします。


サービスキー作成画面では、任意のサービスキー名を入力してCreateをクリックしてサービスキーを作成します。


少しするとStatusがCreatedとなり、サービスキーが出来上がります。Viewをクリックして中身を見てみましょう。


サービスキーの中身は以下のようなクレデンシャル情報がJSON形式で記載されています。
{
"xsappname": "<app-name>",
"serviceinstanceid": "<instance-id>",
"messaging": [
{
"oa2": {
"clientid": "<client_id>",
"clientsecret": "<client_secret>",
"tokenendpoint": "https://<app-url>/oauth/token",
"granttype": "client_credentials"
},
"protocol": ["amqp10ws"],
"broker": {
"type": "sapmgw"
},
"uri": "wss://<app-url>/protocols/amqp10ws"
},
{
"oa2": {
"clientid": "<client_id>",
"clientsecret": "<client_secret>",
"tokenendpoint": "https://<app-url>/oauth/token",
"granttype": "client_credentials"
},
"protocol":["mqtt311ws"],
"broker": {
"type": "sapmgw"
},
"uri": "wss://<app-url>/protocols/protocols/mqtt311ws"
},
{
"oa2": {
"clientid": "<client_id>",
"clientsecret": "<client_secret>",
"tokenendpoint": "https://<app-url>/oauth/token",
"granttype": "client_credentials"
},
"protocol": ["httprest"],
"broker": {
"type": "saprestmgw"
},
"uri": " https://<app-url>/"
}
],
"management": [
{
"oa2": {
"clientid": "<client_id>",
"clientsecret": "<client_secret>",
"tokenendpoint": "https://<app-url>/oauth/token",
"granttype": "client_credentials"
},
"uri": " https://<app-url>/"
}
]
}

このクレデンシャル情報のうち、messagingとmanagementが重要なセクションになります。

messagingセクションにはプロトコル別のクレデンシャル情報が記載されています。後続のデモではPostmanを用いてREST APIでメッセージの送受信を行うので、messagingセクションの3番目、protocolが["httprest"]となっているセクションのクレデンシャル情報を用いることになります。

managementセクションは前述のManagement API用のクレデンシャル情報が記載されています。Management APIを用いてキューやトピックの作成を行う場合はこのクレデンシャル情報を利用します。

以上でサービスキーの作成は完了です。

3. デモ(Postman)


ではPostmanを使ってEvent Meshを使ってみたいと思います。

3-1. クレデンシャル情報のセット


まずはサービスキーのクレデンシャル情報をPostmanに登録します。Postmanの詳細な利用手順は本ブログでは省きますが、画像のようにCollectionのAuthorizationにセットしておくと、トークンを使いまわせるので楽です。

Configure New Tokenでは、Grant TypeをClient Credentialsにし、Access Token URL、Client ID、Client Secretにそれぞれ作成したサービスキーのtokenendpoint、clientid、clientsecretをコピー&ペーストしてください。前述の通りREST APIでの通信になるので、messagingセクションの3番目、protocolが["httprest"]となっているセクションのクレデンシャル情報をコピーしてきてください。


Get New Access Tokenをクリックすると、トークンが発行されます。

3-2. トピックへの送信


トピックへはPOSTリクエストでメッセージを送信します。URL、ヘッダ、ボディは以下のように設定します。

  • URL:<サービスキーのuri>/messagingrest/v1/topics/<トピック名>/messages

    • トピック名(namespace含む)がdefault/sap.demoAppForBlog/1/demoTopicだった場合、<トピック名>は次のようになります。("/"を"%2F"に置き換えてください。)

    • default%2Fsap.demoAppForBlog%2F1%2FdemoTopic



  • HTTP Header

    • x-qos:0 or 1

      • 0の場合:1回だけメッセージを送る。受信確認をしない。

      • 1の場合:受信確認をとることで、最低でも1回メッセージを送ることを保証する。



    • authorization:Bearer <先ほど取得したトークン>



  • HTTP Body:送りたい任意のメッセージ。(メッセージタイプはrawを選択)



Sendをクリックすると、ステータスコード204がレスポンスで返ってきます。これでEvent Meshのキューにメッセージが格納されたことになります。次はそのメッセージを取り出してみましょう。

3-2. キューからの取り出し


キューからの取り出しもPOSTリクエストになります。GETじゃないの?と思う方もいらっしゃるかと思いますが、キューの状態を変更するリクエストなのでPOSTになるのだそうです。URL、ヘッダ、ボディは以下のように設定します。

  • URL:<サービスキーのuri>/messagingrest/v1/queues/<キュー名>/messages/comsumption

    • キュー名(namespace含む)がdefault/sap.demoAppForBlog/1/demoQueueだった場合、<キュー名>は次のようになります。("/"を"%2F"に置き換えてください。)

    • default%2Fsap.demoAppForBlog%2F1%2FdemoQueue



  • HTTP Header

    • x-qos:0 or 1

    • authorization:Bearer <先ほど取得したトークン>



  • HTTP Body:何も入力しない。



Sendをクリックすると、ステータスコード200と共にメッセージが送られてきます。画像のように、JSON形式のデータをやり取りすることもできます。


このように、Event Meshを利用することで非同期にメッセージのやり取りを行うことができます。Postmanを使ったEvent Meshのデモは以上になります。

おわりに


本ブログではSAP Business Technology Platformが提供するバッキングサービスの1つである、SAP Event Meshについてその仕組みとサービスの作成方法、Postmanを用いたデモをご紹介しました。

次回のブログではCloud Application Programming Model(CAP)やSAP Integration SuiteからのEvent Meshの利用方法についても触れていこうと思います。

ご質問やご不明点がございましたら、ぜひこちらからQ&Aをご投稿ください。

参考リンク