Question

使用门户网站使用云事件架构创建新的Azure事件网格域。
使用azure函数创建了新的Web挂钩端点，该端点可以接收订阅验证事件以及事件通知。
使用门户网站为上述域（作为后续订阅的一部分）创建了新的天蓝色事件网格主题。
使用上面的Web hook端点使用云事件架构创建了新的Azure事件网格订阅。
创建订阅后，网格基础结构会通过订阅有效事件调用该终结点，以验证Web挂钩终结点。

令我惊讶的是，验证事件结构（如下所示）似乎符合本机事件网格架构而不是云事件架构：

[{
    "id": "6309ef83-117f-47aa-a07c-50f6e71a8ca5",
    "topic": "/subscriptions/13ad1203-e6d5-4076-bf2b-73465865f9f0/resourceGroups/xxxx-sandbox-rg/providers/Microsoft.EventGrid/domains/eg-xxx-test-cloud-domain/topics/eg-xxx-test-cloud-topic",
    "subject": "",
    "data": {
        "validationCode": "391889BB-FCC3-4269-A2BD-0918B5BAB0AE",
        "validationUrl": "https://rp-westus.eventgrid.azure.net/eventsubscriptions/xxxx-subscription-3/validate?id=391889BB-FCC3-4269-A2BD-0918B5BAB0AE&t=2019-01-30T15:45:37.0521594Z&apiVersion=2018-09-15-preview&[Hidden Credential]"
    },
    "eventType": "Microsoft.EventGrid.SubscriptionValidationEvent",
    "eventTime": "2019-01-30T15:45:37.0521594Z",
    "metadataVersion": "1",
    "dataVersion": "2"
}]

我期望遵循符合云事件模式（基于https://docs.microsoft.com/en-us/azure/event-grid/cloudevents-schema#cloudevent-schema的0.1版本的云事件模式）的订阅验证事件：

{
    "eventID" : "6309ef83-117f-47aa-a07c-50f6e71a8ca5",
    "source" : "/subscriptions/13ad1203-e6d5-4076-bf2b-73465865f9f0/resourceGroups/xxxx-sandbox-rg/providers/Microsoft.EventGrid/domains/eg-xxx-test-cloud-domain/topics/eg-xxx-test-cloud-topic",
    "data": {
        "validationCode": "391889BB-FCC3-4269-A2BD-0918B5BAB0AE",
        "validationUrl": "https://rp-westus.eventgrid.azure.net/eventsubscriptions/xxxx-subscription-3/validate?id=391889BB-FCC3-4269-A2BD-0918B5BAB0AE&t=2019-01-30T15:45:37.0521594Z&apiVersion=2018-09-15-preview&[Hidden Credential]"
    },
    "eventType" : "Microsoft.EventGrid.SubscriptionValidationEvent",
    "eventTime" : "2019-01-30T15:45:37.0521594Z",
    "cloudEventsVersion" : "0.1",
    "eventTypeVersion" : "2",
}

我想念什么？

Answer 1

基本上，Webhook订户正在处理以下两组事件。特定的事件类型存储在http标头“ aeg-event-type”中。

内部事件，例如eventTypes SubscriptionValidation 和 SubscriptionDeletion 。这些事件类型的架构始终与默认架构（例如 EventGridSchema ）相同。换句话说，它不依赖于 EventDeliverySchema 。拥有内部事件默认模式的IMO特别是在拥有CustomInputSchema的情况下，产生了强大的事件类型。
兴趣源事件（主题）是由输入模式定义的事件，目前，Event Grid模型支持3种类型，例如 EventGridSchema （默认）， CloudEventSchema 和 CustomInputSchema 。 AEG支持以下架构输入/输出映射：
1. EventGridSchema 到交付模式 EventGridSchema 和 CloudEventSchema
2. CloudEventSchema 仅用于交付架构 CloudSchemaSchema
3. CustomInputSchema 传递架构 EventGridSchema 和 CloudEventSchema 和 CustomInputSchema
标头中的事件类型为： aeg-event-type = Notification ，并且该架构基于订阅的EventDeliverySchema（请参阅以下映射）。

基于上述情况，对于您的方案，您应该为内部事件（默认架构为EventGridSchema）和基于订阅的EventDeliverySchema的Notification事件具有单独的强类型对象。

以下是http标头的示例：

aeg-subscription-name=EVENTGRIDSCHEMA
aeg-delivery-count=0
aeg-data-version=
aeg-metadata-version=0
aeg-event-type=SubscriptionValidation

注意，只有一个订阅名称可以确定已订阅哪个EventDeliverySchema。最好有一个额外的aeg标头，例如： aeg-subscription-labels 将一些订阅元数据传递给订户处理程序。

作为一种解决方法，我们可以通过url查询参数将一些值传递给订阅者webhook处理程序，例如：＆eds = CustomInputSchema

Answer 2

这是Cloud Event V0.1规范的Azure Event Grid实施中的已知问题/预期行为。在Azure Event Grid中实施Cloud Events v0.1规范时，Cloud Events标准中没有定义验证握手/滥用保护模型，因此，Event Grid的现有验证握手模型/架构也用于Cloud Event订户。

天蓝色事件网格中的订阅验证事件消息模式是什么？

2 个答案: