Модель данных под ваш телематический бизнес: Business Data Repository

Телематическая платформа обычно начинается с привычного набора объектов: транспорт, устройства, водители, геозоны.

Реальная работа клиента этим почти никогда не ограничивается.

У логистической компании к этому добавляются прицепы, договоры, автобазы, типы грузов и записи о техобслуживании. Прокатная компания работает с филиалами, категориями техники, клиентами и объектами аренды. Системному интегратору бывает нужно связать данные из нескольких бизнес-систем с одним и тем же физическим активом.

И здесь жесткая модель данных платформы начинает мешать.

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

Все три способа работают. Но со временем каждый из них становится обузой.

Возьмем типичную логистическую связку: один грузовик может работать с разными прицепами, и на каждом прицепе может стоять свое оборудование — трекеры и датчики. Бизнесу важно знать не только, где грузовик, но и какой прицеп к нему сейчас прицеплен, какие устройства относятся к этому прицепу и какие эксплуатационные данные идут от каждой части связки.

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

Business Data Repository мы создаем как раз для того, чтобы описывать такую структуру напрямую. Интегратор задает грузовики, прицепы, оборудование, договоры или другие бизнес-объекты, связывает их явными отношениями и добавляет каждому типу те атрибуты, которых требует его работа. Тот же подход дальше переносится на строительный парк техники, прокатный бизнес, перевозки с холодовой цепью — и почти на любую другую модель под конкретного клиента.

За этой гибкостью стоит контракт — GraphQL Repository API. Он дает интеграторам единый способ описывать связанные бизнес-сущности и работать с ними, не дожидаясь изменений в схеме платформы. В планах — SDK для Kotlin, TypeScript и Python, чтобы с той же моделью было удобно работать из языков, на которых интеграторы уже пишут, и MCP-сервер поверх тех же сущностей, чтобы обращаться к ним из Navixy и из внешних инструментов.

Важная оговорка сразу: Business Data Repository API и SDK пока не вышли публично. Текущая документация — это документация предварительной версии, и до релиза структуры и поведение еще могут измениться. Так что читать этот текст стоит как рассказ о том, куда движется модель и почему это важно, а не как руководство по внедрению в продакшен уже сегодня.

Модель связанных операций

Business Data Repository API удобно представить как пять слоев:

1. Тип — описать объект в той форме, в какой он реально существует у вас в бизнесе.
2. Связь — соединить записи друг с другом как отношения, а не как строку текста.
3. Проверка — контролировать качество данных на уровне типа поля.
4. Справочник — один раз привести списки значений к единому виду и переиспользовать их везде.
5. История — хранить историю изменений, чтобы рабочий контекст не терялся со временем.

Пользовательские поля здесь тоже есть, но это только один слой.

Начинайте с бизнес-объектов, а не только со стандартных объектов платформы

Пользовательские поля полезны, но решают лишь часть задачи.

Иногда дело не в том, что машине не хватает еще одного атрибута. Вам нужен другой тип объекта в операционной модели.

Например, интегратору может понадобиться представить прицепы, перевозки, сервисные договоры, объекты аренды или вспомогательное оборудование как полноценные бизнес-сущности в той же среде данных.

Business Data Repository API устроен так, чтобы рабочее пространство могло задавать собственные типы в двух семействах объектов: типы активов и типы гео-объектов. Все из списка выше — прицеп, перевозка, сервисный договор, объект аренды, единица оборудования — описывается как ваш собственный тип актива со своими атрибутами. Зоны, площадки и участки обслуживания — это типы гео-объектов.

Сервисный договор больше не нужно втискивать в заметку к машине или держать только во внешней таблице: его можно описать прямо здесь, в одном связанном слое.

Это не значит, что каждый аккаунт начинается с чистого листа. При создании аккаунта клиент может сразу завести готовые типы сущностей — например, Vehicle и Cargo. Такие типы приходят с базовым набором полей, и этот набор расширяется так же, как у любого другого типа: смысл в быстром старте, а не в закрытой схеме.

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

Как Navixy работает с типизированными активами сегодня, описано в руководстве по работе с активами.

Связывайте записи, а не храните идентификаторы обычным текстом

Сами по себе записи дают немного. Польза появляется тогда, когда их можно осмысленно связать друг с другом.

Во многих системах поле вроде trailer в итоге хранит текстовое значение — например, TR-1048. Выглядит полезно, но это по-прежнему просто строка. Платформа сама по себе не знает, существует ли такой прицеп, что это вообще за объект и что еще с ним связано.

Repository API построен вокруг связей-ссылок между записями.

Это меняет то, что интегратор может построить:

• vehicle -> trailer
• equipment -> service contract
• shipment -> vehicle
• asset -> customer, где клиент — запись справочника или ваш собственный тип актива

Ссылка ведет на запись внутри вашей модели. Значит, клиент, поставщик или ответственная команда из последнего примера — это объект, который вы описали сами: запись справочника или тип актива, а не учетная запись в платформе. Определиться стоит заранее: от этого зависит, как во всей модели будут представлены люди и организации.

Различие техническое, но последствия у него практические. Как только связи описаны отношениями, а не свободным текстом, ваши рабочие экраны, правила и API работают со связанным контекстом, а не с разрозненными обрывками данных.

Добавляйте атрибуты под задачу каждого объекта

Когда типы объектов уже есть, пользовательские поля начинают приносить гораздо больше пользы.

У каждого типа появляется свой набор нужных ему атрибутов — вместо одного общего набора дополнительных полей на все случаи.

Прицепу обычно нужны VIN, ограничения по нагрузке и даты осмотра. Сервисному договору — номер, сроки действия и статус. Объекту аренды — поля по использованию и передаче клиенту.

Текущий предварительный контракт описывает систему типизированных полей с проверками: например, ограничения длины для строк, числовые ограничения для десятичных значений, допустимые значения для списков и ссылок. Благодаря этому часть бизнес-логики берет на себя сама модель, а не каждое клиентское приложение по отдельности.

Одно решение в этой конструкции необратимо, и его стоит закладывать в план заранее: тип поля фиксируется в момент создания. Название, границы проверки и обязательность остаются редактируемыми, а поле, которым вы перестали пользоваться, можно отправить в архив и вернуть обратно.

Исключение — сам тип. Перевести поле из текста в ссылку или из числа в список значений можно только одним способом: удалить определение и создать новое. Значения, уже записанные по старому определению, останутся в сохраненных данных, но за ними больше ничего не будет стоять. Относитесь к выбору типа так же, как к типу колонки в схеме, которую нельзя мигрировать: для интегратора, который проектирует модель, а заполнять ее реальными записями будут клиенты, это самое дорогое решение на этой странице.

Актуальные детали по мере развития предварительной версии — в руководстве Реализация пользовательских полей.

Используйте справочники, чтобы бизнес говорил на одном языке

Многие бизнес-атрибуты берутся из ограниченных списков значений: производители, категории работ, классы грузов, структура филиалов, центры затрат.

Без справочников в данных обычно появляется разнобой в написании:

• Bosch
• BOSCH
• Bosch GmbH

В Business Data Repository API есть пользовательские структуры справочников: такие значения приводятся к единому виду один раз и дальше переиспользуются во всех связанных объектах.

Чем больше моделей под конкретных клиентов, тем сильнее это влияет на качество данных: меньше ручной чистки, меньше расхождений и меньше интеграционных багов из разряда «одна сущность — три написания».

Храните контекст изменений, а не только текущее состояние

В операционных процессах текущего значения часто недостаточно.

Обычно спрашивают не о том, какое значение у объекта сейчас, а о том, каким оно было в момент, когда произошло событие.

В Business Data Repository API есть история сущностей и контекст изменений с прицелом на аудит: интегратор может строить интерфейсы, где важны хронология и происхождение значения, а не только последнее состояние.

Для внутренних операций, регламентированных процессов, разбора инцидентов и админ-инструментов, которые видит клиент, это заметно полезнее, чем плоский набор редактируемых полей.

Меньше связующего кода на типовых телематических операциях

Интеграторы много времени тратят на повторяющиеся операционные задачи — те, что находятся где-то между простым CRUD и полноценным движком процессов.

Хороший пример — замена устройства. Когда трекер переставляют с одного актива на другой, модель данных должна нормально отработать смену связи, а не вынуждать писать хрупкую многошаговую синхронизацию вокруг оторванных идентификаторов.

То же самое со случаями, когда на объекте несколько устройств и одно из них нужно явно отметить как основное.

Сами по себе это не громкие обещания. Но они отражают то же направление: описывать рабочие связи напрямую, а не заставлять каждого интегратора заново собирать их вокруг разрозненных идентификаторов.

Почему для этой модели подходит GraphQL

Business Data Repository API работает на GraphQL, и для моделирования связанных данных это удачный выбор.

Интегратор запрашивает ровно те поля и связанные объекты, которые нужны конкретному интерфейсу, вместо того чтобы собирать полные ответы с нескольких фиксированных эндпоинтов и потом сшивать их между собой.

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

Что из этого следует

Телематика живет внутри более широких бизнес-процессов. Машины связаны с прицепами. Техника закреплена за площадками. Активы привязаны к договорам и структурам клиентов. И у каждой компании эти связи свои.

Business Data Repository API мы создаем для того, чтобы этот бизнес-контекст можно было описать в модели: задать нужные структуры, связать их, проверять данные и отслеживать, как все это меняется со временем.

Практическая выгода для интегратора простая: меньше времени на борьбу с жесткой схемой вендора и больше свободы описать то, как клиент на самом деле работает.

Если хотите следить за развитием модели до релиза, начните с указателя документации Business Data Repository API и смотрите обновления в руководствах предварительной версии — в том числе про фильтрацию и сортировку по пользовательским полям в справочнике по фильтрации пользовательских полей.