13.03.2019, 15:11 | #1 |
Участник
|
i-neti: Фреймворк Extensible Data Security (XDS) в Dynamics 365 Finance for Operations
Источник: https://i-neti.ru/?q=blog%2F589
============== Фреймворк Extensible Data Security (XDS) - это особенность Dynamics 365 Finance and Operations и DAX 2012, которая позволяет расширить безопасность на уровне записей и ограничить доступ к таблицам с помощью политик. Эта особенность является улучшением безопасности на уровне записей, которая существовала в предыдущих версиях Dynamics AX. Простыми словами, XDS размещает выражение WHERE (или ON) на любом SQL запросе SELECT, UPDATE, DELETE или INSERT, основываясь на параметрах из другой связанной таблицы. подробнее Источник: https://i-neti.ru/?q=blog%2F589
__________________
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору. |
|
13.03.2019, 21:20 | #2 |
MCT
|
То что перевели, это хорошо, а насколько эта фича реально используется на проектах. Еще в 12 версии по моему очень тяжеловесно себя вела на больших объемах данных. Или область её применения исключительно справочники?
__________________
Axapta book for developer |
|
13.03.2019, 21:36 | #3 |
Участник
|
Работает и альтернатив особо нет. Мне кажется самый ходовой реквест это запретить редактирование или спрятать заказы на продажу по складу, фин аналитике или ещё по какому полю для группы пользователей. Хотя на одном проекте клиент захотел вести 2 бизнеса в одной компании и там все порезали по фин аналитике. Нужно было 2 компании и не мучатся, но... Короче работает и особо не тормозит. Но все зависит от сложности запроса которые вы напишите. Иногда удобно набивать временную табличку и ограничивать ею.она может жить с сессией клиента и тормозит только первый раз когда набивается
|
|
|
За это сообщение автора поблагодарили: Ivanhoe (3), MikeR (-3). |
14.03.2019, 00:30 | #4 |
Banned
|
Цитата:
Применять же XDS на заказы или закупки, что обычно миллионы записей, мне кажется совсем неразумным. Что мешает к примеру, в зависимости от текущего пользователя добавлять свои собственные фильтры на форме в executeQuery. В D365FO это как я понимаю "OnQueryExecuting". Конечно если полиси на программирование вообще то дело другое. Оно конечно "a great dramatic closing for your demos" но на миллионах записей это безумие на мой взгляд. Цитата:
XDS is one of the sparkling features in Dynamics. It takes you beyond the forms achieving the ultimate data control. It is one of the key features that captivate the customer heart and mind. It is a great dramatic closing for your demos.
https://community.dynamics.com/ax/b/...-and-operation |
|
|
За это сообщение автора поблагодарили: MikeR (5). |
14.03.2019, 04:30 | #5 |
Участник
|
Мешает то что полиси вы накладываете на таблицу, а не на форму, что избавляет вас от необходимости модифицировать много форм и отчетов. А по факту что так что так дополнительный селект (если мы к примеру говорим о фин аналитиках) А в 7ке получаеться гибче так как вы в UI можете повесить полиси через контекст на роль или снять, а вам приедться еще и свой костыль лепить чтобы этим управлять, вообщем это просто фреймворк который удобней чем ваши костыли котрые еще надо написать.
|
|
14.03.2019, 06:14 | #6 |
Участник
|
С точки зрения SQL то - это по сути полный скан таблицы заказов и аналитик при открытии формы(если говорить о фильтре на заказах по аналитикам), т.е. недостаток в том что время будет линейно расти и это будет работать до какого-то момента.
ну т.е. в транзакционные таблицы это надо добавлять очень осторожно |
|
|
За это сообщение автора поблагодарили: MikeR (5). |
14.03.2019, 06:47 | #7 |
Мрачный тип
|
Цитата:
На остальное-то зачем ? Никакой бесовщины в сим деянии не ощущается ?
__________________
Мы летаем, кружимся, нагоняем ужасы ... |
|
|
За это сообщение автора поблагодарили: ax_mct (2). |
14.03.2019, 06:58 | #8 |
Участник
|
Цитата:
Сообщение от trud
С точки зрения SQL то - это по сути полный скан таблицы заказов и аналитик при открытии формы(если говорить о фильтре на заказах по аналитикам), т.е. недостаток в том что время будет линейно расти и это будет работать до какого-то момента.
ну т.е. в транзакционные таблицы это надо добавлять очень осторожно Последний раз редактировалось skuull; 14.03.2019 в 07:24. |
|
14.03.2019, 09:56 | #9 |
Участник
|
Добавлять поля в заказ и накладывать фильтры/строить индексы по этим полям. Собственно как работает поле компания
|
|
14.03.2019, 10:47 | #10 |
Moderator
|
Ну дык те же самые фильтры удобнее добавлять с помощью XDS. Вообще этот механизм ни плох и ни хорош сам по себе. Он просто принудительно добавляет условие в запросы по некоторым таблицам. Если условие безумное, индексов нету или сами структуры данных безумны (как в случае новой ГК), то фильтры будут тормозить не зависимо от того, приделаны они с помощью XDS или в ручную, с помощью ковыряния в исходном коде формы.
|
|
|
За это сообщение автора поблагодарили: skuull (3). |
14.03.2019, 11:28 | #11 |
Участник
|
Я так понимаю, есть кто использует и у них особо вопросов нету к XDS.
А все кто против - реальные кейсы можете описать, когда начали использовать и отказались? Или теоретики?
__________________
Ivanhoe as is.. |
|
|
За это сообщение автора поблагодарили: skuull (3). |
14.03.2019, 11:58 | #12 |
Участник
|
Так конкретный же кейс, фильтр по фин аналитике на строке заказа, какие фильтры и индексы будем добалять? Причем ребята с ролью "А" не видят подразделение "Б", а роль "Б" не видит "А" и не тоько на одной конкретной форме заказа, а вообще нигде, включая отчеты.
|
|
14.03.2019, 12:00 | #13 |
Участник
|
@MikeR, разобрался в чем ?
|
|
14.03.2019, 13:08 | #14 |
Участник
|
Цитата:
Цитата:
А старый Record level security остался в D365? |
|
14.03.2019, 13:37 | #15 |
Moderator
|
Цитата:
Сообщение от trud
Как раз один из негативных случаев. Решать подобные вещи очень сложно - т.е. в итоге клиент перетасовал роли и подразделения таким образом чтобы можно было фильтровать по полю из шапки заказа(первоначально была строка), ну и добавили поле в шапку. Хотя в первый год все работало замечательно
А старый Record level security остался в D365? P.S. Старого RLS не было уже в DAX2012 по моему. В целом - мне его нисколько не жалко. XDS в DAX2012 иногда подлгюкивал на моей памяти, но он все равно был намного более стабильным и работоспособным чем RLS. |
|
|
За это сообщение автора поблагодарили: EVGL (2). |
14.03.2019, 13:53 | #16 |
Участник
|
Так аналитика изначально была в строках(а форма заказов отображает шапки). Т.е. заказ показывается пользователю если есть хотя бы одна строка из того чем его подразделение торгует. Я не смог придумать как такое решить индексами и как вообще технически сделать подобную задачу. т.е. на каких-то объемах это просто начало тормозить. можно наверное как-то поиграться с материлизованными вью было
|
|
14.03.2019, 13:55 | #17 |
Участник
|
Цитата:
Сообщение от trud
Ну я встречал только негативные последствия(хотя тут наверное ошибка выжившего, когда все хорошо мне об этом не расскзаывали), кейсы - это фильтр на приджойненную таблицу
Как раз один из негативных случаев. Решать подобные вещи очень сложно - т.е. в итоге клиент перетасовал роли и подразделения таким образом чтобы можно было фильтровать по полю из шапки заказа(первоначально была строка), ну и добавили поле в шапку. Хотя в первый год все работало замечательно А старый Record level security остался в D365? RLS был в 2012, просто был не рекомендуемый . В 365 вроде прибили. |
|
14.03.2019, 14:08 | #18 |
Moderator
|
Цитата:
Сообщение от trud
Так аналитика изначально была в строках(а форма заказов отображает шапки). Т.е. заказ показывается пользователю если есть хотя бы одна строка из того чем его подразделение торгует. Я не смог придумать как такое решить индексами и как вообще технически сделать подобную задачу. т.е. на каких-то объемах это просто начало тормозить. можно наверное как-то поиграться с материлизованными вью было
|
|
14.03.2019, 14:23 | #19 |
Участник
|
Так я о том и говорю, что exists join где условие накладывается на привязанную таблицу - это по сути полный скан таблицы заказов при открытии формы(т.е. ты находишь сначала по индексу записи в фильтрующей таблице, потом ищешь все заказы которые под это попадают(так так на формах обычно сортировка по коду заказа), сортируешь их, и выводишь первые 10. Это отлично работает на малых объемах, но начиная с сотни тысяч уже тормозит и никакими индексами это не победить
|
|
14.03.2019, 14:33 | #20 |
Moderator
|
Цитата:
Сообщение от trud
Так я о том и говорю, что exists join где условие накладывается на привязанную таблицу - это по сути полный скан таблицы заказов при открытии формы(т.е. ты находишь сначала по индексу записи в фильтрующей таблице, потом ищешь все заказы которые под это попадают(так так на формах обычно сортировка по коду заказа), сортируешь их, и выводишь первые 10. Это отлично работает на малых объемах, но начиная с сотни тысяч уже тормозит и никакими индексами это не победить
|
|
|
|