D365 как правильно переопределить метод в таблице.

[Skolos]

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

Пример:

Нужно навесить метод insert на таблицу BankGroup.
Таблица BankGroup - модель Application Suite.
Свой проект я реальзовую на моей модели. В ней подключил модель Application Suite.
Как я понимаю, данные кастомные вещи нужно делать через extension. правильно?
Я создал BankGroup.Extension но добавить в него метод не могу.

Что я не знаю и что делаю не правильно?

[belugin]

https://docs.microsoft.com/en-us/dyn...d-method-table

[Skolos]

Спасибо. С этим разобрался, да и видел подобные статьи. Теперь другое не получается реализовать. Например в 2012 в стандартные методы типа insert я мог добавить аргумент insert(int _i = 0).
Как сделать подобное в 365?

[skuull]

Цитата:

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

Спасибо. С этим разобрался, да и видел подобные статьи. Теперь другое не получается реализовать. Например в 2012 в стандартные методы типа insert я мог добавить аргумент insert(int _i = 0).
Как сделать подобное в 365?

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

[sukhanchik]

Цитата:

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

Спасибо. С этим разобрался, да и видел подобные статьи. Теперь другое не получается реализовать. Например в 2012 в стандартные методы типа insert я мог добавить аргумент insert(int _i = 0).
Как сделать подобное в 365?

Тут просто несколько другая парадигма. Для чего мы хотим передать параметр в insert? Чтобы сделать 2 логики, которые будут по-разному отрабатывать при вставке данных в таблицу.

Теперь у нас есть события. Этих событий мы можем наплодить великое множество, гораздо больше, чем 2 варианта. Более того, мы в коде можем управлять последовательностью вызова обработчиков этих событий. Соответственно, теперь каждая логика будет иметь свой обработчик события insert().


Тут есть 3 варианта развития. Можно как-то внутри себя договориться и использовать единый обработчик insert-а (один класс) и в нем реализовывать все 100500 вариантов логики. Пример в прошлых версиях - класс InventUpdate и его наследники InventUpd_*. В нашем случае через GlobalCache можно будет создать единый инстанс этого обработчика и следить за этим. Минус такого подхода в том, что должен быть единый и постоянный архитектор, который за этим будет следить. Не все компании считают нужным содержать такого человека.

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

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

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

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

[ax_mct]

Цитата:

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

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

А если тащить параметры на самом табличном буфере?
Virtual Field c "SaveContent" = No?
Или завести поле .myParameters типа контейнер и грамотно класть и парсить через свой фрэйморк для этого.
Я бы вообще такой контейнер добавил в .common

А если серьезно то лучше забыть о таких задачах как "как правильно переопределить метод в таблице" в D365. Парадигма программирования изменилась.
Только отсутствие связи или очень слабые связи, то есть или своя таблица или подписка на событие как отмашка.

[skuull]

Цитата:

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

А если тащить параметры на самом табличном буфере?
Virtual Field c "SaveContent" = No?
Или завести поле .myParameters типа контейнер и грамотно класть и парсить через свой фрэйморк для этого.
Я бы вообще такой контейнер добавил в .common

Я про это и говорил упоминая извращения. Непонятно что автор собираеться с этим параметром делать.

[belugin]

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

[Skolos]

Всем большое спасибо за ответы! На счет того, зачем и что я собираюсь делать с этим параметром отвечу: На данный момент я ознакамливаюсь и разбираюсь с D365. И захотел уяснить для себя этот вопрос, так как, правильно заметил sukhanchik, в 2012 привык вешать логику на insert / update / delete.

[Skolos]

Как пример, для понимания, могу предложить следующую задачу синхронизации.
В CustTable добавляем свое enum:NoYes поле isSynch. Оно отображает синхронищзирована ли строка с другой системой.
При insert CustTable поле isSynch=NoYes::No
При update CustTable поле isSynch=NoYes::No

Пускай есть обработчик синхронизации, он фильтрует CustTable по нашему полю и забирает не синхронизированые строки, делает update CustTable поле isSynch=NoYes::Yes
В 2012 я бы добавил параметр и логику в метода update. Как мне поступить в D365?

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

Делаем таблицу myTable с двумя полями.
Enum::NoYes поле isSynch
RefRecId поле CustTableRecId

Связываем ее с CustTable. На insert CustTable вешаем создании соответственной строки и в моей новой таблице. на событие onUpdated CustTable вешаем myTable.isSynch = NoYes::No.
А обработчик синхронизации будет lделать. myTable.isSynch = NoYes::Yes

таком образом я избавляюсь от необходимости в аргументе на update.

И, я заметил, в моих таблицах с методами insert/update/delete я могу работать как угодно, и добавлять параметры. Выходит, в соответствии с новыми парадигмами, в своих таблицах этого так же стоит избегать?

[belugin]

Варианты:

1) Устанавливать в yes только если в update пришло новое значение Yes, иначе No. Проверять по orig() - новое или старое.

2) Тот, кто устанавливает факт синхронизации пользуется только doUpdate, а не update

3) Хранить состояние в отдельной таблице

[dech]

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

Цитата:

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

3) Хранить состояние в отдельной таблице

[ax_mct]

Цитата:

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

Как пример, для понимания, могу предложить следующую задачу синхронизации.
...
И, я заметил, в моих таблицах с методами insert/update/delete я могу работать как угодно, и добавлять параметры. Выходит, в соответствии с новыми парадигмами, в своих таблицах этого так же стоит избегать?

Если возможно по бизнес-логике то лучше через несвязанный batch job(пакетник).

Если нужно "run-time" то postInsert подписка с хранением состояния в отдельной таблице.

[sukhanchik]

Цитата:

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

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

Делаем таблицу myTable с двумя полями.
Enum::NoYes поле isSynch
RefRecId поле CustTableRecId

Связываем ее с CustTable. На insert CustTable вешаем создании соответственной строки и в моей новой таблице. на событие onUpdated CustTable вешаем myTable.isSynch = NoYes::No.
А обработчик синхронизации будет lделать. myTable.isSynch = NoYes::Yes

таком образом я избавляюсь от необходимости в аргументе на update.

Да, это тот вариант, который предлагают другие участники. Более того, так в системе уже активно делают и еще в AX 2012, когда таблицы "режут по вертикали" и связывают 1:1 по RecId.
Вариант с myTable - хороший вариант. Более того, дополнительное поле isSynch даже не нужно. Его роль будет играть наличие записи в myTable. Собственно говоря событие update() тут и не нужно. Приходит обработчик синхронизации, забирает записи из CustTable и вставляет забранные RecId в отдельную таблицу. Это событие (с т.з. бизнес-пользователя) никак не связано с изменением какого-либо другого поля типа "Налоговая группа" непосредственно в CustTable.
Отобразить галку в CustTable можно с помощью дисплей-метода, который будет делать exists join к myTable. Фильтровать - также по (not) exists join (тут придется немного покодить, если захочется организовать пользователю фильтр по этому полю, однако задача глобально - решаема).

Так что в контексте этой задачи использовать методы insert / update для вставки своей логики - не нужно. В отношении delete, если реализовать каскадное удаление в myTable, то на delete в myTable можно будет послать какой-нибудь сигнал второй системе. Но это уже не на CustTable, а в myTable - т.о. штатный функционал не трогается.

Цитата:

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

И, я заметил, в моих таблицах с методами insert/update/delete я могу работать как угодно, и добавлять параметры. Выходит, в соответствии с новыми парадигмами, в своих таблицах этого так же стоит избегать?

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

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

[ax_mct]

Цитата:

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

Всем большое спасибо за ответы! На счет того, зачем и что я собираюсь делать с этим параметром отвечу: На данный момент я ознакамливаюсь и разбираюсь с D365. И захотел уяснить для себя этот вопрос, так как, правильно заметил sukhanchik, в 2012 привык вешать логику на insert / update / delete.

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

Microsoft об этом не говорит, выставляя дырки и хуки, но про себя подразумевает.
А мы по инерции рассматриваем D365FoE только как изменение приемов и техники программирования. И это засада.

[skuull]

Еще извращений с изменением сигнатуры метода от ведущих умов https://blogs.msdn.microsoft.com/mfp...od-signatures/

[Vadik]

Цитата:

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

Еще извращений с изменением сигнатуры метода от ведущих умов https://blogs.msdn.microsoft.com/mfp...od-signatures/

Классная шутка про контекст (Option 3), смеялся до слез

[ax_mct]

Цитата:

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

Еще извращений с изменением сигнатуры метода от ведущих умов https://blogs.msdn.microsoft.com/mfp...od-signatures/

Очень по теме статья для автора темы.

Как обычно самое интересное в комментариях.
1. Конечный клиент это клиент компании Microsoft.
2. Microsoft работает с конечными клиентами напрямую.
3. Цель Microsoft - обновлять систему технически и функционально когда и как он захочет.
4. Ответственность за совместимость на вас как ISV, Партнера или клиента.

Вы все еще хотите переопределять метод в таблице D365FoE в чужом приложении для чужого клиента?

Главное это понять парадигму "the ‘open-close’ paradigm .. Open for extensions, closed for modifications".
Это главнее чем нахождение форточки. И об этой парадигме как-то все молчат, а в ней вся соль.

Цитата:

Michael Fruergaard Pontoppidan
January 19, 2018 at 8:10 am
Thanks Dick.

The overall goal of extensibility is to get our shared customer running on the latest release always. This means that extra care and attention to writing robust extensions are required. Significantly more care than when customizing via overlayering. Ultimately; we want to be able to do a binary replace of AppSuite – and everything still works.

The AX extensibility model is quite powerful – too powerful in some cases. When using this toolbox, you are responsible for building a solution that can “survive” an AppSuite upgrade as-is. Any brittleness you build in, like dependencies on call stack, extensions to methods that are not coherent with the standard method will cause disruption to our customers. One example of the latter is to change the global company context in an extension method. We trust you to make strong, durable and lasting solutions.

I agree there is a turn-around time on extension requests; which can be obstructive to development. The sooner you log them the sooner you’ll get them; plan for this delay.

Regarding option 2: The state is class instance specific – not global. There are cases where the state is coherent with the class and its purpose. Here I would not have concerns.
Regarding option 3: You should really use IDisposable, like outlined, instead of guids and potentially stale caches.
Regarding delegates: Chain-of-command is large replacing the need for delegates (and requests for adding these).

[fed]

Цитата:

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

Очень по теме статья для автора темы.

Как обычно самое интересное в комментариях.
1. Конечный клиент это клиент компании Microsoft.
2. Microsoft работает с конечными клиентами напрямую.

Хотя тема начинает скатыватся в оффтопик, замечу что у меня есть ощущение что у микрософта в очередной раз поменялась концепция. То есть - когда мы в конце апреля 2017ого года начинали наш первый проект на D365, нам на kick-off микрософт долго рассказывал как он нас будет контролировать, нам помогать, какие у нас будут pre-GoLive meetings и тд и тп. В последствии - ничего этого не было. Все взаимодействие свелось к запросам в службу поддержки и DSE ("Низовым индусам").
Похоже что идеологи нового подхода просто не представляли насколько дорого ободится сервисная сторона внедрений, и предпологали что хотя микрософт будет работать напрямую с клиентами, управление мешающимися под ногами партнерами не будет слишком дорого обходится.
На практике все конечно оказалось не так, реалистичных бюджетов на управление партнерами и проектами внедрения у MS конечно нету (конечно за исключением тех немногих проектов, которые ведутся MCS). Поэтому эта идея насчет того что микрософт работает с клиентом напрямую на практике потихонечку умирает (просто явочным порядком - поскольку ни у кого в MS нету времени вести наши проекты напрямую и при
этом еще как-то нас воспитывать). А MFP просто очень удален от реальности и до него эта интересная информация пока не дошла...

[ax_mct]

Цитата:

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

Хотя тема начинает скатыватся в оффтопик,

Создал тему здесь
Эко-система Microsoft, это как?