Веб-сервис, предоставляющий уведомления по нескольким транспортным средствам

Я хочу включить уведомления о событиях для своих клиентов. Существует множество способов отправки уведомлений: электронные письма, sms, XMPP/другие IM, предварительно записанные голосовые сообщения через SIP, службы push-сообщения для конкретного телефона, обратные вызовы REST и т.д.

Я не хочу самостоятельно разрабатывать все эти транспорты, поэтому мне нужен веб-сервис, который может управлять этими уведомлениями для клиентов. Также я не хочу хранить электронные письма/телефоны/другую личную информацию.

Уведомления являются транзакционными (т.е. не массовыми, доставляющими одно и то же сообщение всем). Платные решения приветствуются.

Существует http://pagerduty.com, но это

предназначен для работы внутри предприятия, а не с внешними клиентами
сосредоточен на полном цикле реакции на инцидент, в отличие от простой доставки сообщений

Таким образом, это ставит большую нагрузку на респондентов, и я хочу что-то, что требует нулевого усилия для настройки пользователями.

Monitis - еще один пример. Он имеет несколько транспортов, включая Twitter, но снова он предназначен для инсайдеров, а не для абонентов службы, входящих в массовые номера.

Amazon SNS выглядит слишком низкоуровневым, так как он управляет доставкой push-уведомлений, но для их дублирования я должен написать мобильное приложение, которое я не хочу.

Серверы XMPP, как описано в Как лучше всего отправлять уведомления различным службам IM/уведомлений? традиционно поддерживали идею разных перевозок, но мне бы хотелось, чтобы третий -party.

Twilio имеет только 2 транспорта: SMS и голосовые вызовы и больше ориентированы на полную двухстороннюю связь.

Я даже не могу найти правильные ключевые слова google для поиска сервиса /SaaS, который я хочу.

Вопрос в том, есть ли такие услуги? Образец нескольких дал бы мне представление о том, что искать.

Ответ 1

Это происходит очень поздно, возможно, слишком поздно, но...

Вам не нужно выполнять какой-либо транспорт, но вам может потребоваться создать некоторые из шлюзов, и вам, скорее всего, потребуется собрать приложение, которое будет разговаривать с каждым из шлюзов. Вы вряд ли найдете для этого одну услугу.

Вы уже определили стратегию. У вас в основном есть эти штуки:

транспорты
Шлюзы
Приложение

Каждый из транспортов доступен через какого-либо клиента через API или CLI, поэтому вам нужно выяснить, что такое ваша среда. Java, вероятно, является хорошим выбором, но, вероятно, будут работать и другие межплатформенные среды. Существующая инфраструктура, такая как Apache ServiceMix, поддерживает некоторые из этих транспортов:

https://cwiki.apache.org/confluence/display/SM/Components+list

и может быть другое среднее изделие с похожими, отличными транспортными средствами.

Вероятно, вам понадобится шлюз для каждого провайдера для каждого типа транспорта. Возможно, вам удастся найти поставщика, который обслуживает несколько транспортных средств, например. Twilio SMS и голос, но это, скорее всего, будет исключением. Вы также можете обнаружить, что из-за различий в транспорте (и, следовательно, с функциональностью), более удобно создавать шлюз для каждого типа транспорта. Таким образом, у вас могут быть два настроенных провайдера на вашем шлюзе SMS, один для Twilio и один для Kannel, и у вас может быть ваша учетная запись Twilio, используемая в шлюзе SMS и в шлюзе SIP.

Последний шаг - собрать ваше приложение во что-то значимое. Это может быть что-то вроде:

sent.......: "Thanks for your purchase, ${username}!"

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

response...: "It was a pleasure! --Bob"

Вам нужно будет сохранить основы каждой конечной точки транспорта, например, номер телефона для SMS, имя пользователя для чата и т.д., поэтому, если у вас есть проблемы с защитой PII, вам нужно подумать об этом. Один из вариантов может заключаться в том, чтобы превратить все PII в каждого провайдера, но вам все равно нужно сохранять каждую учетную запись для своих пользователей в каждом провайдере, и вам, вероятно, нужно будет что-то узнать о пользователе, например "$ {username}" выше, чтобы персонализировать ваше уведомление надлежащим образом в вашей заявке. Таким образом, удаление всего PII из вашего приложения кажется маловероятным.

Я не уверен, насколько эта помощь, но, возможно, дает вам некоторые идеи.