Клуб анонимных оверлейщиков

[kashperuk]

Цитата:

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

Но зачем? Затем чтобы можно было автоматически и без спроса менять этот "базовый" код в Production.
То есть, код SalesLineType.update() может меняться автоматически и без спроса в Production. Это так или нет? В этом вопрос.

Production или не-Production тут не причем.

Партнер теперь может ДОБАВИТЬ какую-то логику в выполнение salesLine.update(), без overlayering.

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

[ax_mct]

Цитата:

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

Нет. Не может

А зачем тогда уникальный механизм cлоев заменяется на точки расширения?
Не менять sys* обьекты - это понятно, но речь то идет к примеру о salesLineType и прочих.

В случае использования слоев (overlayering) я cразу могу видеть конфликт визуально, а в случае прицепления - все очень и очень неочевидно.

Если мне не разрешают overlayering для salesLineType то единственное обьяснение для меня что они хотят делать с этими классами что хотят и когда хотят. А иначе смысла в запрещении overlayering - просто нет.

Цитата:

Application Suite Hard Seal is a game changer. It unlocks a continuous update approach for the whole system including functionality and platform.

То есть тот же salesLineType.update() может меняться автоматически вендором в Production.
Откуда уверенность что "Нет. Не может"?
Потому что не могут взрослые люди играть со спичками на пороховом заводе?

http://www.intergen.co.nz/blog/Dynam...-mean-for-you/

[ax_mct]

Кто нибудь знает о системах с автоматическим обновлением и параллельным наличием при этом рынка плагинов?

Кто нибудь знает о системах которые обновляют application code в Production без оглядки и тестирования существующих в Production расширениях?

А он - знает.

[DAX.Company]

ax_mct да подождите вы плакать. Еще год до этого. Потом еще полгода на отладку. Что заранее то слезы лить

[ax_mct]

Цитата:

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

Раньше в salesLine.update(), к примеру, super() не вызывался. Вместо этого вызывался salesLineType.update(), который внутри делал record.doUpdate()

После рефакторинга super() будет вызываться в salesLine.update(), а весь код вокруг него который был в salesLineType вынесен в различные методы.

Тем самым достигается несколько вещей:
- Теперь можно будет подписаться на вызов onInserted, onUpdated, onUpdating, etc. на SalesLine - раньше это было невозможно, так как event тригеррится в super()
- Теперь можно будет с помощью CoC или pre/post-method handlers добавлять требуемую партнерскую логику, которая должна выполняться во время обновления строки заказа.

Цитата:

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

Production или не-Production тут не причем.

Партнер теперь может ДОБАВИТЬ какую-то логику в выполнение salesLine.update(), без overlayering.

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

Спасибо. Production или не-Production как раз очень причем.
При наличии ЛЮБЫХ кастомизаций обновлять автоматически что-бы то ни было в Production уровня ERP - неприемлимый риск для бизнеса. Даже если называть это hot fix.

Поэтому все эти фичи расширения - бессмысленны. Нельзя расширять при seemless updates/
continuous update approach for the whole system including functionality.

А если можно в staging вначале то слоеный overlayering намного надежнее. И необходимости в переходе на extensions в случае тестирования на staging - нет.

То есть прямо говорю о полной бессмысленности перехода с overlayering на extensions при seemless updates. Эти дырки - для никого.

[skuull]

Цитата:

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

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

Я может неправильно понимаю как сейчас происходит обновление не АХ компоненотов на production, но там вроде письмо счастья и вам все накатили, никто же вас не спрашивает\не дает потестировать. Что собсетвенно нового принесет авто обновление еще одно компонента к зоопарку Window, SQL и бог весть еще чего ?

[EVGL]

Цитата:

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

Что собсетвенно нового принесет авто обновление еще одно компонента к зоопарку Window, SQL и бог весть еще чего ?

Представьте себе такой сценарий: втихую применили цифровую инновацию к InventDim, в результате чего extension перестал компилироваться, вызываться и в таблицу партий перестали записываться некие важные атрибуты. В результате этого стало невозможным отследить историю синтеза лекарства, температурный режим и т.д. Умерли люди, начали расследование, а данных нет и концов не найти.

Fed прав, Good manufacturing practice с обязательным тестированием и документированием всего и вся существует для того, чтобы подобные сценарии стали если не невозможными, то маловероятными.

[skuull]

Цитата:

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

Представьте себе такой сценарий: втихую применили цифровую инновацию к InventDim, в результате чего extension перестал компилироваться, вызываться и в таблицу партий перестали записываться некие важные атрибуты. В результате этого стало невозможным отследить историю синтеза лекарства, температурный режим и т.д. Умерли люди, начали расследование, а данных нет и концов не найти.

Fed прав, Good manufacturing practice с обязательным тестированием и документированием всего и вся существует для того, чтобы подобные сценарии стали если не невозможными, то маловероятными.

Я же не отрицаю этих требований и аргументов. Забудем об x++ на секунду, можно ли теперь внедрит АХ таким компаниям если партнер даже не может на 100% сказать, какое программное обеспечение там используется и кто и когда его обновляет? Если нет, то нечего и х++ обсуждать и использовать это как аргумент, а если да то объясните в чем разница между inventDim и изменение в Azure SQL после которого что-то отвалилось.

[EVGL]

Разница в том, что на практике обновления SQL Server хорошо тестируются на обратную совместимость, а Dynamics не использует какие-то сверхъестественные запросы. Пока еще из-за этого ни разу ничего не "слетело". С формальной точки зрения разницы нет.

[skuull]

Цитата:

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

Разница в том, что на практике обновления SQL Server хорошо тестируются на обратную совместимость, а Dynamics не использует какие-то сверхъестественные запросы. Пока еще из-за этого ни разу ничего не "слетело". С формальной точки зрения разницы нет.

Т.е. формально гвоздь в кришку гроба этих внедрений уже забит, никакого отношение к оверлеингу это не имеет, вот и обсуждать нечего.
А с практической точки зрения граждане бангладеша сидящие на клиенте\партнере не сильно отличаються от своих сограждан в МС и также успешно развалят ваш InventDim и в extension модели, и в старой 12ке и в 9ке.

[macklakov]

Цитата:

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

а если да то объясните в чем разница между inventDim и изменение в Azure SQL после которого что-то отвалилось.

А тут тоже не все так просто, между прочим. Если там что-то "пофиксят" так, что запросы станут возвращать несколько другие данные, то последствия могут быть очень суровыми. Другое дело что вероятность такого события крайне низкая, ибо SQL протокол старый, а потому отлично отлаженный и хорошо покрытый тестами.
Тут еще один момент. Софт, зачастую, просто отказывается запускаться если SQL не той версии. Т.е. была своеобразная "защита от дурака". Невозможность запуститься при этом не была большой проблемой, т.к. можно было сидеть на совместимой версии сервера, пока не переведешь клиента на новую версию. В случае же полностью автоматических обновлений, любой софт может заклинить из-за того, что в Azure SQL ввели инновацию. И что в таком случае делать, не очень-то и понятно.

[kashperuk]

Цитата:

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

Спасибо. Production или не-Production как раз очень причем.
При наличии ЛЮБЫХ кастомизаций обновлять автоматически что-бы то ни было в Production уровня ERP - неприемлимый риск для бизнеса. Даже если называть это hot fix.

Поэтому все эти фичи расширения - бессмысленны. Нельзя расширять при seemless updates/
continuous update approach for the whole system including functionality.

А если можно в staging вначале то слоеный overlayering намного надежнее. И необходимости в переходе на extensions в случае тестирования на staging - нет.

То есть прямо говорю о полной бессмысленности перехода с overlayering на extensions при seemless updates. Эти дырки - для никого.

А если они перед этим будут прогонять все ваши автоматизированные тесты? У Вас есть тесты?

[EVGL]

Цитата:

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

А если они перед этим будут прогонять все ваши автоматизированные тесты? У Вас есть тесты?

Нет, конечно. Даже Microsoft Services не пишет автоматизированные тесты, это удорожило бы разработку вдвое.

Тема давняя. До тех пор, пока разработка Microsoft будет придерживать свои автоматизированные тесты у себя и только рассказывать без примеров, как удобно и просто их строить, в 90% случаев партнеры свои тесты писать даже для ISV модулей не будут .

[fed]

Цитата:

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

Нет, конечно. Даже Microsoft Services не пишет автоматизированные тесты, это удорожило бы разработку вдвое.

Тема давняя. До тех пор, пока разработка Microsoft будет придерживать свои автоматизированные тесты у себя и только рассказывать без примеров, как удобно и просто их строить, в 90% случаев партнеры свои тесты писать даже для ISV модулей не будут .

Я просто добавлю, что для не тиражируемых разработок (которые под одного клиента пишутся), писать автоматические тесты будет невыгодным даже если микрософт свои тесты отрелизит...

[kashperuk]

Цитата:

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

Представьте себе такой сценарий: втихую применили цифровую инновацию к InventDim, в результате чего extension перестал компилироваться, вызываться и в таблицу партий перестали записываться некие важные атрибуты. В результате этого стало невозможным отследить историю синтеза лекарства, температурный режим и т.д. Умерли люди, начали расследование, а данных нет и концов не найти.

Fed прав, Good manufacturing practice с обязательным тестированием и документированием всего и вся существует для того, чтобы подобные сценарии стали если не невозможными, то маловероятными.

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

Я поэтому про тесты и спросил - было бы выгодно их начать писать

[Vadik]

Цитата:

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

Представьте себе такой сценарий: втихую применили цифровую инновацию к InventDim, в результате чего extension перестал компилироваться

Холмс, но черт возьми как можно втихую что-то пропатчить в Application Suite так, чтобы ни клиент, ни партнер этого не заметили ?

[mazzy]

Цитата:

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

Холмс, но черт возьми как можно втихую что-то пропатчить в Application Suite так, чтобы ни клиент, ни партнер этого не заметили ?

также как и винду 10, офис.
также как и приложения в телефоне.
также как и яндекс-диск, гугл-докс и прочие сервисы.

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

будут даже некоторые обновления бесплатно накатывать. вспомним ту же виндовс 10.


а технология незаметного патча давно уже опробована на всех платформах. вирусы называется.

[Vadik]

Цитата:

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

Я поэтому про тесты и спросил - было бы выгодно их начать писать

Серьезные люди на подобную фигню не размениваются

[EVGL]

Цитата:

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

Холмс, но черт возьми как можно втихую что-то пропатчить в Application Suite так, чтобы ни клиент, ни партнер этого не заметили ?

Легко. В AX7 можно на лету простым копированием заменить Assembly как в далеких дремучих годах, когда мы брутально AOD копировали. Только здесь даже IIS запускать и перекомпилировать не надо. И все, voila, триггер не вызывается.

[Vadik]

Цитата:

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

Легко. В AX7 можно на лету простым копированием заменить Assembly как в далеких дремучих годах, когда мы брутально AOD копировали. Только здесь даже IIS запускать и перекомпилировать не надо. И все, voila, триггер не вызывается.

То есть DSE скоро будет новое приложение на продуктив на лету накатывать, без тотального пятичасового простоя? Клево, скорей бы уже