AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 24.01.2018, 17:21   #1  
Skolos is offline
Skolos
Участник
 
56 / 13 (1) ++
Регистрация: 06.01.2016
D365 как правильно переопределить метод в таблице.
Добрый день.
По ходу изучения D365 возник вопрос. Как правильно переопределить метод в стандартной таблице.

Пример:

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

Что я не знаю и что делаю не правильно?
Изображения
 
Старый 24.01.2018, 18:51   #3  
Skolos is offline
Skolos
Участник
 
56 / 13 (1) ++
Регистрация: 06.01.2016
Спасибо. С этим разобрался, да и видел подобные статьи. Теперь другое не получается реализовать. Например в 2012 в стандартные методы типа insert я мог добавить аргумент insert(int _i = 0).
Как сделать подобное в 365?
Старый 24.01.2018, 21:28   #4  
skuull is offline
skuull
Участник
Most Valuable Professional
Лучший по профессии 2014
 
699 / 752 (27) +++++++
Регистрация: 08.03.2013
Адрес: ХЗ
Цитата:
Сообщение от Skolos Посмотреть сообщение
Спасибо. С этим разобрался, да и видел подобные статьи. Теперь другое не получается реализовать. Например в 2012 в стандартные методы типа insert я мог добавить аргумент insert(int _i = 0).
Как сделать подобное в 365?
Никак. И так же вы сможете передать новый параметр из существующего кода - никак. Остаётся способ передачи переменных через глобальный кеш или статические поля, но это уже на грани с извращением. Вы лучше задачу опишите.

Последний раз редактировалось skuull; 24.01.2018 в 21:32.
Старый 25.01.2018, 00:20   #5  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,273 / 3466 (122) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от Skolos Посмотреть сообщение
Спасибо. С этим разобрался, да и видел подобные статьи. Теперь другое не получается реализовать. Например в 2012 в стандартные методы типа insert я мог добавить аргумент insert(int _i = 0).
Как сделать подобное в 365?
Тут просто несколько другая парадигма. Для чего мы хотим передать параметр в insert? Чтобы сделать 2 логики, которые будут по-разному отрабатывать при вставке данных в таблицу.

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

Размер: 15.7 Кб

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

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

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

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

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

Последний раз редактировалось sukhanchik; 25.01.2018 в 00:31.
Старый 25.01.2018, 01:26   #6  
ax_mct is offline
ax_mct
Banned
 
2,548 / 1091 (0) ++++++++
Регистрация: 10.10.2005
Адрес: Westlands
Цитата:
Сообщение от skuull Посмотреть сообщение
Никак. И так же вы сможете передать новый параметр из существующего кода - никак. Остаётся способ передачи переменных через глобальный кеш или статические поля, но это уже на грани с извращением. Вы лучше задачу опишите.
А если тащить параметры на самом табличном буфере?
Virtual Field c "SaveContent" = No?
Или завести поле .myParameters типа контейнер и грамотно класть и парсить через свой фрэйморк для этого.
Я бы вообще такой контейнер добавил в .common

А если серьезно то лучше забыть о таких задачах как "как правильно переопределить метод в таблице" в D365. Парадигма программирования изменилась.
Только отсутствие связи или очень слабые связи, то есть или своя таблица или подписка на событие как отмашка.
Старый 25.01.2018, 03:32   #7  
skuull is offline
skuull
Участник
Most Valuable Professional
Лучший по профессии 2014
 
699 / 752 (27) +++++++
Регистрация: 08.03.2013
Адрес: ХЗ
Цитата:
Сообщение от ax_mct Посмотреть сообщение
А если тащить параметры на самом табличном буфере?
Virtual Field c "SaveContent" = No?
Или завести поле .myParameters типа контейнер и грамотно класть и парсить через свой фрэйморк для этого.
Я бы вообще такой контейнер добавил в .common
Я про это и говорил упоминая извращения. Непонятно что автор собираеться с этим параметром делать.
Старый 25.01.2018, 08:58   #8  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Вполне возможно, что автора устроит просто дополнительный extension method c дополнительной логикой и параметром - надо понять контекст.
Старый 25.01.2018, 11:04   #9  
Skolos is offline
Skolos
Участник
 
56 / 13 (1) ++
Регистрация: 06.01.2016
Всем большое спасибо за ответы! На счет того, зачем и что я собираюсь делать с этим параметром отвечу: На данный момент я ознакамливаюсь и разбираюсь с D365. И захотел уяснить для себя этот вопрос, так как, правильно заметил sukhanchik, в 2012 привык вешать логику на insert / update / delete.
Старый 25.01.2018, 11:43   #10  
Skolos is offline
Skolos
Участник
 
56 / 13 (1) ++
Регистрация: 06.01.2016
Как пример, для понимания, могу предложить следующую задачу синхронизации.
В 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 я могу работать как угодно, и добавлять параметры. Выходит, в соответствии с новыми парадигмами, в своих таблицах этого так же стоит избегать?
Старый 25.01.2018, 12:49   #11  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2922 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Варианты:

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

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

3) Хранить состояние в отдельной таблице
Старый 25.01.2018, 14:14   #12  
dech is offline
dech
Участник
Аватар для dech
Самостоятельные клиенты AX
 
642 / 347 (13) ++++++
Регистрация: 25.06.2009
Адрес: Омск
Записей в блоге: 3
При событии обновления обновлять себя же - плохая идея. Во-первых, это рождает запутанный код, а во-вторых, возможны непредвиденные ошибки при не слишком глубоких знаниях разработчика. По мне так лучше
Цитата:
Сообщение от belugin Посмотреть сообщение
3) Хранить состояние в отдельной таблице
__________________
// no comments
Старый 25.01.2018, 15:24   #13  
ax_mct is offline
ax_mct
Banned
 
2,548 / 1091 (0) ++++++++
Регистрация: 10.10.2005
Адрес: Westlands
Цитата:
Сообщение от Skolos Посмотреть сообщение
Как пример, для понимания, могу предложить следующую задачу синхронизации.
...
И, я заметил, в моих таблицах с методами insert/update/delete я могу работать как угодно, и добавлять параметры. Выходит, в соответствии с новыми парадигмами, в своих таблицах этого так же стоит избегать?
Если возможно по бизнес-логике то лучше через несвязанный batch job(пакетник).

Если нужно "run-time" то postInsert подписка с хранением состояния в отдельной таблице.
Старый 25.01.2018, 22:12   #14  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,273 / 3466 (122) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от 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 (3), Skolos (1).
Старый 25.01.2018, 23:12   #15  
ax_mct is offline
ax_mct
Banned
 
2,548 / 1091 (0) ++++++++
Регистрация: 10.10.2005
Адрес: Westlands
Цитата:
Сообщение от Skolos Посмотреть сообщение
Всем большое спасибо за ответы! На счет того, зачем и что я собираюсь делать с этим параметром отвечу: На данный момент я ознакамливаюсь и разбираюсь с D365. И захотел уяснить для себя этот вопрос, так как, правильно заметил sukhanchik, в 2012 привык вешать логику на insert / update / delete.
Мало кто говорит об изменении парадигмы программирования. А оно прежде всего в том что по сути нельзя менять существующие процессы, можно только добавлять свои.

Microsoft об этом не говорит, выставляя дырки и хуки, но про себя подразумевает.
А мы по инерции рассматриваем D365FoE только как изменение приемов и техники программирования. И это засада.
Старый 30.01.2018, 12:24   #16  
skuull is offline
skuull
Участник
Most Valuable Professional
Лучший по профессии 2014
 
699 / 752 (27) +++++++
Регистрация: 08.03.2013
Адрес: ХЗ
Еще извращений с изменением сигнатуры метода от ведущих умов https://blogs.msdn.microsoft.com/mfp...od-signatures/
За это сообщение автора поблагодарили: Vadik (1), ax_mct (3).
Старый 30.01.2018, 12:28   #17  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от skuull Посмотреть сообщение
Еще извращений с изменением сигнатуры метода от ведущих умов https://blogs.msdn.microsoft.com/mfp...od-signatures/
Классная шутка про контекст (Option 3), смеялся до слез
__________________
-ТСЯ или -ТЬСЯ ?
Старый 30.01.2018, 22:01   #18  
ax_mct is offline
ax_mct
Banned
 
2,548 / 1091 (0) ++++++++
Регистрация: 10.10.2005
Адрес: Westlands
Цитата:
Сообщение от 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).
Старый 31.01.2018, 10:25   #19  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от ax_mct Посмотреть сообщение
Очень по теме статья для автора темы.

Как обычно самое интересное в комментариях.
1. Конечный клиент это клиент компании Microsoft.
2. Microsoft работает с конечными клиентами напрямую.
Хотя тема начинает скатыватся в оффтопик, замечу что у меня есть ощущение что у микрософта в очередной раз поменялась концепция. То есть - когда мы в конце апреля 2017ого года начинали наш первый проект на D365, нам на kick-off микрософт долго рассказывал как он нас будет контролировать, нам помогать, какие у нас будут pre-GoLive meetings и тд и тп. В последствии - ничего этого не было. Все взаимодействие свелось к запросам в службу поддержки и DSE ("Низовым индусам").
Похоже что идеологи нового подхода просто не представляли насколько дорого ободится сервисная сторона внедрений, и предпологали что хотя микрософт будет работать напрямую с клиентами, управление мешающимися под ногами партнерами не будет слишком дорого обходится.
На практике все конечно оказалось не так, реалистичных бюджетов на управление партнерами и проектами внедрения у MS конечно нету (конечно за исключением тех немногих проектов, которые ведутся MCS). Поэтому эта идея насчет того что микрософт работает с клиентом напрямую на практике потихонечку умирает (просто явочным порядком - поскольку ни у кого в MS нету времени вести наши проекты напрямую и при
этом еще как-то нас воспитывать). А MFP просто очень удален от реальности и до него эта интересная информация пока не дошла...
За это сообщение автора поблагодарили: Vadik (1).
Старый 31.01.2018, 18:57   #20  
ax_mct is offline
ax_mct
Banned
 
2,548 / 1091 (0) ++++++++
Регистрация: 10.10.2005
Адрес: Westlands
Цитата:
Сообщение от fed Посмотреть сообщение
Хотя тема начинает скатыватся в оффтопик,
Создал тему здесь
Эко-система Microsoft, это как?

Последний раз редактировалось sukhanchik; 01.02.2018 в 09:17.
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
alirazazaidi: Custom financial Dimension shows in lookup D365 for Finance and operations Blog bot DAX Blogs 0 14.09.2017 13:11
organicax: D365 applying application hotfix Blog bot DAX Blogs 0 11.04.2017 01:31
Фильтрование записей при "переходе к основной таблице" demID DAX: Программирование 10 18.11.2015 12:52
Использование метода merge на таблице Lucky13 DAX: Программирование 38 14.04.2011 11:12
Не удаётся правильно настроить DataSource через метод init Dronas DAX: Программирование 1 08.10.2007 09:10
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 12:46.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.