Облачный Битрикс24 и почтовый трекинг - интеграция по SOAP через AWS Lambda
Читатели моего блога уже знают, что в последнее время я полюбила использовать Serverless технологии AWS: Lambda и API Gateway, вебхуки и их обработчики на языке Python3 для кастомизации облачного Битрикс24. Это удобно, просто, изящно и очень дешево.
К примеру, дергать SOAP-сервис Почты России из AWS Lambda - можно бесплатно целый год, а потом, если мои замеры и подсчеты верны, проверка 100 000 почтовых квиточков за год, что с лихвой покроет нужды любого малого бизнеса, обойдется примерно в 12$.
Что же нам для этого потребуется:
1) Получить логин и пароль для интеграции на сайте Почты России https://www.pochta.ru/support/business/api - мне логин и пароль прислали через 5 минут после моего запроса.
2) Подготовить Lambda Layer с библиотекой для работы с SOAP. Я выбрала для себя опенсоурсную билиотеку Zeep. О том, как упаковать ее в Layer, я писала ранее в личном блоге: http://bedrosova.blogspot.com/2019/07/aws-lambda-layer-zeep.html
3) Сделать на стороне Битрикс24 входящий вебхук с правами посылать сообщения пользователю и с доступом к универсальным спискам (в моем случае) или, может быть, к CRM - смотря куда вам нужно складывать результат проверки трекинг-номера.
4) Написать бизнес-процесс в Битрикс24, который будет дергать внешний веб-хук, передавая ему номер почтового отправления, который необходимо проверять, а так же ид элемента и инфоблока, в который необходимо сохранить результат проверки.
5) Написать Lambda функцию, которая примет переданные от Битрикс24 данные, запросит состояние почтового отправления по SOAP в почте России и вернет результат в Битрикс24 по входящему веб-хуку в том или ином виде.
6) Настроить API Gateway для нашей Lambda функции. Подробно этот процесс я расписывала ранее: http://bedrosova.blogspot.com/2019/07/aws-lambda-api-gateway-24.html и еще планирую в будущем написать о том, как сделать все тоже самое не через консоль AWS, а через AWS CLI со своего локального компьютера, потому что, понятное дело, что какой-то небольшой проект можно автоматизировать непосредственно в консоли, но если разрабатывать что-то масштабное, что требует продолжительной итеративной интеграции, то без применения AWS CLI, Docker и SAM - не обойтись.
Сейчас же я хочу рассказать о тех сценариях интеграции почтового трекинга, которые я реализовала в облачном Битрикс24 для Студии Юлии Бедросовой.
Исторически так сложилось, что всю входящую и исходящую почтовую переписку я сканирую и заношу в заведенный специально для этого в Битрикс24 список - Реестр почтовых отправлений. В числе прочих данных я храню там и почтовый трекинг-номер:
На этом списке я реализовала 2 бизнес-процесса:
Первый - маленький, который позволяет быстро проверить трекинг-номер вручную и получить данные по нему в личные сообщения в портале:
Единственное, что он делает - это дергает веб-хук:
Обработчик данного веб-хука на стороне AWS Lambda выглядит следующим образом:
Помню, когда я в последний раз работала с SOAP на PHP - там была простыня кода, а тут на Python3 + Zeep все просто, как 2*2
Запускаю данный бизнес-процесс вручную:
И получаю личное сообщение от самой себя со всей историей перемещения письма и его текущим статусом:
Второй - большой бизнес-процесс запускается автоматически при изменении записи Реестра:
Бизнес-процесс проверяет входящий это документ или исходящий. Для входящих - ничего не делает (я и так его уже получила, раз внесла в реестр, и ничего отслеживать мне не нужно).
Для исходящего трекинг-номер появляется не сразу, потому что я вношу запись в реестр, когда упаковываю документы в конверт, чтобы обозначить там содержимое конверта, а трекинг номер я заполняю уже потом - когда получаю почтовые квиточки, поэтому бизнес-процесс проверяет, есть ли уже трекинг-номер, и если пока нет - ждет 3 дня. Если трекинг-номер уже есть, дергает веб-хук.
Его обработчик похож на тот, что я показывала выше по тексту, но только еще происходит запись финального статуса отправления в поле списка "Почтовый статус". Как проапдейтить список из Lambda функции я тоже уже писала ранее в блоге: http://bedrosova.blogspot.com/2019/07/24-python3-aws-lambda.html
После запуска веб-хука я вставила в бизнес-процесс паузу 5 минут, чтобы дать обработчику на стороне AWS Lambda время на обработку - она занимает до 40 секунд в зависимости от того, как долго отвечает сервис Почты России.
После этого бизнес-процесс проверяет, перешел ли трекинг-номер в статус "Вручение Адресату почтальоном" - если перешел, то цикл перестает крутиться - это финальный статус, к-й возвращает сервис уже после успешного вручения. Если статус не достигнут, то через 3 дня процесс повторяется.
Этот процесс крутится сам по себе и освобождает меня от тупой работы.
Мне достаточно зайти в мой реестр и выставить нужные фильтры, чтобы увидеть состояние моих отправленных писем.
Аналогичным образом можно осуществить интеграцию облачного Битрикс24 с любой внешней системой, которая умеет отдавать данные по SOAP или предоставляет API в любом виде.
К примеру, дергать SOAP-сервис Почты России из AWS Lambda - можно бесплатно целый год, а потом, если мои замеры и подсчеты верны, проверка 100 000 почтовых квиточков за год, что с лихвой покроет нужды любого малого бизнеса, обойдется примерно в 12$.
Что же нам для этого потребуется:
1) Получить логин и пароль для интеграции на сайте Почты России https://www.pochta.ru/support/business/api - мне логин и пароль прислали через 5 минут после моего запроса.
2) Подготовить Lambda Layer с библиотекой для работы с SOAP. Я выбрала для себя опенсоурсную билиотеку Zeep. О том, как упаковать ее в Layer, я писала ранее в личном блоге: http://bedrosova.blogspot.com/2019/07/aws-lambda-layer-zeep.html
3) Сделать на стороне Битрикс24 входящий вебхук с правами посылать сообщения пользователю и с доступом к универсальным спискам (в моем случае) или, может быть, к CRM - смотря куда вам нужно складывать результат проверки трекинг-номера.
4) Написать бизнес-процесс в Битрикс24, который будет дергать внешний веб-хук, передавая ему номер почтового отправления, который необходимо проверять, а так же ид элемента и инфоблока, в который необходимо сохранить результат проверки.
5) Написать Lambda функцию, которая примет переданные от Битрикс24 данные, запросит состояние почтового отправления по SOAP в почте России и вернет результат в Битрикс24 по входящему веб-хуку в том или ином виде.
6) Настроить API Gateway для нашей Lambda функции. Подробно этот процесс я расписывала ранее: http://bedrosova.blogspot.com/2019/07/aws-lambda-api-gateway-24.html и еще планирую в будущем написать о том, как сделать все тоже самое не через консоль AWS, а через AWS CLI со своего локального компьютера, потому что, понятное дело, что какой-то небольшой проект можно автоматизировать непосредственно в консоли, но если разрабатывать что-то масштабное, что требует продолжительной итеративной интеграции, то без применения AWS CLI, Docker и SAM - не обойтись.
Сейчас же я хочу рассказать о тех сценариях интеграции почтового трекинга, которые я реализовала в облачном Битрикс24 для Студии Юлии Бедросовой.
Исторически так сложилось, что всю входящую и исходящую почтовую переписку я сканирую и заношу в заведенный специально для этого в Битрикс24 список - Реестр почтовых отправлений. В числе прочих данных я храню там и почтовый трекинг-номер:
На этом списке я реализовала 2 бизнес-процесса:
Первый - маленький, который позволяет быстро проверить трекинг-номер вручную и получить данные по нему в личные сообщения в портале:
Единственное, что он делает - это дергает веб-хук:
Обработчик данного веб-хука на стороне AWS Lambda выглядит следующим образом:
Помню, когда я в последний раз работала с SOAP на PHP - там была простыня кода, а тут на Python3 + Zeep все просто, как 2*2
Запускаю данный бизнес-процесс вручную:
И получаю личное сообщение от самой себя со всей историей перемещения письма и его текущим статусом:
Второй - большой бизнес-процесс запускается автоматически при изменении записи Реестра:
Бизнес-процесс проверяет входящий это документ или исходящий. Для входящих - ничего не делает (я и так его уже получила, раз внесла в реестр, и ничего отслеживать мне не нужно).
Для исходящего трекинг-номер появляется не сразу, потому что я вношу запись в реестр, когда упаковываю документы в конверт, чтобы обозначить там содержимое конверта, а трекинг номер я заполняю уже потом - когда получаю почтовые квиточки, поэтому бизнес-процесс проверяет, есть ли уже трекинг-номер, и если пока нет - ждет 3 дня. Если трекинг-номер уже есть, дергает веб-хук.
Его обработчик похож на тот, что я показывала выше по тексту, но только еще происходит запись финального статуса отправления в поле списка "Почтовый статус". Как проапдейтить список из Lambda функции я тоже уже писала ранее в блоге: http://bedrosova.blogspot.com/2019/07/24-python3-aws-lambda.html
После запуска веб-хука я вставила в бизнес-процесс паузу 5 минут, чтобы дать обработчику на стороне AWS Lambda время на обработку - она занимает до 40 секунд в зависимости от того, как долго отвечает сервис Почты России.
После этого бизнес-процесс проверяет, перешел ли трекинг-номер в статус "Вручение Адресату почтальоном" - если перешел, то цикл перестает крутиться - это финальный статус, к-й возвращает сервис уже после успешного вручения. Если статус не достигнут, то через 3 дня процесс повторяется.
Этот процесс крутится сам по себе и освобождает меня от тупой работы.
Мне достаточно зайти в мой реестр и выставить нужные фильтры, чтобы увидеть состояние моих отправленных писем.
Аналогичным образом можно осуществить интеграцию облачного Битрикс24 с любой внешней системой, которая умеет отдавать данные по SOAP или предоставляет API в любом виде.
Комментарии