Отслеживание изменений данных в ERP. История возвращения журнала базы данных

[imir]

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

В прежних версиях Microsoft Dynamics AX с этой задачей относительно приемлемо справлялся стандартный Журнал базы данных. Хотя его интерфейс никогда не был user-friendly. Но на это есть определенные причины. Его основная задача – скорость регистрации изменений, т.е. минимальное влияние на производительность плюс компактность хранения информации.

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

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

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

Краткая предыстория развития системы

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

Выход 12-й версии принес некоторые вынужденные изменения. В основном это связано с объединением локализаций всех стран в единое приложение и наращиванием функционала. В итоге структура базы данных претерпела ряд изменений.

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

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

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

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

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

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

Конечно, такие преобразования не могли не сказаться на удобстве работы с данными - просмотр стандартного Журнала базы данных стал еще больше напоминать заставку из фильма «Матрица» без графической оболочки. И если видишь в наборе системных кодов записей блондинку, скорее всего – ты избранный, либо просто опытный разработчик или архитектор.

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

Было принято твердое решение – журнал изменений надо делать заново

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

Первым делом нужно было определиться с важными требованиями к новому журналу изменений:

• Он не должен влиять на производительность системы;
• Не должен занимать много места в базе данных;
• Должен уметь расшифровывать значения в ссылочных полях в понятные пользователю описания;
• Должен уметь собирать на один экран всю информацию из всех связанных таблиц, относящихся к конкретной сущности;
• В том числе позволять отслеживать события удаления связанных данных, например, строк документов.


А помимо этого необходимо добавить недоступные сейчас возможности:

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

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

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

Не должен влиять на производительность системы

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

Тем временем, в очередном обновлении Microsoft перенес само отслеживание изменений из бизнес-логики и поместил его на триггеры в базе данных MS SQL, что существенно ускорило массовые операции обновления данных. С небольшими ошибками правда, о чем мы сообщили Microsoft и ее оперативно исправили в очередном обновлении DAX 365 10.0.4, так что имейте это в виду, если версия вашей системы ниже.

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

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

Не должен занимать много места в базе данных

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

Однако теперь у нас все равно появилось два журнала в системе? И да, и нет. За счет тонкой настройки полей по конкретным заявкам пользователей достигается существенное снижение нагрузки на базу и ее размер. А если этого недостаточно, обработанные записи стандартного журнала можно в принципе удалять, оставив только записи расширенного. Для этого были написаны соответствующие периодические процедуры с гибкими параметрами. Можно даже определить разный срок хранения истории для разных таблиц, например, для справочников и документов.

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

Должен уметь расшифровывать значения в ссылочных полях в понятные пользователю описания

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

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

А вот переименование записи решили не игнорировать, несмотря на то, что это теперь достаточно экзотическая операция. Однако обнаружился нюанс – включение отслеживания переименования записи на уровне sql-триггера равносильно включению отслеживание вставки + удаления записи, и именно вставка – довольно накладное событие. Поэтому автоматическое отслеживание переименования записи, по умолчанию, выключили в параметрах. Его можно включать руками на конкретных таблицах там, где оно практикуется.

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

Расшифровка ссылочных полей, например, адресов или аналитик


Должен уметь собирать на один экран всю информацию из всех связанных таблиц

Нужно было найти правильный подход к дизайну настройки журнала. В системе есть формы, а на формах есть набор связанных таблиц, которые пользователю визуально не видны - он воспринимает данные формы как единое целое. Через несколько итераций прототипирования был найден конечный вид новой удобной формы настройки журнала и связей таблиц, который, с одной стороны, в 95% случаев настраивает эти связи сам, без участия администратора, с другой – позволяет гибко настраивать их вручную, при необходимости. А также позволяет работать с таблицами, которые не видны через интерфейс.

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

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

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

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

Позволять отслеживать события удаления связанных данных

Наиболее частый пример такой потребности – при просмотре изменений в шапке заказа на продажу, закупки или журнала – отслеживать события удаления строк и полей в них. А также всех связанных с этими строками записей.

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

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

Возможность поиска, сортировки и фильтрации по таблице, названию поля, описанию записи

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

Появилось дополнительное преимущество – теперь мы можем модифицировать стандартные названия для целей журнализации. Например – назвать все таблицы SalesTable, SalesTable_W, MCRSalesTable и т.д. одинаково, чтобы пользователь, фильтруясь по описанию «Заказ на продажу» получал сразу все изменения заголовка заказа, включая связанные таблицы, и не вникал с структуру данных.

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

Настраиваемые описания записей

Описание записи таблицы составляется из двух полей, которые сейчас жестко заданы в структуре метаданных и не редактируются без привлечения разработчика. Была добавлена отдельная настройка полей, которые используются для формирования описания записи. Например, для строк заказов это может быть: код товара, название, единица измерения, количество.

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

Пользователи должны иметь возможность видеть какие поля в данный момент отслеживаются и являться инициаторами добавления новых настроек

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

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

Был разработан механизм заявок: в форму персонализации полей была добавлена информация о том, какие события сейчас отслеживаются на конкретном поле, и кнопка для создания заявки на отслеживание новых событий. Уведомление по заявке приходит администратору. Т.к. заявка уже содержит полное описание названия таблицы, поля, форму, ему фактически остается только утвердить ее или отклонить, как и было задумано - в три клика.

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

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

Возможность анализа размера журнала базы данных с точностью до конкретных полей

Но заявки пользователей – это не просто средство экономии времени. Это важный инструмент оптимизации настроек: теперь мы точно знаем, кто конкретно запросил данную настройку, и можем управлять настройками журнала.

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

А чтобы предотвратить их повторную активацию добавлен механизм настройки запрета от включения конкретных настроек в разрезе таблиц и полей.

Регистрация решения в AppSource

Было решено оформить данное решение в виде легко устанавливаемого дополнения системы и зарегистрировать на сайте приложений для продуктов семейства Microsoft Dynamics 365 – AppSource, который к тому времени уже начал свою жизнь и активное развитие.

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

Надеюсь, что проделанный нами путь по возвращению журнала изменений в систему сможет облегчить жизнь многих пользователей, партнеров, заказчиков, их команд внедрения, сэкономит немало времени, улучшит качество данных. И, в конечном счете, повысит качество самих внедрений и удовлетворенность заказчиков новой версией системы Dynamics 365 for Finance and Operations.

Приглашаем партнеров к совместному распространению этого решения. Мы очень ценим обратную связь, это помогает нам улучшать этот инструмент и дальше, поэтому предоставляем партнерам и ISV свободное и неограниченное использование решения в своих непроизводственных средах, например, тестовых или UAT. Воспользуйтесь формой обратной связи на странице решения, либо просто напишите мне на e-mail.

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

Ссылки на решение и форму обратной связи:

https://appsource.microsoft.com/en-u...d_database_log

Канал YouTube с видео, использованными в данной статье:

https://www.youtube.com/channel/UCti...RKtQ/playlists

Иван Миронов, руководитель отела разработки Microsoft Dynamics AX компании Navicon.

imironov@navicons.ru

[raz]

1. Цена?
2. Как получить?

[mazzy]

Цитата:

Сообщение от raz

1. Цена?
2. Как получить?

imir, Прежде всего, спасибо что делаете.

Цитата:

Сообщение от imir

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

э-э-э-э?!

Вопрос:
рассматривали ли фичу MS SQL, которая называется Change Tracknig?
эта фича вроде и в MS SQL Azure есть.
https://social.technet.microsoft.com...-tracking.aspx
https://docs.microsoft.com/ru-RU/sql...ql-server-2016
https://habr.com/ru/post/111207/

что не устроило в штатном Change Tracknig?

Change Tracknig используется в ax2012, ax7+ в модуле Retail.

[imir]

Спасибо, про Change Tracknig - я обязательно почитаю про его работу, в azure в т.ч.
Надо иметь в виду и следующие ограничения:
- нужно определиться с первичным ключом для каждой таблицы, а если он поменяется - иметь это в виду
- есть нюансы при резервном копировании и восстановлении базы, актуально, например с prod на work-copy либо uat и проч.
- нельзя указать конкретные поля для отслеживания

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

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

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

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

[imir]

Цитата:

Сообщение от raz

1. Цена?
2. Как получить?

1) Мы обязательно приложим все усилия, чтобы решение было доступно и полезно внедрению любого масштаба. От пяти пользователей и выше. Поэтому вопрос цены оговаривается индивидуально.

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

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

2) Воспользуйтесь формой обратной связи на странице решения, либо просто напишите мне на e-mail. Для получения дистрибутива и лицензии нам потребуется от вас только имя и номер держателя лицензии, которые вы можете посмотреть в своей справке о системе.

[imir]

Цитата:

Сообщение от mazzy

рассматривали ли фичу MS SQL, которая называется Change Tracknig?
эта фича вроде и в MS SQL Azure есть.
https://social.technet.microsoft.com...-tracking.aspx
https://docs.microsoft.com/ru-RU/sql...ql-server-2016
https://habr.com/ru/post/111207/

что не устроило в штатном Change Tracknig?

Change Tracknig используется в ax2012, ax7+ в модуле Retail.

UDP. Немного запоздало, но я потратил некоторое время на изучение вопроса.

В принципе ссылка с хабра - как всегда самая полезная )

1) CT (Change Tracking) - тут не подходит по смыслу, потому что не логирует версии данных, а только факт того, что они менялись, т.е. список ключей, например, recid.

Забавно кстати, что стандартный export в BYOD может конфликтовать по таблицам с модулями, которые так же пользуются CT. И на яммере посоветовали это "проверить", а что делать - не посоветовали.

2) CDC (Change Data Capture) - не работает в Azure, я не углублялся почему, пока это так.

3) SQL Server Audit - как я понял, потребует средств чтения + в Azure, что более важно, понадобится отдельный azure BLOB storage для журнала со всеми вытекающими подписками и настройками.

Общая проблема у последних двух подходов, как и пишут на Хабре - это "зафиксировать автора изменений". Если посмотреть в текст триггера, то там для расшифровки кода пользователя дергают самописную функцию DBO.SysGetUserIdFromContextInfo().

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

Зато, пока разбирался, понял, что Change Tracking + BYOD - отлично подходят для анализа журнала БД через PowerBI. Это уже инструмент администратора, поскольку настройки прав тут не применяются, зато в нем можно проводить расследования за большие периоды, смотреть тренды и т.д.

В выложил само решение в комплекте с PowerBI-BYOD экспериментами в общий доступ.

Это не мой первый опыт с BI по жизни, но первый - с Entity -> CT -> BYOD -> PowerBI, достаточно позитивный с точки зрения затраченного времени и полученного результата.

В принципе, даже получилось реализовать аналог формы DAX с гридами и т.п. Пока что нехватает возможности использовать графики - как слайсеры, поэтому при нажатии на строку таблицы с них слетают фильтры (либо держать зажатым ctrl). На сайте ideas уже есть пост на эту тему.

[trud]

А изменение адреса в клиенте умеет логировать? Тестовый кейс такой - заходим в клиента, создаем новый адрес(с новой Purpose), сохраняем.(хотим получить запись в отчете об этом). Редактируем этот адрес, сохраняем(тоже нужна запись в отчете). Меняем галку Primary(тоже хотим видеть в отчете). Удаляем этот адрес(тоже хотим видеть в отчете).
Недавно кодировал подобное в 2012, и оказалось, что по стандартному логу такой отчет не сделать, ибо любое редактирование адреса будет как update-insert в логе(так как это TimeEnabled таблицы) и были какие-то загвоздки чтобы распознать эти операции - отличить удаление от редактирования(решилось все доработкой лога БД для части таблиц)

[imir]

При попытке настроить обновление на ValidTimeState таблицах система будет подсказывать варнингом "This is 'ValidTimeStateTable', please mark 'Insert'", о том, что надо логировать вставку вместо обновления, без этого напоминания в стандарте достаточно тяжело производить настройки. Приложил описание сценария на примере справочника сотрудников. Записи в итоге будут отображаться как "вставка", но можно смотреть подробности - на закладке History + можно настроить поля описания записи так, чтобы вся нужная информация читалась сразу из него.
Пример настройки связей таблиц для адресов выкладывал на канале, постараюсь на днях записать данный сценарий на видео, т.к. адреса - одно из "интересных" по структуре мест в системе.

[imir]

Попробовал я поработать с адресами и понял, что без слез на неадаптированную историю изменений valid time state смотреть все же невозможно.

Вкратце, чем отличается поведение valid time state таблиц от обычных:
- Вставка - это вставка
- Обновление - это тоже вставка
- Удаление - это обновление без вставки

Взял себя в руки и доработал поддержку valid time state таблиц, теперь слезы исключительно от умиления.

Шаблон настроек, который использовал в видео, сохранил в инсталляторе, но и без них все прекрасно настраивается, система сама подскажет, что надо логировать вставку, вместо обновления, а при пометке удаления включит логирование поля ValidTo, чтобы отловить событие "удаления" записи и интерпретирует все как надо.

[trud]

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

[imir]

Ок, по прайсу - положил его пока что в папку с решением.

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

По ценнику - хотелось привязаться к индексу чашки кофе в Старбакс ну или бигмака, но кофе звучит благороднее ) Плюс учесть "размер" заказчика и объективную пользу от количества потребителей.
В итоге на данный момент получилось - от 7€-ми до 4€-х в месяц на пользователя.
Именно по убыванию: больше пользователей в системе - меньше ценник на пользователя. Меньше пользователей всего - меньше ценник итоговый.
Плюс есть вариант срочной лицензии, на год, два, три. При покупке на пять лет - лицензия становится бессрочной.
В итоге получаем среднюю цену в 27 000€ при средних же 90 пользователях в системе за бессрочную лицензию.

[Zabr]

Цитата:

Сообщение от imir

В итоге получаем среднюю цену в 27 000€ при средних же 90 пользователях в системе за бессрочную лицензию.

5 евро в месяц на человека за ЖБД ? Это в полтора раза дороже обслуживания золотой карты Сбера (~3.5 евро в месяц). Овердофига.

[imir]

Ну если от Сбера плясать - так и ценник на кофе в России ниже, а прайс универсальный, международный.
В целом, для нас эта тема скорее общественно полезная, нежели коммерческая, а поскольку мы консалтинг, то и вопрос с бюджетами на R&D традиционно непростой.
Мы бы с удовольствием пошли по модели open cource в данном случае, но, боюсь тогда оно станет сильно нестабильным, так что будем поддерживать, развивать, обеспечивать гарантию, а это все затраты.
PS Думаю Российский прайс мы сможем скорректировать.
Так же обратите внимание, что для сред под партнерской лицензией решение бесплатное + 3-х месячный триал - позволят воспользоваться им в самые тяжелые времена - тестовой эксплуатации и стабилизации системы, когда ошибки необученных пользователей и неотлаженных бизнес-процессов приводят к сотням и сотням часов затрат специалистов консалтинга и специалистов поддержки заказчика. Так что оно окупится, скорее всего, еще до окончания триала. А дальнейшее применение - на ваше усмотрение, настройки и стандартные возможности, если они достаточны - останутся в базе.

[imir]

Цитата:

Сообщение от Zabr

5 евро в месяц на человека за ЖБД ?

ЖБД как условно-пользовательский инструмент остался в 9-й версии. Потом, как я писал выше, пришла нормализация бд на фоне усложнения функционала, а с ними: таблицы расширения, сcылки по recid, valid time state, таблицы наследования и вот это все. Причем применили это, как будто намеренно, на основных сущностях системы – заказах/закупках, клиентах/поставщиках, ГАК, договорах, контактной и адресной информации и так далее.

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

Помню, как в момент выхода 12-й версии на рынок в Россию прилетали архитекторы из Core Team MS и встречались с партнерами. Первый вопрос, который я, кажется, тогда задал был – как весь этот взрыв на макаронной фабрике (точной формулировки не вспомню) - повлияет на восприятие конечными пользователями информации? Ответ был примерно таков, что они проделали путь через Атлантику, чтобы их похвалили за крутую архитектуру базы данных, фин-аналитики, subledger прекрасный, а вы.. эх вы ) И улетели, решать с загрузкой-выгрузкой информации в виде DMF, а потом и Data entity. А мы постепенно поняли, что в задачу дешифратора для пользователей рано или поздно придется впрягаться самим.

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

У нас есть клиент, работающий на раннем прототипе и там применимость доходит до 70%. Т.е. 70% пользователей системы что-то ищут на постоянной, ежедневной, еженедельной основе даже учитывая, что это – ранний прототип и Журнал изменений там доступен на строго ограниченном перечне форм.

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

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

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

[vmoskalenko]

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

Цитата:

Сообщение от imir

1) CT (Change Tracking) - тут не подходит по смыслу, потому что не логирует версии данных, а только факт того, что они менялись, т.е. список ключей, например, recid.

Тут у нас есть опыт. Делали именно на CT триггер для отправки данных в 3rd-party application из Data Entity.

Очень много багов. Так как делать надо было быстро, то все делали сами, т.е. практически переписывали стандартный X++ код работы с CT.
Например, в версии 10.0.4 Майкрософт совсем сломал CT, но быстро выпустил обновление для 10.0.4.

Вобщем, то что сделали получилось лучше и стабильней. Но исправлять ошибки в самом SQL уже не стали и пришлось придумывать "Монитор".

Так вот, Монитор.
Потом мы его немного допилили по своему усмотрению. И добавили запись в таблицу логов. За основу интерфейса взяли стандартный Database Log. За улучшением UI/UX не гнались, т.к. это внутренняя тулза, для разборов полётов. Но с ссылочными полями получилось хорошо. Потому что мы сохраняем Data Entity запись на каждое изменение в ней.

Ой, не правду говорю... Не на каждое изменение, а на каждое сканирование CT по изменениям. Так как клиент хотел быстрее, то сканирование проходило с частотой 1 раз в минуту. И для целей логирования это хорошая частота дискретизации. (60Гц? ;-) )

Итого, для CT есть две проблемы

• не всегда стабильно. Нужны костыли
• имеет дискретность (минимум 1 раз в минуту)

Но имеет приемущество, так как суть Data Entity - плоская репрезентация данных, то данные для конечного пользователя выглядят красиво и понятно.

[imir]

Надеюсь экспорт в BYOD, кторый опирается на CT - сейчас работает стабильно ) Потому что начиная с весны это будет основной механизм переноса данных в хранилище, база AxDW, на которой сейчас встроенные power bi дашборды работают - тоже переедет в BYOD.

Кстати, еще полезный кейс - по Журналу изменений теперь можно писать запросы, что раньше было невозможно, поскольку данные были запакованы в контейнер. Т.е. помимо анализа в "глазами", через форму в DAX или power bi, можно писать сложные выборки.

Например: отобрать все заказы за перод, где цена менялась в меньшую/большую сторону руками и т.д. Или, например, выбрать всех клиетов, у кторых в конкретном поле изначально стояло определенное значение, найти все связанные заказы и что-то автоматически с ними сделать, вернуть значения обратно или просто вывести в инфолог.
Cценарии могут быть разные, главное, что жбд теперь можно джойнить в запросах.

[imir]

По поводу продолжать, вроде и так все хорошо работает )
Но есть вот пара "идей" по поводу "журнала чтения" данных.

https://experience.dynamics.com/idea...1-0003ff688f4c
https://experience.dynamics.com/idea...1-0003ff68d4fd

Можно попробовать добавить и такую информацию, но непонятна реальная потребность. В принципе для аудита чтения данных есть даже специальный термин "DLP-система" -Data Loss Prevention.

Может у кого-то были запросы на такое и какие кейсы хотелось решить?

[vmoskalenko]

Цитата:

Сообщение от imir

Но есть вот пара "идей" по поводу "журнала чтения" данных.

https://experience.dynamics.com/idea...1-0003ff688f4c

Я тут недавно в этом копался и нашел чудную Эстонскую функциональность. По факту, они сделали то что указано в этой идеи. На картинке можно найти перечень объектов.
И официальную информацию тут https://docs.microsoft.com/en-us/dyn...-personal-info

P.S. Ну вот почему она не глобальная, а country-specific?

Цитата:

Сообщение от imir

https://experience.dynamics.com/idea...1-0003ff68d4fd

А это вообще не Аксапта, это Навик...

[imir]

Недавно на яммере как раз спрашивали про логирование присвоения ролей безопасности, это показалось хорошим вызовом и мы записали новый видео-разбор.

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