Основные требования к модулям

Скопировать ссылку на статью

Скопировано

Вы можете разработать собственный модуль и разместить его в Маркетплейсе. Модуль может быть как бесплатным, так и платным. Перед размещением модуля вам требуется зарегистрироваться как партнер и заключить договор. Для этого обратитесь к нам через форму на сайте.

Разработка модуля

Ваш модуль может выполнять все функции, которые доступны в API. В справочнике методов приведен полный перечень API-методов. Для работы с API требуется API-ключ. Вы должны понимать, какие API-методы понадобятся для работы модуля. В дальнейшем, в партнерском кабинете, вам потребуется указать {configUrl}, определяющий для системы список доступов, которые предоставляются вашему модулю. При активации модуля методом GET /api/credentials вы можете проверить, все ли необходимые методы разрешены.

Изучите правила работы с API. Важно понимать, какие ограничения накладывает API, а также какие виды ошибок он может возвращать.

Основные требования к модулям

1. Модуль должен использовать только последнюю актуальную версию API.
2. Модуль должен расширять пользовательский функционал и нести очевидную ценность продукту. Решения, дублирующие стандартный функционал, к публикации не допускаются. Также в публикации модуля может быть отказано, если его функционал находится в разработке у вендора.
3. Интеграция подразумевает автоматический обмен данными между системами. Простого вызова интерфейса внешнего сервиса из интерфейса для публикации модуля недостаточно.
4. При заборе данных модулем из системы, необходимо реализовать процесс только с помощью API, чтобы минимизировать работу клиента при подключении и настройки модуля.
5. Интеграция должна осуществлять обмен данными между системой и внешними решениями. Чтобы клиент не переключался между окнами и админками различных сервисов.
6. Описание модуля должно соответствовать функционалу. Название модуля должно быть емкое и не должно содержать элементов фирменного стиля вендора.
7. Любые ограничения в работе модуля либо невозможность обработать какие-либо ситуации или формат данных, если это вызвано ограничением конечной системы, с которой через модуль осуществлена интеграция, должны быть описаны в документации.
8. Для модулей доставки реализован обширный функционал для взаимодействия, который, помимо всего прочего, позволяет не просто выгружать посылки в службу доставки, но также редактировать и отменять/удалять их. Если модуль в полной мере не реализует данные возможности, необходимо указать это в документации к модулю.
9. Настройка параметров модуля доставки должна производиться в личном кабинете модуля. Передавать указанные настройки в конфигурации модуля необходимо в поле integrationModule[integrations][delivery][settings].
10. Решение не должно запрашивать логин и пароль пользователя для авторизации в системе вендора. Для получения необходимых данных из аккаунта клиента необходимо использовать API ключ.
11. Модулем должна быть предусмотрена обработка возможных ошибок со стороны API. Сообщения об ошибках, возникающих по причине неверного оформления данных, некорректной обработки данных менеджерами клиента и/или сбоя непосредственно в конечной системе, с которой модулем реализована интеграция), должны выводиться пользователю, быть понятны и достаточно содержательны. Не допускается вывод стандартных ошибок вида Ошибка сервера, либо stack trace.
12. Не должно быть ошибок в работе модуля, также необходимо убедиться в полной работоспособности всех ссылок и механизмов для подключения и настройки модуля. В противном случае, из-за невозможности подключить либо произвести настройку модуля, сразу же будет принято отрицательное решение о модерации, даже если на тестовой системе партнёра модуль установлен и можно проверить его работоспособность.
13. При настройке соответствий между двумя системами необходимо, чтобы данные из обеих систем всегда были актуальны на странице настроек. В случае, если невозможно получить какие-либо необходимые списки данных для настроек от сторонней системы, не допускается генерация этих данных на основе текущего состояния сторонней системы для пользователя. Список данных должен быть сформирован заранее и обновляться по мере необходимости.
14. Модуль и его описание не должны содержать оскорбительную, непристойную информацию, призывы к насилию, порнографию, расизм, и прочие запрещенные законодательством РФ материалы.
15. Обязательно предусматривать логирование запросов к API и ответов и хранить эти данные в течение месяца или хотя бы нескольких дней, для использования в случае решения проблем с интеграцией.
16. Модуль может быть не допущен для публикации в маркетплейсе без объяснения причин по решению модератора.

Проверка домена системы при подключении модуля

В существующих и новых модулях интеграции, публикуемых в маркетплейсе, требуется проверять адрес аккаунта, в котором включается модуль.

Валидация должна проверять, что:

• Указанный URL имеет корректный формат
• Протокол в URL https://
• Аккаунт находится на одном из доменов данного списка https://infra-data.retailcrm.tech/crm-domains.json

В последней проверке список допустимых доменов необходимо читать напрямую из указанного json-файла. Это связано с тем, что список доменов может расширяться.

Если ваш модуль разработан на Symfony (PHP 7.3+), вы можете использовать готовый валидатор https://github.com/retailcrm/url-validator