Какова схема сообщения о событии проверки подписки в сетке событий Azure?

Question

1. Создание нового домена сетки событий Azure с использованием схемы облачных событий с использованием портала.
2. Создание новой конечной точки веб-перехвата с использованием функции Azure, которая может получать как события проверки подписки, так и уведомления о событиях.
3. Создание новой темы сетки событий Azure для указанного домена (в рамках следующей подписки) с использованием портала.
4. Создание новой подписки сетки событий Azure со схемой облачных событий с вышеуказанной конечной точкой веб-ловушки.
5. Когда подписка создана, конечная точка была вызвана инфраструктурой сетки с событием validaiton подписки для проверки конечной точки веб-ловушки.

К моему удивлению, структура события проверки (показанная ниже), казалось, соответствоваласобственная схема сетки событий, а не схема облачных событий:

[{
    "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"
}]

Я ожидал следующего события проверки подписки, соответствующего схеме облачных событий (на основе версии облачной схемы событий версии 0.1 в https://docs.microsoft.com/en-us/azure/event-grid/cloudevents-schema#cloudevent-schema):

{
    "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».

1. Внутренние события модели таблицы событий, такие как eventTypes Подтверждение подписки и Удаление подписки .Схема для этих типов событий всегда совпадает со схемой по умолчанию, такой как EventGridSchema .Другими словами, это не зависит от EventDeliverySchema .ИМО, имея схему по умолчанию для внутренних событий, создает сильные типы событий, особенно когда у нас есть 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-label , чтобы передать некоторые метаданные подписки обработчику подписчика.

В качестве обходного пути мы можем передать обработчику webhook подписчика некоторые значения через параметры запроса url, например: & eds = CustomInputSchema

Answer 2

Это известная проблема / ожидаемое поведение в реализации Azure Event Grid спецификации Cloud Event V0.1.В то время, когда спецификация Cloud Events v0.1 была реализована в сетке событий Azure, в стандарте Cloud Events не было определено модели проверки рукопожатия / защиты от злоупотреблений, и, следовательно, существующая модель / схема проверки связи Event Grid использовалась также для подписчиков Cloud Event.