Интеграция с Priority ERP
Priority одна из самых распространённых ERP в Израиле, и почти у каждой компании на ней рано или поздно появляется вторая система: интернет-магазин, CRM, склад, портал для клиентов. Вопрос всегда один и тот же: как их связать, чтобы данные не расходились.
Кратко
У Priority три способа обмена: REST API на OData для работы в реальном времени, Web SDK на JavaScript для работы с формами и процедурами так, как это делает пользователь, и загрузки через ממשקים для пакетного обмена файлами. Выбор определяют не удобство разработчика, а лимиты: в облаке у API есть ограничения на число вызовов в минуту на пользователя и на одновременные запросы, и интеграция, которая ходит в Priority за каждой мелочью, упирается в них в первый же загруженный день.
Три способа и когда какой
| Способ | Подходит для | На что смотреть |
| REST API (OData) | Заказ из магазина в Priority, остатки и цены обратно, карточка клиента для CRM | Для API нужно отдельно открыть каждую форму. Также важно учитывать облачные лимиты и лицензию на API |
| Web SDK | Действия, которые в Priority выполняются через форму или процедуру: печать документа, запуск процедуры, вложения | Это пакет на JavaScript, логика которого повторяет работу пользователя в интерфейсе |
| ממשקים (Form Loads) | Пакетная загрузка: прайс-лист, большие справочники, ночной обмен | Файлы или XML/JSON, обработка по расписанию, ошибки видны в журнале загрузки |
Кроме того, в документации для разработчиков есть разделы о webhooks, ODBC и MCP-сервере. Официальный портал: prioritysoftware.github.io.
Авторизация
- Basic с логином и паролем пользователя Priority: самый простой вариант и самый слабый.
- Personal Access Token в новых версиях: для связи сервер с сервером Priority рекомендует именно его.
- OAuth2 через отдельный модуль External ID, только для установки на своих серверах. Пока он включён, Basic не работает, и об этом нужно знать до переключения, а не после.
Отдельно приложение может передавать собственный идентификатор и лицензионный ключ. Без них запрос учитывается по общей лицензии API. Какие лицензии у вас куплены, стоит уточнить у поставщика ещё до проектирования: от этого зависит, сколько отдельных пользователей API можно будет завести.
Лимиты, которые определяют архитектуру
В облачной версии Priority действует правило честного использования. По документации это ограничения на число вызовов в минуту на одного пользователя, на число запросов в скользящем пятиминутном окне, на число одновременно выполняемых запросов с короткой очередью, а также тайм-аут запроса и предельный размер ответа. При превышении лимита приходит HTTP 429. Число строк в одном ответе тоже ограничено настройкой.
Типичная ошибка: магазин при каждом открытии карточки товара запрашивает у Priority остаток. В спокойный день это работает. В день распродажи магазин упирается в лимит, Priority отвечает 429, а покупатель видит ошибку или неверный остаток.
Отсюда правила, по которым мы строим интеграцию:
- Данные, которые меняются редко (каталог, цены, клиенты), забираем по расписанию или по событию и держим у себя. В Priority за ними в реальном времени не ходим.
- В реальном времени отправляем только то, без чего нельзя обойтись: заказ, оплату, резерв.
- Каждый вызов умеет получить 429 и повторить позже с паузой, а не сразу.
- Очередь отправки хранится на нашей стороне. Если Priority недоступен, заказ не теряется, а ждёт своей отправки.
- Каждая операция идемпотентна: повторная отправка того же заказа не создаёт второй документ.
Где интеграции обычно ломаются
- Два мастера одних данных. Клиента меняют и в CRM, и в Priority, и через месяц карточки расходятся. Ещё до написания кода нужно решить, какая система главная для каждого поля.
- Справочники. Коды единиц, складов и условий оплаты в магазине и в Priority не совпадают. Таблица соответствий должна быть явной и с назначенным владельцем.
- Ошибка загрузки без адресата. Документ не загрузился, запись в журнале есть, но её никто не читает. Нужны ответственный человек и уведомление.
- Обновление версии Priority. Изменилась форма или поле, и интеграция молча перестала его заполнять. Нужен проверочный сценарий, который прогоняется после каждого обновления.
Что мы делаем
Проектируем обмен с учётом лимитов и лицензий, строим очередь и журнал, связываем Priority с магазином, CRM или собственной системой и оставляем проверочный сценарий на случай обновлений. Если интеграция уже есть и «иногда теряет заказы», начинаем с журнала: почти всегда причина видна там.
Частые вопросы
Есть ли у Priority API?
Да. REST API на стандарте OData, плюс Web SDK на JavaScript и механизм загрузок (ממשקים) для пакетного обмена. Документация опубликована на портале разработчиков Priority.
Почему интеграция с Priority работает медленно или выдаёт ошибки под нагрузкой?
Чаще всего из-за лимитов облачной версии: число вызовов в минуту на пользователя и число одновременных запросов ограничены, при превышении приходит HTTP 429. Решение в архитектуре: кешировать редко меняющиеся данные и держать очередь на своей стороне.
Какую авторизацию выбрать?
Для связи сервер с сервером Priority рекомендует Personal Access Token. OAuth2 доступен через модуль External ID только при установке на своих серверах, и пока он включён, Basic не работает.
Можно ли связать Priority с интернет-магазином?
Да, это самый частый сценарий. Заказы и оплаты уходят в Priority в реальном времени через очередь, а каталог, цены и остатки забираются по расписанию или по событию.
Нужна ли отдельная лицензия на API?
Обычно да, и её условия зависят от договора с поставщиком. Это стоит уточнить ещё до проектирования, потому что от лицензии зависит, сколько пользователей API можно завести.
С чего начать
Напишите, какая версия Priority у вас (облако или свои серверы) и какую систему нужно к ней подключить. Этого достаточно, чтобы понять, через какой из трёх способов идти.
Написать мне
По теме: Интеграции, Интеграция с חשבוניות ישראל
SLAtech LTD