Читатели нашего блога уже знают, что в последнее время мы все чаще используем 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://blog.bedrosova.ru/aws-lambda-api-gateway-bitrix24/ и еще планирую в будущем написать о том, как сделать все тоже самое не через консоль AWS, а через AWS CLI со своего локального компьютера, потому что, понятное дело, что какой-то небольшой проект можно автоматизировать непосредственно в консоли, но если разрабатывать что-то масштабное, что требует продолжительной итеративной интеграции, то без применения AWS CLI, Docker и SAM — не обойтись.
Сейчас же я хочу рассказать о тех сценариях интеграции почтового трекинга, которые я реализовала в облачном Битрикс24 для Студии Юлии Бедросовой.
Исторически так сложилось, что всю входящую и исходящую почтовую переписку я сканирую и заношу в заведенный специально для этого в Битрикс24 список — Реестр почтовых отправлений. В числе прочих данных я храню там и почтовый трекинг-номер:
На этом списке я реализовала 2 бизнес-процесса:
Первый — маленький, который позволяет быстро проверить трекинг-номер вручную и получить данные по нему в личные сообщения в портале:
Единственное, что он делает — это дергает веб-хук:
Обработчик данного веб-хука на стороне AWS Lambda выглядит следующим образом:
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 в любом виде.