Скучища для профессионалов

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

1. Общее архитектурное решение
2. Надежность и защищенность данных
3. Масштабируемость
4. Согласованность данных
5. Методы ограничения доступа к данным
6. Среда разработки/инструменты разработчика
7. Мультиплатформенность
8. Прочие готовые сервисы платформы

Общее архитектурное решение

Система представляет собой 3-tire приложение. Схематично:

В качестве СУБД может использоваться как Oracle 11g так и PostgreSQL.

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

• Независимость бизнес-логики от клиентского приложения.
• Клиентские станции не имеют прямого доступа к серверу базы данных. Таким образом, при захвате рабочей
  станции невозможно получить прямой доступ к серверу базы данных.
• Централизованное обновление (клиентские приложения умеют обновляться с серверов приложений)

Ряд менее очевидных преимуществ будет освещен ниже.

Сервера приложений и пользовательское приложение написаны на языке C# платформы .NET Framework. Взаимодействие с серверами приложений через .NET Remoting. Существуют и другие клиентские приложения:

• Ultima::eStore, на базе которого реализуется веб-сайт (или вебсайты). Собственно, готовая платформа для интернет-магазина c полным набором сервисов. Коммуникация с БД происходит в онлайне — чтение и запись информации ведутся через вебсервисы (SOAP)
• Ultima::touchStore — работающее в онлайн режиме приложение, спроектированное для работы на терминалах самообслуживания, оснащенными touch-screen панелями. Красивый и удобный для тач-скрин интерфейс, реализующий функционал, аналогичный Ultima::eStore. Приложение написано на .NET Framework и общается с серверами приложений через .NET Remoting.
• Ultima::WMS — программно-аппаратная платформа, на базе которой реализуется система управления складом, удовлетворяющая потребностям конкретного предприятия.
  Поддерживаются различные схемы хранения — секционные, адресные, задачные, учет партий и серийных номеров, генерация штрих-кодов, маршрутизация заданий на комплектацию/хранение/перемещение сборных грузов, учет по местам сборных грузов, учет массо-габаритных параметров номенклатуры (линейные размеры, вес, количество в коробке, хрупкость и т.д.), включая расчет потребностей транспортной емкости для перемещений сборных грузов, автоматизированный учет физических ограничений работы склада (объемные и массовые лимиты хранения и обработки в разрезе складов, зон хранения, ячеек, номенклатурных групп т.д.), поддержка процессов поточной приемки/отгрузки для крупных и особо крупных партий и непрерывных процессов, etc.
  Программная часть написана на .NET CompactFramework. В качестве терминалов используются специализированные противоударные Wi-Fi КПК со сканерами штрих кодов (на текущий момент базовая рекомендуемая модель — Motorola MC3000, кое-где еще доступны хорошо себя зарекомендовавшие, но уже снятые с производства Motorola PPT8800.

Наличие набора разнообразных приложений в традиционной клиент-серверной архитектуре создает определенные сложности при поддержке согласованной модели бизнес-логики. Особенно серьезные проблемы возникают в связках с сайтом, реализующим полный функционал промышленного интернет-магазина. Реализация достаточно банальной бизнес-логики типа «Подарок, если заказ на сумму больше ХХХ» наталкивается на серьезные вопросы согласования на сайте и в основном приложении — как вычислить сумму заказа, как проверить что подарок есть на складе и прочее. Каждый разработчик сможет вспомнить подобные примеры из своей практики.

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

Несколько слов о терминальном доступе. Логическая схема организации представлена следующем рисунке:

Подобная организация позволяет предельно упростить администрирование сети. Рабочая станция может представлять собой дешевый тонкий клиент, без жесткого диска (используется флэш-память) и даже без кулера на процессоре.
То есть ломаться, в общем, нечему.

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

Надежность инфраструктуры (при условии эксплуатации серверов в качественном дата-центре и надежных резервированных каналов связи до него) возрастает на порядок. Как минимум на порядок увеличивается производительность труда системных администраторов.

Надежность и защищенность данных

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

Поэтому в целях сохранности данных уязвимые узлы дублируются. В данном случае это делается с помощью использования Physical Standby Oracle Database и кластера среди серверов приложений. Таким образом, падение даже главного сервера не приведет ни к потере данных, ни даже к остановке деятельности компании — система автоматически переключится на резервный сервер и продолжит работу. Аналогично выход из строя любого из серверов приложений не повлияет на работоспособность системы, клиентские приложения переключаться на работу с другими серверами приложений.
С веб-сайтом — в точности так же.

Плюс к тому:

• Платформа построена таким образом, что не хранит данных в клиентских приложениях (кроме Ultima::eStore — где хранимые данные ограничиваются минимально необходимой информацией для отображения функционального онлайн-каталога — собственно, по определению публичной информацией);
• Сайт общается с сервером приложений исключительно через веб-сервисы, не имея доступа к центральной СУБД.
  Таким образом, даже в случае успешной хакерской атаки злоумышленники не получат доступа к центральной
  базе данных ERP.
• Использование тонких терминальных клиентов позволяет полностью исключить хранение и возможность распространения конфиденциальных данных на рабочих местах;
• Реализация коммуникационного уровня поддерживает аутентификацию по принципу zero knowledge proof
  (по сети вообще не передается пароль в каком-либо виде, в том числе хеши пароля), симметричное шифрование передаваемых данных самыми современными алгоритмами (AES, 3DES и другие), прозрачное сжатие данных в потоке. Настройки шифрования и сжатия могут быть выставлены с точностью до пользователя или отдельного приложения — такая гибкость позволяет балансировать между дополнительной нагрузкой на CPU и необходимостью сжатия/шифрования данных для пользователей, подключенных через общественные незащищенные сети и/или при отсутствии широкополосного доступа к интернету.

Масштабируемость

Доказано на практике, что система обеспечивала приемлемый уровень производительности при нагрузке, генерируемой одновременно работающими 1500-2000 пользователей (и > 70 000 на веб-сайте). Безусловно, такая нагрузка обслуживалась не одним ПК, а кластером серверов приложений.
Сервера приложений умеют образовывать из себя кластер, обмениваясь необходимыми данными.
Кроме того, приложение распределяет нагрузку по серверам базы данных, используя для отчетов и некоторых запросов резервный сервер СУБД.

Сама схема данных представляет собой смешанную OLAP-OLTP схему с несколькими звездообразными образованиями. Таким образом, система с одной стороны не страдает избыточным блокированием, а с другой стороны — позволяет получать отчеты в реальном времени. Масштабирование системы легко производится увеличением либо количества дисковых поверхностей на главном сервере базы данных, либо добавлением резервных серверов для расчета отчетов, либо добавлением новых серверов приложений в кластер.

Инсайдеры знают, насколько ресурсоемкой операцией является разрешение dead lock. Нам удалось реализовать в ядре систему, которая сортирует все операции по изменению данных по внутренним кодам, что исключает возможность пересечения изменяемых данных двумя разными транзакциями,
и, соответственно, значительно снижает вероятность возникновения dead lock.

Согласованность данных

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

Логическая согласованность данных обеспечивается путем жесткого контроля выполнения двух принципов:

А. Принцип двойной записи, который контролируется ядром системы при проведении любой операции с ТМЦ.
Без прямого вмешательства в содержимое таблиц Oracle невозможно изменить данные так, чтобы этот принцип обойти. Помимо прочего, последовательная реализация двойной записи позволила имплементировать такую функцию системы, как честный расчет себестоимости по FIFO. Позволила реализовать в том смысле, что этот расчет выполняется в разумные сроки на рабочих объемах данных.

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

Методы ограничения доступа к данным

Любой компании необходимы инструменты разграничения доступа пользователей к данным.
Ultima ERP предоставляет два взаимодополняющих механизма управления доступом:

• Механизм ветвлений(или, используя внутренний термин, — механизм ролей) представляет собой обобщение традиционной идеи прав.
  Роли можно называть правами, тем более что во многих случаях они совпадают. Однако, используя механизм роли, можно реализовать на порядки более сложные варианты ограничения доступа. Границами служат исключительно пределы фантазии архитектора бизнес-процессов. Система помогает администратору системы, предоставляя в его распоряжение такие инструменты
  как объединение нескольких ролей в одну, явное исключение роли (семантика «дать права кладовщика без права инвентаризации»), механизмы поиска пользователей с заданными ролями и прочее. Основная идея «ветвления» заключается в том, что в зависимости от наличия или отсутствия роли выполняется та или иная «ветвь» программного кода. Например, роль может разрешать отгружать товар клиенту с непогашенной задолженностью. Понятно, что сформулировать такое «право» можно исключительно в виде соответствующего программного кода. Роли не всегда являются правом, поскольку обе ветви могут выполнять значимый код.
  Например — в зависимости от наличия роли показать разным пользователям разные формы ввода данных.
• Предикативный аппарат или ограничения на уровне строкМеханизм предикативного доступа позволяет задавать так называемые предикаты [отображения из произвольного множества во множество (0, 1), или, другими словами — функция, которая всегда возвращает либо 0, либо 1]. Этот механизм позволяет администратору формулировать сколь угодно сложные ограничения. Например, видеть только пользователей, которых создал текущий пользователь. Или видеть контрагентов, созданных коллегами по отделу, а редактировать только своих.
  Пространство для фантазии, опять же, — безгранично.

Среда разработки/инструменты разработчика

Вся совокупность объектов бизнес-логики, отчетов, обработчиков событий, экранных и печатных форм образует в системе так называемую конфигурацию. В свою очередь каждая конфигурация имеет свою историю версий. Сервер приложений в каждый момент времени работает с какой-то одной версией конфигурации. Механизмы версионирования конфигураций поддерживают все основные операции систем версионирования — Fork, Merge, Diff и т.д. Поддерживается пометка тегами версий конфигурации. Такая реализация позволяет каждому разработчику вести разработку в своей версии конфигурации, после чего переносить изменения в версию, которая будет использована на сервере для тестирования.
Как правило, в системе одновременно существует 3 версии:

• Production;
• Test;
• Development.

— помеченных соответствующими тегами. В большой команде удобно создать тег для каждого разработчика и помечать им текущую исправляемую версию. Отдельный тег можно создать для версии исправления "горячих" багов. Сервер может быть запущен в 2 режимах работы с версиями — статическом и динамическом. Первый режим используется для Production и Test сервера, он не позволяет менять структуру бизнес-объектов системы или каким-либо другим способом изменять конфигурацию, при этом сервер демонстрирует максимальную производительность. В динамическом режиме, используемом в основном разработчиками можно на лету менять конфигурацию системы.

Бизнес-правила формирования объектов, отчетов и прочего реализуются в виде классов на Visual Basic.NET, при этом разработчик получает все самые последние возможности языка — LINQ (для запроса и получения бизнес объектов), generics, lambda-функции и так далее. Для реализации более нестандартных задач сервер поддерживает MEF (Managed Extensible FrameWork) и публикацию служб (Singletone и SingleCall) через .NET Remoting. При этом платформа предоставляет службы для LINQ запросов с клиентских приложений для доступа к объектам системы, при этом реальная работа происходит на сервере приложений с проверкой всех прав доступа.

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

Любой объект системы может быть помечен тегом, значительно упрощая задачу переноса функций между версиями
(или даже отдельными конфигурациями) системы. Пометив например некоторые сценарии и объекты системы тегом «Жалобы и предложения» можно легко получить их список в дальнейшем для просмотра или экспорта.

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

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

Для программирования поведения системы предоставляется удобный редактор кода, поддерживающий подсветку синтаксиса и IntelliSense (в том числе по объектам системы), методы трассировки и отладки, multi-target логирование
(в том числе в EventLog) и так далее.

Для разработки клиентских (интранет) приложений реализован генератор форм по метаданным с возможностью изменения Layout формы. Это решение позволяет в большинстве случаев ограничиться декларативным описанием объекта системы. Для более сложных случаев, когда требуется реализовать сложное поведение формы, можно использовать, например, Visual Studio и набор готовых компонент для отображения данных.

В набор входят TextBox, DropDown, Label, Radio, Checkbox, Grid и еще около 50 компонент. Разработчик волен использовать любые сторонние компоненты.

Система предоставляет готовые инструменты для создания сложных параметрических отчетов с разнообразными фильтрами и детализациями. Разработчику достаточно сформулировать так называемый «базовый» запрос (OLAP-аналогия — куб) и указать, какие именно детализации и фильтры может использовать пользователь.
Система самостоятельно сгенерирует форму настройки отчета. Более того, если базовый запрос строится на таблице фактов, то достаточно описать таблицу фактов в терминах Измерения, Переменные и система сама построит все необходимые фильтры. При этом — зная структуру данных система позволяет формулировать запрос с «бесконечной детализацией». Для примера — допустим в системе описан итог «Остатки на складе» как куб с измерениями Склад (из справочника складов) и Товар (справочник товаров), переменные — Количество. Теперь представим, что в складе указан офис, а у офиса — город. Для товара, допустим, указан производитель, у производителя — страна. В этом случае система позволит выбрать в качестве детализации например Склад.Офис.Город и Товар.Производитель.Страна.

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

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

Платформа предоставляет инструменты для разработки печатных форм, причем данные для вывода печатных форм так же генерируются обработчиком. Это позволяет строить сколь угодно сложные печатные формы. Доступен экспорт в PDF, Word, Excel, TIFF, HTML.

Кроме механизмов доступа к данным через LINQ или через другие службы сервера приложений разработчик может выполнять произвольные SQL запросы. При этом если разработчик явно не изменял уровень доступа к данным, даже для произвольного SQL запроса будут применены все необходимые ограничения доступа. Результат запроса может быть получен как в Detached-data модели (например просто получить DataTable), так и в attached модели — требуется иногда для обработки сверхбольших (скажем миллион строк) результатов запроса. Кроме того, если в системе присутствует открытый для чтения Standby сервер, и текущий запрос не требует доступа к временным таблицам, то разработчик может запросить использовать соединение с одним из StandBy серверов.

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

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

Мультиплатформенность

Сервер приложений разработан таким образом, что способен выполняться как в .NET FrameWork в любой поддерживающей его Windows, так и на платформе Mono. Это позволяет запускать сервер приложений на серверах с Linux. Кроме того, сервер приложений (вместе с СУБД) может быть развернут на Amazon Cloud. Поддержка клиентских приложений на платформе Mono значится в перспективном планировании, реализация зависит от соответствующего развития самой платформы Mono.

Поддерживаются два наиболее удобных фреймворка для Unit-тестирования — NUnit и VSTest (удобен для разработчиков Visual Studio). Сами классы тестов инвариантны относительно платформы.

Прочие сервисы платформы

• Колл-центр. Система предоставляет интеграцию с двумя серверами IP-телефонии — Asterisk и FrontRange.
  В обоих случаях платформа поддерживает связь с сервером телефонии в двустороннем порядке, т.е. позволяет как передавать команды (набрать номер телефона, взять звонок из очереди и т.п.), так и реагировать на события (входящий звонок, создание очереди и прочее). Общая логическая схема связи с сервером телефонии представлена на следующем рисунке:
  
  
  Asterisk — бесплатный open-source сервер с низкой стоимостью владения, который закроет потребности любой компании с относительно невысоким потоком звонков (грубо, до 5000 звонков в день и 500 звонков в час)
  Начиная c 10 000 звонков в день или пике в 1000 звонков в час мы рекомендуем использовать коммерческий и более устойчивый к высоким нагрузкам FrontRange.
  
  
  
• Ultima::WMS. Платформа предоставляет API для:
  
  • — управления сканером штрихкодов (включение сканера, получение считанного ШК и т.п.);
  • — управления устройством (например проигрывание звука при сканировании штрихкода или при какой-либо ошибке);
  • — авторизации пользователей и проверки прав доступа;
  • — получения данных с сервера приложений;
  • — управления интерфейсом пользователя;
  • — автоматического обновления приложения;
  • — коммуникации с сервером приложений;
  • — готовые классы и методы для получения таблиц данных, документов, справочников;
  • — отображения редактируемых таблиц, меню и прочих элементов управления пользовательского интерфейса.
  
  Помимо того, Ultima::WMS скрывает детали передачи данных между клиентским приложением и сервером приложений, позволяя при разработке приложения сосредоточится на реализации экранной логики, передав подробности сериализации и передачи объектов платформе.
  
  Аналогично главному клиентскому приложению позволяет настраивать интерфейс пользователя.
  
  Для обработки промежуточного слоя логики взаимодействия с терминалами сбора данных в кластере может быть выделен отдельный сервис (или несколько). Выделенный сервис требуется при реализации сложной складской
  логики и может кешировать данные, снижая нагрузку на СУБД, а также рассылать события о изменении данных подключенным терминалам.
• Поддержка отправки SMS через GSM терминал или SMPP шлюз, с возможностью ограничения времени отправки в ночное время
• Поддержка отправки почты, в том числе HTML писем с вложениями
• Отправка уведомлений пользователям системы. В уведомлении можно указать ссылку на объект системы,
  который будет открыт (в уведомлении появляется специальная кнопка)
• Логирование истории всех изменений в объектах (пользователь, дата, объект). В любой момент времени можно узнать, автора изменений любого объекта системы
• Сервис печати, позволяющий идентифицировать принтеры в системе и организовать автоматическую печать, вести учет кто, когда, какую печатную форму и сколько листов на какой принтер распечатал. При использовании этого сервиса сокращается пересылаемый трафик в случае территориально распределенных офисов — на сервер печати передается только идентификатор принтера, печатной формы и необходимых данных. Передача по сети отрендеренной печатной формы исключается
• Доступ к прочим СУБД. Платформа предоставляет методы для доступа к MySQL

Вам действительно все это интересно и тем более понятно? — Приходите к нам работать, нам нужны вменяемые специалисты, мы платим им вменяемые деньги.