Описание платформы БИП

Детализированное техническое описание

Общее описание

Белорусская информационная платформа (далее БИП) — набор программно-технических решений, предназначенный для построения масштабируемых распределенных облачных информационных систем различных уровней сложности.

Компоненты облачной информационной системы: для построения ИС на платформе БИП требуется определенный набор компьютерного оборудования, системного ПО и организации линий связи между её компонентами. В зависимости от назначения и размера системы можно выбрать оборудование необходимой мощности: начать практически с одного компьютера и наращивать количество и характеристики оборудования по мере роста потребности в вычислительной мощности.

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

1. Информационный ресурс вместо «фиксированного ТЗ»

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

Для этого разработана концепция «информационного ресурса» (ИР) — программно-технического модуля, работающего в рамках технологий платформы. Все служебные операции (безопасность, журнал операций, механизмы блокчейна) выполняются служебными компонентами платформы; в специализированный софт ИР выполняет нужную заказчику бизнес-логику.

2. Компоненты облачной информационной системы

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

Рис. 1. Архитектура облачной системы БИП: рабочие места, серверы приложений, сервер БД и файловый сервер

• Сервер базы данных (СБД) — ключевая компонента, предназначена для хранения данных.
• Файловый сервер (ФС) — хранение файлов, прикрепленных к объектам ИС.
• Сервер приложений (СП) — их столько, сколько требуется для удовлетворения требований пользователей в вычислительных мощностях. В настоящее время эксплуатируется более 10 СП разной мощности.
• АРМ пользователя — любые рабочие места, позволяющие запустить один из стандартных браузеров и подключиться к ИС по защищенному каналу связи из офиса или из дома.

Любая облачная система состоит из вышеперечисленных компонент и/или их аналогов.

Системный стек платформы: ОС Linux + СУБД PostgreSQL + HTTP-серверы Apache/nginx + платформенная исполняющая система BCLIP. Конкретный дистрибутив Linux подбирается под требования заказчика — платформа не привязана к одному дистрибутиву.

2.1. Сервер базы данных (СБД)

Назначение. СБД — «сердце» ИС, поскольку хранение и обработка данных — её ключевая функция. Надежность хранения и оперативность работы с данными — основные показатели успешности системы.

Требования к оборудованию. Выделение СБД в отдельную компоненту дает возможность использовать оборудование различного уровня мощности. Практически любой современный компьютер может быть применен как СБД начального уровня. Более мощные системы включают выделенные подсистемы хранения данных, кластеризацию и репликацию, распределение обработки между несколькими компьютерами в территориально распределенных ЦОДах — сохранность данных гарантируется вплоть до разрушения ЦОДа.

Системное ПО:

• ОС Linux — базисная ОС для серверов БД и приложений, рекомендуется и для АРМ. Открытая альтернатива проприетарным ОС без привязки к вендору. Допустима любая ОС, позволяющая работать математическому обеспечению СУБД.
• СУБД PostgreSQL — один из наиболее распространенных и мощных серверов управления базами данных, широко используется научным мировым сообществом для обработки очень широкого круга видов данных экстремально большого объема. Используется нашей компанией приблизительно с 2000 г., выбрана в частности для обеспечения лицензионной чистоты решений.

Универсальная интегрированная структура БД разработана компанией специально для построения распределенных ИС для совместной работы пользователей различных компаний на основании общего НСИ с глобальными объектами и возможностью выделения информационных блоков только для сотрудников отдельного предприятия. Это позволило:

• использовать единые глобальные данные — например, справочник МКБ-10 для медиков и справочник ТНВЭД для учета товаров;
• для каждого предприятия формировать структуры данных с доступом только для его сотрудников (основные средства, транспортные средства и т.д.);
• разработчикам использовать единый набор API для создания различных прикладных проектов по единым правилам с единой технологией контроля изменения данных; это повышает скорость разработки и надежность, позволяет консолидировать работу разработчиков и легко дополнять набор ИР;
• пройти одну аттестацию по безопасности ИС для всех включенных в неё проектов.

Технологии гарантированной сохранности данных

• Резервное копирование БД — стандартный способ при разрушении дискового пространства. Типичные ошибки: копирование в другую папку на том же диске (при разрушении диска пропадает и копия; RAID-массив не является несокрушимым) и репликация с частотой, неадекватной скорости обновления. Копию следует помещать на съемный носитель в удаленное место или в территориально удаленный ЦОД. Желательны система оповещения о резервировании и ответственный за контроль. Классическая технология требует минимум трёх копий — при терабайтных БД задача требует сложных технологий и дорогих устройств.
• Онлайновая репликация БД — копия ведется практически в режиме онлайн; резервная БД переводится в режим основного СБД за несколько минут, обеспечивая работу практически 24/7. Доступны стандартная репликация PostgreSQL и разработанная нашей компанией технология параллельной записи данных в два СБД. Онлайновая репликация не отменяет резервного копирования, но обеспечивает работу в режиме 24/7.
• Разделение информации на актуальную и архивную — при большом объеме накопленных данных актуальные и архивные данные разделяют: архив хранится на менее быстродействующих носителях и даже съемных устройствах для снижения эксплуатационных расходов.

Во всех разрабатываемых компанией ИС предусмотрены все варианты гарантированной сохранности. Пользователям облачных ИС дается 15-минутная гарантия сохранности данных: при разрушении носителей информации гарантируется восстановление данных с потерей максимум 15 последних минут до «катастрофы».

2.2. Сервер приложений (СП)

Назначение. СП — «мозг» ИС, обработка запросов пользователей. Вместе с СБД обеспечивает оперативность: внесение информации, изменение, формирование отчетности.

Оборудование. Любой современный компьютер как СП начального уровня. Мощные системы — кластеризация и распределение нагрузки между несколькими компьютерами в распределенных ЦОДах, что гарантирует работоспособность при DDOS-атаках на один из ЦОДов.

ПО: ОС Linux; HTTP-серверы Apache или nginx; исполняющая система BCLIP для исполнения CGI-модулей.

2.3. Файловый сервер (ФС)

Кроме данных в таблицах, информация хранится в виде файлов, «привязанных» к объектам ИС: тексты договоров, ТТН, графические образы. Традиционно — поля типа BLOB, у которых недостатки:

• увеличивает время обработки при сохранении (больше операций с диском и ОЗУ по сравнению с прямой обработкой файла);
• уменьшает «прозрачность» обработки — поведение СБД зависит от версии и планировщика, нет возможности модифицировать поведение системы.

Платформа предусматривает отдельный ИР «файловый сервер»: таблица Т185 с данными о файлах + выделенное дисковое пространство для самих файлов. Отказ от BLOB-полей дает:

• полную прозрачность процесса обработки файлов и программные ресурсы контроля и управления;
• гибкость размещения хранилища — от директории на СП до отдельного программно-технического комплекса с собственными требованиями к аппаратуре и процедурами сохранности данных.

2.4. АРМ пользователя

Среда разработки позволяет создавать приложения с тремя вариантами интерфейса:

• Текстовый — без графической оболочки, минимальные требования к рабочему месту, наивысшая производительность и отказоустойчивость. Работа через терминальные сессии, при размещении на СП — доступ по SSH: минимальные требования к каналу связи, максимальная надежность удаленной работы.
• Графический — библиотека GTK, полноценный GUI. Недостаток — ориентация только на ОС с поддержкой этой библиотеки (несколько версий Linux).
• CGI/WWW — приложения по HTTP. Сочетает надежность текстового интерфейса (отсутствуют ненадежные графические компоненты) с возможностями dHTML, CSS, JSON. Единственный недостаток — доступ только через браузер, что одновременно и главное преимущество:

• приложение автоматически кроссплатформенно — единственное требование к рабочему месту: установлен браузер;
• транспортный уровень обеспечивают промышленные протоколы HTTP/HTTPs и TCP/IP;
• доступны все варианты UI из мира интернета, поддерживаемые промышленными (не проприетарными!) протоколами HTTP и CSS;
• базисный браузер — FireFox, тестирование также для Opera и Chrome. Строго документированные возможности протоколов гарантируют работоспособность на всех платформах.

ПО АРМ: ОС Linux (открытая альтернатива проприетарным ОС). Для текстовых приложений — минимальные требования к оборудованию.

3. Каналы связи

Для приложений с единой БД нужны каналы связи с СБД и/или СП. Два основных потока данных: HTTP между браузером и СП, SQL-запросы к СБД по TCP/IP. TCP/IP применяется и при обмене с аппаратурой (например, обработка данных с анализаторов в «Лабораторной информационной системе»). Учитываются типы и объемы трафика.

Три уровня организации:

• Локальная сеть предприятия — все ресурсы (СБД, СП, АРМ) в локальной сети, трафик внутри неё. От простейшего хаба до сложных оптоволоконных сетей с маршрутизаторами. Подключение удаленных рабочих мест экономически нецелесообразно — стоимость и сложность поддержки растут нелинейно.
• Intranet корпорации — локальные сети предприятий объединены глобальными линиями. Появляются внешние каналы: проблемы надежности, расчет пропускной способности, альтернативные каналы для 24/7, каналы для мобильных рабочих мест. Сложность поддержки растет практически геометрически.
• Internet / ЦОД провайдера — весь круг проблем роста ИС решается оператором: единые рабочие места по единому стандарту, 24/7 поддержка, доступ АРМ через 3G-модем как основная или резервная линия, подключение всех предприятий по единой схеме без построения Intranet, аварийный доступ при отказе локальной сети/роутера.

Протоколы взаимодействия

Рис. 2. Уровни сетевых протоколов и отдельный набор форматов файлов

Прикладной уровень (высокоуровневые протоколы): HTTP / HTTPS, WebSocket, FTP, потоковая репликация БД и файлов.

Транспортный уровень: TCP/IP, UDP.

Сетевой / канальный уровень: Ethernet, WiFi.

Низкоуровневые интерфейсы и протоколы: COM (RS232, RS485), PRINTER, USB.

Форматы файлов (отдельно от протоколов): TXT, JSON, XML, DBF, HTML. Применение этих форматов при обмене данными со сторонними системами описано в разделе 12 «Организация взаимодействия со сторонними ИС».

4. Облачная ИС как набор информационных ресурсов

Платформа БИП — набор ИР, каждый решает определенную задачу обработки информации в общем пространстве данных с большим количеством пользователей. Понятие «ИР» введено взамен понятия «ИС»: ИС решает определенный круг задач определенным кругом пользователей, а БИП позволяет создавать набор информационных сервисов с доработкой текущих и созданием новых по мере потребностей. Технологии позволяют развивать ИС по методологии Agile; сервисы могут создаваться, сопровождаться и развиваться разными командами разработчиков под разные классы пользователей.

Методы развития сервиса:

• создание новых версий программных модулей бизнес-процесса с предоставлением доступа пользователю-заказчику;
• настройка экранных и отчетных форм под заявки пользователя без изменения программного модуля (заголовок отчета под пожелания заказчика и т.п.) — снижает требования к команде разработчиков и повышает надежность за счет меньшего числа модулей;
• ведение локальных НСИ самостоятельно заказчиком: глобальные справочники (МКБ-10, ТНВЭД) заполняются один раз и доступны всем; локальные (карточки складского учета) заполняет заказчик по своим правилам, без новой версии сервиса;
• организация взаимодействия с существующими ИС через REST API;
• размещение ИС в облачном ЦОД и работа по HTTP с интерфейсом dHTML позволяет предоставлять доступ не только корпоративным подразделениям, но и сторонним пользователям по модели SaaS — гибкая политика оплаты.

Хранение исходного кода и настроек в защищённой БД. В защищённой базе данных хранится не только информация, но и сама логика работы системы: исходный код бизнес-логики, а также раздельные конфигурации её настройки — отдельно для разных предприятий в одном облаке и отдельно для рабочих мест внутри одного предприятия, шаблоны документов с различными вариантами текста для разных предприятий и настройки интерфейса рабочего места. Исходный код компилируется непосредственно из базы данных. Поскольку на рабочих местах используется обычный браузер, обновление интерфейса и бизнес-логики у клиента происходит «на лету» — без каких-либо дополнительных действий по внедрению обновлений. Это обеспечивает централизованное управление версиями и контроль доступа.

Встроенная система документирования — интегрированная в платформу система для хранения всей документации в единой БД с предоставлением информации по правам доступа. Данные организованы древовидно: разделы нумерованы, имеют родителя и подчиненные, вложенность не ограничена. Программа чтения получает номер раздела как параметр — команды чтения размещаются в нужных местах. Каждому разделу назначается свой уровень доступа (нижний — «гость»). В текст кроме CSS-форматированного HTML можно вставлять ссылки на ИР с файлами, ссылки на графику, видео, аудио. Возможно формирование единого HTML-документа со всеми дочерними разделами для слитного просмотра.

5. Примеры проектов на базе платформы

• МИС «Лекарь» — наиболее известная медицинская ИС. Развёрнута в ЦОД БОТ: основные и резервные СБД, пять СП, выделенные сервер файлов и сервер регистрации событий. Репликация БД и динамическое перераспределение нагрузки на СП. Аттестация по безопасности уровня 3-ФЛ и 3-ЮЛ; есть версия с аттестацией 3-ДСП.
• АИС «Купец» — автоматизация бизнес-процессов ритейла. Модули с WWW, текстовым и графическим интерфейсом. Сеть магазинов с взаимодействием через центральную БД. Подключение пользователей по SaaS.
• РИАС «Кадры» — Республиканская ИАС автоматизации кадровой службы. Эксплуатируется в МЗ РБ, подключены все медицинские организации министерства. С 2016 — силами РНПЦ МТ в среде Intranet заказчика. Хранилище на PostgreSQL, программы в WWW-интерфейсе.
• СКУД «Кипарис» — система контроля и управления доступом, производитель ООО «Апекс-Реал». Контроллеры собственного производства и российских поставщиков. Хранилище на PostgreSQL, графический и WWW интерфейс, среда Intranet заказчиков.
• ЭО «Кипарис» — программно-технический комплекс электронной очереди на собственном оборудовании: монитор очереди, табло, компьютер управления телевизором.

Варианты построения ИР:

• ПАК по ТЗ заказчика с любым интерфейсом, приемо-сдаточные испытания, установка в среде заказчика, гарантийное обслуживание, доработки по частичным ТЗ;
• ПАК по ТЗ, установка в среде исполнителя, сопровождение на весь срок проекта, работа по Agile (только облачный интерфейс);
• подключение заказчика к существующему ИР исполнителя, обучение, работа по договору сопровождения (только облачный интерфейс).

6. Разработка прикладного ПО

Базисные языки: BCLIP (бизнес-процессы) и JavaScript (браузерный интерфейс). При использовании браузера как интерфейса допустимы все языки, поддерживающие CGI-протокол.

Текстовый интерфейс: доступны те же варианты доступа к данным, что и у графических приложений, но вместо RDS — протокол SSH: на порядок меньше трафика, экономнее каналы связи. Используется системными программистами для работы с удаленными СБД/СП. Платформа позволяет создавать текстовые приложения и использовать их для низкоуровневой работы на удаленных ресурсах. Базовый язык — BCLIP; где не требуется сохранение в БД — любые языки Linux.

CGI (Common Gateway Interface): программа не имеет непосредственной связи с пользователем; вызывается HTTP-сервером при запросе браузера, ответ конвертируется в HTTP-ответ. По каналу связи идет трафик HTTP — самый продвинутый в части безопасности и надежности, развиваемый протокол. Стандарт HTTP и HTML управляется W3C — гарантирована кроссплатформенность. Отсутствие прямого общения с оператором требует механизмов контроля работы; платформа (20+ лет опыта) выработала такие механизмы на языке BCLIP для разработки и сопровождения сложных ИС. Также допустимы любые языки Linux там, где не требуется сохранение в БД.

Графический интерфейс: приложение на АРМе получает прямой доступ к удаленному СБД по локальной сети/Intranet/Internet и передает SQL-запросы. Альтернатива — клиент-серверная архитектура с «удалённым вызовом процедур» (RPC): снижает требования к каналу, но усложняет разработку (два приложения вместо одного). Третий вариант — размещение приложения на СП и удаленный рабочий стол (RDS) на АРМе: по каналу передаются изменения графического образа (имеет аналоги и в других ОС).

7. Исполняющая система BCLIP: технические возможности

Происхождение и эволюция. Исполняющая система BCLIP — компилятор, совместимый с языком CA-Clipper (xBase), созданный на рубеже 1990–2000-х годов московской компанией «АйтиК» как свободный проект под лицензией GPL. Его задача — перенос банковских и корпоративных приложений, написанных для CA-Clipper 5.2/5.3 под DOS, на Linux/Unix без переписывания. Общий предок BCLIP и проекта Harbour — язык CA-Clipper (Nantucket, 1985; с 1992 года — Computer Associates). Harbour — более поздняя параллельная ветвь той же линии xBase, а не предок BCLIP.

BCLIP в платформе БИП представляет собой узкоспециализированную реализацию, оптимизированную для работы в Linux-инфраструктуре Enterprise-уровня и интегрированную с СУБД PostgreSQL.

Языковая парадигма: лаконичный синтаксис для работы с БД и элементы метапрограммирования. BCLIP ориентирован на декларативное описание бизнес-логики и позволяет компактно выражать операции с данными. Ключевые возможности:

Операторы работы с базами данных — лаконичный синтаксис для создания экранных форм ввода данных с валидацией:

USE Customer SHARED NEW
@ 1, 0 SAY "CustNum" GET Customer->CustNum VALID Customer->CustNum > 0
READ

Оператор макросов (runtime-компилятор) — выполнение компиляции и исполнения произвольного выражения в рантайме, динамическое формирование обращений к полям БД, генерация кода на основе пользовательского ввода:

&( "Customer->" + cFieldName )
&( cExpression )

CodeBlocks (замыкания) — захват переменных из внешнего контекста, поддержка замыканий, делегатов и функциональных объектов:

{ |x, y| x + y + nExternalVar }

Объектно-ориентированное программирование — классы, наследование, инкапсуляция, полиморфизм:

CREATE CLASS Person
    VAR Name
    METHOD New( cName )
    METHOD Describe()
ENDCLASS

Архитектура подключения к базам данных. BCLIP реализует архитектуру Replaceable Database Drivers (RDD), обеспечивающую независимость от конкретной СУБД: PostgreSQL (основная), MySQL, SQLite, Firebird, Oracle, ODBC, а также совместимость с форматами xBase (DBF, DBFNTX, DBFCDX).

Лицензия и открытость. BCLIP распространяется под лицензией GPL (свободный проект «АйтиК»). Это обеспечивает независимость от вендора, доступ к исходному коду и задокументированный синтаксис, совместимый с CA-Clipper.

Обоснование выбора. BCLIP выбран в качестве исполняющей системы платформы БИП по следующим причинам:

1. Проверенная надёжность — технология эксплуатируется с 1985 года, миллионы приложений в банковской, страховой и управленческой сферах.
2. Высокая производительность — компилируемый код с возможностью runtime-оптимизации.
3. Масштабируемость — поддержка множества серверов приложений.
4. Открытость — отсутствие vendor lock-in, полная отчуждаемость кода.
5. Импортонезависимость — открытый исходный код, независимость от вендора.
6. Совместимость — возможность переноса кода с других xBase-диалектов (Harbour, xHarbour, FlagShip, FoxPro).

8. Структура базы данных

Рис. 3. Типы таблиц платформы и модель разграничения прав доступа

В БД платформы предусмотрены таблицы четырех типов (плюс кодификаторы), отличающиеся способом внесения, уровнем доступа и правилами хранения:

• Кодификаторы T0 — НСИ, общая для всех участников; служебная информация. Изменять могут только сотрудники разработчика ИС.
• Филиальные таблицы T1 — информация конкретного учреждения с возможностью выборки по всем учреждениям в одном SQL-запросе. Доступ — только сотрудникам конкретного предприятия.
• Филиальные таблицы T2 — информация конкретного учреждения без необходимости выборки по многим учреждениям. Доступ — только сотрудникам конкретного предприятия.
• Глобальные таблицы T3 — НСИ, общая для всех. Данные одного предприятия могут накапливаться в больших объемах, не влияя на быстродействие системы для остальных участников.
• Ежегодники учета событий T4 — общая НСИ, таблицы создаются для каждого года (месяца), информация автоматически распределяется по таблицам по дате. Предохраняет систему от переполнения; «старые» таблицы можно размещать на внешних носителях.

Операции изменения данных отражаются в журнале операций — возможность «разбора полетов» о причинах появления неверных данных. Ответственность за достоверность данных таблиц первого типа определяется должностными обязанностями сотрудников службы сопровождения.

9. Соответствие требованиям безопасности информации

Рис. 4. Уровни защиты и аттестация ОАЦ

Различные информационные системы, развёрнутые на платформе БИП, неоднократно проходили аттестацию на соответствие требованиям классов защиты 3-ин, 3-юл, 3-спе и 3-ДСП. Аттестации подлежат конкретные развёрнутые ИС, а не операционная система и не платформа как таковая: в процессе аттестации определяются требования к работе ИС и способам подключения пользователей. Если организация подключается к уже аттестованному решению, собственная аттестация ей может не потребоваться; новое решение, созданное на базе платформы, проходит облегчённую аттестацию. В результате создаётся защищённое информационное пространство для обработки персональных, медицинских и специальных данных.

Опыт работы с белорусскими VPN-решениями. Компания имеет опыт построения защищённых каналов связи на базе белорусских VPN-решений: Bel VPN, itVPN, SCrypto. Оказывается техническая поддержка по их настройке и сопровождению.

Требования по подключению: каналы связи, проходящие через интернет, должны быть защищены от стороннего воздействия аттестованным способом; каждая локальная сеть и каждое рабочее место — через защищенный канал; по незащищенному каналу доступа к ИС нет.

По закону пользователи определяют ответственного — «офицера безопасности». В результате предприятие обрабатывает персональные данные своих клиентов в защищенной ИС и освобождается от необходимости самостоятельно выполнять мероприятия по аттестации своей локальной ИС. Выполняются требования нормативного документа ПРИКАЗ ОАЦ ПРИ ПРЕЗИДЕНТЕ РБ от 20 февраля 2020 г. N 66 «О мерах по реализации Указа Президента РБ от 9 декабря 2019 г. N 449».

10. Обеспечение сохранности информации и работоспособности

Рис. 5. Параллельная репликация между двумя ЦОД и переключение при отказе основной площадки

Аппаратные сбои СБД (вплоть до разрушения дисковой подсистемы):

• утеря данных — подсистема репликации гарантирует по условиям договора сохранность информации, внесенной более 15 минут назад;
• остановка ресурса — резервные СБД восстанавливают работоспособность максимум за полчаса. Это на порядок надежнее стандартного ежедневного копирования.

Нарушения работы ЦОДа: причина более редкая, но последствия разрушительные (пример — пожар ЦОДа в Одессе). Защита — репликация БД: одна из реплик в другом ЦОД. При выходе из строя основного ЦОДа ИС перераспределяется на запасные площадки, перенастройка занимает около часа. Пользователям достаточно зайти с резервного адреса без дополнительных действий.

Ошибки сотрудников:

• неправильно выполненная операция — механизм «транзакционности»: все изменения выполняются «пакетом»; при выявлении ошибки ни один байт не сохраняется, даже если программа уже изменила какие-то записи; пакет изменений — «транзакция»;
• успешная операция с неправильными (но логически непротиворечивыми) данными — пакет фиксируется в журнале операций и может быть отменен уполномоченным сотрудником (сторнирование) с возвратом к состоянию «до операции». Используется встроенный механизм блокчейн, который не даст отменить операцию, если её результаты уже были использованы для выполнения следующей.

Ошибки ПО: частично выполненная операция предотвращается транзакционностью; некорректно выполненная — исправляется сторнированием через журнал операций с последующим заказом исправления у поставщика.

Работа 24/7: резервные СБД и резервные СП размещены в разных ЦОДах; для СП — динамическое перераспределение нагрузки; для СБД — перераспределение запросов уже на уровне ПО в зависимости от их типов. В совокупности это позволяет наращивать мощность добавлением количества и мощности компьютеров.

11. Разграничение прав доступа

• Доступ к ИС — аппаратный ограничительный уровень: защищенный канал связи; локальная сеть предприятия также должна быть аттестована.
• Права предприятия — уникальный номер и выделенная ниша данных. Доступ к данным другого предприятия — только в определенных владельцем границах; часть данных — в публичном доступе. Главный критерий участия — первичность в цепочке обработки данных.
• Тема, роль, режим — терминология: «Тема» — название ИР или его части (например, «Кадровый учёт»); «Роль» — подмножество операций внутри темы («Настройка работы подсистемы», «Текущая работа с персоналом»); «Режим» — набор программ внутри роли («Работа с актуальной карточкой сотрудника», «Прием на работу» и т.п.).

12. Организация взаимодействия со сторонними ИС

Файловый обмен — выгрузка/вкачка данных. Поддерживаемые форматы вкачки:

• TXT — текстовый файл с согласованным форматом;
• JSON — текстовый файл в формате JSON согласованной структуры;
• XML — текстовый файл с согласованным перечнем полей в стандарте XML;
• DBF — формат стандарта xBase, хорошо структурированный.

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

Полный перечень протоколов и форматов приведён в разделе 3 «Каналы связи» (подраздел «Протоколы взаимодействия»).