Microsoft Dynamics AX

Microsoft Dynamics AX (ранее Microsoft Axapta) – система управления ресурсами предприятия класса ERP для средних и крупных – с численностью персонала более 10 тыс. сотрудников - компаний.

Cкриншот - Microsoft Dynamics AX 2012 R3

Разработчиком решения Axapta, из которого «выросла» Microsoft Dynamics AX, была датская компания Damgaard Data A/S. Первая версия системы была выпущена в марте 1998 года в Дании и США. Название Axapta сменилось на Dynamics AX в 2004 году, после того как Microsoft приобрела разработчиков системы.

Функционально решение охватывает все области менеджмента предприятия: управление производством, дистрибуцией в сложных цепочках поставок, розничными сетями (индустриальное решение Dynamics AX for Retail), финансами, включая учёт по различным стандартам в холдинговых структурах, проектной деятельностью и сервисным обслуживанием, продажами, маркетингом, взаимоотношениями с клиентами, управление персоналом, а также контроль и анализ бизнеса, соответствие корпоративным политикам.

Microsoft Dynamics AX поддерживает одновременную работу в системе от 20 до 500 пользователей. На практике существуют инсталляции с числом пользователей более 1000, а также тестовые инсталляции для 3000 одновременно работающих с системой и более 32 тыс. обычных пользователей.

Пользователями Microsoft Dynamics AX являются более 12 000 компаний из сотни с лишним стран мира. Продаваемая в России версия по состоянию на середину 2015 года - Microsoft Dynamics AX 2012 R3, выпущенная в 2014 году.

В 1 квартале 2016 года ожидается выход новой версии системы – Dynamics AX 7.

История развития системы

2020: Запуск Neti модуля интеграции Microsoft Dynamics AX и 1С

6 апреля 2020 года компания Neti сообщила о разработке интеграционного модуля Microsoft DAX-1C, который позволяет настроить постоянную или сессионную передачу данных между системами, соблюдая все требованиям к форматам документов и учитывая особенности обеих информационных систем. Интеграционный модуль Microsoft Dynamics AX — 1С работает с версиями AX 3.0, 4.0, 2009 и 2012. Подробнее здесь.

2015: Флагманская ERP-система Microsoft станет мобильной

Технический директор Microsoft Business Solutions Майк Эренберг (Mike Ehrenberg) в декабре 2015 года рассказал TAdviser о развитии мобильных решений для продуктов Dynamics. По его словам, последние два года Microsoft активно работает над тем, чтобы обеспечить пользователям возможность полноценно работать со всеми своими бизнес-решениями с любых устройств, в том числе со смартфонов и планшетов.

Эренберг отметил, что появления такой возможности ожидали многие пользователи Dynamics, поскольку мобильные устройства все больше и больше используются для бизнес-задач: «Мобильность стала неотъемлемой, необходимой частью работы, и ее обеспечение для пользователей - один из ключевых моментов стратегии Microsoft в целом». Российский рынок облачных ИБ-сервисов только формируется 2.4 т

Майк Эренберг рассказал, что в новом релизе флагманской ERP-системы Microsoft - Dynamics AX 7, выход которого ожидается в первом квартале 2016 года, появится клиент на базе HTML5, который позволит работать с системой через браузер с различных платформ, включая мобильные устройства. Клиент разрабатывался с учетом результатов глубокого анализа юзабилити и оптимизирован для работы на устройствах с сенсорными дисплеями, говорит он.

C этим же релизом также планируется выпустить и универсальное приложение под ОС Windows 10, через которое также можно будет полноценно работать с системой с планшетов и смартфонов. По словам Майка Эренберга, вскоре после релиза Dynamics AX 7 аналогичное приложение планируется выпустить также под iOS и Android.

Приложение для внесения и анализа расходов для Dynamics AX под Android

Приложение Dynamics AX будет поддерживать функцию Continuum, разработанную Microsoft для Windows 10. Она позволяет превратить телефон в компьютер, подсоединив его к внешнему дисплею и клавиатуре. Таким образом, используя мобильное устройство, можно будет работать с Dynamics AX на большом дисплее.

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

Технический директор Microsoft Business Solutions отметил, что приложения для Dynamics AX компания выпускала и ранее, однако с их помощью можно было осуществлять лишь отдельные функции.

В пример он привел одно из них - Dynamics AX "Расходы". Оно позволяет оформлять командировочные и отчеты по затратам во время деловых поездок. Можно сделать покупку, занести в систему документацию по ней, сфотографировать чек и товар и через мобильное устройство отправить данные в систему Dynamics. Отчет о расходах с приложенной фотографией чека появляются в ней почти сразу после отправки, их увидит финансовая служба компании, которая примет решение, утверждать эти расходы или нет. Это приложение доступно для Windows Phone, iOS и Android.

С выходом полнофункционального приложения для Dynamics AX будет завершен ключевой цикл разработки мобильных клиентов для бизнес-решений – теперь они будут в наличии для всех продуктов Dynamics. Ранее возможность работать с мобильных устройств уже была реализована для ERP-системы Dynamics NAV и Dynamics CRM. Для работы с Dynamics NAV с планшетов требуется доступ к системе версии 2015 или более поздней версии, а на телефонах - доступ к Dynamics NAV 2016 или более поздней версии.

Для Dynamics CRM мобильное приложение появилось еще в 2013 году для планшетов, а позже и для смартфонов. В декабре 2015 года, с релизом Dynamics CRM 2016, в приложении была реализована поддержка работы в режиме оффлайн.

2011: Старт продаж Dynamics AX 2012

В августе 2011 года вышла версия Dynamics AX 2012.

Топ 10 проблем, обнаруженных при проверке кода в Dynamics AX

В 2011 году команда Premier Field Engineer приступила к проверке кода Dynamics AX для ключевых клиентов, по итогам которой сформировала список обнаруженных проблем^[1]:.

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 пройдя по ссылке [1].

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 что бы получить подробный отчет о вашей модели.

2008: Запуск Dynamics AX 2009

В июне 2008 года вышла версия Dynamics AX 2009.

2006: Выход Dynamics AX 4.0

Система впервые вышла под новым названием – Dynamics AX 4.0.

2004: Новая концепция системы, новое название

Летом 2004 года, после завершения финансового года, Microsoft опубликовала новую концепцию - теперь Project Geen означает не совершенно новую систему, а некий план развития в рамках двух волн (Two waves: Wave One, Wave Two). Суть новой концепции:

1. Никаких революций и написанных «с нуля» систем. Только совместимость. Только эволюционное развитие. Плавный и гарантированный апгрейд со старых версий.

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

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

Новая концепция привела к рождению нового бренда - Microsoft Dynamics. Системы были переименованы в очередной раз. Теперь Axapta получила название Microsoft Dynamics AX, а Navision - Microsoft Dynamics NAV. На переходное время маркетинговые руководители разрешали писать новые названия с упоминанием старых в скобках: Microsoft Dynamics AX (ранее известный как Microsoft Business Solutions Axapta) и Microsoft Dynamics NAV (ранее известный как Microsoft Business Solutions Navision).

Официальные лица Microsoft тогда предпочитали не уточнять даты окончания «волн», также старались не акцентировать внимание на конечном продукте, который появится в результате этих двух волн, не говорить о его свойствах. Название продукта также не приводилось. В дальнейшем волны более-менее определились с датами и сроками, однако даже спустя несколько лет оставалось непонятным, когда запланировано завершение Project Geen.

2003: Проект Project Green

В конце 2003 года официальные лица из Microsoft объявили о проекте Project Geen - в рамках которого все ERP-системы должны быть заменены новой, созданной с нуля ERP-системой, в которой будут учтен опыт, накопленный командами купленных систем. Также планировалось все перевести в Visual Studio и все переписать на .Net.

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

Очень быстро со стороны официальных лиц Microsoft прекратились подобные высказывания и разговоры о кардинально новой системе. До конца финансового года наступила пауза - компания отложила Green Project до 2008 года, число разработчиков проекта было уменьшено с 200 до 70.

2001: Microsoft покупает Navision

В конце 2001 года появилось сообщение о том, что Microsoft покупает Navision, а в июле 2002 года вышло официальное заявление о том, что покупка завершена. После этого стала происходить стремительная смена названий: Navision Axapta официально стала называться Microsoft Navision Axapta, а Navision Attain стал называться Microsoft Navision Attain.

Затем в документах и правилах наименования продуктов произошли изменения. Название Attain исчезло, а Navision теперь нельзя было применять к Axapta. Официально системы стали называться Microsoft Business Solutions Axapta и Microsoft Business Solutions Navision. Мало того, правильные официальные названия двух систем на тот момент выглядели следующим образом:

• Microsoft® Business Solutions-Axapta
• Microsoft® Business Solutions-Navision

Некоторые продолжали использовать название Navision Axapta, некоторые сокращали до Microsoft Axapta, до MBS Axapta или просто говорили Axapta.

В то время в правилах по использованию названий продукта, Microsoft рекомендовала в качестве сокращенного названия использовать Microsoft Axapta.

Что же касается Navision, партнеры и разработчики почти не использовали это название, однако многие неискушенные люди запомнили название Attain и задавали вопросы именно по нему. Разработчики между собой называли его просто Navision. Уже тогда в интерфейсе программы (Navision 3.70) нигде не было слова Attain.

2000: Navision поглощает Damgaard

В конце 90-х гг. и в начале 2000 года произошли структурные изменения у разработчиков Axapta. Компания Navision приобрела компанию Damgaard, после чего началась чехарда с именами и названиями.

Ходили слухи, что Damgaard сначала предложил себя для продажи Microsoft, но в этом случае что-то не сложилось. В результате Damgaard продался своему первому конкуренту. Сразу после продажи, Axapta официально стала называться Navision Damgaard Axapta. Затем Damgaard быстро исчез из названия и Axapta получила свое официальное название Navision Axapta.

Многие маркетинговые материалы (документация, буклеты, демо-ролики) идут именно с этих времен. Именно отсюда повелось название Navision Axapta. В Axapta долгое время в окошке «О системе» было написано Navision Axapta.

В это время у компании Navision стало две системы: свой Navision Attain и приобретенная Navision Axapta. Именно с этого времени системы активно позиционируются на разные рынки, хотя раньше они конкурировали на одном и том же рынке.

1990-е: Работы по созданию новой системы Damgaard Axapta

В 1990-х годах, Damgaard начал работы по созданию новой системы Damgaard Axapta. В этой системе изначально присутствовали: возможность трехуровневой работы, объектно-ориентированный язык, полная поддержка Windows (Axapta никогда не создавалась для других ОС), инструменты для web-разработки, динамически рисуемые окна и отчеты (MorphX), технология функциональных ключей. В Axapta почти сразу отказались от поддержки СУБД собственного формата и оставили только MS SQL и Oracle.

В системе появились новые интересные модули типа Balanced Scorecard (система взаимосвязанных показателей), были серьезно развиты модули «Управление складом», «Управление персоналом», CRM и т.п. По сравнению с Concorde были существенно переделаны базовые модули «Главная книга», «Расчеты с дебиторами и кредиторами», «Управление запасами», «Производство» и др. В целом же, ERP-функционал Axapta был во многом заимствован из Concorde и перенесен на новую технологическую платформу.

В это же время, Navision также полностью перевел свою систему под Windows и стал развивать ее в сторону ERP. Название системы было изменено с Navision Financials на Navision Attain. В последней появился производственный модуль, модуль планирования загрузки мощностей, модуль управления работами и ресурсами и т.п.

С середины 90-х гг. Attain также можно называть ERP-системой. К концу 90-х гг. в Navision Attain был окончательно сформировался сервер приложений (что позволило системе работать в трехуровневой среде), была отлажена работа с MS SQL, был введен многоязычный интерфейс. К 2000 году обе ERP-системы окрепли, обросли функциональностью и сервис-паками, а также форумами специалистов.

К этому времени Damgaard Axapta обладала более серьезной технологической платформой, чем Navision Attain. Однако для Navision Attain было гораздо больше документации и методических материалов, чем для конкурента.

Все это время Damgaard Axapta и Navision Attain были разными системами от разных поставщиков. Внешние описания функциональных возможностей становились все более похожими, поскольку системы направлены на один и тот же рынок, на одних и тех же клиентов.

Резюмируя:

• Damgaard Axapta - революционная наследница идей и возможностей Concorde XAL, который в свою очередь являлся революционным наследником финансовых систем C4 и C5;
• Navision Attain - эволюционное развитие системы Navision Financials.

1980-е: Damgaard Data и Navision конкурируют в Дании

В 1980-х годах в Дании работали две фирмы - Damgaard Data и Navision^[2]. Обе они серьезно конкурировали за свой датский и европейский рынки и хотели завоевать американский рынок. Начинали они примерно одинаково - с разработки финансовых программ. У Damgaard Data это была C4 (а затем C5), у Navision - Navision Financials.

Затем Damgaard двинулся в сторону наращивания технологии и выпустила революционный по тем временам продукт - Concorde XAL, обладавший мощной инструментальной средой. В нем присутствовали: функционально-ориентированный язык, серьезный генератор отчетов, динамически создаваемые формы, технология слоев, поддержка многоязычного интерфейса. Тогда не было общепризнанной СУБД, поэтому Concorde XAL работал с базой данных собственного формата, с MS SQL и с Oracle. Конкорд мог работать под DOS и в Unix-системах. Concorde XAL полностью поддерживал MRP II, позволял работать с проектами, содержал другие модули - его по праву можно было называть ERP-системой.

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

В результате постоянной конкуренции друг с другом, системы от Damgaard и Navision многое позаимствовали друг от друга. Некоторые функции Concorde XAL были явно сделаны «в пику» Navision и, наоборот, некоторая функциональность Concorde XAL практически без изменений появилась в Navision.

Читайте также

• Microsoft Dynamics NAV
• Microsoft Dynamics CRM
• Microsoft Business Solutions

Примечания