Облачный Битрикс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 выглядит следующим образом:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| import json | |
| from zeep import Client | |
| from botocore.vendored import requests | |
| from urllib.parse import parse_qs | |
| def lambda_handler(event, context): | |
| url = 'https://tracking.russianpost.ru/rtm34?wsdl' | |
| barcode = event['barcode'] | |
| my_login = '************' | |
| my_password = '**********' | |
| client = Client(url) | |
| OperationHistoryRequest= { | |
| "Barcode":barcode, | |
| "MessageType":0, | |
| "Language":"RUS" | |
| } | |
| AuthorizationHeader= { | |
| "login":my_login, | |
| "password":my_password | |
| } | |
| with client.settings(strict=False): | |
| result = client.service.getOperationHistory(OperationHistoryRequest,AuthorizationHeader) | |
| info='\n' | |
| FinalStatus='' | |
| for item in result: | |
| try: | |
| info=info+' '+str(item['OperationParameters']['OperDate'])[:10]+' ' | |
| except: | |
| pass | |
| try: | |
| info=info+' '+str(item['AddressParameters']['OperationAddress']['Index'])+' ' | |
| except: | |
| pass | |
| try: | |
| info=info+' '+str(item['OperationParameters']['OperAttr']['Name'])+' ' | |
| except: | |
| pass | |
| try: | |
| FinalStatus=str(item['OperationParameters']['OperAttr']['Name']) | |
| except: | |
| pass | |
| info=info+'\n' | |
| data = { | |
| "user_id": 1, | |
| "message": barcode+' '+info+'\n '+FinalStatus | |
| } | |
| response = requests.get('https://bedrosova.bitrix24.ru/rest/1/************/im.message.add.json',data) | |
| return { | |
| 'statusCode': 200, | |
| } |
Помню, когда я в последний раз работала с 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 в любом виде.
Комментарии