FunctionsとAzure Service Bus SDKのメッセージ形式の違い

このエントリは2019/09/26現在の情報に基づくものです。今後の機能追加や変更に伴い、記述内容との乖離が発生する可能性があります。

以前のエントリで後日と表現していた、FunctionsとSDKを混在させた場合についての記述である。以前のエントリはこちら。

Azure Service Busでカスタムプロパティをやりとりする
https://logico-jp.io/2019/09/12/send-and-receive-custom-propeties-through-azure-service-bus/

結論からいうと、
FunctionsのアプリとSDKのアプリ間でメッセージのやりとりはすべきでない
（混ぜては危険）

SDKとFunctionsを混在させる場合

Functionsが期待しているデータ形式と、SDKが期待しているデータ形式が違うので相互接続できない。どう違うのか、Service Bus Explorerを使って確認してみる。なお、Service Bus Explorerは以下を参照。

Azure Service Bus Explorer
https://github.com/paolosalvatori/ServiceBusExplorer

SDKから投げ込んだメッセージ

SDKで投げ込んだ場合、以下のような感じのメッセージになっている。

fromBinaryData()を使った場合

しっかりバイナリメッセージ…。カスタムプロパティには指定した値が正しく格納されていることを確認した。

fromValueData()を使った場合

ValueDataという制約から、POJOをJSONに変換して投げ込むと、Service Busには当然ながらそのままJSONとして格納されていることがわかる。この場合も、カスタムプロパティに指定した値が入っていることを確認できた。

{
  "comments": "test comment",
  "sbMessageBody": {
    "op": "create",
    "data": "textdata",
    "kind": "common:welldb:wellbore:1.0.0",
    "id": "common.welldb:raj25"
  }
}

Functionsから投げ込んだメッセージ

MessageBodyを作成する際に、fromBinaryData()を使う場合はバイナリ、fromValueData()を使うと値（JSON）として内部でパッケージングされる。バインディング時にdataTypeを指定できるが、現時点では設定しても変化しないので注意が必要。また、メッセージはSDKのMessageインスタンスがそのまま流れるわけではなく、MessageをラップしたWebJobsのメッセージとして流れる。そのため、カスタムプロパティもラップされている。

fromValueData()を使った場合

前述の通り、カスタムプロパティは指定した値が正しく格納されているが、ラップされていることがわかる。

{
  "deliveryCount": 0,
  "messageId": "b4471a70-22b8-4c71-ac82-9f6186488e0c",
  "messageBody": {
    "bodyType": "VALUE",
    "valueData": {
      "sbMessageBody": {
        "data": "textdata",
        "id": "common.welldb:raj25",
        "kind": "common:welldb:wellbore:1.0.0",
        "op": "create"
      },
      "comments": "test comment"
    }
  },
  "contentType": "application/octet-stream",
  "sequenceNumber": 0,
  "properties": {
    "account-id": "common",
    "correlation-id": "12345-67890-abcde-fghij-klmno",
    "data-partition-id": "common"
  },
  "correlationId": "12345-67890-abcde-fghij"
}

fromBinaryData()を使った場合

binaryDataとしてバイト配列の各要素が入っている。カスタムプロパティは指定した値が正しく格納されているが、 ラップされていることがわかる。

{
  "deliveryCount": 0,
  "messageId": "4b2b3215-5bc8-4993-89be-29039d604cb7",
  "messageBody": {
    "bodyType": "BINARY",
    "binaryData": [
      [
        -84,
        -19,
        ...
        116,
        101
      ]
    ]
  },
  "contentType": "application/octet-stream",
  "sequenceNumber": 0,
  "properties": {
    "account-id": "common",
    "correlation-id": "12345-67890-abcde-fghij-klmno",
    "data-partition-id": "common"
  },
  "correlationId": "12345-67890-abcde-fghij"
}

で、どうなの？

上記のメッセージを見てわかる通り、以下のような感じ。

• Functions->SDKの場合、
  • SDK側でうまくパースすればメッセージを取得することは理論的には可能
  • Functionsのバインディングを使わずにSDKを使ってService Busに投げ込めば、JSONのパースを考慮せずにメッセージを送信可能だが、わざわざそんなことはしないでしょ。
• SDK->Functionsの場合は不可
• カスタムプロパティは、Functionsを使うとWebJobメッセージの中にラップされる

ということで、混ぜてはいけない、（当然ながら無理にやってもサポートしていないので）お勧めしない、という結論。