Ласкаво просимо до чергового випуску Microsoft Knowledge Nuggets. Я ваш ведучий Міро Пітерс. Отже, ось сценарій. Ви працюєте в Business Central і вам потрібна одна невелика зміна. Можливо, додаткове поле в картці клієнта, інший етап погодження або правило, яке перевіряє замовлення перед його публікацією. Потім хтось згадує розширення AL, таблиці, сторінки та модулі коду, і раптом це невелике прохання звучить як ціла нова мова. Це мова, звісно, але вона не повинна здаватися загадковою. Уявіть Business Central як офісну будівлю. AL надає розробникам інструкції, як додати кімнату, форму або нове правило, не пробиваючи дірки в самій будівлі. Це і є сьогоднішня порція знань. До кінця цього випуску ви дізнаєтеся, що означає розробка на AL, чому існують розширення і як індивідуальні налаштування вписуються в Business Central. Чому бізнес налаштовує Business Central під себе? Business Central вже обробляє багато щоденних робочих процесів, фінанси, клієнтів, замовлення на продаж, рахунки, фактури і все це в одній системі замість купи електронних таблиць та окремих інструментів.

Для багатьох компаній стандартних налаштувань достатньо для виконання більшості завдань. Але ось у чому справа. Не існує двох компаній, які працюють однаково. Візьмемо дистриб'ютора продуктів харчування, якому потрібні деталі про партії товарів, які ніколи не використовує інша компанія. Сервісну компанію, який потрібен спеціальний процес погодження перед виставленням рахунків. Роздрібного продавця, який хоче мати рівніви нагород для знижок. Або когось іншого, кому потрібна форма з власними полями та внутрішніми правилами. Бізнес не буде змінювати свої методи роботи через одне відсутнє поле. І ви також не хочете, щоб кожен дрібний запит перетворювався на ризиковану зміну всієї системи. Раніше це було більшою проблемою. У старих системах розробники відкривали оригінальний код і редагували його безпосередньо. І це працювало доти, доки не надходило наступне оновлення. Тоді компанія мала нову версію від Microsoft з одного боку, власні зміни з іншого, і хтось мав узгоджувати все це, перш ніж можна було встановити оновлення.

Уявіть офіс, де кожен орендар прокладає нові кабелі через стіни без жодного плану. Це працює певний час, але коли будівлі потрібен ремонт, ніхто не знає, який кабель кому належить. Business Central обирає інший шлях. Замість переписування стандартного додатка, розробники створюють окреме доповнення, яке підключається до нього, зберігаючи стандартну частину недоторканою, тоді як власні зміни компанії працюють поруч через підтримувані точки системи. Це розділення має значення під час оновлень, оскільки Microsoft оновлює свою частину будівлі, а користувацькі налаштування залишаються у власному просторі. Звісно, все одно потрібні тестування та виправлення, адже це програмне забезпечення, але від розробника більше не вимагається копіювати та переробляти кожну зміну всередині оригінального коду Microsoft. Отже, що саме бізнес налаштовує під себе? Кастомізація додає дані.

Також додаються екрани, що ведуть персонал через завдання у правильному порядку. Вони також забезпечують дотримання правил, наприклад, зупиняють замовлення, якщо відсутній необхідний документ. Індивідуальні розробки також допомагають людям уникати ручних операцій. Уявіть, що персонал щоп'ятниці копіює дані клієнтів із Business Central в інший інструмент, вручно перевіряє умови, а потім надсилає звіт менеджеру. Якісно виконана зміна зберігає цю інформацію в Business Central, послідовно застосовує правила та надає персоналу кнопку або сторінку, що відповідає їхній щоденній роботі. Давайте розвіємо один міф. Ви не повинні налаштовувати все підряд. Стандартний Business Central уже має багато вбудованих процесів. Зміна чогось лише тому, що це виглядає інакше, ніж у старій системі створює додаткову роботу в майбутньому. Тож якісна кастомізація починається з чіткої бізнес-причини, з якою проблемою стикаються люди, що має відбуватися натомість, і чи може стандартний продукт це вже робити.

Коли стандартний продукт не задовольняє цю потребу, на сцену виходить All. AL фокусується на самому Business Central, считуючи, додаючи та змінюючи записи на рівні бази даних, одночасно контролюючи роботу сторінок, звітів та інших частин застосунку. Він також обчислює значення, переміщує дані та показує повідомлення, коли правила не виконуються в процесах. Це великий обсяг роботи для однієї мови, але AL – не універсальний інструмент для будь-якого програмного забезпечення, і ви не обрали б його для створення публічного сайту покупок, мобільної гри чи окремого настільного застосунку. AL існує для одного цілеспрямованого завдання – формування даних і поведінки всередині Business Central так, щоб система відповідала тому, як працює компанія. І саме це ми розглянемо далі. AL і розширення – безпечна модель доповнень. AL розшифровується як мова застосунків Application Language. Це мова програмування Microsoft для Business Central, яка надає розробникам структурований спосіб створення нових бізнес-функцій або зміни поведінки існуючих частин системи.

Але слово «розширення» так само важливе, як і «all». Розширення – це окремий застосунок, який може встановити Business Central. Він містить індивідуальні налаштування компанії, тоді як стандартний застосунок Business Central залишається недоторканим. Думайте про це не як про переписування довідника, а як про додавання до нього затверджених сторінок. Так, сторінок, які відповідають початковим правилам, не стираючи їх. Це може звучати як технічна деталь, але це змінює те, як індивідуальні налаштування існують часом. Уявіть, що компанії потрібна нова офісна кімната для спеціальної команди. Старий підхід означав би пробивання стіни в головній будівлі та зміну самої конструкції. Це може розв'язати проблему сьогодні, але майбутній ремонт стане кошмаром, бо оригінальна будівля більше не відповідає кресленням. Розширення працює інакше. У будівлі вже є двері, розетки та правила для додавання простору.

Ви будуєте нову кімнату через ці схвалені з'єднання. Кімната належить компанії, але головна будівля може обслуговуватися без руйнування кожної нестандартної стіни. Саме так працюють розширення Business Central. Базовий додаток містить стандартну роботу, яку надає Microsoft. Розширення може додавати власні поля, екрани, кнопки, правила, звіти і навіть посилання на інші системи. Воно може реагувати на певні бізнес-дії, але робить це через підтримувані способи підключення до стандартного додатка. Отже, межі вбудовані. Це добре. Безмеж невеликий індивідуальний запит може проникнути глибоко в зони, яких він не повинен торкатися. Завдяки розширенням розробник працює з чіткими типами об'єктів і визначеними точками підключення, що полегшує розуміння коду, коли комусь іншому потрібно буде його прочитати пізніше. Такий підхід також ідеально підходить для хмарної версії Business Central. Microsoft регулярно оновлює цей сервіс.

Компанії все одно потрібно тестувати своє розширення після змін, особливо якщо воно залежить від частин продукту, які були оновлені. Програмне забезпечення ніколи не знімає необхідності турботи про нього. Але відокремлення власного коду зменшує ймовірність того, що кожне оновлення перетвориться на серйозну переробку старих модифікацій. Ви можете почути згадки про CAL, коли мова йде про старіші системи Dynamics NAV. CAL з'явився в ранній моделі розробки, де програмісти часто змінювали оригінальні об'єкти програми безпосередньо. Багато компаній роками успішно використовували системи в такий спосіб, але це тісно пов'язувало власні розробки зі стандартним кодом, а оновлення вимагали багато роботи з порівняння та виправлення. AL перевів Business Central на розробку на основі додатків. Це не означає, що кожне розширення є великим чи складним. Одне розширення може лише додати поле до запису клієнта та відобразити його на знаємому екрані.

Інше може містити повне рішення для певного типу бізнесу з власними записами, процесами, сторінками та звітами. Обидва дотримуються однієї базової ідеї. Власний додаток існує поруч із Business Central, а не приховує його переписану версію. Ви також можете встановити більше, ніж одне розширення. Компанія може використовувати розширення від програмного партнера для розрахунку зарплати, інше – для доставки і невелике внутрішнє розширення для правил, важливих лише для цієї компанії. Business Central об'єднує їх у спільну робочу систему, доки вони дотримуються правил платформи та не конфліктують між собою. Отже, AL – це не просто спосіб написання коду. Це мова, яку розробники використовують для створення цих додаткових програм, а розширення – це контейнер, який переносить ці зміни в Business Central. Ця модель дозволяє компанії адаптувати систему, зберігаючи стандартний продукт впізнаваним і легшим в обслуговуванні.

Тепер давайте відкриємо одне з цих розширень і розглянемо його складові елементи. Основні будівельні блоки AL – всередині розширення All. Розробники працюють з об'єктами. Об'єкт – це окрема іменована частина програми з чітким завданням, як-от зберігання інформації, відображення екрана, виконання правила чи створення документа. Коли ви бачите ці завдання окремо, AL починає здаватися набагато менш схожим на суцільну стіну коду. Почнемо з місця, де зберігається бізнес-інформація. Таблиці зберігають дані в Business Central. Уявіть таблицю як цифрову картотеку для одного типу записів. Одна шафа може містити клієнтів, інша – товари, а ще одна – замовлення на продаж. Кожен запис – це один файл у цій шафі. Таблиця клієнтів містить один запис для кожного клієнта. Таблиця товарів містить один запис для кожного продукту. Якщо вашій компанії потрібна інформація, яку стандартний бізнес-централ не зберігає, розширення може створити власну таблицю, можливо, для рівнів винагород, оглядів обладнання чи затвердження проєктів.

Поля – це підписані місця всередині кожного запису. Запис клієнта може включати ім'я, адресу, умови оплати та номер телефону, оскільки таблиця клієнтів містить поля для цих деталей. Поля можуть містити текст, дати, суми, відповіді «Так» чи «Ні» або вибір із фіксованого списку. Поле також може вказувати на інший запис. Наприклад, клієнт може містити поле «Айді винагороди». Замість введення довільного тексту персонал обирає рівень винагороди з окремої таблиці винагород. Цей зв'язок підтримує дані в чистоті, оскільки всі обирають із одного і того самого відомого списку. Отже, таблиці зберігають факти. Але як люди бачать ці факти і як з ними працюють? Сторінки. Сторінка – це екран, який ви відкриваєте в «Бізнес-централ». Картка клієнта – це сторінка. Список замовлень на продаж – це сторінка. Сторінка контролює те, що користувачі можуть переглядати, вводити, шукати та з чим працювати. Різні сторінки підходять для різних завдань.

Сторінка картки фокусується на одному записі за раз, наприклад, на одному клієнті або одному товарі. Сторінка списку показує багато записів у рядках, що зручно, коли потрібно швидко переглянути, відфільтрувати або знайти щось. Сторінка робочого аркуша підтримує роботу, де люди вводять або обробляють кілька рядків інформації разом. Таблиця зберігає інформацію. Сторінка показує її користувачеві. Такий розподіл корисний, оскільки ви можете змінити екран, не змінюючи місце зберігання даних, або використовувати ту саму таблицю на кількох сторінках, коли різним командам потрібні різні представлення одних і тих самих записів. А що, як дані вже належать до стандартного запису Business Central? Ви зазвичай не створюєте таблицю клієнтів на заміну лише тому, що вам потрібно одне додаткове поле. Ви використовуєте розширення таблиці. Розширення таблиці додає ваше поле до існуючої таблиці клієнтів. Стандартний запис клієнта залишається на своєму місці, а ваше розширення додає специфічні дані компанії поруч зі стандартними полями.

Це може бути ідентифікатор винагороди, примітка про доставку, менеджер облікового запису або поле, що з'єднує з іншою частиною бізнесу. Але додавання поля до таблиці не відображає його автоматично на екрані. Для цього ви використовуєте розширення сторінки. Розширення сторінки додає поле, групу або дію до існуючої сторінки. Якщо бізнесу потрібно, щоб персонал обирав рівень винагороди під час перегляду клієнта, розширення сторінки може розмістити поле ID винагороди прямо в картці клієнта, де вже працюють співробітники. Це зберігає звичний досвід роботи. Замість того, щоб направляти користувачів на окремий спеціальний екран для простої деталі, розширення додає цю деталь на знайому їм сторінку. Розширення сторінки також може додавати дію, кнопку або команду меню, що запускає завдання. Наприклад, картка клієнта може містити дію винагороди, яка відкриває список винагород. За екраном вам потрібне місце для бізнес-правил.

Таким місцем часто є коди у ніт. Коди у ніт містить процедури AL – це іменовані фрагменти коду, які виконують певну роботу. Думайте про це як про BackOffice, який виконує завдання, коли сторінка, звіт або інший процес просить про допомогу. Припустимо, рівень винагороди визначає знижку для клієнта. Розрахунок знижки має бути в коди у ніт, а не в самій сторінці картки клієнта. Тоді процес продажу, звіт або майбутня сторінка зможуть використовувати одне й те саме правило без дублювання в багатьох місцях. Одне правило – одне місце для його підтримки. Бізнес-централ також включає інші типи об'єктів для різних завдань. Звіти збирають дані та представляють їх у вигляді документа або макета, як от рахунок фактура або звіт про продажі. Запити «Квіріс» ставлять конкретні питання до даних, наприклад, які клієнти замовили певний товар за період. Наприклад, XML-порти допомагають імпортувати або експортувати дані у структурованому форматі, часто коли іншій системі потрібно обмінятися інформацією з «Бізнес-централ».

Зберіть ці частини разом, і ви зможете уявити невелике розширення для винагород клієнтів. Таблиця «Винагород» зберігає кожен рівень та його відсоток знижки. Сторінки «Винагород» дозволяють персоналу керувати цими рівнями.

Кожен об'єкт відповідає за окрему частину роботи. Це робить розширення зручнішим для читання, тестування та внесення змін, коли «Бізнес-правило» змінюється через півроку. Але «Бізнес-правило» часто має виконуватися в точно визначений момент, наприклад, під час обліку замовлення. Ось тут стають у пригоді тригери та події. Події, тригери та «Бізнес-правила». Отже, ви додали поле «Винагороди» клієнта. Добре, ось справжнє запитання. Коли «Бізнес-централ» має використовувати це поле? Уявіть, що ви збираєтеся облікувати замовлення на продаж. Перш ніж система створить фінальні записи, ви хочете провести додаткову перевірку. Можливо, клієнту потрібен підтверджений рівень винагороди, перш ніж почне діяти знижка. Або, можливо, має існувати необхідний документ на доставку, перш ніж замовлення зможе рухатися далі. Ви хочете цю перевірку в потрібний момент, але не бажаєте копіювати весь процес обліку продажів у своє розширення лише заради одного правила.

Цей процес вже виконує багато роботи у фоновому режимі. Якщо ви його скопіюєте, ваше розширення буде змушене підтримувати всі майбутні зміни. Не найкращий варіант. Тому IAL надає розробникам кілька способів запуску коду. Те, що ви оберете, залежить від того, що має статися. По-перше, тригери. Тригер – це іменована точка всередині об'єкта IAL, де може виконуватися код. Коли хтось змінює значення в полі таблиці, тригер запускає код. Коли сторінка відкривається або закривається, тригер запускає код. Звіти, запити, XML-порти, таблиці, розширення, IAL – всі вони мають такі точки, куди розробник може додати правила. Візьмемо поле ID винагороди для клієнта. Коли користувач вибирає рівень винагороди, може спрацювати тригер перевірки. Код перевіряє, чи заблокований клієнт, чи існує такий рівень винагороди, чи потрібно оновити інше поле. Перевірка відбувається саме в момент зміни значення, а не пізніше, коли хтось виявить помилку.

Тригери добре працюють, коли правило безпосередньо стосується цього об'єкта. Але Business Central також використовує події. Подія – це як повідомлення. Одна частина програми надсилає його, коли щось стається. Вона може сповістити, що запис ось-ось буде вставлено, що документ скоро буде обліковано, або що процес завершено. Ваше розширення може прослуховувати це повідомлення. Код, який здійснює прослуховування, називається підписником події. Він очікує напевну іменовану подію. Коли Business Central ініціює цю подію, підписник виконує власну процедуру. Стандартний процес залишається головним. Наприклад, коли Business Central починає облік замовлення на продаж, він ініціює подію перед продовженням. Ваше розширення для винагород отримує це повідомлення. Воно перевіряє ID винагороди, клієнта та правило знижки. Потім воно або дозволяє процесу продовжитися, або зупиняє його з чітким повідомленням.

Стандартний процес публікації, як і раніше, належить Business Central. Ваше розширення просто додає своє правило, специфічне для компанії у цій точці підключення. Ви часто чутімєте назви подій, як от OnBafo або Onafta. OnBafo означає, що ваш код запускається перед завершенням дії. Це ідеально підходить для перевірки, яка може запобігти наступному кроку. Наприклад, зупинка замовлення на продаж, якщо умова не виконується. Afta означає, що дія вже відбулася. Ви можете відреагувати, створити пов'язаний запис, оновити примітку або розпочати іншу роботу. Назви вказують на час, а час має значення. Правило, яке запускається після публікації, не може їй запобігти. Правило, яке запускається занадто рано, може не мати потрібних даних. Тому розробники обирають подію залежно від того, що і коли має робити бізнес-правило. Код також може запускатися від дії. Користувач натискає кнопку, наприклад, перевірити статус винагороди, і ця дія викликає процедуру.

Код також може виконуватися, коли один об'єкт викликає інший через змінну. Це звучить технічно, але все просто. Одна частина розширення просить іншу виконати роботу. Змінні допомагають у цьому. Змінна – це іменоване місце, яке зберігає значення під час виконання коду. Це може бути число, текст, дата або навіть запис бізнес-централ, наприклад, поточний клієнт. В АЛ ви оголошуєте їх за допомогою ВАП. Наприклад, процедура винагород може використовувати змінну «Кастама» для зберігання запису поточного клієнта. Інша змінна – «Дискаунт пасент» зберігає розмір знижки. Це не постійні записи. Це лише робочі значення для цієї частини коду. Ось як це працює з місцем зберігання коду. Якщо правило може використовуватися у кількох місцях, помістіть його в кодеуніт. Таким чином, картка клієнта, процес продажу та звіт можуть викликати одну і ту саму процедуру знижки замість того, щоб мати власні версії.

Це дозволяє уникнути знайомої проблеми. Один екран застосовує знижку 10%, інший – 5% і ніхто не знає, якому правилу довіряти. Зберігання спільних бізнес-правил в одному кодеуніт дає розширенню єдине джерело для такого рішення. Отже, тригери обробляють правила, пов'язані з об'єктом. Події дозволяють розширенню реагувати на власні процеси Business Central. Кодеуніт зберігають спільну логіку разом. Коли ці елементи з'єднані, виникає питання, де розробники пишуть, тестують та перевіряють весь цей EL-код. Розробка на EL зазвичай відбувається у Visual Studio Code, яку часто називають VS Code. Це ваш робочий простір для написання файлів All. Він допомагає впорядкувати ваше розширення. Він допомагає знаходити проблеми та надсилає готовий додаток у середовище Business Central для тестування. Але VS Code сам по собі – це лише загальний редактор коду. Для нього потрібне розширення мови EL від Microsoft.

Це розширення пояснює VS Code, як працює Business Central. Воно може пропонувати назви об'єктів під час введення. Воно вказує на помилки перед публікацією. Воно допомагає переглядати поля та процедури. І воно підключає ваш проект до середовища Business Central. Це позбавляє від необхідності вгадувати. Коли ви розпочинаєте новий EL проект, можна запустити команду Elgo у VS Code. Вона створює базову папку проекту та файли налаштувань, назву розширення, видавця, версію та середовище Business Central. Сприймайте цю папку проекту як верстак для розширень. Кожен файл EL належить до неї. Один файл може містити таблицю, інший – розширення сторінки, а CodeUnit може мати власний файл. Таким чином, коли хтось відкриває проект, він може знайти потрібну частину без гортання величезного документа. Коли код готовий до тестування, VS Code компілює його у пакет додатка. Це встановлювана версія розширення.

Business Central зчитує цей пакет і додає розширення до середовища. Якщо є відсутнє поле, одрук або інша проблема, що заважає збірці додатка, VS Code повідомить про це до того, як пакет потрапить у Business Central. Тестування має відбуватися спочатку в Пісочниці. Пісочниця – це окреме середовище Business Central, де можна випробувати зміни без ризику для поточної роботи. Ви публікуєте розширення, відкриваєте сторінки, які воно змінює, вводите тестові записи і перевіряєте, чи правила працюють, як очікувалося. Таке розділення має значення. Ви ж не хочете дізнатися, що нове правило перевірки блокує замовлення на продаж, поки персонал намагається виконувати свою роботу. У Пісочниці можна припускатися помилок, видаляти тестові дані, змінювати код і публікувати знову, не впливаючи на робочі записи. Іноді код запускається, але результат виглядає неправильно. Ось тоді на допомогу приходить налагодження.

Ви ставите точку зупину в коді, запускаєте процес, і розширення призупиняється під час виконання. Під час цієї паузи можна перевірити значення, як от поточний клієнт, обраний рівень винагороди або відсоток знижки, обчислений процедурою. Замість того, щоб вгадувати, чому правило не спрацювало, ви можете побачити саме те, що отримав код. Команди розробників також використовують DIT, щоб зберігати історію своєї роботи. DIT записує зміни у файлах проєкту з часом. Якщо хтось змінює правило і створює проблему, команда може порівняти версії, побачити зміни та, за потреби, повернутися до попередньої версії. Це також допомагає, коли над одним розширенням працює кілька розробників. Для початківця найкращий шлях – починати з малого. Спочатку вивчіть можливості Business Central, а потім створіть одну таблицю та одну сторінку. Після цього розширті стандартну сторінку, додайте просте бізнес-правило та дізнайтеся, як події та інсталяційні дані вписуються в проєкт.

Далі давайте поєднаємо ці елементи в один невеликий додаток, який бізнес дійсно зможе використовувати. Простий приклад – створення додатку для винагород клієнтів. Як насправді виглядає справжнє розширення на L? Давайте зануримося у простий приклад. Уявіть, що вашій компанії потрібні рівні винагород для клієнтів, кожен зі своєю знижкою. Ви починаєте зі створення таблиці винагород. Сприймайте її як цифрову картотеку, де кожен файл містить ідентифікатор, опис та відсоток знижки. Наприклад, статус «Золотий» дає знижку 10%. Вашому персоналу потрібно керувати цими рівнями, не торкаючись технічних інструментів. Тому ви додаєте дві сторінки – сторінку списку винагород для перегляду всіх рівнів і сторінку картки винагороди для редагування чи створення нової. Вони можуть додати новий рівень, змінити відсоток або переглянути існуючі дані, не відкриваючи середовище розробки. Далі ви розширюєте таблицю клієнтів новим полем під назвою ID винагороди.

Це поле пов'язує кожного клієнта з одним записом винагороди, і ви розміщуєте його прямо на сторінці картки клієнта, де персонал уже веде облік даних. Потім ви додаєте дію для винагород, щоб вони могли відкривати список винагород безпосередньо з тієї ж картки. Саме правило знижки знаходиться всередині кодової одиниці – кодеунів. Коли іншому процесу потрібна знижка клієнта, він звертається до цієї кодової одиниці, замість того, щоб обчислювати її знову і знову на кожній сторінці. Це ефективно. Інсталяційна кодова одиниця додає початкові рівні винагород під час першого встановлення вашого розширення. А підписник подій перевіряє обраний рівень винагороди під час процесу продажу, застосовуючи правило вашої компанії саме в потрібний момент. Це одне невелике розширення, але зверніть увагу на те, що воно містить. Таблиці даних, екрани користувачів, навігаційні дії, логіка налаштування та бізнес-правила – усе це працює разом.

Це справжня сила ОЛ. Отже, висновок – ваша відправна точка в розробці на ОЛ. Отже, основний висновок. Розробка на IEL дозволяє додавати до бізнес-централ-специфічні функції, необхідні вашій компанії, не змінюючи основну програму. І вам не потрібно будувати все відразу. Почніть з одного поля, одного розширення сторінки та одного чіткого правила. Це ваш перший будівельний блок. Якщо цей фрагмент знань був для вас корисним, підпишіться на улюбленій подкаст-платформі та поділіться ним з тими, хто лише починає розробку в бізнес-централ. Приєднуйтесь до нас наступного разу, коли ми додамо ще одну частину пазла. Я Марко Пітерс, і це був черговий епізод Microsoft Knowledge Nuggets на М365FM.