azure event grid中的订阅验证事件消息架构是什么？

Question

1. 使用门户创建了具有云事件架构的新azure事件网格域
2. 使用azure函数创建了新的web钩子endpoint，该endpoint可以接收订阅验证事件和事件通知
3. 使用门户为上述域创建了新的azure事件网格主题（作为以下订阅的一部分）
4. 使用云事件架构和上述web挂钩endpoint创建了新的azure事件网格订阅
5. 创建订阅时，网格基础设施通过订阅验证事件调用endpoint，以验证web钩子endpoint

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

[{
    "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/cloud events-schema # cloud event-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

这是云事件V0.1规范的Azure事件网格实现中的已知问题/预期行为。在Azure事件网格中实现云事件V1.1规范时，云事件标准中没有定义验证握手/滥用保护模型，因此事件网格的现有验证握手模型/架构也用于云事件订阅者。

Answer 2

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

> < li>

事件网格模型的内部事件，例如事件类型SubscriptionValidation和SubscriptionDeletion。这些事件类型的架构始终与默认架构(如EventGridSchema)相同。换句话说，它不依赖于EventDeliverySchema。在我看来，拥有内部事件的默认模式是一种强事件类型，特别是当我们有一个CustomInputSchema时。

兴趣源事件(主题)是由输入模式定义的事件，目前事件网格模型支持三种类型，如EventGridSchema(默认)、CloudEventSchema和CustomInputSchema。AEG支持以下模式输入/输出映射:

1. EventGridSchema到交付模式、EventGridSchema和CloudEventSchema
2. CloudEventSchema到仅交付模式CloudSchemaSchema
3. CustomInputSchema到传递模式、EventGridSchema和CloudEventSchema以及CustomInputScheme

标头中的事件类型为：aeg-event-type=通知，架构基于订阅的EventDeliverySchema（请参阅以下映射）。

基于上述，对于您的场景，您应该为内部事件（默认模式为EventGridSchema）和基于订阅的EventDeliverySchema的通知事件提供单独的强类型对象。

以下是超文本传输协议标头的示例：

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

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

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