Вспомним даты выхода всех версий Navision. Ключевыми являются Navision 2009, в котором была представлена полноценная трехуровневая архитектура. Также в этой версии появился ролевой клиент и веб-служба. В версии 2013 мы полностью отходим от классического клиента, остается только ролевой клиент, добавлена интеграция с SharePoint-порталом. В более поздних версиях появляется веб-клиент, далее - расширения (extensions) первой версии, в 2018й появляются расширения второй версии. В 2019 году выходит финальная версия D365 BC.

На что стоит обратить внимание в D365 BC?

1. Есть возможность устанавливать Navision, как в облаке, так и локально.
2. Есть сервисы по загрузке данных RapidStart и различные интеграции с SharePoint, Офисом и другими продуктами.
3. Появился мобильный клиент. Он позволяет подключаться к Navision через планшет и смартфон. Мобильный клиент разработан и для Android, и для iOS. Изначально был только Windows Client, классический, который потом эволюционировал в ролевой клиент. В 2013 версии появился Sharepoint Клиент, но в конкурентной борьбе побеждает веб-клиент, который позволяет подключиться к Navision через браузер, ничего дополнительно не устанавливая, просто введя в адресной строке адрес сервера Navision.

На протяжении всех этих лет развития визуально Navision остается неизменным, меняется только способ подключения. Пользовательский интерфейс системы все легко узнают. Этот интерфейс Navision очень похож на Microsoft Dynamics AX и другие продукты Microsoft.

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

И вот начиная с версии NAV 2017 Microsoft вводит новую функциональность – extensions. Точнее, это даже не функциональность, а новый способ разработки модификаций. Суть этого способа следующая: для каждого расширения разработчик разворачивает отдельную базу разработки и выполняет на этой базе модификации «классическим» способом. Далее запускаются команды Power Shell, которые сравнивают модифицированное приложение и оригинальное (без правок). Эти команды вычисляют дельту, а и из этой дельты формируется расширение, которое потом устанавливается на приложение клиента в виде надстройки.

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

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

И вот в версии NAV 2018 появляются расширения второй версии.

Что же изменилось в ней по сравнению с первой версией?

Первое. Разработка перенесена в Visual Studio Code. Синтаксис C/AL заменен на синтаксис AL. Вот некоторые отличия AL от С/AL. В объектах убрали триггер документации, убраны все графические элементы отображения объектов.

AL используется только для разработки расширений. В классической разработке остается C/AL.

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

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

Теперь установка расширений выполняется из Visual Studio Code c помощью одной команды без параметров. Все параметры подключения к базе прописываются в отдельном конфигурационном файле в проекте. Этот файл используется и при скачивании кода, и для установки приложений, и для дебагинга, и, вообще, для всех операций, связанных с приложением. В расширениях же первой версии для установки приходилось запустить серию команд в Power Shell с большим числом параметров.

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

Объясню на примере. У нас есть расширение A, B, C. Расширение B зависимо от расширения А, расширение C зависимо от расширения B. В итоге в расширении C можно использовать функциональность расширения А. Например, в расширении А добавили поле в существующую таблицу. В расширении С мы можем использовать его. В расширении А добавили таблицу, в расширении С можем эту таблицу использовать. И так далее.

Теперь расскажу о новых типах объектов. Это TableExtension и PageExtension.

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

Еще одна особенность этих новых типов объектов – на них покупать лицензии не нужно, они бесплатные.