はじめに

この記事は chillSAP 夏の自由研究2021 の記事として執筆しています。

前回の記事で、Event Meshの概要とAPIの使い方について紹介しました。今回はCAPを使ってメッセージを送受信してみたいと思います。
CAPを使うとEvent Meshとの統合が簡単にできます。今回は以下のようなシナリオを実装します。

CAPからEvent Meshのトピックにメッセージを送信する
送信したメッセージをCAPのイベントハンドラで受け取る

自分で送信して自分で受信とは変な感じですが、簡単にするために1つのサービスにしています。

前提

Event Meshはトライアル版(dev)を使い、サービスインスタンスの作成まで完了させておきます。
サービスインスタンスの作成方法については、前回の記事をご参照ください。

ステップ

CAPのプロジェクトを作成
Event Meshを使うための設定
送信用のイベントハンドラを作成
受信用のイベントハンドラを作成
デプロイ

1. CAPのプロジェクトを作成

以下のコマンドでCAPのプロジェクトを作成します。プロジェクト名はcap-emとしました。

cds init cap-em

必要なモジュールをインストールします。

npm install

2. Event Meshを使うための設定

以下のモジュールをインストールします。

npm i @sap/xb-msg-amqp-v100

package.jsonに以下の設定を追加します。

  "cds": {
    "requires": {
      "messaging": {
        "kind": "enterprise-messaging-shared"
      }
    }
  }

ローカル実行用の設定として、プロジェクトのルートにdefault-env.jsonファイルを作成します。まず、以下のような構造を作ります。

{
	"VCAP_SERVICES": {
		"enterprise-messaging": [
			{
				"label": "enterprise-messaging",
				"credentials": {}
			}
		]
	}
}

次に、credentialsの中にEvent Meshのサービスキーの中身をコピーして貼り付けます。最終的に以下の形になります。

{
	"VCAP_SERVICES": {
		"enterprise-messaging": [
			{
				"label": "enterprise-messaging",
				"credentials": {
					"xsappname": "clone-xbem-service-broker-3b8f5738face419d89ace9a895e2e28e-clone!b54386|xbem-service-broker-!b2436",
					"management": [
						{
							"oa2": {
								"clientid": "xxxx",
								"clientsecret": "xxxx",
								"tokenendpoint": "https://b736177ctrial.authentication.eu10.hana.ondemand.com/oauth/token",
								"granttype": "client_credentials"
							},
							"uri": "https://enterprise-messaging-hub-backend.cfapps.eu10.hana.ondemand.com"
						}
					],
					"serviceinstanceid": "3b8f5738-face-419d-89ac-e9a895e2e28e",
					"messaging": [
						{
							"oa2": {
								"clientid": "xxxx",
								"clientsecret": "xxxx",
								"tokenendpoint": "https://b736177ctrial.authentication.eu10.hana.ondemand.com/oauth/token",
								"granttype": "client_credentials"
							},
							"protocol": [
								"amqp10ws"
							],
							"broker": {
								"type": "sapmgw"
							},
							"uri": "wss://enterprise-messaging-messaging-gateway.cfapps.eu10.hana.ondemand.com/protocols/amqp10ws"
						},
						{
							"oa2": {
								"clientid": "xxxx",
								"clientsecret": "xxxx",
								"tokenendpoint": "https://b736177ctrial.authentication.eu10.hana.ondemand.com/oauth/token",
								"granttype": "client_credentials"
							},
							"protocol": [
								"mqtt311ws"
							],
							"broker": {
								"type": "sapmgw"
							},
							"uri": "wss://enterprise-messaging-messaging-gateway.cfapps.eu10.hana.ondemand.com/protocols/mqtt311ws"
						},
						{
							"oa2": {
								"clientid": "xxxx",
								"clientsecret": "xxxx",
								"tokenendpoint": "https://b736177ctrial.authentication.eu10.hana.ondemand.com/oauth/token",
								"granttype": "client_credentials"
							},
							"protocol": [
								"httprest"
							],
							"broker": {
								"type": "saprestmgw"
							},
							"uri": "https://enterprise-messaging-pubsub.cfapps.eu10.hana.ondemand.com"
						}
					]
				}
			}
		]
	}
}

3. 送信用のイベントハンドラを作成

srvフォルダ配下にcatalog-service.cdsファイルを作成します。

catalog-service.cds

service CatalogService {
    type Message {
        id: Integer;
        message: String;
    }
    action send(message: Message)
}

srvフォルダ配下にcatalog-service.jsファイルを作成し、sendアクションが呼ばれたときのイベントハンドラを実装します。ここでは"topic1"というトピックに対してメッセージを送信しています。

catalog-service.js

module.exports = async function () {
    const messaging = await cds.connect.to("messaging")
    this.on('send', async (req) => {
        console.log(JSON.stringify(req.data))
        messaging.emit("topic1", req.data.message)
    })
}

テスト実行

cds watchコマンドでサービスを起動します。
コマンドラインに以下のように表示されれば、Event Meshに接続できています。

VS Codeの拡張であるREST Clientを使ってテストをしてみます。以下のようにテスト用のファイルを作成します。

test.http

POST http://localhost:4004/catalog/send
Content-Type: application/json

{
	"message": {
		"id": 100,
		"message": "hello"
	}
}

"Send Request"の文字をクリックしてリクエストを送信します。右側が結果です。

コンソールには以下のように、送信したメッセージの内容が表示されます。

4. 受信用のイベントハンドラを作成

メッセージを受信したときに動くイベントハンドラを作成します。catalog-service.jsに以下のコードを追加します。"topic1"に受信したメッセージを表示するだけのシンプルな処理です。

module.exports = async function () {
    const messaging = await cds.connect.to("messaging")
    this.on('send', async (req) => {
        console.log(JSON.stringify(req.data))
        messaging.emit("topic1", req.data.message)
    })

    //add
    messaging.on('topic1', async(msg)=> {
        const messagePayload = JSON.stringify(msg.data)
        console.log('===> Received message : ' + messagePayload)       
    })
}

cds watchを実行すると、コンソールに以下のように表示されます。これは、"CAP/0000"というキューと、"topic1"に対するキューサブスクリプションが登録されたことを表しています。
そして、さきほどsendアクションで送信したメッセージを受信しています。

メッセージの内容を少し変えて送信してみます。

{
    "message": {
        "id": 101,
        "message": "hello"
    }
}

Event MeshのAPIを使ってメッセージを送信

前回の記事でやったように、APIを使ってメッセージを送ってみます。

受信したメッセージがundefinedになってしまいました。

そこで、イベントハンドラを以下のように変えてみます。

    messaging.on('topic1', async(msg)=> {
        const messagePayload = JSON.stringify(msg.data)
        console.log('===> Received message (body) : ' + messagePayload)

        const messageHeader = JSON.stringify(msg.headers)
        console.log('===> Received message (header) : ' + messageHeader)
               
    })

ヘッダにメッセージを受信していました。

sendアクションでCAPからメッセージを送った場合は以下のようになります。なぜこのような違いがあるのかはわかりませんが、ヘッダ、ボディ両方にメッセージが来るケースを想定しておいたほうがよさそうです。

CAPで使用するキューについて

受信用ハンドラを定義した場合、キューはデプロイ時に自動で登録されます。よって、キューをマニュアルで登録する必要はありません。"CAP/0000"というキューはローカル実行用のキューで、デプロイすると本番用のキューが別途登録されます。

※自動登録されたキューではなく独自のキューを使いたい場合は、以下のブログが参考になります。
CAP – Specifying the queues to be consumed from SAP Event Mesh

5. デプロイ

以下のコマンドでmta.yamlファイルを生成します。

cds add mta

resourcesセクションにEvent Meshのサービスインスタンス（登録済のもの）を指定し、サービスのrequiresセクションにも同じものを追加します。

_schema-version: '3.1'
ID: cap-em
version: 1.0.0
description: "A simple CAP project."
parameters:
  enable-parallel-deployments: true
   
build-parameters:
  before-all:
   - builder: custom
     commands:
      - npm install --production
      - npx -p @sap/cds-dk cds build --production

modules:
 # --------------------- SERVER MODULE ------------------------
 - name: cap-em-srv
 # ------------------------------------------------------------
   type: nodejs
   path: gen/srv
   parameters:
     buildpack: nodejs_buildpack
   provides:
    - name: srv-api      # required by consumers of CAP services (e.g. approuter)
      properties:
        srv-url: ${default-url}
   requires:
    - name: em-test #add

resources:
 - name: em-test #add
   type: org.cloudfoundry.existing-service

以下のコマンドでビルド、デプロイします。

mbt build
cf deploy mta_archives/cap-em_1.0.0.mtar

デプロイ後、cf logs cap-em-srv --recentでサービスのログを表示すると、登録されたキュー名を見ることができます。

キュー名はcap-em-srv/8974となり、8974の部分は何かといえば、登録されたアプリケーションIDの先頭4桁のようです。

参考