Интеграция с 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, а покупатель видит ошибку или неверный остаток.

Отсюда правила, по которым мы строим интеграцию:

  1. Данные, которые меняются редко (каталог, цены, клиенты), забираем по расписанию или по событию и держим у себя. В Priority за ними в реальном времени не ходим.
  2. В реальном времени отправляем только то, без чего нельзя обойтись: заказ, оплату, резерв.
  3. Каждый вызов умеет получить 429 и повторить позже с паузой, а не сразу.
  4. Очередь отправки хранится на нашей стороне. Если Priority недоступен, заказ не теряется, а ждёт своей отправки.
  5. Каждая операция идемпотентна: повторная отправка того же заказа не создаёт второй документ.

Где интеграции обычно ломаются

  • Два мастера одних данных. Клиента меняют и в 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