Три года назад, наша команда (Premier Field Engineer) приступила к проверке кода Dynamics AX для ключевых клиентов. Это было довольно интересно, в связи с множеством модификаций различных проектов.
Сегодня я хотел бы немного вернуться в прошлое и рассказать здесь о нескольких наиболее распространенных проблем обнаруженных нами. Если вы ведущий разработчик Dynamics AX, возможно вы удивлены, почему эти проблемы до сих пор существуют. По этой причине, я и решил написать эту статью. Чаще всего разработка сейчас распределяется между разными командам, иногда несколькими партнерами и аутсорсинг компаниями, с разными навыками и квалификацией. Поэтому такие хорошо известные проблемы по-прежнему встречаются в рабочих проектах, когда правила best practices и проверки кода – не определены должным образом.
Следующий список не является исчерпывающим и основывается только на нашем опыте.
1. Неправильное кэширование приводит к ненужным обращениям к базе данных
Кэширование одно из важных свойств системы. Трехуровневая архитектура Dynamics AX позволяет определить кеширование на AOS и клиенте. Неправильное использование кеширования является первой причиной влияющей на производительность. Убедитесь, что выполняются следующие правила:
• У всех ваших таблиц установлена соответствующая табличная группа. Например, таблица с основными данными должны иметь группу “Main”, для таблиц с транзакционными данными должна быть указана группа «Transaction» (шапка или строки).
• Не оставляйте значение «None» для свойств «CacheLookup» и устанавливайте правильное значение: «EntireTable» для параметрических таблиц и «Found» для таблиц из группы «Main».
• Проверьте предельно допустимый размер кэша для каждой группы таблиц в настройках производительности сервера.
2. Ресурсоемкие запросы к базе данных из формы
Начиная с версии Dynamics AX 2012, вы можете использовать инструмент Form Style checker чтобы обнаружить любые запросы написанные непосредственно на формах. Как правило, такой код содержится в методе click() кнопки. SQL операции, такие как update, create, delete (обновление, создание, удаление) записи должны быть написаны на уровне класса или прямо на таблице. Единственная версия кода на классе поможет вам также избежать дублирования метода и поддерживать его актуальным.
3. Большие и ресурсоемкие запросы связанные с выборкой всех полей таблицы
Это возможно самая распространенная проблема имеющая большое влияние на производительность, но в то же время ее проще всего обнаружить и исправить. Используйте Exist Join и перечисление полей, всегда когда это возможно. Убедитесь, что в каждой выборке в коде указаны только необходимые поля. Та же идея с использованием exist join в выборке когда это возможно, для уменьшения объема данных передаваемых между AOS и базой данных. Это особенно актуально когда при модификации на существующие таблицы добавляется много новых полей.
Например, код:
While select TableA
{ Select TableB where TableB.FieldA == TableA.FieldA;
Print TableB.FieldB;
}
Заменить на следующий:
While select FieldA from TableA Join FieldA, FieldB from TableB
Where TableB.FieldA == TableA.FieldA;
{
Print TableB.FieldB;
}
4. Громоздкие и ненужные циклы
Это одна из наиболее редких проблем, но просто выявляемая и легко исправляемая. По существу, разработчики не используют агрегирующую функцию, а выполняют цикл для подсчета суммы или количества записей. Можно легко найти такой паттерн с помощью поиска в АОТ по ключевым словам «++» или «=+».
Таким образом, код:
While Select TableA where FieldA = “ConditionA”
{ CounterA ++;
}
Нужно заменить на следующий код:
Select count(RecId) from TableA where FieldA = “ConditionA”;
Counter A = TableId.RecId;
5. Очень много дисплей методов на гриде
Это главная причина медленного открытия и обновления формы. В этом легко убедиться: удалите дисплей метод, запустите утилиту Trace Parser tool и сравните трассировки запросов. В сценарии с использованием дисплей методов на столбцах грида, метод исполняется для каждой строки. Что ведет к значительным издержкам ресурсов.
Производительность дисплей методов может быть повышена за счет их кэширования на сервере приложений. Кэширование дисплей методов может также улучшить производительность при передаче записи с сервера на клиента. Значения всех кэшированных методов устанавливаются когда данные выбираются из базы данных. Кроме того, значение обновляется, когда вызывается метод “reread” на источнике данных формы. Избежать обращение к базе данных по RPC, вы можете используя новую функциональность в AX 2012 – Computed Column (Вычисляемая колонка). Значения этой колонки хранится непосредственно в базе данных SQL Server как представление. Вы можете посмотреть краткий обзор этой возможности на MSDN пройдя по ссылке http://msdn.microsoft.com/en-us/library/gg845841.aspx.
6. Прямой запрос несовпадающий с AOT индексами
Каждый раз, когда я проверяю новую систему Dynamics AX, я сразу проверяю хранимые процедуры в SQL Server Management Studio. Это основное место где вы можете встретить прямые запросы к базе данных DAX. Вы также можете найти прямые запросы в X++ коде, воспользовавшись поиском по ключевым словам “connection.createStatement()”. Прямой запрос может быть очень полезным, если он написан хорошо. Если нет – то он будет влиять на производительность, поскольку существующие индексы не используются в плане запроса.
Статья в блоге Michael DeVoe демонстрирует хороший пример запроса который не соответствует AOT индексам, таким как PartitionID и DataAreaId в AX 2012 R2.
Другой проблемой является стоимость поддержки такого кода. Любое изменение в схеме AOT не будет автоматически обновляться в прямых запросах подобно X++ методам. Это подобно хардкодной метке и противоречит принципам объектно-ориентированного языка X++.
7. Не используется проверка на возможность доступа к полю при разработке
Для того что бы убедиться, что мы неверно используем доступ к полям, можно использовать системный параметр “Error on Invalid Field access”. Эта настройка будет кидать исключение если к полю, которое не было извлечено, попытаться получить доступ. Этот параметр можно найти в разделе администрирование\Настройка\Система\Конфигурация сервера и требует перезапуска службы AOS. Настоятельно рекомендуется включить этот параметр при тестировании своих модификаций в приложении, чтобы избежать неприятных и трудно выявляемых ошибок в рабочей системе. Обратите внимание, это относится к системам начиная с AX 2012.
8. Ошибка компиляции в рабочей системе
Почему мы должны говорить об этом? На самом деле мы часто обнаруживаем ошибки и предупреждения Best Practices когда компилируем код на рабочей системе. Если вы следуете рекомендациям по внедрению кода, чтобы перенести новую разработку на рабочую систему, вы должны были запустить полную компиляцию несколько раз на предыдущих этапах. Для целей аудита, я также рекомендую работающей команде сохранять результаты каждой компиляции в HTML файл.
Вы также можете настроить инструмент Best Practice добавив собственные правила. Классы, используемые для проверки правил называются SysBPCheck<ElementKind>. Вызывайте методы init, check и dispose один раз для каждого узла AOT, в котором существуют элементы для компиляции.
И последнее, но не менее важное, вы должны определить для компилятора не завершать компиляцию если есть предупреждения. Таким образом большинство ошибок и предупреждений могут быть легко исправлены и нет никакого оправдания для откладывания их решения. Всегда нужно усилие, чтобы найти время для таких задач, но это несомненно окупится в долгосрочной перспективе.
9. Регресс групповых операций до операций построчной обработки
Три групповых операции, Update_RecordSet, Insert_RecordSet и Delete_From являются отличным способом повысить производительность запросов используя только одно RPC обращение к базе данных для нескольких строк. Проблема в том, что переписав SYS методы update(), insert() и delete() можно нарушить работу этих функций. Неправильная настройка может привести к построчной обработке строк запроса. Поэтому рекомендуется проверять RPC вызовы и проверить трассировщиком производительность подобного кода.
10. Очень много полей в таблицах
В версии Dynamics AX 2012 увеличилось количество таблиц, по сравнению с предыдущими версиями из-за проведенной нормализации базы данных. Это в основном, сделано для уменьшения избыточности данных в таблицах, а также для повышения производительности. Например, для таблиц с типом Parameter, в которых существует только одна запись в Компании. Напротив, в некоторых случаях может быть рекомендована денормализация для повышения производительности, поскольку это снижает количество присоединений в запросе.
Вам нужно найти правильный баланс при выполнении доработок, но основное правило заключается в том, чтобы ограничить количество полей в SYS таблицах до 50. Во время посещения одного из наших клиентов, мы обнаружили множество таблиц с сотнями новых полей. Что более удивительно, то что большинство из них оставались пустыми в рабочей системе, потому что модель данных не была глубоко проанализирована. Не забывайте запускать Customization Analysis Tool из Lifecycle Services что бы получить подробный отчет о вашей модели.
Ссылка на оригинал: http://blogs.msdn.com/b/axinthefield/archive/2014/02/18/top-10-issues-discovered-in-the-dynamics-ax-code-review.aspx
Добавить комментарий
Для отправки комментария вам необходимо авторизоваться.