0
  1. 使用门户创建了具有云事件架构的新天蓝色事件网格域。
  2. 使用 azure 函数创建了新的 Web 挂钩端点，该函数可以接收订阅验证事件和事件通知。
  3. 使用门户为上述域（作为以下订阅的一部分）创建了新的 azure 事件网格主题。
  4. 使用上述 Web 挂钩端点创建了具有云事件架构的新 azure 事件网格订阅。
  5. 创建订阅后，网格基础架构会使用订阅验证事件调用端点来验证 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",
}

我错过了什么？

4

2 回答 2

2

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

  1. 事件网格模型的内部事件，例如 eventTypes SubscriptionValidation和SubscriptionDeletion。这些事件类型的架构始终与默认架构相同，例如 EventGridSchema。换句话说，它不依赖于EventDeliverySchema。IMO，当我们有一个 CustomInputSchema 时，拥有内部事件的默认模式正在制作一个强大的事件类型。

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

    1. EventGridSchema到交付模式EventGridSchema和CloudEventSchema
    2. CloudEventSchema仅交付模式CloudSchemaSchema
    3. CustomInputSchema到交付模式EventGridSchema和CloudEventSchema和CustomInputSchema

    标头中的事件类型是：aeg-event-type=Notification，并且模式基于订阅的 EventDeliverySchema（参见以下映射）。

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

以下是 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

于 2019-01-31T12:58:45.843 回答
0

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

于 2019-01-30T19:54:40.853 回答