Как появление IEM-систем
сделало ERP устаревшими >

Как устроен процесс разработки,
и куда лазить руками

Как и в любой ERP-системе, задача разработчика:

  • описать структуру объектов, в которых будет храниться информация;
  • создать (если требуется сложная экранная логика, простые формы генерируются автоматически) формы для управления этими объектами;
  • описать их поведение, то бишь написать функции преобразования из одного в другое, обработать различные события (сохранение, удаление etc).

Используемые в Ultimate Solid наиболее важные для реализации бизнес-логики объекты принадлежат трем типам:

  • справочники;
  • документы;
  • итоги.

Кроме них еще существуют:

  • табличные части;
  • развязочные таблицы;
  • состояния документов;
  • константы;
  • переводы (поддержка интернационализации);
  • и прочее — всего около 40 видов объектов.

Структура и описание этих объектов формируют метаданные конкретной имплементации решения на платформе Ultimate Solid.

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

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

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

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

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

Абстрактно сформулированная бизнес-логика автоматизируемого предприятия практически трансформируется в скрипты, срабатывающие в те или иные моменты по соответствующим событиям.
На текущий момент в Ultimate Solid насчитывается 23 типа событий и, соответственно, потенциально вызываемых ими скриптов.
    • подготовки данных для печати;
    • обслуживания web-запросов по протоколам SOAP/REST;
    • генерации проводок;
    • генерации сложных отчетов;
    • unit-тесты;
    • команды над документом;
    • команды над списком документов;
    • команды над записью справочника;
    • команды над списком записей справочника;
    • обработка событий записи справочника;
    • обработка событий документа;
    • интерфейсы;
    • сервисы;
    • провайдеры колонок для отчетов;
    • периодические задачи;
    • драйверы итогов;
    • непривязанные команды;
    • общий обработчик событий справочника;
    • общий обработчик событий документа;
    • обработчик событий итога;
    • мобильные интерфейсы;
    • мобильные сервисы;
    • валидаторы транзакций.
Раскрыть список

В итоге деятельность разработчика определяется последовательностью действий:

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

Скрипты пишутся во встроенной среде разработки на языке C#, редактор поддерживает автоподстановку (аналог IntelliSense в MS VisualStudio). Cистема контроля версий позволяет независимо двум (и более) разработчикам вносить изменения в бизнеслогику. «Независимо» означает, что эти условные два (или более) разработчика могут вносить изменения в скрипты параллельно, не влияя на результат работы друг друга.
Изменять структуру объектов можно так же независимо, при определенных ограничениях, описанных в документации.
Полезная особенность встроенной системы версионирования — легко понять, какие, собственно, изменения произведены. Отслеживание изменений и выполненных заявок на изменение позволяет радикально сократить время на тестирование не в ущерб его качеству и полноте.

Экранная логика основного desktop-клиента реализуется в виде форм WinForms приложения.
Рисовать их можно в чем угодно, но самый, с нашей точки зрения, удобный вариант — в VisualStudio.
Для создания экранной логики Android устройств можно пользоваться Xamarin Studio. Естественно, разработка ведется не в чистом поле, а на основе предоставляемых компонент и инструментов.



 

Как появление IEM-систем сделало ERP устаревшими