PLM-forum.ru

Здравствуйте.

Хочется понять, какие у E6 есть механизмы делегирования как полномочий, так и прав доступа к объектам. Есть ли возможность полностью оказаться в шкуре другого пользователя? Знаю, что есть атрибуты Abscence Delegator и Abscence Start Date, но как они работают? Простое выставление даты не ведет к тому, что делегатор получает права "отсутствующего" пользователя.

Добрый день!
Не совсем понял, при чём тут атрибуты Abscence Delegator и Abscence Start Date, но если вопрос о том, как в течении выполнения программы, сменить уровень доступа с того, который имеет текущий пользователь, на какой-то дургой, то нужно использовать ContextUtil и PushPopShadowAgent.
Если в кратце, то в системе, по умолчанию, есть суперпользователь - Shadow Agent. Так вот по хорошему, когда что-то выполняется в программе, всё выполняется как бы от лица текущего пользователя. Но далеко не всегда у него на это есть соответствующие полномочия. По этому, перед тем, как что-то делать, надо как бы поместить его контекст в стек (Push), сменив его на контекст User Agent'a (или другого пользователя), и выполнить то, что надо. По окончанию работы, вернуть контекст текущего пользователя (Pop).
Я правильно понял, что обэтом был вопрос?

Спасибо за ответ.
Push и pop позволяют менять контекст на время выполнения программы, а мне требуется, чтобы эта смена происходила на уровне пользовательской сессии.
К примеру, пользователь решает: "Сейчас я буду за Васю", нажимает на кнопку "Смена контекста", выбирает один из доступных контекстов, делегированных ему, и с этого момента начинает работать от имени Васи, фактически виртуально залогинившись под ним.
В жизни делегирование может использоваться для назначения заместителя на время отсутствия заболевшего сотрудника. Системой заместитель должен восприниматься также, как если бы это был сам заболевший сотрудник. Соответственно, я надеялся, что при выставлении Abscence Delegator и Abscence Start Date произойдёт примерно такая передача полномочий и ролей. На мой взгляд, проще всего было бы решить вопрос "виртуальным логином", но где ж его в ENOVIA взять...

Может быть тогда сделать по кнопке "Смена контекста" Push и не возвращать его, пока пользователь не нажмёт "вернуть контекст"? Тогда и делать Pop.
Хотя у заказчика таких проблем вроде бы не возникало никогда. Всегда есть 2-3 Process Owner'а, которые как Бизнесс Администраторы, следят за всем, и в отпуск видимо ходят по очереди

А вот меня и интересовало, не "поппит" ли эновия контекст обратно сразу по окончании программы? Если нет, то Ваш вариант мне подойдёт. Просто я-то думал, что есть автоматический Pop на тот контекст, с которым был запушен код.

Может быть кстати и такое, что вернётся контекст по окончанию программы, вне зависимости от того, был ли вызван Pop или нет. Хотя, с дургой стороны, зачем тогда вообще этот Pop нужен...
В любом случае, можно легко попробовать.
На счёт "автоматического" переключения - я такого не встречал...
Кстати, вот допустим, напишете вы программулину, которая меняет контекст, создадите кнопку где-то в тулбаре. А как именно вы вызываете программы (JPO) по нажатию на кнопку? Есть ли какие-то "излюбленные" методы, как такое делать? Самописаня JSP или OOTB? Или вообще может JavaScript код в команде?

Методы скорее не "излюбленные", а "известные мне" , поэтому вызываю через JSP. JavaScript код, как я понял, не работает с базой данных напрямую, соответственно, непонятно, как вызвать из него JPO.
Кстати говоря, судя по всему push "задвигает" контекст не до окончания программы, а до явного вызова метода pop. Соответственно, простенькая JPO может обеспечить ту смену контекста, которая мне нужна. О результатах отпишусь.

Из javascript можно обращаться к сервлету, который в свою очередь будет вызывать JPO.

Fil писал(а):Из javascript можно обращаться к сервлету, который в свою очередь будет вызывать JPO.

Ну так сразу надо код в студию! Чтобы потомкам хоть что-то осталось!

Код в студию - значит код в студию

Допустим нам понадобилось запустить JPO с передачей в него каких-то параметров и получить что-то в ответ.
Воспользуемся библиотекой jquery, чтобы сделать все без всяческих переадресаций, перезагрузок страниц и т.д.
Скачаем библиотеку из интернета (в свободном доступе) и подключим её

<script type="text/javascript" src="jquery.js"></script>

Для примера возьмем 2 input-а с названием JPO и метода для выполнения, а также div с "кнопкой" и будем выполнять фнукцию по клику:

Код: Выделить всё

<input id="classname" style="position:absolute; width:127px; top:30px; left:18px; border:none; background: none;" type="text" />
<input id="methodname" style="position:absolute; width:127px; top:30px; left:18px; border:none; background: none;" type="text" />

<div id="Senddiv" style="cursor: pointer;" onclick="send();">Отправить</div>

По нажатию запускаем функцию:

Код: Выделить всё

function send(classname,methodname)
{
   $class=classname.value;[/color]    //берем значения input полей[color=#008040]
   $method=methodname.value; 
   
   $.post("http://xxx.xxx.xxx.xxx:8080/enovia/jposervlet", {class:$class, method:$method}, function(data) {
               var result = data;[/color] // передаем в jposervlet название JPO и метода; ответ от сервлета записываем в result[color=#008040]
               });
} //функция отправляет post запрос в сервлет jposervlet

//jposervlet следующим образом обрабатываем наш запрос - принимает имя JPO и метода/выполняет метод указанного JPO/
//возвращает клиенту результат выполнения JPO (далее приведен пример кода doPost в сервлете jposervlet):

Код: Выделить всё

protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
      
      String class = request.getParameter("class");
      String method = request.getParameter("method");
      String result="";
      Context context;[/color] //для запуска JPO нам нужен контекст под которым его запускать[color=#008040]
      
      String[] init = new String[] {};[/color] //[color=#008040]
      String[] args = new String[] {};[/color] // параметры для класса и метода (оставим пустыми)[color=#008040]
      
      try {

//// тут мы создадим контекст вручную(для пример не будем ничего ни откуда доставать и хранить - не будем различать пользователей)

Код: Выделить всё

context = new Context(host);
               context.setUser("Имя пользователя"); [/color]//например Test Everything[color=#008040]   
               context.setPassword("Пароль");
               context.setVault("vault");
               context.setLocale(new Locale("en"));
               context.connect();

//// ну и вызываем, собственно, метод из JPO и результат его записываем в result:

Код: Выделить всё

result = (String) JPO.invoke(context,class,init,method,args,String.class);
               
      } catch (MatrixException e) {
         e.printStackTrace();
      }

      response.setContentType("text/plain");
      PrintWriter out = response.getWriter();
      out.println(result);
      out.flush();
      out.close();
   }

Спасибо за наглядный пример! Может кому поолезно будет.
Я бы ещё посоветововал посмотреть в сторону AJAX'а, а не jquery, так как первый входит в поставку эновии, так что не нужно ничего качать дополнительного.
Также, для простоты, можно использовать JSP вместо сервлета.

Так можно делать (через сервлет) если, например, гаджет для винды надо написать и никаких намеков на переадресацию быть не может.
По поводу jquery - на мой взгляд крайне полезная библиотека, помимо AJAX реализует уйму полезных фишек. (jquery.js - 262кб)

Снова здравствуйте.

Описав фантастический круг длиной в два года, возвращаюсь к вопросу делегирования полномочий. Но на этот раз хотелось бы сформулировать его по-другому: как работает ENOVIA V6, когда ее пользователи болеют?

Вот у нас есть пользователь, который выполняет ответственные задачи. Доступ к объектам, необходимым ему для работы он получает благодаря назначенным ему ролям, а также, для конкретных объектов, выданным грантам. Кроме того, пользователь является участником десятков маршрутов (Route).

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

В реальной жизни у моих заказчиков есть:
либо боллше одного человека, с соответствующими ролями и доступом, чтобы объекты "не зависали" а над ними мог кто-либо другой порабоать;
либо есть специальный пользователь (key-user), который в случае болезни кого-либо может переадресовать объект/задание кому-то ещё или справиться сам;
либо есть бизнесс адиминстратор, который уже средствами толстых клиентов либо всё того же вёба так же может переадресовать объеты и т.п.

Спасибо за оперативный ответ.
Гранты, как я понимаю, заказчиками не используются?
Как передаются права на контент, прилепленный к маршруту?
При организации доступа к множеству объектов используются штатные средства (веб и толстые клиенты) или самописные (скрипты)? Вручную передавать права в организации численностью >1000 человек невесело...

Добрый день!

Хотел бы привести мои соображения и опыт на счёт вопроса "когда пользователи болеют"?
По поводу роутов - они в системе моделируют в высокой степени универсальный механизм поручений. С помощь этого инструмента получается довольно эффективно организовать процессы.
-В случае если задача поступает на исполнение пользователю, а он теряет возможность её исполнения, то владелец данного задания всегда имеет возможность выполнить переназначение исполнителя;
-В случае если задача поступает на исполнение в тот момент, когда пользователь не имеет возможность исполнения задач (указаны заместитель и даты отсутствия) - задача автоматически перенаправляется заместителю с соответствующими комментариями в тексте письма
Механизм доступа к контенту роута использует гранты, и в целом может быть настроен.
Проблемы могут возникать в случае если речь идёт о процессах в системе с заложенной методикой их реализации, например, таким процессом является ресурсное планирование проектов (в Program Central):
При согласовании поданых данных табелей учёта рабочего времени имеется несколько предустановленных моделей доступа к функциям утверждения. В соответствии с настройками за это отвечает либо соответствующий Project Lead, либо Resource manager подразделения исполнителя.
В случае если, например, ответственный руководитель подразделения отсутствует, то доступ к функионалу контроля рабочего времени сотрудников отдела не передаётся и назначение ролей не позволяет решить вопрос.
Т.е. возникает проблема не только на уровне доступа к данным, но и на уровне доступа к функционалу. Но и в таких случая доступ к необходимым командам может быть сконфигурирован или запрограммирован. Хотя в таких областях встаёт вопрос об использовании стандартной заложенной методики в целом. Многим она не подходит.
Также есть модели организации доступа типа workspace, но использование этих моделей в реальных процессах не подразумевает наличие каких-либо изменений в связи с, например, болезнью, которые не могли бы быть выполнены пользователями. Далее, если объекты, над которыми выполняется работа, построены на модели Common Document Model, то организация доступа с помощью грантов там реализована для пользователей.

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

Отмечу, что в релизе 2014х появился функционал переключения контекстов (vplm контекстов) доступный для пользователей в интерфейсе, однако, он, скорее служит для организации доступа к группам функций и проектным данным для самого пользователя.

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

Я правильно понял, что вопрос с болезнью решается в ENOVIA V6 не централизованно, а в рамках приложений (централов)? И если мы пишем свое приложение, то должны сами позаботиться о решении этого вопроса.

Добрый день!
Каждое из приложений является только платформой и предоставляет набор инструментов для построения на основе неё решения автоматизации различных процессных областей.
По моему опыту, по-умолчанию, ни одно из приложений не имеет ни достаточно детальной модели данных, ни функционала для реального использования в автоматизации процессов "как есть".
-Если решение использует модели Business Process Services, то, соответствено, вопрос "болезни" решается на уровне BPS (например, механизмы Route). Многие централы также используют модели Business Process Services
-Если решение построенное на каком-то централе, разработанном приложении или его части определяет особые уникальные правила, то их необходимо, в большинстве случаев расширять/изменять, и такие расширения не являются универсальными.
Если отвечать на вопрос, то в части использования "универсальных" инструментов - решение централизованное, а в части "частных" инструментов, соответственно, частное.
Если разрабатываемое приложение или расширение организует, скажем, какой-то процесс согласования и при этом использует только механизмы Route (как есть или его расширение),
то вопрос решается один раз для инструментария Route в целом. И вопрос этот, опять же повторюсь, как-то решён по-умолчанию.

Большое спасибо.

Механизм грантов (grants) в ЭНОВИИ очень старый и неудобный и Дасо от него отходит, по этому он сейчас почти что нигде не используется (разьве что только в Program Central'e в Project Access List'e). Так что гранты использовать не рекомендую.
Все сущестующие централы - это надостройки над BPS (Business Process Services). Они решают задачи именно узкоспециализированные (Program Central - управление проектам, Engineering Central - управление изменениями, и т.п.), и вопрос замещения пользователя при болезни в них не решается и решаться не должен. Это именно задача основы Эновии, то есть AEF (Application Exchange Framwork) и BPS. Fill, правилььно сказал про Роуты и при дожной настройке и использовании - они достаточно гибкие. Для вего остального есть мастеркард триггеры, JPO и Configurable Components (то есть надо настраивать)

Хотел бы добавить,
по поводу грантов - не то, чтобы они мало используются, например доступ к Документам (CDM) во многом на грантах всё ещё работает, особенно если речь идёт о Роутах и Workspace-ах. Да и в Program Central и Library Central повсеместно.
Соглашусь, что гранты очень не удобны, так как очень сложно эффективно их отслеживать и гораздо проще ошибиться при их использовании, однако, производительность системы в целом в отдельных задачах они могут существенно повысить.
Вместо динамического вычисления доступов (программами или выражениями) - простая проверка с фиксированным временем исполнения.
Также по поводу вопросов "замещения":
Многие централы (ярким примером является Program Central) через функционал предлагают использовать вполне определённые процессы и их реализация далеко не всегда в качестве основы используют BPS механизмы.
В случае процессов ECO/ECR в инжиниринг централе, используются Route-ы с шаблонами (используется BPS механизм), а вот в Sourcing Central, Program Central, например, довольно много процессов, которые не используют никаким образом механизмы, предоставляемые BPS. (Хотя BPS механизмы также много используются)
Пример: в процессе учёта фактического рабочего времени Program Central-ом предлагается процедура утверждения Timesheet-ов (либо Project Lead-ом) Resource Manager-ом подразделения пользователя, подавшего Timesheet.
Организация доступа к возможности участия пользователей в этом процессе в большой части определена на уровне команд (Access Program и Access Expression), которые относятся непосредственно к Program Central-у.
По-умолчанию, право на утверждение и даже просмотр Timesheet-ов определяется простыми выражениями, прописанными в командах. Обеспечение доступа к данным командам кроме как их изменением не представляется возможным (если только не подменять собственными и т.д.)
В не зависимости от того, к чему относить "расширение"(кастомизацию) - к BPS или к Central-у - приходится вносить изменения непосредственно в ту часть, которая относится именно к Program Central.
Несмотря на то, что Central-ы являются надстройками на BPS - расширением для BPS дело не ограничивается.