В НОРБИТ мы занимаемся SRM-решениями. Сегодня расскажем про особенный для нашей команды проект — разработку BPMS-платформы NBT. Мы не просто создали бизнес-решение для заказчика, а разработали собственный продукт с нуля, — всё это подразумевает совершенно другой подход к проектированию, разработке, управлению командой, организации процессов доставки изменений и планирования выпусков.
В общем, в статье не только красивая КДПВ. Ещё вы узнаете:
- про наш опыт проектирования микросервисной архитектуры (выбор инструментов, подходов к использованию этих инструментов, а именно абстрагирование их использования);
- про разработку конструктора бизнес-объектов и внедрение в решение конструктора бизнес-процессов для обеспечения подхода Low-code development;
- про то, как мы организовали работу над проектом и избавили разработчиков от некоторых рутинных или отвлекающих их аспектов при работе над системой (абстрактные межсервисные взаимодействия, автогенерация кода, атмосфера в команде);
- и про то, какой мем помогал нам в сложные периоды.
Олмо Молла на Deep Food Tech Conference 2023
Источник
Наше подразделение в компании НОРБИТ занимается преимущественно автоматизацией закупочных процессов, для чего создает разного рода решения на платформе .Net.
Разработка таких решений начиналась еще на ASP.NET WebForms, затем новые версии этих решений создавались уже на базе ASP.NET MVC. Помимо разработок на .NET у нас были и есть другие проекты и решения, но все же разработки на .NET составляют около 80% от всех проектов подразделения.
Ограничения как ASP.NET WebForms, так и ASP.NET MVC предполагают, что для функционирования решений на этих платформах обязательно требовалось развертывание на ОС семейства Windows Server, а на стороне БД (базы данных) был реализован объем логики, не позволявший быстро и безболезненно перейти на СУБД, отличные от MS SQL Server. Это не предусматривало каких-то препятствий и сложностей до начала массового перехода на отечественное ПО.
Начиная с 2014-2015 годов, ИТ-рынок очень серьезно стал двигаться в сторону импортозамещения, и перед нами достаточно остро встал вопрос развертывания наших систем на операционных системах и СУБД, которые бы подходили под новые требования. По сути это стало вопросом № 1, который нам потребовалось решить, чтобы наши решения могли закрывать требования потенциальных заказчиков в долгосрочной перспективе.
При этом, имея сильные компетенции и достаточно большую команду .NET-разработчиков, начинать разработку нового кроссплатформенного ядра не на .NET не представлялось рациональным. Выход платформы .NET Core с открытым исходным кодом для нас оказался весьма кстати, в том числе из-за его совместимости с такими операционными системами, как Windows, Linux и macOS.
Вопрос № 2, который нам потребовалось решить, состоял в том, что большинство созданных ранее решений предполагали обязательное программирование для добавления атрибутов бизнес-объектов или изменения бизнес-процессов в системе.
Что такое бизнес-процессы? Модуль 1. Урок 1
Связан он с двумя аспектами.
- Для кастомизации наших решений в проектах мы обычно разделяли уровень ядра (базового решения) и какие-то особенности, связанные с конкретными внедрениями, запросами от заказчиков, выносили на уровень настроек. Но при этом реализация этих отличий, например, наличие отдельных атрибутов или бизнес-правил в том или ином объекте системы, все равно требовала написания отдельного кода, вынесение в настройки этих атрибутов или бизнес-правил.
- В последние годы все больше и больше набирает популярность подход Low-code development, по сути, встроенных в разного рода решения конструкторов, позволяющих «на лету» создавать и настраивать бизнес-объекты и бизнес-процессы.
Вопросов и проблем на входе в проект, о котором речь пойдет далее, было гораздо больше. Но эти три (импортозамещение и open-source, Low-code, низкий порог входа и быстрая скорость погружения новых членов команд) мы считаем ключевыми, которые нам предстояло решить.
Проектирование
Обдумывание этих вопросов привело нас к осознанию того, что нам нужен некий конструктор, в который смогут «играть» аналитики и конструировать систему (бизнес-объекты и бизнес-процессы) под потребности заказчика. Звучит дерзко, но ведь это намного интереснее, чем написать очередную систему для заказчика. По сути, мы решили сделать свой продукт в виде конструктора и развивать его.
Создание бизнес объектов это
Service Desk справке
Бизнес-объекты
Бизнес-объекты — это строительные блоки системы, представляющие все элементы, с которыми вы можете работать. Бизнес-объекты могут быть физическим элементами, такими как пользователи или активы, или могут представлять абстрактные элементы, например, цвета, проблемы, новых сотрудников.
Каждый бизнес-объект имеет набор атрибутов, который представляет информацию, необходимую вам для описания бизнес-объекта. Каждый бизнес-объект может иметь свой набор атрибутов. Вы можете связать бизнес-объекты вместе, чтобы не дублировать одну и ту же информацию. Это называют взаимосвязями .
Рекомендуется во время создания нового бизнес-объекта добавить атрибуты даты создания и обновления, а также создания и обновления пользователя. Если бизнес-объект не будет использоваться в качестве объекта коллекции, тогда необходимо добавить только атрибут даты создания.
Для получения информации о добавлении этих типов атрибутов см. раздел Типы постоянства.
Источник: help.ivanti.com
Бизнес с San Francisco
Java постепенно становится привычным инструментом для проектирования сложных распределенных вычислительных систем масштаба предприятия. Компания IBM, обладающая значительным опытом в области компонентного программирования, решила использовать свой опыт в разработке крупных систем, взяв за основу технологию Java и связанные с этим языком дополнительные спецификации, такие как JavaBeans. Так родился проект San Francisco. Первоначально он не соответствовал спецификации Enterprise JavaBeans, но сейчас IBM собирается привести все его элементы в соответствие со спецификацией
Java постепенно становится привычным инструментом для проектирования сложных распределенных вычислительных систем масштаба предприятия. Компания IBM, обладающая значительным опытом в области компонентного программирования, решила использовать свой опыт в разработке крупных систем, взяв за основу технологию Java и связанные с этим языком дополнительные спецификации, такие как JavaBeans. Так родился проект San Francisco. Первоначально он не соответствовал спецификации Enterprise JavaBeans, но сейчас IBM собирается привести все его элементы в соответствие со спецификацией.
Основная цель проекта San Francisco — дать разработчикам сложных программных систем базовые элементы для создания промышленных и бизнес-приложений. При этом IBM разделила все элементы проекта на три группы или слоя компонентов (см. рисунок):
- базовые классы и утилиты (Foundation);
- общие бизнес-объекты (Common Business Objects — CBO);
- основные бизнес-процессы (Core Business Processes).
Базовые классы и утилиты
Нижний уровень компонентов San Francisco должен поддерживать работу основных механизмов (таких как сущности — Entity), которые определены в спецификации Enterprise JavaBeans. Эти компоненты поддерживаются и в San Francisco. Спецификация Enterprise JavaBeans (см. JavaWorld Россия # 6, 1997) определяет сущности как ключевой элемент приложения, необходимый и для хранения данных, и для управления транзакциями.
Аналогичные объекты с примерно теми же свойствами есть и в San Francisco, и они реализованы в слое базовых классов и утилит. Причем в проекте IBM присутствуют как постоянные сущности с поддержкой многопользовательского доступа, механизмами защиты и долговременного хранения (в San Francisco это просто сущности), так и временные — однопользовательские (в San Francisco — зависимости).
Зависимости (Dependent) в San Francisco связаны с определенными сущностями. Они связаны только с одним объектом (сущностью) и не сохраняются вместе с ним. Они предназначены для увеличения производительности системы. Одним из примеров зависимости является кэш, который позволяет ускорить некоторые операции загрузки и сохранения.
Другой важной сферой применения зависимостей являются команды (Command), которые хранят бизнес-логику работы конкретной сущности. Вынесение логики за пределы сущности позволяет быстро настроить бизнес-процесс и в целом сделать систему более гибкой.
Кроме того, в San Francisco предусмотрены специальные классы — Collections и Query — которые позволяют объединять команды в последовательности, что еще более упрощает разработку бизнес-процессов. Все основные операции по созданию бизнес-объектов и управлению ими выполняются с помощью класса BaseFactory.
Например, с помощью метода Global.factory().begin() можно начать транзакцию, с помощью Global.factory().commit() подтвердить ее. Этот класс позволяет также управлять и постоянными сущностями. Класс BaseFactory также имеет аналогию в Enterprise JavaBeans.
Поддержка спецификации Enterprise JavaBeans гарантирует, что компоненты San Francisco можно будет использовать в различных средствах разработки, которые отвечают этому стандарту. Уже сейчас элементы San Francisco можно использовать в различных стандартных средствах отладки, таких как JBuilder и Visual Caffee.
Для идентификации постоянных сущностей в San Francisco предусмотрены специальные объекты — Handle, которые гарантируют уникальную идентификацию сущностей внутри распределенной системы. Эти объекты очень важны для функционирования системы, поскольку позволяют одним объектам ссылаться на другие, составляя тем самым структуры любой сложности.
Кроме того, с помощью информации, хранящейся в объекте Handle, можно в BaseFactory создавать новые постоянные сущности. Программист, использующий элементы комплекта San Francisco, не должен заботиться о том, где и как будут храниться постоянные сущности.
Чтобы сделать механизмы хранения сущностей как можно более автоматизированными и удобными, используется специальная утилита, позволяющая хранить сущности на различных носителях — в базе данных, файловой системе или упаковывать их в поток. Хранение сущностей в базе данных основывается либо на механизме ODBC, либо на представлении сущностей в виде связанных таблиц.
Использование механизма потоков, а через них и файловой системы опирается на стандарт POSIX. Поскольку сущности в San Francisco рассчитаны на работу в многопользовательском режиме, разработчикам этого проекта пришлось предусмотреть механизм блокировок. В San Francisco он представлен тремя типами.
Два из них — блокировка на чтение и блокировка на запись — работают так же, как и в других базах данных. То есть если одна программа обратилась к сущности с блокировкой по чтению (записи), то San Francisco гарантирует, что никакая другая программа не сможет прочитать (изменить) данную сущность, пока блокировка не будет снята.
Однако такая система блокировок может вызвать определенные конфликтные ситуации и остановить работу всей базы данных. Чтобы дать программисту возможность выбора, в San Francisco предусмотрен третий режим блокировок — так называемая оптимистичная (optimistic) блокировка.
В этом случае программа может изменить сущность только в том случае, если между чтением и записью данных никакая другая программа не меняла содержимого сущности. Если же изменение все-таки произошло, то при попытке записать новое значение возбуждается исключительная ситуация. С помощью перечисленных механизмов базовые классы и утилиты обеспечивают для приложений следующие службы: наименование; хранение и кэширование объектов; двухфазовая фиксация транзакций; система блокировок; разрешение конфликтов; организация очередей; аутентификация; авторизация на уровне задач; управление сеансами и серверами. Широкий спектр служб, которые реализованы в комплекте San Francisco, дают возможность строить на их основе надежные и достаточно сложные распределенные вычислительные системы. Самыми простыми примерами таких систем являются следующие слои San Francisco — бизнес-объекты и бизнес-процессы.
Бизнес-объекты (CBO)
Базовые классы являются фундаментом для создания бизнес-объектов, которые реализуют функции, необходимы для построения распределенных вычислительных систем. В слое бизнес-объектов San Francisco собраны наборы классов, которые объединяются по категориям. Все категории компонентов San Francisco делятся на три типа — основные (general) и финансовые (financial) бизнес-объекты и обобщенные механизмы.
Основная задача разработчиков бизнес-объектов — создать широкий набор общих элементов, которые можно было бы затем использовать для создания реального приложения. Причем разработчики бизнес-объектов уже могут не беспокоиться о низкоуровневых механизмах организации распределенных вычислительных систем, таких как мониторы транзакций, безопасность операций и поддержка многопользовательского режима. Все эти особенности должны быть реализованы на более низком уровне San Francisco — на уровне основных классов и утилит. Следует отметить, что разработчик системы может использовать только те элементы CBO, которые ему необходимы, а если перечисленных элементов не хватает, то он может написать свой собственный элемент. Перечисленные бизнес-объекты являются основой для бизнес-процессов — следующего уровня San Francisco, причем клиент, использующий различные механизмы бизнес-процессов, может и не задумываться о том, какие из бизнес-объектов при этом задействованы.
Бизнес-процессы
Основная цель разработки San Francisco — предоставить программистам как можно больше элементов для построения бизнес-приложений. Базовые классы определяют наиболее общие механизмы построения распределенных вычислительных систем. Бизнес-объекты задают основные компоненты бизнес-приложений и некоторые операции по их обработке.
Осталось определить способы взаимодействия между бизнес-объектами, и получится уже готовое бизнес-приложение. Собственно, создание основы для разработки бизнес-процессов и является задачей проекта San Francisco, поэтому высший, третий слой элементов состоит из базовых процессов, которые программисты смогут использовать в качестве шаблонов.
На конференции JavaOne компания IBM объявила о выходе нового варианта San Franscisco — 1.2, в котором реализованы следующие наиболее общие бизнес-процессы. Сводная финансовая книга (General Ledger), которая содержит основные механизмы поддержки финансовых бизнес-процессов предприятия, таких как финансовые журналы, подсчет балансов счетов, банковские проводки и процессы для автоматизации других элементов финансовой деятельности.
Компонент для управления хранилищем (Warehouse Management Component), в котором содержатся процессы для управления хранилищем: проверка качества хранимых объектов, их инвентаризация, планирование движения, подсчет остатков и многое другое. Компонент для управления ордерами (Order Management Component), который включает в себя элементы для управления финансовыми документами, такими как приходный и расходный ордера, дисконтные документы и другие.
IBM планирует расширить набор бизнес-процессов и объектов. Над созданием различных бизнес-процессов совместно с компанией IBM работают и ее партнеры. Причем некоторые из них в странах СНГ. В основном проект San Francisco ориентирован для создания финансовых бизнес-приложений и поддержки логистики.
Разработка на Java элементов San Francisco позволяет строить достаточно сложные и надежные вычислительные системы. Широта возможностей и удобство использования компонентного программирования делают San Francisco привлекательным инструментом для разработчиков распределенных вычислительных комплексов масштаба предприятия. Более подробную информацию об этом проекте можно найти в Internet по адресу http://www.ibm.com/java/sanfrancisco.
Где работает San Francisco
Разработка бизнес-приложений из элементов San Francisco возможна только на платформах Windows 95 и NT. Для этого рекомендуется следующая конфигурация ПК: процессор Pentium/166 МГц; оперативная память 64 Мбайт; дисковая память 250 Мбайт; монитор с разрешением 1024×768, 256 цветов. Требования для работы компонентов San Francisco на платформах Windows такие же. Кроме того, исполнять сервисные компоненты можно на платформе AIX. IBM также планирует перенести сервисные компоненты на другие ОС: IBM OS/400, Sun Solaris и HP-UX.
Элементы СВО
Основные бизнес-объекты:
Адреса (Address) — представление адресов;
Бизнес-партнеры (Business Partner) — хранение и классификация информации о бизнес-партнерах;
Классификация (Classification) — объединение объектов в группы по какому-нибудь признаку;
Компания (Company) — представление внутренней иерархии компании или организации;
Валюта (Currency) — хранение информации о валютах и курсах их обмена;
Календарь (Natural Calendar) — управление информации, связанной с датами;
Серии номеров (Number Series) — представление последовательности номеров и функции для их генерации;
Проект (Project) — объединение объектов, описывающих проекты компании;
Единицы изменения (Unit of Measure) — описание единиц измерения, используемых в системе.
Финансовые объекты:
Банковский счет (Bank Accounts) — хранение информации о банковском счете;
Приход-расход (Gain/LossAccounts) — учет всех операций с валютой;
Финансовые группы (Financial Batches) — объединение счетов по какому-либо признаку;
Финансовая интеграция (Financial Integration) — интеграция финансовой информации для представления ее в сводной финансовой книге предприятия;
Интерфейс к сводной финансовой книге (Interface of General Ledger) — предоставление доступа к сводной финансовой книге предприятия.
Обобщенные механизмы:
Кэшированный баланс (Cached Balances) — реализация механизма ускоренного вычисления финансового баланса;
Расширяемые элементы (Extensible Item) — представление элементов, которые могут быть быстро и легко модифицированы;
Ключи (Keys) — реализация механизма ключей;
Проверка результатов (Validation Results) — определение механизма для проверки финансовых результатов.
Источник: www.osp.ru
