Jira Assets и 1С: модель данных, поля и правила синхронизации
Содержание 12 разделов
Что нужно знать о API, лицензировании и рисках, прежде чем строить обмен данными между двумя системами
Кому и зачем нужна эта интеграция
Учёт оборудования — ноутбуков, серверов, сетевых устройств, лицензий на ПО — обычно ведётся в двух разных логиках одновременно. Бухгалтерия и финансовый учёт живут в 1С: там оборудование — это основные средства или малоценные активы с инвентарными номерами, амортизацией и материально ответственными лицами. ИТ-служба и служба поддержки при этом привыкли работать в Jira: там оборудование — это объект (asset), к которому привязаны заявки, инциденты, история обслуживания и связи с сотрудниками.
Когда эти два учёта не связаны, типичная проблема — расхождение данных: техника списана в бухгалтерии, но всё ещё числится «в работе» в Jira, или наоборот, новый ноутбук выдан сотруднику и заведён в Jira, но не отражён в 1С. Отсюда и запрос на интеграцию: одна система должна быть источником истины по финансовой части, вторая — по оперативной, а данные — синхронизироваться автоматически.
Материал будет полезен ИТ-директорам, руководителям сервисной поддержки и разработчикам, которые оценивают, стоит ли (и как) связывать Jira Assets с 1С, а также тем, кто уже строит такую интеграцию и хочет понять технические и юридические ограничения заранее.
Что такое Jira Assets простыми словами
Assets — это модуль внутри Jira Service Management, который хранит структурированную информацию об активах компании: оборудовании, лицензиях, помещениях, контрактах и любых других объектах, которые нужно отслеживать и связывать с заявками. До 2022 года модуль назывался Insight и был отдельным маркетплейс-приложением; затем Atlassian интегрировала его в JSM под новым названиемAssets (formerly Insight) is a feature within Jira Service Management that allows teams to track their assets, configuration items, and resources, functioning as a repository that houses hardware, software, office supplies, licenses and other items.
Важный нюанс: Assets — не самостоятельный продукт, который можно купить отдельно. Он поставляется только в составе определённых тарифов Jira Service Management [8][9]. До начала 2026 года модуль был доступен только на тарифах Premium и Enterprise; с обновлением тарифной сетки Assets появился и на Standard-плане с лимитом в 5 000 объектов, тогда как Premium даёт 50 000, а Enterprise — 500 000 объектов бесплатно, при превышении лимита включается плата за каждый дополнительный объект [9][10]. Это принципиально для расчёта стоимости владения: если единственная цель — учёт оборудования, компании придётся оплачивать целый тариф JSM (с инцидент-менеджментом, ИИ-функциями и прочим), а не только модуль активов.
Как устроена Jira Assets изнутри
Объекты, схемы и типы
Данные в Assets организованы в объектные схемы (object schema) — по сути, отдельные базы данных внутри Jira для разных категорий активов (например, «Компьютеры», «Сетевое оборудование»). Внутри схемы есть типы объектов (object type) с набором атрибутов, а каждый конкретный ноутбук или сервер — это объект (object entry) с уникальным ключом.
REST API и workspaceId
Для облачной версии Jira все обращения к Assets идут не напрямую к домену компании, а через отдельный API-шлюз Atlassian с обязательным идентификатором рабочего пространства — workspaceId, который нужно один раз получить через API и затем передавать во всех последующих запросахAssets REST API uses the workspaceId to identify your individual instance of Assets, and you must include the workspaceId when making any calls to the REST API. Базовый URL выглядит так: https://api.atlassian.com/ex/jira/{cloudId}/jsm/assets/workspace/{workspaceId}/v1/... [3][4].
Через API доступны, в частности, операции чтения и создания схемполучение списка схем требует OAuth 2.0 scope read:cmdb-schema:jira, а создание новой схемы выполняется POST-запросом с указанием имени и ключа схемы, а также создание отдельных объектов с указанием типа объекта и значений атрибутов [6]. Отдельная группа методов отвечает за массовый импорт данных, включая длительные фоновые процессы с отслеживанием прогресса выполнениязапуск импорта возвращает идентификатор процесса и требует OAuth-скоуп import:import-configuration:cmdb, а статус выполнения можно отслеживать через отдельный ресурс прогресса.
Авторизация
Для облачной Assets REST API актуальный способ авторизации — OAuth 2.0 (3LO) с конкретными scope для каждой группы операций; Basic Auth по логину и API-токену тоже встречается в документации и обсуждениях сообщества, но именно OAuth-подход рекомендован для новых интеграций и обязателен для части операций импорта [24][28].
Язык запросов AQL
Для выборки объектов по сложным условиям используется Atlassian Query Language (AQL) — язык запросов, специфичный для Assets, который позволяет фильтровать объекты по атрибутам, типу, связям с другими объектами. Именно AQL обычно используют, чтобы находить объекты для последующего обновления через интеграцию.
Российская специфика: сначала не техника, а статус продукта
Прежде чем проектировать обмен данными, стоит проверить три вещи, которые прямо влияют на целесообразность интеграции именно с Jira.
Статус Atlassian в России. Летом 2023 года Atlassian заблокировала учётные записи ряда российских пользователей и компанийНапомним, в августе 2023 стало известно, что аккаунты пользователей в сервисах Atlassian будут заблокированы в течение 30 дней, а компания официально прекратила работу с локальными клиентами и партнёрамиВ 2023 году Atlassian официально покинула российский рынок, прекратив работу с локальными клиентами и партнерами. Это означает, что для многих российских организаций легальное приобретение новых лицензий, продление подписки и официальная поддержка Jira Service Management (а значит, и Assets) уже недоступны или сопряжены с существенными рисками.
Сворачивание серверных версий. Параллельно Atlassian сворачивает весь линейный ряд self-hosted продуктов: поддержка Jira Server прекращена в феврале 2024 года, а с 30 марта 2026 года прекращаются продажи новых лицензий Data CenterУже с 30 марта 2026 года перестанут продаваться новые лицензии на продукты Data Center, включая Jira, Confluence и Bamboo, а в 2029 году локальные версии полностью снимаются с поддержкиС марта 2026 года компания прекратит продажи новых лицензий для Data Center, в 2028 году действующие клиенты не смогут приобретать продукты и расширять существующие лицензии, а полная поддержка версий Data Center прекратится в 2029 году. То есть даже компании, у которых уже развёрнута локальная инсталляция Jira с Assets, со временем останутся без обновлений безопасности.
Требования к ПО на объектах КИИ. С 1 января 2025 года указом президента госорганам и заказчикам запрещено использовать иностранное программное обеспечение на значимых объектах критической информационной инфраструктурыС 1 января 2025 года органам государственной власти и заказчикам запрещается использовать иностранное программное обеспечение на значимых объектах критической информационной инфраструктуры (КИИ) страны. Если компания относится к субъектам КИИ (телеком, финансовый сектор, транспорт, энергетика, промышленность и др.) и ведёт учёт оборудования значимых объектов в Jira, использование Assets на таких объектах формально запрещено, а не просто нежелательно.
Хранение персональных данных. Учёт оборудования почти всегда включает персональные данные — ФИО материально ответственного лица, сотрудника, за которым закреплена техника. При использовании облачной Jira эти данные обрабатываются на серверах за пределами России, что для ряда компаний создаёт дополнительные регуляторные риски по 152-ФЗ, вплоть до штрафов и блокировки сервисов при нарушенияхТипичные проблемы: отсутствие согласия на обработку, хранение данных за рубежом или использование несертифицированных систем.
Вывод из этих трёх пунктов простой: интеграция Jira Assets с 1С технически осуществима, но для новых проектов в 2026 году она скорее относится к категории «поддержка существующей инсталляции, пока это возможно», чем «стратегическое решение на годы вперёд». Дальше в статье рассматриваются оба сценария — и интеграция с уже работающей Jira, и переход на отечественный аналог.
Как 1С работает с внешними системами
Со стороны 1С для обмена данными используется несколько устоявшихся механизмов. HTTP-сервисы позволяют публиковать в 1С собственные REST-подобные эндпоинты, которые внешняя система может вызывать по HTTPИнтеграция 1С через REST API — наиболее востребованный сегодня подход: взаимодействие происходит через стандартные HTTP-запросы GET, POST, PUT, DELETE, с помощью которых можно читать, добавлять, изменять или удалять данные прямо из 1С. Также доступны SOAP-веб-сервисы для более строго формализованного обменаSOAP-веб-сервисы 1С надёжны и строго описывают структуру данных, до сих пор используются там, где требуется формализованный обмен с чёткой валидацией, например в банках и государственных системах и OData-интерфейс для чтения и изменения данных по стандартному протоколу.
Для более сложных сценариев — множество источников, очереди сообщений, единая точка мониторинга обменов — используется продукт «1С:Шина», который поддерживает разные способы подключенияПо способам подключения «1С:Шина» поддерживает разные подходы: SOAP-веб-сервисы, HTTP-взаимодействие, обмен файлами, прямой обмен с внешними СУБД через JDBC, а также обмен через брокеры сообщений, в частности по AMQP 1.0.
Что касается собственно учёта оборудования, готового модуля именно под класс задач Jira Assets в типовых конфигурациях 1С нет: основные средства (ОС) и малоценное имущество ведутся в 1С по разным правилам, и это создаёт свои сложности уже внутри самой 1СОсновная проблема учета в том, что способ работы в 1С с основными средствами и с малоценкой разный: у ОС есть уникальный инвентарный номер, а у малоценки — нет, малоценка заводится сразу несколькими позициями с одним инвентарным номером на всех, а по истечении срока полезного использования ОС переводится в малоценку, что требует смены справочника и инвентарного номера. Поэтому при интеграции важно заранее договориться, какая система является источником истины для какого поля: финансовые атрибуты (стоимость, амортизация, инвентарный номер по бухучёту) логично тянуть из 1С, а оперативные (кто пользуется, где физически находится, история заявок) — оставлять в Jira.
Варианты реализации интеграции
Вариант 1. Прямая интеграция через REST API
Самый гибкий вариант — написать интеграционный сервис (обычно middleware-скрипт или отдельный микросервис), который с одной стороны обращается к HTTP-сервису или OData-интерфейсу 1С, а с другой — к Assets REST API с OAuth-авторизацией. Сервис периодически или по событию сверяет объекты по ключевому полю (например, инвентарному номеру), создаёт недостающие объекты в Assets через /object/create [6] и обновляет изменившиеся атрибуты. Такой подход даёт полный контроль над логикой сопоставления полей и обработкой конфликтов, но требует разработки и сопровождения кода.
Вариант 2. Через интеграционную платформу (iPaaS/ESB)
Вместо собственного кода можно использовать интеграционную шину или no-code/low-code платформу, которая уже умеет работать и с 1С, и с внешними REST API — это снижает объём разработки, но добавляет зависимость от ещё одного инструмента и его лицензии. Похожий подход давно применяется для интеграции 1С с российскими системами техподдержки: обработка на стороне 1С обращается к внешнему API по токену, синхронизируя справочники и объектыПосле установки обработки необходимо указать адрес аккаунта и API-токен, привязанный к пользователю с ролью «Администратор»; в обработке реализована загрузка и синхронизация базы клиентов, контактных лиц и договоров из 1С во внешнюю систему.
Вариант 3. Плановый экспорт-импорт без API в реальном времени
Если частота изменений невысока (например, инвентаризация раз в месяц или квартал), не обязательно строить онлайн-обмен. Assets поддерживает импорт данных из CSV, в том числе для массового обновления полей у уже существующих объектовДля обновления объектов активов в нескольких рабочих элементах используется импорт из внешней системы через CSV-файл с колонками ключа рабочего элемента, темы и пользовательского поля, где объекты указываются в формате «workspaceid:objectid». Это самый дешёвый по разработке вариант, но он не подходит, если данные должны быть синхронными в режиме, близком к реальному времени.
Вариант 4. Переход на отечественный аналог с интеграцией с 1С
С учётом всего, что сказано в разделе про российскую специфику, для многих компаний более рациональный путь — не интеграция Jira Assets с 1С, а перенос функции учёта активов и заявок в российское ITSM-решение (например, Okdesk, SimpleOne, Naumen и другие системы из реестра отечественного ПО), у которых уже есть готовые интеграции с 1СПри выборе ITAM-решения стоит оценивать интеграционный потенциал системы — умение «дружить» с Discovery-сканерами, службами каталогов, ERP-системами на базе 1С и ITSM, а также наличие системы в реестре отечественного ПО как признак импортонезависимости. Например, у Okdesk есть готовая обработка для синхронизации данных с 1СВ обработке реализовано два сценария интеграции: загрузка и синхронизация базы клиентов, контактных лиц и договоров из 1С, а также сопоставление созданных ранее в системе компаний с базой компаний в 1С и складской учёт оборудования как отдельная функциональность продукта [44][45]. Такой путь требует миграции данных и процессов, но снимает риски, связанные со статусом Atlassian и требованиями к иностранному ПО.
Практические этапы внедрения
Независимо от выбранного варианта, порядок работ обычно похож:
- Аудит текущего состояния. Зафиксировать, что уже ведётся в 1С (основные средства, МЦ, кто отвечает за учёт) и что — в Jira Assets (схемы, типы объектов, атрибуты), найти расхождения.
- Определение источника истины по каждому полю. Финансовые атрибуты — из 1С, оперативные — из Jira; отдельно прописать, что происходит при конфликте значений.
- Выбор ключа сопоставления объектов. Обычно это инвентарный номер или серийный номер устройства — по нему сопоставляются записи в двух системах.
- Настройка доступов. В 1С — публикация HTTP-сервиса или OData с ограниченными правами; в Jira — регистрация OAuth-приложения с нужными scope для схем, объектов и (если требуется) импорта.
- Реализация обмена и обработка ошибок. Логирование неудачных запросов, повторные попытки, оповещение ответственных при устойчивых сбоях синхронизации.
- Тестирование на ограниченном наборе данных. Прогон на нескольких десятках объектов перед подключением полной базы, проверка граничных случаев (объект удалён в одной системе, но не в другой; смена инвентарного номера при переводе ОС в малоценку).
- Промышленный запуск и регламент поддержки. Определить, кто отвечает за интеграцию при сбоях, как часто выполняется полная сверка данных.
Ограничения, ошибки и риски
- Стоимость доступа к Assets. Модуль недоступен отдельно от платного тарифа JSM, а при превышении лимита объектов включается дополнительная плата за каждый объект в месяц [8][9] — это стоит закладывать в расчёт совокупной стоимости, а не только в стоимость разработки интеграции.
- Юридические риски использования иностранного SaaS. Для субъектов КИИ, госорганов и организаций с повышенными требованиями к ИБ прямое использование облачной Jira может противоречить действующим ограничениям [43].
- Отсутствие официальной поддержки и обновлений. Для локальных инсталляций Jira риск растёт год от года по мере сворачивания Data Center-линейки [9][15].
- Расхождение моделей данных. Разные правила учёта ОС и малоценного имущества в 1С не совпадают напрямую со структурой объектов в Assets, из-за чего наивное «поле в поле» сопоставление часто ломается при переводе актива из одной категории в другую [31].
- Одностороннее удаление объектов. Если актив списан в 1С, но интеграция не удаляет и не помечает архивным соответствующий объект в Jira, накапливаются «мёртвые души» — это одна из самых частых практических проблем при подобных обменах.
- Персональные данные в связке с активами. Привязка сотрудника к оборудованию означает обработку персональных данных, и при использовании зарубежного облака этот момент нужно отдельно учитывать в политике обработки ПДн [78].
Как выбрать решение
Если у компании уже есть развёрнутая и легально используемая Jira Service Management с Assets, нет статуса субъекта КИИ и не планируется масштабный переход на другие инструменты — точечная интеграция через REST API или готовый iPaaS-коннектор может быть оправданным решением на ближайшую перспективу.
Если компания относится к субъектам КИИ, находится в госсекторе, планирует развитие ИТ-инфраструктуры на годы вперёд или уже столкнулась с ограничениями доступа к Atlassian — разумнее рассмотреть перенос учёта активов и заявок в российское ITSM-решение с последующей интеграцией с 1С, благо для этого уже есть готовые практики и коннекторы.
Ни то, ни другое не требует обязательно сложной разработки: если задача — разовая выгрузка данных для отчётности, может быть достаточно регламентного экспорта CSV; если нужен обмен в реальном времени с обработкой ошибок и мониторингом — потребуется полноценная интеграция или внедрение специализированного решения.
Как может помочь «Пятый фактор»
Основная сложность подобных интеграций обычно не в самом факте вызова API, а в сопоставлении разнородных моделей данных, обработке конфликтов и в том, чтобы обмен продолжал работать надёжно и после того, как обе системы обновятся. Команда «Пятого фактора» может изучить текущий процесс учёта оборудования, оценить, что уместнее в конкретной ситуации — точечная интеграция с уже используемой Jira или миграция на отечественное решение с последующим подключением к 1С, — и помочь с разработкой, настройкой обмена данными или технической консультацией по выбору архитектуры.
Технически связать Jira Assets с 1С можно несколькими способами — от прямых вызовов REST API до регламентного обмена файлами. Но для российской компании в 2026 году отправная точка — не выбор протокола, а честная оценка того, на чём строить учёт оборудования вообще: продолжать ли использовать Jira с учётом статуса Atlassian на российском рынке и требований к ПО на объектах КИИ, или перейти на отечественную систему и интегрировать с 1С уже её. Ответ на этот вопрос определяет всю дальнейшую архитектуру решения.
Чтобы обсудить задачу или получить консультацию, свяжитесь с командой «Пятого фактора» любым удобным способом.
Источники
[1] levelup.gitconnected.com — Working with Jira Assets Rest API in Python: A Comprehensive Tutorial — https://levelup.gitconnected.com/working-with-jira-assets-rest-api-in-python-a-comprehensive-tutorial-5b9bb218b96e
[2] confluence.atlassian.com — Assets REST API — https://confluence.atlassian.com/assetapps/assets-rest-api-1168847897.html
[3] developer.atlassian.com — Assets REST API guide (workspace) — https://developer.atlassian.com/cloud/assets/assets-rest-api-guide/workflow/
[4] developer.atlassian.com — Jira Service Management Cloud REST API (Assets workspace) — https://developer.atlassian.com/cloud/jira/service-desk/rest/api-group-assets/
[5] support.atlassian.com — Link asset objects to Jira Cloud issues automatically — https://support.atlassian.com/jira/kb/workarounds-to-automatically-link-the-asset-object-to-jira-issues/
[6] support.atlassian.com — Create Assets objects via REST API — https://support.atlassian.com/jira/kb/how-to-create-assets-objects-via-rest-api-based-on-different-attribute-type/
[7] support.atlassian.com — How to import Assets object schema using REST API — https://support.atlassian.com/jira/kb/how-to-import-assets-object-schema-using-rest-api/
[8] assetmanagementforjira.com — Jira Asset Management Pricing: A Complete Guide for 2026 — https://assetmanagementforjira.com/blog/jira-asset-management-pricing-a-complete-guide
[9] assetmanagementforjira.com — Jira Assets: What every tier actually includes — https://assetmanagementforjira.com/blog/jira-assets-what-every-tier-includes
[10] atlassian.com — Service Collection Pricing — https://www.atlassian.com/software/jira/service-management/pricing
[11] community.atlassian.com — How to Access Jira Assets API — https://community.atlassian.com/forums/Jira-Service-Management/How-to-Access-Jira-Assets-API/qaq-p/3161175
[12] developer.atlassian.com — Assets REST API — Import — https://developer.atlassian.com/cloud/assets/rest/api-group-import/
[13] developer.atlassian.com — Assets REST API — Object Schema — https://developer.atlassian.com/cloud/assets/rest/api-group-objectschema/
[14] dev.ua — Atlassian покидает Россию — https://dev.ua/ru/news/atlassian-leaves-russia
[15] projecto.pro — Jira уходит в облако: почему российским компаниям пора искать аналоги — https://projecto.pro/blog/news/jira/
[16] blog.tutortop.ru — Как интегрировать 1С с внешними системами: API, REST, SOAP и микросервисы — https://blog.tutortop.ru/integratsiya-1s-s-vneshnimi-sistemami-cherez-api/
[17] binavigator.ru — Современная интеграция 1С: REST API, OData и асинхронность — https://binavigator.ru/articles/servisy-1s/sovremennaya-integratsiya-1s-rest-api-1s-shina-i-arkhitektura-besshovnykh-resheniy/
[18] evateam.ru — Atlassian прекращает продажу и поддержку on-premise версий Data Center — https://www.evateam.ru/blog/news-blog/atlassian-prekrashhaet-prodazhu-podderzhku-premise-versij/
[19] pravdaosro.ru — Запрет на использование иностранного ПО на объектах КИИ РФ вступил в силу — https://pravdaosro.ru/news/zapret-na-ispolzovanie-inostrannog/
[20] habr.com — Учёт ИТ-оборудования компании на основе справочника в 1С — https://habr.com/ru/articles/750256/
[21] habr.com — Системы управления ИТ-активами (ITAM): ТОП-10 решений для учета и контроля — https://habr.com/ru/companies/simpleone/articles/1031098/
[22] okdesk.ru — Интеграция Help Desk с 1С — https://okdesk.ru/blog/1c-integration/
[23] help.okdesk.ru — REST API Okdesk — https://help.okdesk.ru/knowledge_base/articles/rest-api-146
[24] itelon.ru — 152-ФЗ: как правильно хранить персональные данные в компании — https://itelon.ru/blog/kak-khranit-personalnye-dannye-po-152-fz/