Azure Service Bus规则解析JSON负载：New-AzureRMServiceBusRule报400错误

首先，咱们直接说核心问题：你遇到的400错误是因为Service Bus规则引擎的SQL过滤表达式对嵌套JSON的访问语法有特定要求，而你用的body.type不符合这个规范。下面一步步拆解原因和解决方案：

为什么body.type报错，type = 'payment'却能生效？ #

• 当你的消息负载是{header: {...}, body: {type: "payment"}}这种嵌套JSON结构时，Service Bus的规则引擎如果要正确解析JSON属性，需要明确以$作为整个JSON payload的根节点标识。直接写body.type会被引擎误认为是在访问一个名为body的顶级系统属性，而不是你JSON payload里的嵌套body对象，自然会返回400错误。
• 至于type = 'payment'能生效，大概率是因为你的客户端发送消息时没有把Content-Type设置为application/json——此时规则引擎不会解析JSON，而是把整个消息payload当作纯文本处理，刚好你的文本里包含type: "payment"这个字符串，引擎误打误撞匹配成功了，但这种方式非常不可靠（比如payload里其他地方出现相同字符串也会匹配）。

正确的嵌套JSON解析方法 #

要在规则中正确解析嵌套的JSON负载，需要做两步：

1. 确保消息发送时设置正确的Content-Type #

你的客户端在发送消息时，一定要把Content-Type头设置为application/json。这会告诉Service Bus规则引擎：“这是一个JSON格式的消息，你可以解析它的属性”。

2. 使用正确的SQL过滤表达式语法 #

在创建规则时，用$作为根节点，然后通过点号访问嵌套属性。针对你的payload，正确的条件应该是：

New-AzureRMServiceBusRule -ResourceGroupName "你的资源组名" -Namespace "你的命名空间" -Topic "你的主题名" -Subscription "你的订阅名" -Name "规则名" -FilterSqlExpression "$.body.type = 'payment'"

这里的$.body.type明确告诉引擎：“从JSON根节点（$）开始，找到body对象，再匹配它的type属性等于'payment'”。

额外注意事项 #

• 如果你已经升级到了较新的Az模块（AzureRM已经被官方弃用，建议迁移），对应的命令是New-AzServiceBusRule，语法完全一致。
• 在PowerShell中写SQL表达式时，要注意引号的转义：如果用双引号包裹整个表达式，内部的单引号可以直接写；如果用单引号包裹，内部的单引号需要写成两个单引号（比如'$.body.type = ''payment'''）。
• 如果因为客户端限制无法设置Content-Type，退而求其次可以用字符串匹配，比如：

  -FilterSqlExpression "CONTAINS(sys.body, 'type: ''payment''')"
  

  但这种方式不建议，因为容易出现误匹配，且性能不如JSON属性匹配。

内容的提问来源于stack exchange，提问作者Jeff Hornby