* Опытному разработчику

• * Управление стилями окон
• * Учётные регистры
• Планировщик задач
• Макросы в шаблоне чека
• Создание HTTP Web-сервисов
• Домино8 в режиме WEB- сервера. Замеры производительности.
• Обмен с весами

* Управление стилями окон

Этот документ описывает управление стилем (внешним видом) для окон стандартных интерфейсов Домино8 - главного окна (main window), табличного вида просмотра (browse) и табличного вида просмотра со встроенной формой фильтра (browse filter), формы ввода (form) и иерархического древовидного вида просмотра (tree)

Применимо начиная с версии ядра 11.7.4.1

Файлы конфигурации, определяющие стиль окон

Параметры, которые описывают стиль (дизайн) окон интерфейсов, задаются в xml-файлах конфигурации в схеме design. Система считывает эти файлы, используя порядок просмотра каталогов, заданный в корневом файле описания конфигурации bin\config.xml для схемы с id=2 (design). Стандартное описание схемы design

<scheme id="2" name="design" log_="design">
  <path base="root"    dir="config\design.new" save="1" />
  <path base="root"    dir="config\design" collection="1"/>
  <path base="product" dir="config\design" collection="1"/>
  <path base="bin"     dir="config\design" collection="1"/>
  <path base="root"    dir="config\design" />
  <path base="product" dir="config\design" />
  <path base="module"  dir="config\design" />
  <path base="bin"     dir="config\design" />
</scheme>

Стандартный стили находятся в каталоге bin\config\design, и могут переопределяться на уровне проектного модуля, проектного решения в целом (продукта) и подкаталога config\design каталога установки продукта.

Каждый интерфейс имеет свой строковый идентификатор стиля. Стандартные идентификаторы:

• Interface - общие параметры для всех окон
• MainWindow - главное окно приложения
• StandardBrowse - табличный вид просмотра
• StandardBrowseFilter - табличного вида просмотра со встроенной формой фильтра
• StandardForm - форма ввода
• StandardTree - иерархический древовидный вид просмотра
• MessageBox - окно с сообщением
• PrjEditTree - редактор проекта

Соответственно xml-файл конфигурации с параметрами стиля должен иметь имя, совпадающее с идентификатором. Корневой тег файла

<object name="ИдентификаторСтиля">

Параметры задаются тегом

<p n="Имя параметра" v="Значение параметра"/>

Параметры стиля читаются из раздела с соответствующим стандартным идентификатором. Если параметр не описан, то в качестве значения по умолчанию  берется значение из раздела (файла) c идентификатором Interface.

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

Описание шрифтов, цветов и размеров

Шрифт элемента описывается в файле конфигурации четверкой параметров гарнитура, размер, вес и стиль. Пример описания шрифта для элемента browse:

<p n="browse.font-family"   v="Arial" />
<p n="browse.font-size"     v="8pt" />
<p n="browse.font-weight"   v="normal" />
<p n="browse.font-style"    v="normal" />

Вес (font-weight) может быть thin, extralight/ultralight, light, normal/regular, medium, semibold/demibold, bold, extrabold/ultrabold или heavy/black. Через знак / перечислены эквивалентные нотации, т.е. normal и regular - это одно и то же.

Стиль (font-style) может быть normal или italic.

Значение цвета задается в виде шестнадцатеричного RGB значения в css- нотации. Пример задания цвета border-color для элемента cell:

<p n="cell.border-color" v="#96AECF" />

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

<p n="cell.color"           v="#000000" />
<p n="cell.color:focus"     v="#000000" />
<p n="cell.color:inactive"  v="#B0B0B0" />
<p n="cell.color:disabled"  v="#B0B0B0" />

Размеры, отступы и границы задаются в числовом виде в абсолютных единицах (экранных пикселах), либо в поинтах (pt). Для задания размера в поинтах нужно сразу после значения добавить pt.

Отступы и границы задаются 4 значениями (rect) в css- нотации (сверху, справа, снизу, слева). Можно задать 3 значения (сверху, справа-слева, снизу), 2 значения (сверху-снизу, справа-слева), либо вообще одно значение (все 4 стороны одинаково). Пример задания отступов внутри элемента cell:

<p n="cell.padding" v="3,4,3,4"/>

Структура окон и общие параметры

Все окна имеют настраиваемую рамку (frame), заголовок (caption) и панель инструментов (toolbar). Рамка является самым внешним элементом окна и позволяет менять его размеры. По внешней стороне рамки можно отрисовать контрастную границу (border). Заголовок находится внутри рамки в верхней части окна. Панель инструментов может находится внутри рамки с любой из четырех сторон. Если панель сверху, то она размещается под заголовком.

Имена параметров рамки окна начинаются с префикса «frame.».

Имя параметра	Что описывает
visible	Видимость рамки окна. Тип boolean, допустимые значения true/yes/1 и false/no/0
size	Ширина рамки окна (rect), отдельно по всем сторонам
border	Толщина контрастной границы (rect)
background-color	Цвет фона у рамки окна
border-color	Цвет контрастной границы

Окно может быть в двух состояниях - активное и неактивное (active и inactive). Цвета для состояния active задаются описанными в таблице параметрами -color. Для состояния inactive цвета задаются с суффиксом :inactive.

Заголовок окна - это прямоугольный элемент с текстом и стандартными кнопками управления. Для заголовка можно задать видимость (visible), отступ от рамки окна (spacing), рамку (border) и отступ для текста внутри заголовка (padding).

Высота заголовка рассчитывается автоматически с учетом отступов, толщины рамки, высоты текста и кнопок. Можно задать высоту явно параметром height.

Отступ вокруг рамки заголовка, заданный параметром spacing, закрашивается цветом фона рамки окна (frame.background-color). Можно указывать отрицательные значения отступа (втяжку) - в этом случае заголовок будет наезжать на рамку окна.

Имена параметров заголовка начинаются с префикса «caption.».

Имя параметра	Что описывает
visible	Видимость заголовка окна. Тип boolean, допустимые значения true/yes/1 и false/no/0
spacing	Отступы от рамки окна (rect), отдельно по всем сторонам
border	Толщина рамки (rect)
padding	Отступ внутри заголовка (rect)
height	Высота заголовка фиксированная
text-align	Выравнивание текста внутри заголовка ([left]/center/right)
font-…	Четыре стандартных параметра, шрифт заголовка
color	Цвет текста заголовка
background-color	Цвет фона заголовка
border-color	Цвет рамки

Заголовок вместе с окном может быть в двух состояниях - активное и неактивное (active и inactive). Цвета для состояния active задаются описанными в таблице параметрами -color. Для состояния inactive цвета задаются с суффиксом :inactive.

Внутри заголовка размещаются стандартные кнопки управления. Слева кнопка системного меню (menu), справа кнопки закрытия (close), разворачивания (maximize) и сворачивания окна (minimize). Кнопки сворачивания и разворачивания есть только у главного окна приложения.

Кнопка управления - это прямоугольный элемент, для которого можно задать отступ от рамки заголовка (spacing), рамку (border) и отступ для пиктограммы внутри кнопки (padding).

Система автоматически рассчитывает размер (ширину) кнопок с учетом отступов, толщины рамки, и ширины пиктограммы. Все кнопки при автоматическом расчете будут одинаковой ширины (по максимально широкой кнопке). Параметр width позволяет явно задать ширину для конкретной кнопки, причем система автоматически увеличит ширину, если пиктограмма с учетом отступов не помещается в указанный размер.

Пиктограмма кнопки может быть либо иконкой, либо символом. В первом случае указывается имя ico-файла и размер, во втором шрифт и код символа. Если  задано относительное имя ico-файла, то полный путь считается относительно каталога файла конфигурации. Символ задается либо явно, либо как шестнадцатеричный код unicode в формате #XXXX.

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

Имена общих параметров для всех кнопок заголовка начинаются с префикса «caption.button.». Имена параметров, специфичных для конкретной кнопки, начинаются с префиксов «caption.button.menu.», «caption.button.minimize.», «caption.button.maximize.» и «caption.button.close.»

Имя параметра	Что описывает
spacing	Отступы от рамки заголовка (rect), отдельно по всем сторонам
border	Толщина рамки (rect)
padding	Отступ внутри кнопки (rect)
width	Ширина кнопки
icon	Имя файла иконки, символ или код символа для пиктограммы.
icon.size	Размер иконки в пикселях, от 16 до 96. Может быть [small]/medium/large/huge, эквивалентно 16/24/32/48. Иконки всегда квадратные, т.е. 16х16, 24х24…
font-…	Четыре стандартных параметра, шрифт пиктограмм. Только общий на все кнопки.
color	Цвет шрифтовой пиктограммы
background-color	Цвет фона кнопки
border-color	Цвет рамки

Кнопка может быть в трех состояниях - нормальное, выбранное и нажатое (normal/selected/pressed). Цвета для состояния normal задаются описанными в таблице параметрами -color. Для остальных состояний цвета задаются с суффиксами :selected и :pressed. Если цвета состояний «выбранное» и «нажатое» не заданы, то они будут рассчитаны от основных цветов.

Параметры конфигурации панели инструментов

Панель инструментов (toolbar) присутствует в главном окне и во всех интерфейсах. Имена параметров панели инструментов начинаются с префикса «toolbar.».

Имя параметра	Что описывает
visible	Видимость панели инструментов. Тип boolean, допустимые значения true/yes/1 и false/no/0
style	Стиль отрисовки toolbar classic/[theme]/flat
place	Место размещения toolbar. Допустимые значения [float]/left/top/right/bottom. По умолчанию float - местоположение определяется проектом и может быть изменено пользователем. Остальные значения жестко фиксируют toolbar с указанной стороны окна.
font-…	Четыре стандартных параметра, задают стандартный шрифт для всех элементов toolbar
color	Стандартный цвет текста для всех элементов toolbar
background-color	Цвет фона, для style=classic или flat
border-color	Цвет рамки toolbar
padding	Отступы от границ до элементов toolbar (кнопок) (rect)
border	Толщина рамки toolbar (rect), для style=flat
button.margin	Отступы между кнопками (rect)
button.padding	Отступы внутри кнопки (rect)
button.border	Толщина рамки вокруг кнопки (rect), для style=flat
button.font…	Четыре стандартных параметра, задают шрифт кнопок, переопределяют toolbar.font…
button.color	Цвет текста на кнопках, переопределяет toolbar.color
button.background-color	Цвет фона кнопки, для style=classic или flat
button.border-color	Цвет рамки кнопки, для style=flat
button.icon-color	Цвет шрифтовой иконки, по умолчанию = button.color
button.max-text-width	Максимальная ширина текста. По умолчанию 14 символов.
button.icon.size	Размер иконки на кнопках в пикселях, от 16 до 96. Может быть [small]/medium/large/huge, эквивалентно 16/24/32/48. Иконки всегда квадратные, т.е. 16х16, 24х24…
button.icon.place	Местоположение иконки относительно текста [top]/left
button.icon.margin	Отступы между иконкой и текстом (rect)
tab.color	Цвет текста на закладках, переопределяет toolbar.color
tab.background-color	Цвет фона закладки, -1 = прозрачный
tab.border-color	Цвет рамки закладки

Кнопка на панели инструментов может находится в четырех состояниях - normal, disabled, selected и pressed. Цвета для состояния normal задаются описанными в таблице параметрами toolbar.button….-color. Для остальных состояний можно задавать отдельные наборы цветов, добавляя к имени параметра имя состояния через двоеточие

<p n="toolbar.button.color"                     v="#A0A0A0" />

<p n="toolbar.button.background-color"          v="#303030" />

<p n="toolbar.button.border-color"              v="#303030" />

<p n="toolbar.button.icon-color"                v="#F0A040" />

 

<p n="toolbar.button.color:selected"            v="#C0C0C0" />

<p n="toolbar.button.background-color:selected" v="#505050" />

<p n="toolbar.button.border-color:selected"     v="#505050" />

<p n="toolbar.button.icon-color:selected"       v="#60F000" />

 

<p n="toolbar.button.color:pressed"             v="#F0F0F0" />

<p n="toolbar.button.background-color:pressed"  v="#606060" />

<p n="toolbar.button.border-color:pressed"      v="#F0F0F0" />

<p n="toolbar.button.icon-color:pressed"        v="#F02020" />

Закладка на панели инструментов (есть только в главном окне приложения) может находится в двух состояниях - normal и active. Цвета для состояния normal задаются описанными в таблице параметрами toolbar.tab….-color. Для состояния active можно задавать отдельный набор цветов, добавляя к имени параметра имя состояния через двоеточие, например toolbar.tab.color:active

Параметры конфигурации главного окна приложения

Идентификатор стиля для главного окна приложения - MainWindow. Файл bin\Config\Design\MainWindow.xml содержит стандартные настройки, применяемые по умолчанию.

Имена параметров главного окна приложения начинаются с префикса «window.».

Имя параметра	Что описывает
background-color	Цвет фона главного окна приложения. По умолчанию используется цвет, заданный в настройках ОС для фона главного окна MDI- приложения.
wallpaper	Имя файла с картинкой, которая будет использована для «мощения» фона главного окна приложения. Стандартное значение - "images\$Background.png"

Параметры конфигурации формы ввода

 

Параметры конфигурации иерархического вида просмотра

Идентификатор стиля для иерархического вида просмотра - StandardTree. Файл bin\Config\Design\ StandardTree.xml содержит стандартные настройки, применяемые по умолчанию. Система позволяет изменить шрифт и набор цветов, которые используются в редакторе проекта. Имена параметров должны начинаться с префикса «row.» или «tree.», если иное не указано явно. При поиске значения система подставляет префиксы в указанном порядке.

Имя параметра	Что описывает
icon.size	Размер иконки в пикселях, от 16 до 96. Может быть [small]/medium/large/huge, эквивалентно 16/24/32/48.
font-…	Четыре стандартных параметра, задают шрифт
color	Цвет текста
background-color	Цвет фона
border-color	Цвет для отрисовки линий дерева Цвет для шрифтовых иконок свернуть/развернуть (альтернативный стиль отображения иерархии)
indent * префикс «row.»	Размер отступа, только для альтернативного стиля отображения иерархии
margin * префикс «tree.»	Отступы (rect) от границ окна
margin * префикс «row.»	Отступы (rect) между строками дерева по вертикали, и отступы по горизонтали между иконками- элементами строки
padding * префикс «row.»	Отступы (rect) по сторонам текста внутри строки

Элементы дерева могут находится в разных состояниях (focus, inactive), и для каждого состояния можно задать свой цвет фона и текста. Для этого к имени параметра добавляется имя состояния через двоеточие.

Состояние focus - это текущий элемент, на котором стоит указатель в виде просмотра. Система рисует плашку (прямоугольник) с цветом background-color:focus поверх основного фона. Для отображения текста элемента используется цвет color:focus

Состояние inactive - это текущий элемент, на котором стоит указатель в виде просмотра. При этом сам вид просмотра находится не в фокусе. В остальном поведение аналогично состоянию focus.

Параметры конфигурации табличного вида просмотра с формой фильтра

 

Параметры конфигурации редактора проекта

Редактор проекта основан на стандартном иерархическом виде просмотра. Идентификатор стиля для редактора проекта - PrjEditTree. Файл bin\Config\Design\PrjEditTree.xml содержит стандартные настройки для окна редактора проекта, применяемые по умолчанию. Система позволяет изменить шрифт и набор цветов, которые используются в редакторе проекта. Имена параметров должны начинаться с префикса «row.» или «tree.», если иное не указано явно. При поиске значения система подставляет префиксы в указанном порядке.

Имя параметра	Что описывает
icon.size	Размер иконки в пикселях, от 16 до 96. Может быть [small]/medium/large/huge, эквивалентно 16/24/32/48.
font-…	Четыре стандартных параметра, задают шрифт
color	Цвет текста
background-color	Цвет фона
border-color	Цвет для отрисовки линий (дерева)
padding	Отступы текста от границ строки (rect)
indent * префикс «row.»	Размер отступа, только для альтернативного стиля отображения иерархии
margin * префикс «tree.»	Отступы (rect) от границ окна
margin * префикс «row.»	Отступы (rect) между строками дерева по вертикали, и отступы по горизонтали между иконками- элементами строки

Элементы проекта могут находится в разных состояниях (disabled, comment, warning, error, marked, focus, inactive), и для каждого состояния можно задать свой цвет фона и текста. Для этого к имени параметра добавляется имя состояния через двоеточие.

Состояние disabled - это элементы, которые недоступны для редактирования. Стандартно выделяется серым цветом шрифта на обычном фоне.

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

Состояние warning - это родительские элементы для элементов в состоянии error. Стандартно выделяется оранжевым цветом шрифта на обычном фоне.

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

Состояние marked - это элементы, которые выделены (помечены) в результате поиска или пользователем явно. Стандартно выделяется синим цветом шрифта на обычном фоне.

Состояние focus - это текущий элемент, на котором стоит указатель в виде просмотра. Система рисует плашку (прямоугольник) с цветом background-color:focus поверх основного фона. Для отображения текста элемента используется цвет их состояния, или color:focus для обычных элементов. Стандартный цвет плашки для текущего элемента - серо-голубой #88C8FF.

Состояние inactive - это текущий элемент, на котором стоит указатель в виде просмотра. При этом сам вид просмотра находится не в фокусе. В остальном поведение аналогично состоянию focus.

Так как элемент проекта может одновременно находится в нескольких состояниях, то для применения цветов действует правило вытеснения (каждый последующий цвет вытесняет предыдущий). Порядок вытеснения соответствует порядку, в котором состояния описаны выше.

 

* Учётные регистры

Учетный регистр  – поддерживаемая на системном уровне структура для хранения исторических данных (фактов), их агрегирования и получения на их основе различных отчетов.

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

• возможность описывать произвольное количество учетных регистров разной структуры
• проводки односторонние, нет понятия дебет и кредит,
• свободная структура аналитик без ограничения по количеству и типу данных, аналитики, как правило, имеют фиксированный смысл,
• вектор сумм вместо одной суммы в стандартных проводках – экономия места
• произвольное количество агрегатов различной структуры, построенных по общему множеству фактов (несколько разных структур сальдо)

Для работы с новыми структурами данных в объекты Домино добавлены новые методы:

1. "Акцепт.Создание записей движения по учетным регистрам" – вызывается при стандартном и коротком акцепте документа, а также при приеме почтой документа с проводками. Служит для добавления записей в указанный (в силу того, что их количество в проекте не лимитировано) набор учетных регистров.
2. "Деакцепт.Удаление записей движения по учетным регистрам" – вызывается при стандартном и коротком деакцепте документа, а также при удалении/изменении почтой документа. Служит для удаления записей из указанного (в силу того, что их количество в проекте не лимитировано) набора учетных регистров.

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

С точки зрения проекта учетный регистр – это набор таблиц и описание их взаимосвязей. Опишем последовательно все необходимые для создания учетного регистра проектные компоненты.

Таблица фактов

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

Таблица фактов обязательно должна ссылаться на базовую таблицу фактов и наследовать  ее поля (параметры). Для наследования полей в разделе «Параметры» описания таблицы нужно указать атрибут <Наследуемые параметры>.

Описание структуры базовой таблицы 1507433[30867462] ФАКТЫ
Документ	Аналог соответствующего поля проводки.
Строка документа	Аналог соответствующего поля проводки.
Дата	Аналог соответствующего поля проводки.
Приход/Расход (+/-)	Указывает, как запись таблицы фактов влияет на агрегаты - увеличивает ('+') или уменьшает (‘-‘). Примечание: для уменьшения размера таблицы тип данного поля - короткая строка в 1 символ.
Влияет на агрегаты (1/0)	Указывает, изменяет ли запись таблицы фактов агрегаты - изменяет ('1') или не изменяет ('0'). Примечание: для уменьшения размера таблицы тип данного поля - короткая строка в 1 символ.

Остальные поля таблицы фактов условно делятся на аналитики и суммы. Их количество и типы не регламентируются. То, как будет интерпретироваться конкретное поле (как аналитика или как сумма), определяется описанием структуры учетного регистра.

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

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

Таблица пула

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

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

Особенности проектного описания таблицы пула:

1. Таблица пула должна ссылаться на таблицу фактов как на базовую.
2. В разделе «Параметры» вместо элементов «Параметр» нужно использовать конструкцию «Использовать параметр» со ссылкой на параметр таблицы фактов.
3. В разделе «Параметры» нельзя использовать конструкцию <Наследуемые параметры>
4. Таблица пула должна содержать все аналитики и все суммы из таблицы фактов, которые используются в агрегатах.
5. Поля базовой таблицы фактов в структуру записи таблицы пула включать не нужно, так как они не участвуют в расчете агрегатов.

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

Таблицы-агрегаты

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

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

Особенности проектного описания таблицы-агрегата:

1. Таблица-агрегат должна ссылаться на таблицу фактов как на базовую.
2. В разделе «Параметры» вместо элементов «Параметр» нужно использовать конструкцию «Использовать параметр» со ссылкой на параметр таблицы фактов.
3. В разделе «Параметры» нельзя использовать конструкцию <Наследуемые параметры>
4. Набор аналитик и сумм, включаемых в запись агрегата, определяется потребностями агрегирования.
5. Поля базовой таблицы фактов в структуру записи агрегата включать не нужно

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

Таблица оборотов

Таблица оборотов – это виртуальная сущность, которая используется для доступа к данным учетного регистра через оператор SELECT языка скриптов. Хотя обороты описываются в проекте как обычная таблица, физически в базе данных она не создается. К этой виртуальной таблице можно обращаться только для выборки данных, запись в нее невозможна.

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

Особенности проектного описания таблицы оборотов:

1. Таблица оборотов должна ссылаться на базовую таблицу оборотов: 1507433[30867463] ОБОРОТЫ.
2. Параметры базовой таблицы оборотов должны быть обязательно включены в структуру записи таблицы путем задания атрибута <Наследуемые параметры> в разделе «Параметры».
3. В разделе «Параметры» для описания полей используется стандартная конструкция «Параметр».
4. Параметры таблицы по смыслу (способу использования) делятся на:
   • «Начало периода» и «Конец периода» (наследуются из базовой таблицы)
   • Аналитики – дублируют набор аналитик таблицы «Факты»
   • Приход – сумма прихода (обороты) за период
   • Расход – сумма расхода (обороты) за период
   • Сумма – исходящая сумма на дату конечную
5. Смысловая привязка параметров оборотов производится непосредственно в описании учетного регистра.

Так как таблица оборотов является виртуальной, описывать индексы по ней не имеет смысла.

Выборка данных оператором SELECT аналогична выборке по стандартным оборотам:

1. Если запрашиваются набор аналитик и поля со смысловым значением "ПРИХОД", то в разрезе этих аналитик возвращаются суммы, собранные по записям таблицы фактов за указанный диапазон дат и имеющим в качестве значений поля "Приход/Расход (+/-)" значение '+'. Аналогом является поле "Обороты по дебету" стандартной таблицы оборотов.
2. Если запрашиваются набор аналитик и поля со смысловым значением "РАСХОД", то в разрезе этих аналитик возвращаются суммы, собранные по записям таблицы фактов за указанный диапазон дат и имеющим в качестве значений поля "Приход/Расход (+/-)" значение '-'. Аналогом является поле "Обороты по кредиту" стандартной таблицы оборотов.
3. Если запрашиваются набор аналитик и поля со смысловым значением "СУММА", то в разрезе этих аналитик возвращаются исходящие суммы на конечную дату, собранные по записям таблиц фактов, пула и подходящего (по набору возвращаемых/ограничивающих аналитик и сумм) агрегата. Аналогом является поле "Исходящее сальдо (дебет - кредит)" стандартной таблицы оборотов. Допустимо ограничение лишь на конечную дату – на равенство. Если ограничение на конечную дату не задано, то рассчитываются суммы без учета фактов, то есть «текущее значение сумм».
4. Возможна комбинация предыдущих 3-х случаев. В таком случае требуется ограничение на диапазон дат. Ограничение на дату конечную может быть опущено – в этом случае расчет ведется от даты начальной и до конца истории.

Собственно описание учетного регистра

Учетный регистр – это системная структура, которая описывает взаимосвязи таблиц и смысловую привязку их полей. Учетные регистры описываются в специализированном разделе "Структура базы данных"->"Учетные регистры". Описания учетных регистров скрыты от прикладного программиста: для работы с его данными используются таблица фактов (допустимо чтение, добавление и удаление записей) и псевдо-таблица оборотов (допустимо только чтение)

Описание взаимосвязей таблиц в учетном регистре выглядит таким образом:

1. Таблица фактов привязывается ссылкой в самом учетном регистре. Допустима только одна таблица фактов и, соответственно, только одна ссылка на нее.
2. Таблица пула привязывается атрибутом «Промежуточный пул». Допустима только одна таблица пула и, соответственно, только одна ссылка на нее.
3. Агрегатные таблицы привязываются множественным атрибутом «Агрегат». Допустимо задавать произвольное количество агрегатных таблиц, отличающихся набором агрегирующих аналитик и сумм (при этом, все указанные поля должны присутствовать в таблицах фактов и пула). Соответственно, атрибут "Агрегат" - множественный.
4. Псевдо-таблица оборотов привязывается разделом «Взаимосвязь таблиц фактов и оборотов».

Раздел «Взаимосвязь таблиц фактов и оборотов» помимо ссылки на таблицу оборотов описывает взаимосвязи полей таблиц фактов и оборотов:

1. Атрибут «Признак "Приход/Расход (+/-)"» определяет, какое поле таблицы фактов система должна интерпретировать как знак операции. Является обязательным.
2. Атрибут «Признак "Влияет на агрегаты (1/0)"» определяет, какое поле таблицы фактов система должна интерпретировать как признак отражения записи фактов в агрегатах. Является обязательным.
3. Атрибут "Начало периода" связывает поле "Дата" таблицы фактов с полем "Начало периода" таблицы оборотов (через атрибут "Отображается в оборотах как"). Является обязательным.
4. Атрибут "Конец периода" связывает поле "Дата" таблицы фактов с полем "Конец периода" таблицы оборотов (через атрибут "Отображается в оборотах как"). Является обязательным.
5. Множественный атрибут "Приход" связывает числовое поле таблицы фактов с соответствующим полем таблицы оборотов, смысл которого есть сумма, собранная по записям таблицы фактов за указанный диапазон дат и имеющим в качестве значений поля "Приход/Расход (+/-)" значение '+'. Аналогом является поле "Обороты по дебету" стандартной таблицы оборотов.
6. Множественный атрибут "Расход" связывает числовое поле таблицы фактов с соответствующим полем таблицы оборотов, смысл которого есть сумма, собранная по записям таблицы фактов за указанный диапазон дат и имеющим в качестве значений поля "Приход/Расход (+/-)" значение '-'. Аналогом является поле "Обороты по кредиту" стандартной таблицы оборотов.
7. Множественный атрибут "Сумма" связывает числовое поле таблицы фактов с соответствующим полем таблицы оборотов, смысл которого есть исходящая сумма на конечную дату, собранная по записям таблиц фактов, пула и подходящего (по набору возвращаемых/ограничивающих аналитик и сумм) агрегата. Аналогом является поле "Исходящее сальдо (дебет - кредит)" стандартной таблицы оборотов.
8. Множественный атрибут "Аналитика" связывает поле-аналитику таблицы фактов с полем-аналитикой таблицы оборотов.

Администрирование учетных регистров

Домино при старте автоматически не создает учетные регистры. Для работы с учетными регистрами надо создать соответствующие структуры на сервере БД. Для создания всех описанных в проекте учетных регистров служит процедура:
127[48431867] Создать структуры хранения учетных регистров
подключенная в меню
"Администрирование данных"->"Обслуживание БД"
и
"Администратор организации"->"Обслуживание БД"

При повторном запуске структуры данных не пересоздаются, а меняются в соответствии с новым проектным описанием (т.е вместо оператора CREATE TABLE используется оператор ALTER TABLE). Если описание таблиц не изменилось, то будут перегенерены только триггера и хранимые процедуры. Данным, уже лежащим в таблицах, повторный запуск не угрожает - если конечно не изменено описание полей таблиц.

Учетный регистр «Движение товаров»

Учетный регистр 30867634[30867457] «Движение товаров» предназначен для поэтапного перевода товарного учета со стандартных проводок на более экономичную схему, использующую специализированные структуры хранения. Движение товаров агрегируется в разрезе подразделений(складов), товаров, партий и цветов/размеров. Кроме того, используется понятие «направления» - неагрегатной аналитики, которая позволяет группировать обороты по смыслу (сути) товарной операции. Движение товаров учитывается по количеству и по четырем суммам (закупочной, учетной, продажной и фактической).

Функционал, отвечающий за работу с учетным регистром «Движение товаров» вынесен в отдельную проектную библиотеку «#Товародвижение:Новая модель». В нее входят:

• собственно описание учетного регистра и его таблиц
• признак «Режим обработки товародвижения» и логика его переключения
• процедуры – методы для создания и удаления записей о движении товаров по документам и по строкам документов
• базовые SQL- запросы для доступа к данным учетного регистра «Движение товаров»
• базовый вид просмотра для просмотра записей таблицы фактов

Управление работой учетного регистра «Движение товаров»

Пока не реализовано: Признак включения  -

 Пока не реализовано: Признак отключения стандартных проводок по товародвижению

 Пока не реализовано: Признак использования в расчетах нового механизма вместо старого (отладочный)

 Отнесение операций (классов и типов) документов к разряду товарных. Предполагается, то операция является товарной, если она отражается в учетном регистре «Движение товаров». Иными словами - если создает записи движения в этом учетном регистре. Для создания записей движения производится по учетному регистру «Движение товаров» существует специальная процедура-метод «Создание записей о движении товаров …». В стандартном проекте эта процедура-метод подключена для классов документов «ПРИХОДНЫЙ ТОВАРНЫЙ ДОКУМЕНТ» и «РАСХОДНЫЙ ТОВАРНЫЙ ДОКУМЕНТ» - соответственно, все документы указанных классов считаются товарными.

Разделение операций на приходные и расходные. Операция считается приходной (увеличивает остаток), если документ относится к классу «ПРИХОДНЫЙ ТОВАРНЫЙ ДОКУМЕНТ», и расходной – если к классу «РАСХОДНЫЙ ТОВАРНЫЙ ДОКУМЕНТ».

Влияние товарного документа на остаток. Задается признаком на операцию (тип документа) «Влияет на товарный остаток». Если признак не задан, то по умолчанию считается, что операция на остаток влияет.

Привязка типов документов к направлениям. Задается атрибутом на операцию (тип документа) «Направление движения товара». Для каждой товарной операции обязательно должно быть указано направление движения.

Пока не реализовано: Задание для типа документа ограничения на множество классов/типов строк, которые будут обрабатываться как товарные

Кодификатор направлений

Проектный кодификатор «Направление движения товара» 838-18[838-1] описывает группировку товарных операций по стандартным смыслам. Товарные операции относятся к тому или иному направлению путем задания его(направления) в параметрах вызова процедуры-метода создания записей о движении товаров. Непосредственно в записи таблицы фактов хранится аббревиатура этого кодификатора – это сделано для экономии места.

Стандартные направления:

• Приход/Возврат поставщику (DL)
• Реализация/Возврат от покупателя (SL)
• Перемещение (TF)
• Списание (WO)
• Инвентаризация (IN)
• Производство (MN)
• Пересортица (RG)
• Переоценка (OE)
• Прочее (OZ)

Структура сумм и аналитик учетного регистра «Движение товаров»

Имя	Тип	Описание
Аналитики
Подразделение	UID	Подразделение(склад), на котором учитываются остатки товара.
Продукт	UID	Собственно, продукт.
Партия	UID	Партия продукта.
Размер	UID	Дополнительная необязательная аналитика. Как правило, используется для учета в разрезе цветов или размеров.
Направление	STRING(2)	Неагрегатная аналитика, отражающая суть товарной операции, например «Приход от поставщика», «Реализация», «Внутреннее перемещение». Хранится как двухбуквенная аббревиатура соответствующего проектного кодификатора.
Суммы
Количество	NUMBER(19,6)	Количество товара в физических единицах учета.
Сумма закупочная	NUMBER(19,6)	Сумма по цене закупочной
Сумма учетная	NUMBER(19,6)	Сумма по цене учетной
Сумма продажная	NUMBER(19,6)	Сумма по цене продажной (розничной).
Сумма фактическая	NUMBER(19,6)	Неагрегатная сумма по фактической цене продажи. Имеет смысл только в виде оборотов за период для некоторых направлений.

Обороты

Структура псевдо-таблицы оборотов повторяет структуру сумм и аналитик для учетного регистра «Движение товаров», описание которой приведено выше. Проектное описание псевдо-таблицы обороты: 1507433[30867461] «Движение товаров.Обороты».

Таблицы учетного регистра «Движение товаров»

Факты: 1507433[30867460] «Движение товаров. Факты» Имя таблицы БД: DB1_TRANSFER
Поле	Имя в БД	Тип	Примечание
Документ	DOCUMENT	UID	Обязательное поле
Строка документа	LINE	UID
Дата	FACT_DATE	DATETIME	Обязательное поле
Приход/Расход	SIGN	STRING(1)	Обязательное поле
Влияет на агрегаты (1/0)	AGGR	STRING(1)	Обязательное поле
Подразделение	DEPT	UID	Обязательное поле
Продукт	PRODUCT	UID	Обязательное поле
Партия	PARTY	UID	Обязательное поле
Размер	SIZE	UID
Направление	DIRECTION	STRING(2)	Обязательное поле
Количество	QTY	NUMBER(19,6)	Обязательное поле
Сумма закупочная	PURCHASE_SUM	NUMBER(19,6)
Сумма учетная	ACCOUNT_SUM	NUMBER(19,6)
Сумма продажная	RETAIL_SUM	NUMBER(19,6)
Сумма фактическая	ACTUAL_SUM	NUMBER(19,6)

 

Пул: 1507433[48431153] «Движение товаров. Пул» Имя таблицы БД: DB1_TRANSFER_POOL
Поле	Имя в БД	Тип	Примечание
Подразделение	DEPT	UID	Обязательное поле
Продукт	PRODUCT	UID	Обязательное поле
Партия	PARTY	UID	Обязательное поле
Размер	SIZE	UID
Количество	QTY	NUMBER(19,6)	Обязательное поле
Сумма закупочная	PURCHASE_SUM	NUMBER(19,6)
Сумма учетная	ACCOUNT_SUM	NUMBER(19,6)
Сумма продажная	RETAIL_SUM	NUMBER(19,6)

 

Агрегат: 1507433[48431154] «Движение товаров. Остатки по партиям и размерам»  Имя таблицы БД: DB1_TRANSFER_A1
Поле	Имя в БД	Тип	Примечание
Подразделение	DEPT	UID	Обязательное поле
Продукт	PRODUCT	UID	Обязательное поле
Партия	PARTY	UID	Обязательное поле
Размер	SIZE	UID
Количество	QTY	NUMBER(19,6)	Обязательное поле
Сумма закупочная	PURCHASE_SUM	NUMBER(19,6)
Сумма учетная	ACCOUNT_SUM	NUMBER(19,6)
Сумма продажная	RETAIL_SUM	NUMBER(19,6)

 

Агрегат: 1507433[48431154] «Движение товаров. Остатки по базовым товарам»  Имя таблицы БД: DB1_TRANSFER_A2
Поле	Имя в БД	Тип	Примечание
Подразделение	DEPT	UID	Обязательное поле
Продукт	PRODUCT	UID	Обязательное поле
Количество	QTY	NUMBER(19,6)	Обязательное поле
Сумма закупочная	PURCHASE_SUM	NUMBER(19,6)
Сумма учетная	ACCOUNT_SUM	NUMBER(19,6)
Сумма продажная	RETAIL_SUM	NUMBER(19,6)

 

Процедуры – методы для создания и удаления записей о движении товаров

Базовое проектное решение включает в себя четыре процедуры-метода, которые реализуют стандартные алгоритмы создания и удаления записей по учетному регистру «Движение товаров».

1. 220[48431151] «Создание записей о движении товаров по документу в целом»
2. 220[30867500] «Удаление записей о движении товаров по документу в целом»
3. 220[30867501] «Создание записей о движении товаров по строке документа»
4. 220[30867502] «Удаление записей о движении товаров по строке документа»

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

Стандартный алгоритм создания записей движения для товарных документов (по учетному регистру «Движение товаров») реализован в виде процедуры-метода 220[48431151] «Создание записей о движении товаров по документу в целом». Эта процедура-метод вызывается стандартной реализацией метода «Акцепт. Создание записей движения по учетным регистрам» для документов с классом «» и «». Метод «Акцепт. Создание записей движения по учетным регистрам» вызывается процедурами акцепта документа и короткого акцепта документа.

Алгоритм процедуры-метода «Создание записей о движении товаров по документу в целом»

1. Формальные параметры процедуры
   • Влияет на агрегаты ([Да]/Нет) (по умолчанию берется из операции)
   • Направление (по умолчанию берется из операции)
   • Список классов и типов товарных строк
2. Проверяет значение глобального параметра (флага) «Рассчитывать данные по учетному регистру «Движение товаров»». Если параметр не установлен, то выход с признаком успешного завершения.
3. Удаляет записи движения по документу из таблицы фактов УР «Движение товаров»
4. По классу документа определяет знак операции:
   • класс «ПРИХОДНЫЙ ТОВАРНЫЙ ДОКУМЕНТ» - это операция прихода (‘+’)
   • класс «РАСХОДНЫЙ ТОВАРНЫЙ ДОКУМЕНТ» - это операция расхода (‘-’)
   • любой другой класс – это не товарная операция, выход с ошибкой.
5. Из типа документа (операции) получает признак влияния на агрегаты - как атрибут типа документа «Влияет на товарный остаток». Если на операцию этот признак не определен, то по умолчанию предполагается, что операция влияет на остаток. Используя формальный параметр процедуры (см.1.1.), можно явно задать признак влияния на агрегаты – в этом случае настройки, заданные на операцию, игнорируются.
6. Из типа документа (операции) получает направление движения товара - как атрибут типа документа «Направление движения товара». Если на операцию этот признак не определен, то процедура завершается с ошибкой. Используя формальный параметр процедуры (см.1.2.), можно явно задать направление движения товара – в этом случае настройки, заданные на операцию, игнорируются.
7. Пока не реализовано, планируется: Из проектного описания типа документа (операции) получает список классов/типов товарных строк. Нужно это или нет – вопрос. В текущем варианте это передается через формальный параметр.
8. Первый цикл по строкам документа. Перебирает строки документа, удовлетворяющие следующим условиям:
        - класс и тип строки удовлетворяют заданным ограничениям
         - заполнено поле «Родитель»
         - заполнено поле «Продукт»
         - значение в поле «Количество» не равно 0
   и создаются записи фактов УР «Движение товаров» со следующими значениями полей

Поле таблицы фактов	Формула для расчета значения
Документ	Строка. Документ
Строка	Строка. Строка
Дата	Строка. Дата строки
Приход/Расход	знак операции, вычисленный в п.4
Влияет на агрегаты	значение, вычисленное в п.6
Направление	значение, вычисленное в п.5
Подразделение	Документ. Подразделение
Продукт	Строка. Продукт. Родитель; если пусто (продукт не имеет родителя), то Строка. Продукт
Партия	Строка. Продукт
Размер	Строка. Размер
Количество	Строка. Количество
Сумма закупочная	Строка. Количество * Строка. Цена закупочная
Сумма учетная	Строка. Количество * Строка. Цена учетная
Сумма продажная	Строка. Количество * (Строка. Родитель. Цена розничная; если пусто, то Строка. Цена розничная)
Сумма фактическая	Строка. Сумма продажная (фактическая); если пусто, то Строка.Количество * (Строка. Родитель. Цена продажная (фактическая); если пусто, то Строка. Цена продажная (фактическая))

9. Второй цикл по строкам документа. Перебирает строки документа, удовлетворяющие следующим условиям:
        - класс и тип строки удовлетворяют заданным ограничениям
         - поле «Родитель» пусто
         - заполнено поле «Продукт»
         - продукт из строки имеет тип «УСЛУГА»
         - значение в поле «Количество» не равно 0
   и создаются записи фактов УР «Движение товаров» со следующими значениями полей

Поле таблицы фактов	Формула для расчета значения
Документ	Строка. Документ
Строка	Строка. Строка
Дата	Строка. Дата строки
Приход/Расход	знак операции, вычисленный в п.4
Влияет на агрегаты	значение 0 (не влияет)
Направление	значение, вычисленное в п.5
Подразделение	Документ. Подразделение
Продукт	Строка. Продукт. Родитель; если пусто (продукт не имеет родителя), то Строка. Продукт
Партия	Строка. Продукт
Размер	Строка. Размер
Количество	Строка. Количество
Сумма закупочная	Строка. Количество * Строка. Цена закупочная
Сумма учетная	Строка. Количество * Строка. Цена учетная
Сумма продажная	Строка. Количество * Строка. Цена розничная
Сумма фактическая	Строка. Сумма продажная (фактическая); если пусто, то Строка.Количество * Строка. Цена продажная (фактическая)

Стандартный алгоритм удаления записей движения для товарных документов (по учетному регистру «Движение товаров») реализован в виде процедуры-метода 220[30867500] «Удаление записей о движении товаров по документу в целом». Эта процедура-метод вызывается стандартной реализацией метода «Деакцепт. Удаление записей движения по учетным регистрам» для документов с классом «» и «». Метод «Деакцепт. Удаление записей движения по учетным регистрам» вызывается процедурами деакцепта документа и короткого деакцепта документа

220[30867501] Создание записей о движении товаров по строке документа

220[30867502] Удаление записей о движении товаров по строке документа.

Базовые SQL- запросы для доступа к данным учетного регистра «Движение товаров»

12124205[48431347] Движение товаров. Факты

12124205[48431348] Движение товаров .Обороты

Вид просмотра

371[48431396] Движение товаров. Факты

 

Планировщик задач

Задание планировщика – это документ специального класса “ЗАДАНИЕ ДЛЯ ПЛАНИРОВЩИКА ЗАДАЧ”. Параметры этого документа описывают задачу, которую нужно выполнить, и расписание, по которому эта задача должна выполняться.

Есть три типа заданий – “Локальное задание”, “Задание для всех узлов сети” и “Задание для узла сети”. Планировщик обрабатывает эти три типа одинаково. Различие состоит только в том, как эти задания передаются между узлами сети почтовой службой – именно ради этого и введены разные типы заданий. Тип задания выбирается при его создании, и потом не может быть изменен.

Ввод параметров задания

Форма ввода параметров задания (закладка «Основные параметры») позволяет ввести следующие параметры:

• Признак «Является актуальным», по умолчанию «Да», позволяет исключить задание из списка исполняемых, не удаляя его. Если этот признак имеет значение «Нет», то такое задание исключается планировщиком из списка исполняемых.
• Строка «Идентификатор планировщика» позволяет распределять общий список заданий между несколькими параллельно работающими планировщиками. Это актуально для систем с высокой нагрузкой, либо в том случае, когда требуется параллельное исполнение заданий. Планировщик выполняет из общего списка только те задания, у которых указан идентификатор, совпадающий с идентификатором планировщика. Идентификатор задается планировщику при конфигурировании системы, его значение отображается в заголовке окна планировщика.
• Поле «Узел сети» доступно только для задания с типом “Задание для узла сети”. В это поле необходимо выбрать (из списка) узел сети, на котором это задание будет выполняться. Задание данного типа выполняется планировщиком только в том случае, если узел сети в задании совпадает с узлом сети, к которому привязана текущая БД. «Чужие» задания планировщик игнорирует. Кроме того, это поле используется почтовой службой Домино для маршрутизации (передачи) таких заданий из центральной БД, где они обычно создаются, на соответствующие узлы-точки, где эти задания должны выполняться.
• Поле «Задача» определяет, что именно должен выполнить планировщик, исполняя это задание. Задача выбирается из списка возможных, содержимое этого списка определяется установленным проектным решением.

Управление расписанием

• Закладка «Основные параметры». Основной параметр управления расписанием – это «Режим запуска». Есть четыре варианта:

1. 1. Ежедневно, в указанное время
   2. Ежедневно, в указанном интервале времени с указанной периодичностью
   3. С момента запуска планировщика с указанной периодичностью
   4. От указанной даты-времени с указанной периодичностью

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

• Закладка «Планирование по дням недели» содержит группу признаков, каждый из которых определяет возможность запуска задания в определенный день недели. Общее правило: если для какого-либо дня недели признак не задан, то считается, что запуск задания в этот день разрешен. Если для всех дней недели установлены значения признаков «Нет», то такое задание выполняться не будет. Планирование по дням недели влияет на расписание для любого режима запуска задания.

Режим «Ежедневно, в указанное время»

Задание будет запущено один раз в день в указанное время(*, см. Примечание). Если установлено ограничение по дням недели, то задание будет выполняться только в указанные дни.

Режим «Ежедневно, в указанном интервале времени с указанной периодичностью»

Наиболее общий вариант управления расписанием. Задаются время начала, время окончания и периодичность запуска задания. Задание запускается многократно в течении дня с указанной периодичностью. Если время начала не задано, то считается 00:00:00. Если не задано время окончания, то считается 23:59:59. Если установлено ограничение по дням недели, то задание будет выполняться только в указанные дни.

• Период повторения (задания) –  это целое положительное число, он может быть задан в секундах, минутах или часах. Можно задавать в сутках, но это лишено смысла. Так же бессмысленно задавать период больше, чем продолжительность интервала времени, в котором разрешен запуск задания – в этом случае задание будет выполняться один раз в сутки в момент, определенный параметром «Время начала».
• Время начала интервала может быть больше, чем время окончания. Это значит, что интервал переходит через полночь на следующий день. Например, интервал с 22:00 до 04:00 означает запуск задания с 10 часов вечера текущего дня до 4 часов утра следующего дня. Если установлено ограничение по дням недели, и интервал переходит через полночь, то контроль дня идет по времени начала интервала. Например, если разрешено выполнение задания нашего в субботу и воскресенье,  то оно будет выполняться  каждую неделю с 10 часов вечера субботы до 4 часов утра воскресенья, и 10 часов вечера воскресенья до 4 часов утра понедельника.

Режим «С момента запуска планировщика с указанной периодичностью»

Очень простой режим. Задание первый раз запускается при запуске планировщика, и далее повторяется с указанной периодичностью. Период повторения (задания) –  это целое положительное число, он может быть задан в секундах, минутах или часах или днях. Если установлено ограничение по дням недели, то задание будет выполняться только в указанные дни.

Режим «От указанной даты-времени с указанной периодичностью»

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

Время очередного запуска задания, которое рассчитал планировщик, является планируемым временем. Запуск задания именно в этот момент не гарантирован, т.е. планировщик не является сервисом «реального времени». Запланированные задания выполняются планировщиком последовательно, и пока текущее задание не завершится, следующее не может быть запущено. Поэтому гарантируется только то, что а) задание не будет запущено раньше положенного, и б) запланированное задание будет выполнено, даже если реальное время его запуска «выезжает» за разрешенный интервал.

 

Макросы в шаблоне чека

В шаблоне чека ФР в формате TXT допустимы следующие макросы:

• <LOGO> - печать на ФР загруженного ранее логотипа
• Символ 'B' в обрамлении символов '<' и '>' - жирная печать строки
• <Font:x> - печать выбранным фонтом, где x - номер фонта. Специфично для моделей ФР. Переключает ФР на указанный фонт. Фонт используется до тех пор, пока не будет переопределён. Сбрасывается после окончания печати файла.
• <domino_field align = "_align_" length = "_len_" variable = "{_varname_}"/> - печать переменной отчёта с именем _varname_ с  выравниванием:
  • _align_ - влево(left) или вправо (right), центрировать (center) строку в пределах указанной длины (length)
  • _len_ - ширина в символах печатаемой строки. Строка дополняется пробелами до указанного значения (спереди, если выравнивается вправо, или сзади, если влево). 
• <QR>{Символы QR-кода} - печать на ФР строки символов, следующей за макросом, в виде QR-кода.
• <CUT> - отрезка чека на ФР.

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

 

Создание HTTP Web-сервисов

С помощью Домино8 можно создавать разнообразные HTTP Web-сервисы, которые обеспечивают доступ сторонних приложений к возможностям инфраструктуры Домино и конкретных проектных решений.

Экземпляр Домино8, запущенный в режиме  сервера, предоставляет однопоточный HTTP- прослушиватель (listener), который интегрируется в инфраструктуру HTTP- сервера ОСWindows. Сервер Домино8 принимает HTTP- запросы от клиентов, обрабатывает их с использованием проектных процедур и возвращает результаты обработки.

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

Запуск и работа Домино8 в режиме сервера

Для запуска приложения в режиме сервера следует указать следующие параметры:

• <Проект>    – первый (позиционный) параметр, указывает путь к файлам проектного решения
• /SERVER       – ключ указывает, что приложение должно выполняться в режиме сервера
• LISTEN          – http-адрес, который будет прослушивать этот экземпляр сервера
• DBSERVER    – имя сервера oracle
• SCHEME       – имя схемы на сервере oracle, в которой хранится БД Домино
• USERNAME  – пользователь Домино, от имени которого будет работать этот экземпляр сервера
• USERPWD    – пароль пользователя Домино
• TOKEN         – уникальный идентификатор экземпляра приложения

Пример строки запуска с проектом RETAIL-STORE:

C:\Domino\RETAIL-STORE-2010\Bin\Domino8.exe
      C:\Domino\RETAIL-STORE-2010\Project\RETAIL-STORE
      /SERVER
      LISTEN=http://localhost:8081/domino/
      DBSERVER=oracle6
      SCHEME=TEST
      USERNAME=Администратор
      TOKEN=2fdb96d1-952f-4ac3-8c49-213afb4886c1

Адрес для прослушивания (URI) задаётся в форме http://IP_or_Name:Port/RootPath/.  Адрес должен начинаться на http:// и заканчиваться на /. Этот адрес будет корнем, относительно которого будут именоваться описанные в проекте Http-сервисы и методы. Например, если указан URI http://localhost:8081/Domino/Store/ ,и в проекте описан сервис с именем first/svc1 и методами m1 и m2, то эти методы будут доступны по адресам http://localhost:8081/Domino/Store/first/svc1/m1 и http://localhost:8081/Domino/Store/first/svc1/m2.

Имя сервера oracle (DBSERVER) может быть либо ссылкой на файл tnsnames, либо полным путём в соответствии с правилами SQL*Net. Описание БД в проекте при работе в режиме сервера не используется. В примере показан вариант со ссылкой на файл tnsnames. Пример задания полного пути к серверу:

DBSERVER=(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.1.33)(PORT=1521))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=orcl)))

Уникальный идентификатор приложения (токен) используется для удалённой остановки экземпляра. Рекомендуется использовать достаточно длинное уникальное значение, например GUID.

Запуск в режиме сервера отличается от обычного запуска следующим:

• Файл сертификата не загружается, лицензия не проверяется
• Главное окно приложения не создаётся и не отображается на экране
• Модуль работы с оборудованием не инициализируется
• Действия «после старта», описанные в проекте, выполняются. Действия «После входа пользователя» не выполняются
• Отображение окон сообщений и интерфейсных окон блокируется.

Работа приложения в режиме сервера протоколируется в стандартный файл журнала LOG\Alert_ИмяПродукта.log. Протоколируются поступающие Http-запросы и ответы. Кроме того, в каталогах LOG\WEB\<OsPID> отдельными файлами протоколируются все Http-сессии обмена клиент-сервер. Имя файла равно порядковому номеру сессии. В файл записываются исходный http- запрос со всеми параметрами, данные запроса (content), и данные ответа.

Описание Http-сервисов и методов в проекте

Все http- сервисы и их методы описываются в специальном разделе проекта «HTTP- сервисы».

Http- методы – это именованные проектные функции, которые вызываются http- прослушивателем в ответ на входящие запросы. Могут наследоваться от 249[39780357] "{ ... скрипт ... }", либо от любой другой проектной функции. Методы вызываются http- прослушивателем по имени, поэтому имя метода должно быть корректным с точки зрения синтаксиса URI. Если у метода указан атрибут «Внешнее имя», то в качестве URI используется его значение. Собственное имя метода может в этом случае быть любым. Внутри одного сервиса не должно быть двух (активных) методов с одинаковыми именами.

Http-cервис представляет собой именованную папку (раздел), в которой описаны один или несколько методов. Имя сервиса используется в качестве локального пути к его методам, и поэтому оно должно быть корректным локальным  URI. Имя сервиса может быть составным – например a/b/c. Если у сервиса указан атрибут «Внешнее имя», то в качестве URI используется его значение. Собственное имя сервиса может в этом случае быть любым удобоваримым именем. Имя сервиса может быть пустым.

Внутри сервиса кроме собственно методов могут быть описаны вложенные сервисы. Путь к методам вложенного сервиса формируется соединением их путей. Например если внутри сервиса «a» описан вложенный сервис «b», то путь к методам «b» будет a/b

Регистр в наименованиях сервисов, методов и параметров игнорируется. Записи first/svc1/m1 и First/Svc1/M1 равнозначны.

Приведённый ниже пример описывает два сервиса - first и second. Сервис first реализует два метода (first/getProduct и first/encode), имена которых определяются атрибутом «Внешнее имя». Сервис second c внешним именем sec реализует один метод (sec/m1). Кроме того, описан метод с именем common/m1/m3, не входящий ни в один из сервисов.

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

Для того, чтобы отключить (заблокировать) некоторый метод, используется стандартный признак «Использование (в режиме выполнения)». Он может быть как безусловным (укажите «Нет»), так и условным. Этот признак можно задавать как для самого метода, так и для его подстановки.

Для того, чтобы полностью заместить метод, отключите его с помощью подстановки, указав «Использование (в режиме выполнения)»=Нет. После этого опишите еще один метод с точно таким же именем, как у замещаемого метода.

Реализация Http-методов

Http- методы – это именованные проектные функции, которые вызываются http- прослушивателем в ответ на входящие запросы. Методы могут наследоваться от 249[39780357] "{ ... скрипт ... }", либо от любой другой проектной функции.

Для получения параметров из строки http- запроса по их имени используется функция 387[63111218] "HTTPService.GetRequestParam". Для удобочитаемости рекомендуется описать локальные переменные с именами, совпадающими с именами параметров, и присвоить им начальные значения через вызов функции GetRequestParam. Такая нотация позволяет по заголовку метода легко понять, какие он принимает параметры.

Есть так же возможность получить значение множественного параметра, который повторяется в строке запроса несколько раз. Для этого при вызове функции кроме имени нужно указать порядковый номер (индекс) параметра в запросе. Например, GetRequestParam('id', 1) возвращает первое вхождение параметра id в запрос, GetRequestParam('id', 4) - четвёртое.

Параметры http-запроса могут быть без имени (точнее, с пустым именем ''). Знак равенства в этом случае ставить не обязательно. У запроса «имяМетода?aaa&=bbb&ccc» три параметра с пустым именем и значениями aaa, bbb и ccc.

Параметры так же могут быть переданы в содержимом POST- запроса  с указанием Content-Type:application/x-www-form-urlencoded.

Полный текст http-запроса с путём, именем метода и всеми параметрами возвращает функция 387[63111215] "HTTPService.GetRequest ". Запрос возвращается в «сыром» (raw) формате, т.е. параметры будут кодированы согласно RFC-1522. Это низкоуровневая возможность, и для написания обычных сервисов она, как правило, не требуется.

Функция 387[67305508] "HTTPService.GetRequestHttpMethod" возвращает тип входящего запроса (GET, POST…).

Функция 387[67305509] " HTTPService.GetRequestRemoteAddress" возвращает ip-адрес клиента, приславшего запрос.

Для получения параметров заголовка http- запроса по их имени используется функция 387[63111219] "HTTPService.GetRequestHeader". Функция так же относится к низкоуровневым, и применяется редко для реализации специфических возможностей.

Для получения содержимого http POST- запроса используется функция 387[63111216] "HTTPService.GetRequestContent". Содержимое возвращается в виде единой строки. При приёме происходит автоматическое перекодирование данных с использованием атрибута charset параметра заголовка Content-Type. Двоичные типы (application/octet-stream, image/jpeg и т.п.) и multipart- типы не поддерживаются. Если тип содержимого запроса application/x-www-form-urlencoded, то оно автоматически преобразуется в параметры http- запроса: для этого типа функция  GetRequestContent будет возвращать пустое значение.

Для получения типа содержимого http POST- запроса (content-type) используется функция 387[63111217] "HTTPService.GetRequestContentType". Она возвращает значение параметра Content-Type заголовка http- запроса, Эквивалентно вызову GetRequestHeader('Content-Type').

Рекомендованным форматом для содержимого запросов и ответов является text/xml. Для работы с данными в этом формате есть необходимый проектный функционал. Однако это не является обязательным требованием.

Функция-метод может возвращает содержимое (content) ответа только текстового типа. Бинарные форматы не поддерживаются. По умолчанию текст ответа возвращается в кодировке utf-8, есть возможность явно указать кодировку.

Функция-метод может возвращать содержимое ответа двумя способами: либо как раздел <data> стандартного xml-контейнера ответа, либо формируя его целиком. В первом случае ответ обязательно должен быть корректной xml-структурой без заголовка. Во втором случае нет никаких ограничений на формат ответа кроме того, что он должен быть текстовым.

Стандартный xml-контейнер ответа имеет вид

<?xml version="1.0" encoding="Кодировка ответа"?>
<response>
 <cmd>Имя метода</cmd>
 <params>
  <param>
   <name>Имя первого параметра</name>
   <value>Значение первого параметра </value>
  </param>
  ... Остальные параметры ... 
 </params>
 <data>
  Содержимое ответа в xml-формате
 </data>
 <result>
  <code>
   Код завершения метода (0 - успешно)
  </code>
  <msg>
   Текст сообщения об ошибке (описание кода завершения)
  </msg>
 </result>
</response>

Для того, чтобы вернуть содержимое как раздел <data> стандартного контейнера, необходимо сформировать его как строку в xml-формате (без стандартного заголовка <?xml version=… ?>) и передать функции 387[63111221] "HTTPService.SetResponseData". Переданное содержимое не проверяется на корректность.

Если функция-метод возвращает ответ в стандартном xml-контейнере, то параметр Content-Type в заголовке ответа автоматически устанавливается в text/xml;charset=КодировкаОтвета

В разделе <result> стандартного контейнера ответа возвращаются код завершения метода и текстовое описание кода завершения. При успешном завершении метода код равен 0. В случае сбоя (аварийного прерывания) функции-метода в этот раздел записывается внутренний код Домино с расшифровкой. С помощью функции 387[63111223]  "HTTPService.SetResponseResult" разработчик может явно установить код и текст сообщения, которые будут записаны в раздел <result>. Нужно учитывать, что некоторые коды завершения приводят в возврату специфических кодов состояния HTTP (HTTP status code) в ответе клиенту - см.ниже.

Для того, чтобы вернуть содержимое произвольного формата, нужно сформировать его как строку и передать функции 387[63111220] "HTTPService.SetResponseContent".

В качестве содержимого функции 387[63111220] "HTTPService.SetResponseContent" можно установить значение NULL. В этом случае стандартный xml-ответ, содержащий параметры запроса, код и описание ошибки ответа не формируется.

Для того, чтобы изменить параметр Content-Type в заголовке ответа, нужно использовать функцию 387[63111224] "HTTPService.SetResponseContentType". Функции следует передавать только MIME-тип сообщения без ‘;’ и параметров. Например при отправке ответа в json-формате нужно установить 'text/json' или 'application/json'. При отправке ответа система автоматически формирует параметр Content-Type как 'MIME-тип;charset=КодировкаОтвета'

По умолчанию текст ответа возвращается в кодировке utf-8. Для того, чтобы изменить кодировку ответа, нужно использовать функцию 387[63111225] "HTTPService.SetResponseContentCharset". Функции нужно передать либо MIME- наименование кодировки, либо номер кодовой страницы. Например, значения ‘windows-1251’ и 1251 равнозначны.

Для прямого изменения параметров заголовка http- ответа используется функция 387[63111222]  "HTTPService.SetResponseHeader". Функция относится к низкоуровневым, ей следует пользоваться с осторожностью.

Функция-метод может возвращать целое значение. Это значение используется в качестве кода состояния HTTP (HTTP status code) в ответе клиенту. Может принимать значение от 200 до 599, остальные значения игнорируются. Если метод не возвращает ничего, то в ответе будет установлен код состояния 200 Ok.

Если метод завершается с ошибками класса 244 «Системная ошибка» или 254 «Ошибка в описании проекта», то в ответе устанавливается код состояния 500 Internal server error.

Если прослушиватель не находит метод по имени, то он возвращает код состояния 404 Not found. при этом в качестве содержимого ответа возвращается стандартный xml-контейнер без раздела <data>, <result><code>-1</code><msg>Неизвестная команда</msg></result>. Нужно помнить, что при поиске метода по имени учитывается признак «Использование (в режиме выполнения)»

Пример 1. Поиск товара по коду

Метод first/getProduct ищет товар по продажному коду или коду, и возвращает uid, код и имя найденного продукта в разделе <data> стандартного xml-контейнера ответа. В случае, если продукт не найден, устанавливает код завершения 20, текст сообщения «Запись не найдена».

В примере использованы функции HTTPService.GetRequestParam для получения значения параметра из строки запроса, HTTPService.SetResponseData для записи результат в раздел <data>, HTTPService.SetResponseResult для установки кода завершения «Запись не найдена». Для формирования результата в xml- формате применены встроенные операторы генерации xml (XML-тег)

Пример 2. Перекодировщик произвольных строковых данных

Метод first/encode демонстрирует применение функций низкого уровня. Он принимает на вход текстовые данные в произвольной кодировке, и возвращает их в кодировке, которая указана параметром charset запроса.

Пример вызова метода утилитой curl. Входные данные в кодировке windows-1251 должны находиться в файле first.encode.in.txt. Выходные данные в кодировке utf-16 будут записаны в файл first.encode.out.txt

curl.exe
   -o first.encode.out.txt
   --trace-ascii first.encode.trc
   -H "Content-Type: text/plain;charset=windows-1251"
   -d @first.encode.in.txt
   "http://localhost:8081/domino/first/encode?charset=utf-16"

Проектные процедуры и функции

Для взаимодействия метода с контекстом Http-прослушивателя ядро Домино8 предоставляет специальные функции. Этот раздел содержит полный список таких функций.

387[63111215] "HTTPService.GetRequest : STRING"

Функция возвращает полный текст http-запроса с путём, именем метода и всеми параметрами. Запрос возвращается в «сыром» (raw) формате, т.е. параметры будут кодированы согласно RFC-1522. Это низкоуровневая возможность, и для написания обычных сервисов она, как правило, не требуется.

387[63111216] "HTTPService.GetRequestContent : STRING"

Функция возвращает содержимое (content) POST- запроса как строку

387[63111217] "HTTPService.GetRequestContentType : STRING"

Функция возвращает значение параметра Content-Type заголовка запроса.

387[63111218] "HTTPService.GetRequestParam : STRING"

Функция возвращает значение параметра из URI запроса по его имени. Имя параметра  задаётся параметром функции «Имя параметра». Если параметр отсутствует, то функция возвращает NULL. Для неуникальных параметров запроса можно параметром «Индекс» указать их номер по порядку начиная с 1. Например, HTTPService.GetRequestParam('id', 5) возвращает значение 5 вхождения параметра id в строку запроса.

387[63111219] "HTTPService.GetRequestHeader : STRING"

Функция возвращает значение параметра из заголовка запроса по его имени. Имя параметра заголовка задаётся параметром функции «Имя параметра». Для неуникальных параметров заголовка можно параметром «Индекс» указать их номер по порядку начиная с 1 (аналогично GetRequestParam).

387[63111220] "HTTPService.SetResponseContent : void"

Функция устанавливает текстовое содержимое ответа целиком, без ограничения на формат. Её вызов отключает возврат из http-метода содержимого в форме стандартно xml- контейнера. Содержимое передаётся параметром функции «Выражение» как строка произвольного формата. Бинарные типы содержимого не поддерживаются.

387[63111224] "HTTPService.SetResponseContentType : void"

Функция устанавливает MIME- тип содержимого ответа (Content-Type=). Имеет смысл только если http- метод возвращает содержимое произвольного формата функцией HTTPService.SetResponseContent. Если метод возвращает стандартный xml-контейнер ответа, то его тип автоматически устанавливается в text/xml. Значение MIME- типа передаётся параметром функции «Выражение».

387[63111225] "HTTPService.SetResponseContentCharset : void"

Функция устанавливает кодировку (charset=) содержимого ответа. По умолчанию текст ответа возвращается в кодировке utf-8. Для того, чтобы изменить кодировку ответа, нужно передать либо MIME- наименование кодировки, либо номер кодовой страницы. Например, значения ‘windows-1251’ и 1251 равнозначны. Кодировка передаётся параметром функции «Выражение».

387[63111221] "HTTPService.SetResponseData : void"

Функция устанавливает значение раздела <data> стандартного контейнера ответа. Значение передаётся параметром функции «Выражение» как строка в xml-формате (без стандартного заголовка <?xml version=… ?>).

387[63111222] "HTTPService.SetResponseHeader : void"

Функция устанавливает значение параметра в заголовке ответа. Имя параметра заголовка передаётся параметром функции «Имя параметра». Значение параметра - параметром функции «Выражение». Имя параметра следует задавать без двоеточия на конце. Параметры заголовка неуникальны - можно добавить любое число одноименных параметров. Некоторые системные параметры - например, Content-Length, нельзя установить таким образом: параметр не будет записан в заголовок ответа и в AlertLog приложения останется запись об ошибке.
Функция относится к низкоуровневым, ей следует пользоваться с осторожностью.

387[63111223] "HTTPService.SetResponseResult : void"

Функция устанавливает код завершения http-метода и текст сообщения, которые будут возвращены в разделе <result> стандартного контейнера ответа. Код завершения передаётся параметром функции «Выражение» как целое число. Код 0 соответствует успешному завершению. Текст сообщения передаётся параметром функции «Текст сообщения» как строка. Нужно учитывать, что некоторые коды завершения приводят в возврату специфических кодов состояния HTTP (HTTP status code) в ответе клиенту.

249[63111299] "UID как строка в RAW-формате"

Функция - уточняющий параметр объекта. Возвращает UID объекта как строку в RAW формате

249[63111298] "Преобразовать UID/UIDSET к строке в RAW-формате"

Функция преобразует значение UID или UIDSET, заданное параметром «Выражение», к строке в RAW-формате

Встроенные методы

Кроме методов, реализованных на уровне проекта, Http-сервер Домино предоставляет  встроенные методы.

Получить значение одного или всех атрибутов объекта по его UID (get)

Возвращает значение указанного, либо всех атрибутов объекта. UID объекта задаётся параметром id=. Это может быть как UID объекта БД, так и UID проектного элемента. Имя атрибута, значение которого нужно вернуть, задаётся параметром attr=. Если параметр не зада, то возвращаются все атрибуты объекта.

Для объектов БД имя атрибута может быть либо числовым идентификатором (индекс поля в проекте), либо строковым именем, совпадающим с именем поля в таблице БД oracle. Например для товара (product) записи attr=5 и attr=CODE равнозначны.

Для проектных элементов имя атрибута может быть одним из списка (NAME, VALUE, ABBREVIATION, EXT_NAME, TYPE, TYPE_NAME).

Результат возвращается в стандартном xml-контейнере в разделе <data> в. структуре <record>. Каждый атрибут возвращается отдельным тегом, имя тега совпадает с именем атрибута.

Пример запроса проектного элемента и результат (ответ)

GET http://host:port/RootPath/get?id=332[1966128]

<response>

 <cmd>get</cmd>

 <params>

  <param>

   <name>id</name><value>42401836[42401793]</value>

  </param>

 </params>

 <data>

  <record>

   <ID>0287002C02870001</ID>

   <NAME>ВОДКА</NAME>

   <TYPE>000000010287002C</TYPE>

   <TYPE_NAME>Кодификатор алкогольной продукции (ГАК)</TYPE_NAME>

   <VALUE/>

   <ABBREVIATION>0318</ABBREVIATION>

  </record>

 </data>

 <result><code>0</code></result>

</response>

Пример запроса объекта БД (продукт, атрибут «Наименование») и результат (ответ)

GET http://host:port/RootPath/get?id=3:0:0:176665&attr=NAME

<response>

 <cmd>get</cmd>

 <params>

  <param>

   <name>id</name><value>3:0:0:176665</value>

   <name>attr</name><value>NAME</value>

  </param>

 </params>

 <data>

  <record>

   <ID>8C0000000002B219</ID>

   <NAME>Ранец orange Алмаз дет 600Д</NAME>

  </record>

 </data>

 <result><code>0</code></result>

</response

Создать объект в БД (insert)

Создаёт новый объект в БД. Категория объекта (таблица) задаётся параметром table=. Возможные значения USER, CLASSIF, PARTNER, PRODUCT, DOCUMENT, LINE. Тип объекта (числовой, по проекту) задаётся параметром type=.

Значения атрибутов для создаваемого объекта передаются в содержимом (content) POST- запроса в xml-формате. Структура контейнера

<?xml version="1.0" encoding="Кодировка запроса"?>
<request>
 <data>

  <record>

   <ИмяАтрибута1>Значение атрибута 1</ИмяАтрибута1>

   <ИмяАтрибута2>Значение атрибута 2</ИмяАтрибута2>

   ...

   <ИмяАтрибутаN>Значение атрибута N</ИмяАтрибутаN>

  </record>

</data>
</request>

Имя атрибута должно совпадать с именем поля в таблице БД oracle. Например для товара (product) 305[5]"Код" - <CODE>, 305[6] "Наименование" - <NAME>, 305[14745607] "ЕИ" - <F14745607>

Возвращает стандартный xml-контейнер с кодом завершения и описанием результата. В разделе <data> в структуре <record> возвращается атрибут ID, содержащий UID созданного объекта.

Обновить значения атрибутов объекта БД (update)

Изменяет значения атрибутов существующего объекта БД. UID объекта задаётся параметром id=.

Значения атрибутов для изменения передаются в содержимом (content) POST- запроса в xml-формате. Структура контейнера идентична тому, который используется в операции insert

Возвращает стандартный xml-контейнер с кодом завершения и описанием результата

Удалить объект из БД (delete)

Удаляет объект из БД, UID которого задаётся параметром id=.

Возвращает стандартный xml-контейнер с кодом завершения и описанием результата

Акцептовать объект (accept)

Выполняет стандартный акцепт объекта, UID которого задаётся параметром id=.

Возвращает стандартный xml-контейнер с кодом завершения и описанием результата

Деакцептовать объект (deaccept)

Выполняет стандартный деакцепт объекта, UID которого задаётся параметром id=.

Возвращает стандартный xml-контейнер с кодом завершения и описанием результата

Встроенные методы принимают UID объектов  как в стандартном строковом, таки в RAW-формате. Встроенные методы всегда возвращают UID объектов в RAW-формате

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

Домино8 в режиме WEB- сервера. Замеры производительности.

Тест производительности

Описание теста

Тест выполняется локально на одном компьютере, чтобы исключить влияние скорости передачи данных по сети.

Один экземпляр Домино8 запускается в режиме WEB- сервера с полностью отключённым протоколированием. На проекте написан простейший метод, который без задержек отвечает на входящий http-запрос. Ответ представляет собой текст в формате xml длиной 108 байт.

Второй экземпляр Домино8 запускается в обычном режиме (клиента). На проекте написана процедура, которая в течении 60 секунд непрерывно в цикле вызывает описанный выше метод web-сервера. По окончании работы процедура показывает количество запросов, которое web- сервер успел обработать за прошедшее время.

В первом варианте теста запускается один экземпляр Домино-клиента, который посылает запросы на сервер. Во втором варианте теста запускается пять экземпляров Домино-клиента, которые одновременно посылают запросы на сервер.

Тестируется два варианта запуска WEB- сервера - с прослушиванием localhost и с прослушиванием реального ip-адреса сервера. В первом случае запросы от клиента к серверу идут через внутренний loopback, во втором - через сетевой интерфейс, что требует больших ресурсов.

Тестовые платформы

1. Intel Core2 Duo E8400 @3GHz, 8 Gb (одно ядро + HT)
2. Intel Xeon E5 2690 @3GHz, 16 Gb (четыре ядра без HT)

Результаты тестирования

Измерялась производительность web-сервера, запросов в секунду

Платформа		Intel Core2 Duo E8400	Intel Xeon E5 2690
Один клиент	localhost	3600	2900
	ip	3200	2500
Пять клиентов одновременно	localhost	7400	9300
	ip	6600	8600

Тест на размер очереди входящих сообщений

Описание теста

Тест выполняется локально на одном компьютере, чтобы исключить влияние скорости передачи данных по сети. Тестируется вариант запуска WEB- сервера с прослушиванием localhost.

Экземпляр Домино8 запускается в режиме WEB- сервера с полностью отключённым протоколированием. На проекте написан простейший метод (аналогично предыдущему тесту), который отвечает на входящий http-запрос с задержкой в 0.1 сек. Ответ представляет собой текст в формате xml длиной 108 байт.

В качестве клиента используется специально написанное многопоточное приложение. Каждый поток в цикле без задержек последовательно посылает 5 http- запросов к тестируемому серверу и получает от него ответы. Результаты и время выполнения записываются в отдельный протокол потока. Всего параллельно запускается 500 потоков, таким образом в очереди на сервере будет постоянно находится 500 запросов, а ожидаемое время ответа сервера на запрос будет примерно 500 * 0.1 = 50 сек.

На втором этапе последовательно увеличивается число потоков клиента до появления ошибок в ответах сервера. Так определяется максимальное количество входящих соединений для сервера и его реакция на перегрузку.

Тестовая платформа

Intel Core2 Duo E8400 @3GHz, 8 Gb (одно ядро + HT)

Результаты тестирования

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

Ошибки в логах сервера и клиента отсутствуют.

Среднее время выполнения запроса 50-55 секунд, что примерно соответствует расчётному 0.1 сек. на запрос при 500 запросах в очереди.

Количество выполненных запросов во всех логах клиента одинаковое - 5.

Предельное количество потоков, при котором система работает без ошибок - 1000. При дальнейшем увеличении числа потоков начинают регистрироваться ошибки закрытия соединения со стороны сервера «WebException : The underlying connection was closed: An unexpected error occurred on a receive». Таким образом можно предположить, что количество входящих соединений web-сервера равно 1000 при настройках «по умолчанию».

Для увеличения числа входящих соединений нужно менять настройки Microsoft IIS (смотрим документацию).

Тест связки NGINX + пул web- серверов Домино

Описание теста

Сервер NGINX развернут на VM с CentOS7. Никаких специфических настроек ОС не делалось.

После установки linux рекомендуется отключить SELinux. В противном случае возникает масса проблем с настройками nginx, когда отклоняются те или иные операции. Можно также отключить SE только для домена httpd_t

semanage permissive -a httpd_t

В настройках /etc/nginx/nginx.conf делаем следующее:

Контекст main

# Увеличиваем общее число файлов для рабочих процессов. Так как мы работаем
# в режиме proxy, то минимум число входящих соединений х2 + резерв
worker_rlimit_nofile 65535;

events {
   # Увеличиваем число соединений на рабочий процесс
   worker_connections 4096;
  # Включаем возможность одновременного приёма множества подключений
   multi_accept on;
}

Контекст http

# Включаем буферизацию логов доступа
access_log … buffer=32k flush=10s;

# Описываем пул web- серверов Домино
upstream DominoWeb {
   server 192.168.1.150:8081;
   server 192.168.1.150:8082;
   server 192.168.1.150:8083;
   …
   server 192.168.1.150:8098;
}

Контекст server

# Слушаем порт 8080
listen 8080;

# Локация для перенаправления запросов
location /domino/ {
   # Проксируем запросы на пул DominoWeb по методу round-robin
   proxy_pass http://DominoWeb;
}

Пул из 16 WEB- серверов Домино развернут на VM c Win19 Server. Память сервера 8Гб, процессоры 2х Intel Xeon E5 2680 @2.4GHz (по два ядра без HT). Суммарно web- сервера требуют 16 * 300Мб = 4,8Гб оперативной памяти.

В настройках firewall добавили правило, разрешающее входящие tcp соединения на порты 8080-8099.

Каждый экземпляр Домино8 WEB- сервера запускается на отдельном порту и с полностью отключённым протоколированием.

start C:\Domino\WebService\BIN\domino8.exe
   C:\Domino\WebService\PROJECT\RETAIL-STORE-2010
   /SERVER
   LISTEN=http://192.168.1.150:8081/domino/
   DBSERVER=oracle4
   SCHEME=MEGAITALIA
   USERNAME=Администратор
   TOKEN=81

На проекте написан простейший метод (аналогично предыдущему тесту), который отвечает на входящий http-запрос с регулируемой задержкой (значение задержки передаётся параметром запроса). Ответ представляет собой текст в формате xml длиной 300 байт

В качестве клиента для тестирования используется специально написанное многопоточное приложение. Каждый поток в цикле без задержек последовательно посылает 100 http- запросов к тестируемому серверу и получает от него ответы. задержка ответа сервера задаётся параметром запроса delay. Результаты и время выполнения записываются в отдельный протокол потока. Общее число потоков задаётся параметром JOBS. Таким образом в очереди на сервере будет постоянно находится JOBS запросов, которые будут распределяться между 16 web-серверами Домино. Ожидаемое время ответа сервера на запрос будет примерно JOBS * delay / 16

В процессе тестирования определяются значения параметров JOBS и delay, при которых появляются ошибки в ответах сервера. Так как число JOBS ограничено 1000, то для проверки работы бОльшего числа одновременных соединений с сервером запускается несколько экземпляров тестового приложения-клиента.

PS: При работающем SELinux могут быть такие проблемы:

Если после настройки прокси в nginx.conf  location … { proxy_pass домино_web_сервер} мы получаем ошибку 502 Bad Gateway, а в логах nginx видим (13: Permission denied) while connecting to upstream, то нужно разрешить в SELinux upstream http соединения:

setsebool -P httpd_can_network_connect 1

Для того, чтобы при включённом SELinux увеличить число файлов на рабочий процесс (worker_rlimit_nofile) нужно разрешить эту операцию:

setsebool -P httpd_setrlimit 1

Результаты тестирования

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

Стабильная работа описанной связки наблюдается только при JOBS < 200. Далее в логах клиента начинают регистрироваться периодические ошибки невозможности связи с сервером. При этом в логах сервера ошибок нет. При увеличении delay до 100ms безошибочная работа достигается при JOBS порядка 500. Предварительная гипотеза - исчерпание каких-то ресурсов, связанных с сетевыми протоколами (по аналогии с DDos атаками). Источником ошибок может быть как сервер nginx, так и тестовый клиент.

Тема требует дальнейшего исследования с привлечением профильных специалистов по nginx и сетевым протоколам.

 

Обмен с весами

126[2621442] "Передача товаров в весы через локальную сеть : Передача в PLU весов (ОБЩАЯ)"
126[29163522]"Передача товаров из строк документа в весы через локальную сеть : Передача товаров из строк документа в весы (ОБЩАЯ)"
Копать отсюда. Смотреть как они используются. Но модель жуткая, возможно психическое расстройство