09.07.2017, 18:29 | #141 |
Участник
|
Цитата:
Партнер теперь может ДОБАВИТЬ какую-то логику в выполнение salesLine.update(), без overlayering. Для того чтобы это сделать, ему не нужно никого спрашивать, если Вы об этом.. |
|
09.07.2017, 18:37 | #142 |
Banned
|
А зачем тогда уникальный механизм 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.
Откуда уверенность что "Нет. Не может"? Потому что не могут взрослые люди играть со спичками на пороховом заводе? http://www.intergen.co.nz/blog/Dynam...-mean-for-you/ |
|
09.07.2017, 19:26 | #143 |
Banned
|
Кто нибудь знает о системах с автоматическим обновлением и параллельным наличием при этом рынка плагинов?
Кто нибудь знает о системах которые обновляют application code в Production без оглядки и тестирования существующих в Production расширениях? А он - знает. |
|
|
За это сообщение автора поблагодарили: EVGL (1). |
09.07.2017, 19:31 | #144 |
Участник
|
ax_mct да подождите вы плакать. Еще год до этого. Потом еще полгода на отладку. Что заранее то слезы лить
|
|
|
За это сообщение автора поблагодарили: ax_mct (1). |
09.07.2017, 19:52 | #145 |
Banned
|
Цитата:
Сообщение от kashperuk
Раньше в salesLine.update(), к примеру, super() не вызывался. Вместо этого вызывался salesLineType.update(), который внутри делал record.doUpdate()
После рефакторинга super() будет вызываться в salesLine.update(), а весь код вокруг него который был в salesLineType вынесен в различные методы. Тем самым достигается несколько вещей: - Теперь можно будет подписаться на вызов onInserted, onUpdated, onUpdating, etc. на SalesLine - раньше это было невозможно, так как event тригеррится в super() - Теперь можно будет с помощью CoC или pre/post-method handlers добавлять требуемую партнерскую логику, которая должна выполняться во время обновления строки заказа. Цитата:
При наличии ЛЮБЫХ кастомизаций обновлять автоматически что-бы то ни было в Production уровня ERP - неприемлимый риск для бизнеса. Даже если называть это hot fix. Поэтому все эти фичи расширения - бессмысленны. Нельзя расширять при seemless updates/ continuous update approach for the whole system including functionality. А если можно в staging вначале то слоеный overlayering намного надежнее. И необходимости в переходе на extensions в случае тестирования на staging - нет. То есть прямо говорю о полной бессмысленности перехода с overlayering на extensions при seemless updates. Эти дырки - для никого. |
|
|
За это сообщение автора поблагодарили: macklakov (1). |
09.07.2017, 22:55 | #146 |
Участник
|
Цитата:
Сообщение от fed
Во многих индустриях (в частности в фармацевтике), обязательно использование стандартизированых систем управления качеством. И большая часть систем качества требует верификации устанавливаемого программного обеспечения. Не буду притворятся что я очень хорошо процесс верификации понимаю, но одно из его требований состоит в том, что любое обновление, перед развертыванием, должно либо тестироваться самим клиентом, либо каким-то независимой тестирующей организацией. Поэтому никакой автоматической установки обновлений в фармацевтике нет и быть не может. Аналогичный подход применяется и в других индустриях где системы управления качеством достаточно стандартизированы.
И разговоры об автоматическом обновлении чего либо просто демонстрируют как в MS на самом деле плохо понимают свой рынок... |
|
09.07.2017, 23:16 | #147 |
Banned
|
Цитата:
Fed прав, Good manufacturing practice с обязательным тестированием и документированием всего и вся существует для того, чтобы подобные сценарии стали если не невозможными, то маловероятными. |
|
|
За это сообщение автора поблагодарили: macklakov (1). |
10.07.2017, 01:36 | #148 |
Участник
|
Цитата:
Сообщение от EVGL
Представьте себе такой сценарий: втихую применили цифровую инновацию к InventDim, в результате чего extension перестал компилироваться, вызываться и в таблицу партий перестали записываться некие важные атрибуты. В результате этого стало невозможным отследить историю синтеза лекарства, температурный режим и т.д. Умерли люди, начали расследование, а данных нет и концов не найти.
Fed прав, Good manufacturing practice с обязательным тестированием и документированием всего и вся существует для того, чтобы подобные сценарии стали если не невозможными, то маловероятными. |
|
|
За это сообщение автора поблагодарили: macklakov (1). |
10.07.2017, 01:44 | #149 |
Banned
|
Разница в том, что на практике обновления SQL Server хорошо тестируются на обратную совместимость, а Dynamics не использует какие-то сверхъестественные запросы. Пока еще из-за этого ни разу ничего не "слетело". С формальной точки зрения разницы нет.
|
|
10.07.2017, 02:22 | #150 |
Участник
|
Цитата:
А с практической точки зрения граждане бангладеша сидящие на клиенте\партнере не сильно отличаються от своих сограждан в МС и также успешно развалят ваш InventDim и в extension модели, и в старой 12ке и в 9ке. |
|
10.07.2017, 02:26 | #151 |
NavAx
|
Цитата:
Тут еще один момент. Софт, зачастую, просто отказывается запускаться если SQL не той версии. Т.е. была своеобразная "защита от дурака". Невозможность запуститься при этом не была большой проблемой, т.к. можно было сидеть на совместимой версии сервера, пока не переведешь клиента на новую версию. В случае же полностью автоматических обновлений, любой софт может заклинить из-за того, что в Azure SQL ввели инновацию. И что в таком случае делать, не очень-то и понятно.
__________________
Isn't it nice when things just work? Последний раз редактировалось macklakov; 10.07.2017 в 03:05. |
|
10.07.2017, 11:38 | #152 |
Участник
|
Цитата:
Сообщение от 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. Эти дырки - для никого. |
|
|
За это сообщение автора поблагодарили: Vadik (1). |
10.07.2017, 11:52 | #153 |
Banned
|
Цитата:
Тема давняя. До тех пор, пока разработка Microsoft будет придерживать свои автоматизированные тесты у себя и только рассказывать без примеров, как удобно и просто их строить, в 90% случаев партнеры свои тесты писать даже для ISV модулей не будут . |
|
|
За это сообщение автора поблагодарили: Bobkov (1). |
10.07.2017, 11:57 | #154 |
Moderator
|
Цитата:
Сообщение от EVGL
Нет, конечно. Даже Microsoft Services не пишет автоматизированные тесты, это удорожило бы разработку вдвое.
Тема давняя. До тех пор, пока разработка Microsoft будет придерживать свои автоматизированные тесты у себя и только рассказывать без примеров, как удобно и просто их строить, в 90% случаев партнеры свои тесты писать даже для ISV модулей не будут . |
|
10.07.2017, 12:10 | #155 |
Участник
|
Цитата:
Сообщение от EVGL
Представьте себе такой сценарий: втихую применили цифровую инновацию к InventDim, в результате чего extension перестал компилироваться, вызываться и в таблицу партий перестали записываться некие важные атрибуты. В результате этого стало невозможным отследить историю синтеза лекарства, температурный режим и т.д. Умерли люди, начали расследование, а данных нет и концов не найти.
Fed прав, Good manufacturing practice с обязательным тестированием и документированием всего и вся существует для того, чтобы подобные сценарии стали если не невозможными, то маловероятными. Но конечно все равно более агрессивно, чем сейчас, когда никто не обновляется по 5 лет. Я поэтому про тесты и спросил - было бы выгодно их начать писать |
|
10.07.2017, 12:12 | #156 |
Модератор
|
Холмс, но черт возьми как можно втихую что-то пропатчить в Application Suite так, чтобы ни клиент, ни партнер этого не заметили ?
__________________
-ТСЯ или -ТЬСЯ ? |
|
10.07.2017, 12:15 | #157 |
Участник
|
Цитата:
также как и приложения в телефоне. также как и яндекс-диск, гугл-докс и прочие сервисы. наоборот, будут придумывать специальные механизмы, чтобы пользователю казалось, что он на что-то влияет и без его разрешения никаких обновлений не ставится. будут даже некоторые обновления бесплатно накатывать. вспомним ту же виндовс 10. а технология незаметного патча давно уже опробована на всех платформах. вирусы называется. |
|
10.07.2017, 12:16 | #158 |
Модератор
|
Серьезные люди на подобную фигню не размениваются
__________________
-ТСЯ или -ТЬСЯ ? |
|
10.07.2017, 12:18 | #159 |
Banned
|
Легко. В AX7 можно на лету простым копированием заменить Assembly как в далеких дремучих годах, когда мы брутально AOD копировали. Только здесь даже IIS запускать и перекомпилировать не надо. И все, voila, триггер не вызывается.
|
|
10.07.2017, 12:22 | #160 |
Модератор
|
То есть DSE скоро будет новое приложение на продуктив на лету накатывать, без тотального пятичасового простоя? Клево, скорей бы уже
__________________
-ТСЯ или -ТЬСЯ ? |
|
Теги |
#многоходовочка, #стокгольмскийсиндром, extensions, overlayering, все пропало, титаник задраен |
|
Опции темы | Поиск в этой теме |
Опции просмотра | |
|