Почему после последнего обновления Azure API Management произойдет сбой ранее стабильного и рабочего шаблона Liquid?

У нас есть конечная точка управления API Azure, которая принимает запросы в следующем формате:

{
    "messageType": "EVENT",
    "eventData": {
        "installedApp": {
            "installedAppId": "xxx",
            "locationId": "yyy"
        },
        "events": [
            {
                "eventTime": "2020-11-13T13:14:50.8011105+00:00",
                "eventType": "DEVICE_EVENT",
                "deviceEvent": {
                    "eventId": "3a08b3f3-25b1-11eb-962f-975d499d1166",
                    "locationId": "yyy",
                    "ownerId": "a975533a-a1ae-49f7-88f1-94368bd4d605",
                    "ownerType": "LOCATION",
                    "deviceId": "c3fdc7c6-08f2-4ba3-92b3-0cdfa2b141f5",
                    "componentId": "main",
                    "capability": "motionSensor",
                    "attribute": "motion",
                    "value": "inactive",
                    "valueType": "string",
                    "stateChange": true,
                    "data": {},
                    "subscriptionName": "all_motion_sub"
                }
            }
        ]
    }
}

Он передает их через шаблон Liquid:

<set-body template="liquid">{
    "id": "{{context.Variables["RequestId"]}}",
    "API": "SmartThings",
    "InstalledAppId": "{{body.eventData.installedApp.installedAppId}}",
    "LocationId": "{{body.eventData.installedApp.locationId}}",
    "DeviceEvents":[
        {% assign device_events = body.eventData.events | Where: "eventType", "DEVICE_EVENT" %}
        {% JSONArrayFor event in device_events %}
        {
            "EventId": "{{event.deviceEvent.eventId}}",
            "LocationId": "{{event.deviceEvent.locationId}}",
            "DeviceId": "{{event.deviceEvent.deviceId}}",
            "ComponentId": "{{event.deviceEvent.componentId}}",
            "Capability": "{{event.deviceEvent.capability}}",
            "Attribute": "{{event.deviceEvent.attribute}}",
            "Value": "{{event.deviceEvent.value}}",
            "StateChange": {{event.deviceEvent.stateChange}},
            "EventTime": "{{event.eventTime | Date: "yyyy-MM-ddTHH:mm:sszzz" | Default: context.Variables["RequestDateTime"] }}"
        }
        {% endJSONArrayFor  %}
    ],
    "EventTime": "{{context.Variables["RequestDateTime"]}}"
}</set-body>

И генерирует вывод, который отправляется в приложение логики для дальнейшей обработки:

{
    "id": "d5e2a032-14b3-40ca-9c6b-4e13f8d2285c",
    "API": "SmartThings",
    "InstalledAppId": "xxx",
    "LocationId": "yyy",
    "DeviceEvents": [
        {
            "EventId": "3a08b3f3-25b1-11eb-962f-975d499d1166",
            "LocationId": "yyy",
            "DeviceId": "c3fdc7c6-08f2-4ba3-92b3-0cdfa2b141f5",
            "ComponentId": "main",
            "Capability": "motionSensor",
            "Attribute": "motion",
            "Value": "inactive",
            "StateChange": true,
            "EventTime": "2020-11-13T13:14:50.8011105+00:00"
        }
    ],
    "EventTime": "2020-11-13T13:14:50.8011105+00:00"
}

Примерно до 23:00 по Гринвичу 11.11.2020 это работало, как ожидалось, и работало в продакшене в течение нескольких месяцев. Начиная с этого времени, отображение Liquid начало давать сбой, вместо этого производя:

{
    "id": "2c93647c-f9ef-4747-adfb-985805a71f0c",
    "API": "SmartThings",
    "InstalledAppId": "xxx",
    "LocationId": "yyy",
    "DeviceEvents": [
        {
            "EventId": "",
            "LocationId": "",
            "DeviceId": "",
            "ComponentId": "",
            "Capability": "",
            "Attribute": "",
            "Value": "",
            "StateChange": ,
            "EventTime": "2020-11-13T13:14:50.8011105+00:00"
        }
    ],
    "EventTime": "2020-11-13T13:14:50.8011105+00:00"
}

У нас есть запланированное событие обслуживания в журналах «Обновление управления API» с полуночи четверга, поэтому похоже, что произошло какое-то критическое изменение.

Что изменилось, чтобы вызвать это, и как нам это исправить?


person Jude Fisher    schedule 13.11.2020    source источник


Ответы (1)


На эту проблему я тестирую на своей стороне, а также воспроизводю вашу ситуацию. Похоже, в APIM есть ошибка жидкого шаблона. После воспроизведения вашей проблемы я тестирую в другом APIM, но он не показывает такой же проблемы, жидкий шаблон отлично работает в этом APIM. Затем я тестирую несколько APIM (с той же политикой тела набора и телом запроса) и резюмирую результат, как показано ниже:

введите описание изображения здесь

Судя по результатам многих тестов и приведенным выше результатам, я предполагаю, что это может быть ошибка после обновления APIM. И ошибка может быть связана с местоположением или ценовым уровнем (я не уверен), потому что я не могу найти никаких различий между этими APIM, кроме местоположения и ценового уровня. Поэтому я предлагаю вам проделать ту же работу в другом APIM (с другим местоположением и ценой), это временно решит проблему.

=============================== Обновление =========== ==================

Я провел еще несколько тестов и нашел способ решения этой проблемы. Я обнаружил, что проблема была вызвана строкой {% assign device_events = body.eventData.events | Where: "eventType", "DEVICE_EVENT" %}. Если мы не назначаем body.eventData.events device_events, вместо этого используйте body.eventData.events непосредственно в цикле for, например {% JSONArrayFor event in body.eventData.events %}. Тогда жидкий шаблон подойдет.

Таким образом, мы можем просто удалить строку назначения и выполнить условие where в цикле for. См. Мой шаблон жидкости ниже:  введите описание изображения здесь

person Hury Shen    schedule 16.11.2020
comment
Спасибо - это полезно. Мне дали понять, что проблема активно исследуется, поэтому я буду ждать, чтобы узнать, предложат ли они исправление или обходной путь. - person Jude Fisher; 16.11.2020
comment
Привет, @JudeFisher, я сделал еще несколько тестов и обновил свой ответ. Пожалуйста, обратитесь к моему обновлению. - person Hury Shen; 17.11.2020
comment
Привет, @JudeFisher. Могу я узнать, работает ли обходной путь обновления на вашей стороне? - person Hury Shen; 17.11.2020
comment
Да, обходной путь хорош. Большое спасибо. Я оставлю вопрос открытым ненадолго, так как мне все еще интересно узнать, как это было сломано и каким должно быть какое-либо постоянное исправление, но я приму ваш ответ через несколько дней, если больше ничего не придет. - person Jude Fisher; 18.11.2020
comment
Привет, @JudeFisher. Так как другого ответа нет, не могли бы вы принять мой ответ, спасибо ~ - person Hury Shen; 25.11.2020