Как получать уведомления о совокупности в реальном времени с помощью SmartREST?

Мы используем совокупность REST API. Работают регулярные уведомления в реальном времени, например. мы подписываемся на /alarms/*, запускаем наш цикл подключения/опроса, и когда мы создаем сигнал тревоги, мы получаем ожидаемый JSON. Мы не устанавливали какие-то специальные модули или операторы, это просто работает. Но когда мы пытаемся сделать то же самое с SmartREST, мы получаем эту ошибку, как только создается тревога:

40,,/alarms/177649296,Could not find any templates subscribed for the channel

Следуя справочному руководству (http://cumulocity.com/guides/reference/smartrest/ ) мы пробовали это так, когда все запросы имеют один и тот же X-Id-заголовок, и все запросы приводят к ожидаемому http-статусу 200 и без сообщений об ошибках, кроме последнего:

  1. Зарегистрируйте шаблон умного ответа, выполнив POST для /s
    Body: 11,102,,,$.channel
  2. Рукопожатие: POST в /cep/realtime
    Тело: 80 Ответ — наш clientId (например, 191het1z38bp7iq1m96jqqt8jnef)
  3. Подпишитесь: POST в /cep/realtime
    Текст: 81,191het1z38bp7iq1m96jqqt8jnef,/alarms/*
  4. Подключить: POST к /cep/realtime
    Текст: 83,191het1z38bp7iq1m96jqqt8jnef

В обычном случае REST уведомление состоит из массива JSON с двумя элементами, каждый из которых имеет свойство «канал». Так что это то, что мы ожидаем от нашего шаблона ответа. Вместо этого мы получаем вышеупомянутую ошибку 40.

Наш шаблон ответа неверен? Разве он не соответствует X-Id должным образом? Что значит, что нет "подписанных на канал шаблонов"? Подписки выполняются для clientId, а не для конкретного шаблона ответа, и шаблоны в любом случае должны сопоставляться автоматически. Так что, вероятно, «шаблон» здесь означает «X-Id»? Документация кажется неоднозначной в отношении значения этого слова. Но в любом случае мы использовали один и тот же заголовок X-Id во всех запросах.

Любое указание на то, что мы делаем неправильно, будет оценено по достоинству, поскольку мы уже пробовали почти все.


complex-event-processing cumulocity
person rob retro    schedule 21.08.2017    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Протокол SmartREST был разработан для связи IoT-устройства ‹-> платформы. Таким образом, никогда не было никакого дизайна, связанного с его использованием для подписки на данные в реальном времени (за исключением, конечно, операций, необходимых устройству), поскольку обычно устройствам не нужно подписываться на данные, которые они создали сами.

Тем не менее, его можно использовать, но с несколькими ограничениями. Ваш подход в принципе правильный, но есть одна проблема с подпиской. Подписки с подстановочными знаками не будут работать со SmartREST, потому что при подписке он связывает ваш X-Id с каналом, на который вы подписаны, но никогда не публикуется сообщение на канале /alarms/*. Таким образом, это странное сообщение об ошибке, в котором говорилось, что для канала, на котором появился сигнал тревоги, не было подписки на шаблон. Внутри CometD вы по-прежнему получаете сигнал тревоги из-за подписки с подстановочными знаками, но часть SmartREST не работает.

Сообщения публикуются на канале с идентификатором устройства (например, /alarms/12345). Если вы подпишитесь на /alarms/12345, это сработает. Конечно, вы можете подписаться на любое количество каналов, но групповая подписка не будет работать.

Относительно шаблонов нужно знать следующее. Анализ SmartREST выполняется не на необработанном JSON CometD, а на полезной нагрузке внутри него (например, сигнал тревоги). Таким образом, шаблон для будильника может выглядеть так:

11,500,,$.severity,$.id,$.type,$.severity

Это сработает только в том случае, если объект имеет серьезность и вернет идентификатор, тип и серьезность.

person TyrManuZ    schedule 21.08.2017
comment
Спасибо! Это именно то объяснение, которое мне было нужно. Мы всегда тестировали подстановочные знаки, потому что это было очень удобно. Не знал, что SmartREST его не поддерживает. С подпиской на определенный канал работает. :) - person rob retro; 21.08.2017
comment
Небольшое уточнение: эксперименты показывают, что он связывает ваш X-Id с каналом, на который вы подписаны, не связан с механизмом организации очереди, о котором идет речь stackoverflow.com/q/35841237/8495341 Если я сделаю еще одно рукопожатие, но с тем же X-Id, то мои предыдущие подписки и данные, которые тем временем могли быть поставлены в очередь на сервере, не переносятся. к новому соединению, и я не получаю ни одного из этих уведомлений. В этом есть смысл, поскольку несколько устройств могут подключаться к одному и тому же X-Id в любое время. - person rob retro; 23.08.2017
comment
Да, это правильно. X-Id не имеет ничего общего с общим процессом CometD. Он просто используется для отображения из JSON в CSV. То, что вы получаете и что кешируется, определяется процессом CometD, как если бы вы использовали полезную нагрузку JSON. - person TyrManuZ; 25.08.2017