Тестовое задание по глубокому копированию сделок в amoCRM или Composition over inheritance. Часть 1

Fullstack PHP developer (я), нет опыта с amoCRM, и тестовое задание на позицию backend-разработчика из двух задач.

Под фильтрами здесь понимается зашитое в код условие на бюджет сделки, воронку продаж и этап.

Let's do it!!(Вам нравятся длинные предложения в русском языке? Русский язык он такой: с суффиксами и окончаниями! :-) )

Т.к. опыта с amoCRM у меня никакого нет, вначале разберёмся, как тут всё устроено, и как всё будет работать в общих чертах. Итак, amoCRM - это SaaS решение, которое автоматизирует работу отдела продаж компании and all the stuff around, например, звонки. Ключевое понятие (сущность) вокруг которого строится работа - это заявки клиента. Заявки поступают в воронку продаж, их перемещают с этапа на этап, к заявкам добавляются контакты клиента, создаются примечания, задачи и тому подобное.

Также в приложении amoCRM есть экран (dashboard) со всевозможной аналитикой по заявкам. Пока отметим для себя раздел "События" в этом dashboard. Очень интересная вещь.

Если вы когда-нибудь авторизовались на сайте через кнопку соцсетей, то вы, в принципе, поймёте, о чём идёт речь далее.

(А как вам три слова подряд с буквой "ё"? Do you like it?)

Чтобы на своём сайте, который мы создадим, иметь возможность перемещать заявки в нашем аккаунте amoCRM, надо пройти подобную авторизацию. Речь идёт о протоколе OAuth2, суть которого в том, что мы обмениваем авторизационные данные (идентификатор клиента, секретный ключ и код авторизации) на не менее секретный токен (временный "пароль"). Затем мы используем полученный токен при каждом обращении к API amoCRM. Так система будет узнавать, что пользователь - это именно тот пользователь, за которого он себя выдаёт. (Ещё системе авторизации amoCRM есть понятие refresh token, но тестовое задание можно сделать и без разбирательств с ним. Не будем заморачиваться с деталями!) Компания Microsoft (и Github) пошли дальше: к выданому токену можно задавать допустимые действия пользователя в системе, например: работу с репозитариями, workflow и т.д.

Технически, авторизация с использованием OAuth2 делается довольно просто. Идём в раздел amoMarket web-приложения, создаём т.н. Внешнюю интеграцию с сайтом и прописываем URL скрипта нашего сайта для редиректа (бэкенд amoCRM отдаст заголовок Location с этим URL). Т.к. переадресация будет происходить локально в браузере, мы вполне можем использовать адрес вида http://localhost/my_script_to_redirect.php, ну, или http://localhost/redir, если у вас роутинг в приложении. :-)

На стороне клиента (наш сайт) поступим максимально просто. Отдадим скрипту код авторизации, который УЖЕ доступен в web-интерфейсе amoCRM (amoMarket -> Установленные -> (Ваша интеграция) -> Ключи и доступы). После этого обменяем код авторизации на токен доступа, сохраним его в файл и будем заниматься более интересными вещами.

(Строго говоря, при таком сценарии редирект с бэкенда amoCRM даже не зовётся, т.е. технически он не нужен. Но при создании класса AmoCRMApiClient для работы с API мы этот адрес передаём в конструктор. Так что пусть будет. Это не предмет нашего исследования at the moment :-) )

В силу отсутствия у меня mini PC с Linux, а также некомфортностью работы со связкой Vagrant, Laravel Homestead и docker (Опять этот маппинг директорий настраивать... SSH authorization... Подсети... Где оно всё там находится?! OMG!), для этого тестового задания воспользуемcя ОС Windows. В качестве редактора кода с лихвою хватит уютненького и лёгкого Sublime Text. Для web-сервера и "публикации" нашего приложения будем использовать Laragon, а также такую фичу файловой системы NTFS как symbolic links. Они очень удобны: можно "на лету" менять параметр DocumentRoot в конфиге Apache.

Всё относящееся к тестовому заданию будет храниться в директории с незамысловатым именем api-test. Внутри создадим папки с self-explained названиями app и project-management. В папке app создадим каталог webroot, на который будет указывать symbolic link из Apache. А также директории src и config, в которой будут храниться (sensitive) настройки приложения и токен доступа. (По-хорошему, последний файл надо хранить в каком-нибудь хранилище секретов, зашифрованным или хотя бы в другой папке. Но не в этот раз! ;-) )

А пока создадим в папке webroot файл index.php, в папке config файл .env.sensitive.data и директорию token-storage для хранения токена доступа к бэкенд amoCRM. Вот что получилось:

В части 2 создадим тестовые сделки, напишем супер-красивый код и реализуем первую задачу. Проект целиком уже доступен в репозитарии:

Stay tuned!! :-)