Краткий экскурс для тех кто собирается перейти на amoCRM.
Итак, вот что вас ждет:
Большинство бизнесов уже имеют какие-то системы, в которых хранят свои данные по клиентам — это могут быть таблички экселя, или другая crm. Поэтому вероятность того, что работа с amoCRM начнется с чистого листа практически равна нулю. Потребуется как минимум перенос данных из старой системы в новую, а как максимум — настройка двусторонней синхронизации для плавного перехода, так как клиент хоть и хочет перейти на новую систему — от старой отказаться пока не может, потому что там весь его бизнес.
Итак мы начинаем разрабатывать интеграцию или синхронизацию, и конечно же сперва пойдем в доки amoCRM https://www.amocrm.ru/developers/content/crm_platform/platform-abilities узнавать и выяснять как там все работает. Оттуда мы узнаем как через программный интерфейс создавать сделки, как создавать контакты, как привязывать сделки к контактам, как создавать товары, компании и так далее.
И вот мы все узнали, написали нашу синхронизацию/интеграцию, все протестировали, все замечательно, внедряем решение в бизнес клиента, клиент тестит, все отлично, все довольны.
Но по прошествии некоторого времени начинают поступать жалобы следующего содержания: "Не упала заявка — в нашей системе она есть, в amo ее нет", или "Не обновился статус заявки — в нашей системе она в статусе оплачено, а в амо она в статусе новая". Мы начинаем судорожно искать проблему, залезаем в логи, и видим там следующую картину: запрос отправлен — успешно, запрос отправлен — успешно, запрос отправлен — ошибка. Что? Как? Какая ошибка? С какой стати? Данные сформированы корректно, мы тестировали этот момент сотню раз и все работало, но в логах ошибка. Пробуем отправить ошибочный запрос на создание сделки снова — и успешно. Мы ничего не меняли, ничего не чинили, мы просто отправили запрос еще раз и все сработало.
Ну ладно думаем мы, с кем не бывает, amo ведь тоже не идеальная, ну упала, ну поднялась, ну потеряли один лид, ничего страшного, ручками восстановим, ручками запрос еще раз отправим и все будет хорошо.
Но по прошествии еще некоторого времени снова поступают те же обращения — не упала заявка, не обновился статус. Мы уже начинаем сердиться, мол что за фигня, снова идем в логи, и снова видим ту же проблему, и вот теперь то мы понимаем что характер у нее регулярный. И тут мы решаем пройтись по всем логам и посмотреть — а сколько же всего запросов на создание сделок, контактов и других сущностей претерпело ошибку? Фильтруем логи и с ужасом наблюдаем следующее: 400 ошибочных запросов меньше чем за год, но распределенных не равномерно во времени, а следующим образом — 2 недели все ок, а в какой-то один день мы теряем 5 лидов и 6 обновлений статусов этих лидов.
Будучи разумными мы держим в голове мысль, что ошибка может быть и на нашей стороне, но не видя ее мы обращаемся в техническую поддержку amoCRM. Мол ребята, как так получается, что ваше api отвечает по разному в зависимости от времени — то успешно, то нет? При этом, мы детально описываем проблему, отправляем логи, отправляем пояснения к логам, чтобы разработчики не дай боже не запутались в структуре json' а. В ответ амо присылает нам такой ответ (сообщение скопировано как оно есть):
Здравствуйте.Вы обратились в клиентскую службу поддержки, мы не оказываем поддержку разработчиков с приватными интеграциями. Есть документация на сайте, есть много различных комьюнити разработчиков, у которых можно проконсультироваться по методам и другим вопросам.
Если вы разрабатываете публичные виджеты, то у нас организован отдельный канал общения с поддержкой по разработке — технический аккаунт. Для того чтобы мы могли сделать ваш аккаунт техническим, нужен новый аккаунт, который вы можете самостоятельно зарегистрировать на amoCRM.ru. После этого, нужно активировать чат с технической поддержкой, и написать следующее "Нужен чат с отделом интеграций, для создания технического аккаунта."
После этого сообщения мы понимаем, что это занавес. Публичные виджеты мы не разрабатываем, и поэтому нас футболят.
Уважаемое amoCRM, от имени разработчика, который уже 4 года работает с вашим api хочу вам сказать следующее. Реальная причина, по которой была написана данная статья заключается в «энтузиазме» вашей техподдержки в решении проблемы клиента.
Есть клиенты, которым плевать упадет им там лид или нет. На таких клиентах ошибки не находятся, потому что не ищутся. А есть клиенты, которым на это не плевать. И именно такие клиенты и указывают на подобные ошибки. Я проработал с огромной кучей клиентов, и только спустя год, благодаря клиенту, которому не плевать, я таки изучил проблему.
Соответствующий скрин прилагаю, дабы не быть голословным. Код ошибки:{«error_code»:«110»,«error»:«Неверный логин или пароль»}
P.S. Логин и пароль не может быть неверным, потому что никакие логины и пароли не используются в авторизации oAuth 2.0.
Да, косяк. Плохо. Уже переслал коллегам с моим комментарием.
Да, приватные виджеты мы формально не обслуживаем, но тут поддержка не права. Потеря данных у нас всегда имеет высший приоритет. И я всегда исповедовал принцип, что на один кейс, который стал нам известен, есть минимум 10 клиентов, которые промолчали. А уж если клиент готов помогать разобраться - это особенно ценно. В общем, извиняюсь, не правы.
С потерей данных при обращении к АПИ все непросто. Ошибки могут случаться (это очевидно), и единственный вариант - копить очередь. Мы могли бы копить ее на своей стороне, но если мы не отработали запрос, чего нам копить? То есть, по хорошему, очередь должен реализовать внешний сервис, а АПИ отдавать корректную ошибку, если "не зашло".
Мы, конечно, должны обеспечивать максимальную доступность базовых методов АПИ (прежде всего, добавление сделки/покупателя/контакта), но кейсы бывают самые разные и хитрые - очередь надежнее.
И еще раз повторюсь. Наш внутрений регламент звучит так:
- потеря данных - это высший приоритет (тут типичная потеря данных)
- редкий и хорошо подготовленный запрос - это большая ценность. Одно обращение = 10 инцидентов, о которых мы не знаем.
- если у нас "не воспроизводится" или "воспроизводится редко" ценность обращения увеличивается, т.к. без помощи клиента мы уже сами багу не найдем
Поэтому, тут мы точно не правы. Еще раз извиняюсь и прошу написать ребятам еще раз (хотя я уже написал)
Михаил, спасибо за обратную связь! Контакт с поддержкой установлен, будем разбираться в проблеме. По ошибкам согласен с вами, они могут случаться, от этого никто не застрахован. Поэтому тут скорее важно получить корректное ее описание, чтобы максимально быстро понять в чем именно проблема, и сервис работающий с амо смог корректно ее обработать.
Дамы и господа - проблема решена.
В чем же она заключалась? Ответ: очередь, очередь и еще раз очередь.
Что будет если засыпать амо одновременными запросами из нескольких сервисов на обновление одной и той же сделки? Ничего хорошего. Амо обеспечивает отработку запроса, но не обеспечивает постановку этих запросов в очередь. Собственно и не должна. Копить очередь на стороне интегратора - это правильный подход. Собственно это мы и сделали, и уже давно. Но пара запросов на обмен токенов прошла вне очереди и это стало причиной ошибки. В техподдержке этот факт выявили, и прислали развернутый ответ, за что конечно же ребятам спасибо.
Мораль басни: интеграторам ставить все запросы в очередь обязательно, без очереди все потонет. От амо хотелось бы получать корректный ответ об ошибке, чтобы интегратор сразу понимал что отправляет невалидные данные, ну и стараться не игнорить пользователя с его ошибками, ведь на то она и техническая поддержка. Всем спасибо.