Добрый день!
В этой серии статей мы хотим рассказать об Ultima Businessware — нашей платформе для построения ERP систем.
Это первая, вводная статья, в которой расскажем об эволюции (т.е. среде и взаимодействии с ней) платформы и перечислим основные и самые интересные возможности платформы.
В следующих постах мы планируем рассказать о подробностях устройства и реализации этих самых возможностей. Кроме того, по ходу изложения мы будем делиться с особенностями организации процесса разработки у нас.
Эволюция
Сейчас модно после такого заголовка ставить ссылку на википедию, но мы, нон-конформисты, делать этого не будем. Собственно, здесь речь пойдет о среде, в которой возникла и развивалась платформа.
Так вот о среде — началось в 2004-м году на сервере с 4Гб памяти и 4-мя ядрами. А вокруг кружила толпа в 150 пользователей, которым очень надо было продавать товар. И покупать. И хранить, и доставлять и еще много чего. И, надо сказать, пользователи эти лупили в кнопки, не отвлекаясь на обед. Курили так и вообще на рабочем месте. Суммируя, мы имели тысячи транзакций в час. И это было не так страшно, как блокировки — эти толпы пользователей и еще клиенты через сайт гонялись за товаром.
Но, кроме этого, компания умудрялась быстро расти, что сопровождалось невероятно быстрым изменением бизнес-процессов и, как следствие, самого приложения.
Вот в такой среде и возникла первая версия нашей платформы — много пользователей, высокая транзакционная нагрузка, гонка за ресурсами, бизнес-процессы, не позволяющие аннигилировать блокировки, постоянные изменения и ошибаться нельзя. И единственный путь — увеличение производительности, сокращение времени блокирования, оптимизация пользовательского интерфейса, упрощение разработки чтобы успевать за изменениями.
Исторической правды для надо сказать, что та, первая версия платформы существует и эксплуатируется во многих компаниях до сих пор и, скорее всего, продолжит эксплуатироваться, ввиду того, что релиз платформы, случившейся в 2013-м году, несовместим с предыдущим. Про предыдущий релиз рассказывать не будем, ибо он будет доживать свой век у существующих клиентов. Ради статистики только приведем пару цифр:
- на нем работает около 4000 пользователей;
- на сайт ежедневно заходят около 200 000 клиентов.
Платформа
Трех-звенное приложение, сервер приложений полностью разработан с нуля, использует для коммуникации Zyan Project. Ведущий разработчик платформы является одним из его контрибуторов. Общая схема приложения приведена на следующей схеме:
Как видно, в качестве СУБД используется Oracle Database. Пока мы сохраняем поддержку 11gR2, однако с выходом новой версии ODA и ExaData планируем отказаться и перейти к 12c. Для слабонагруженных решений систему можно запустить на EnterpriseDB с Oracle Compatibility.
Столь жесткая привязка, нехарактерная для других решений автоматизации обусловлена необходимостью оптимизации производительности. Используя возможности Oracle Database мы смогли реализовать очереди внутри базы (немного о них мы расскажем в статье про сервер печати), ну и оптимизировать много внутренних процессов.
Сервер приложений и клиентское приложение — полностью managed приложения написаны на C# 5.0, т.е. используют LINQ и async/await (постараемся поделится своим опытом использования последних в следующих статьях). Собственно вся бизнес-логика реализуется в виде обработчиков различных событий тех или иных бизнес-объектов. Если Вы знакомы с 1С, то узнаете их — это справочники, документы и некий аналог регистра, у нас называется итогом.
Собственно клиентских приложений может быть много, но в платформу входит одно, в котором и встроена среда разработки и администрирования. Это GUI для описания структуры и взаимосвязей бизнес-объектов и редактор кода для скриптов. Скрипты на C#, аналог IntelliSense в редакторе присутствует.
На сервер приложений соответственно возложено исполнение бизнес-логики, преобразование реляционных данных в объекты системы и обратно, управление событиями и прочее.
Для иллюстрации стоит привести следующую диаграмму:
Ну и наконец сервер печати, уже трижды упомянутый, наша гордость в некотором смысле, отвечает за отправку на принтеры соответствующих печатных форм. Позволяет “виртуализировать” доступ к принтерам, организовать гарантированную доставку, убрать ожидание доступа до принтера (и как правило сократить время блокирования) и еще много чего. Подробнее расскажем в отдельной статье про его устройство.
Ну и далее про что мы собираемся рассказать:
- Управление транзакциями. Как было и как стало. Проблемы управления транзакциями при многопоточной обработке.
- Управление изменениями. Как у нас устроен контроль версий. Зачем он нужен, и что позволяет.
- Поддержка REST/SOAP. Как у нас организована их поддержка.
- Большой брат и история изменения данных. Почему Oracle Flashback Archive пока не может быть использован.
Вместо заключения
Мы постарались немного рассказать о нашей системе и заинтересовать Вас. В следующих статьях мы немного углубимся в детали, делать это в первой же статье — прямой путь к перегреву .
Кроме этого, постараемся о всех интересных возникающих задачах, не составляющих know-how или коммерческой тайны рассказывать в нашем блоге.
Автор: Rupper
