Возможно ли в Teamcenter узнать дату/время добавления item'а в структуру ревизии другого item'а, также конкретного пользователя, создавшего вхождение?

[NeedMoreLODs 81]

Есть некий item1.

У этого item'а есть ревизия.

Пусть это будет ревизия item1/00.

В структуру ревизии /00 добавлен, среди прочих, другой item - пусть это будет item2.

Т.е. итоговая картина примерно такая:

Item1
  Item1/00
    Item2

Есть необходимость в возможности получения даты/времени добавления конкретного item в структуру, а также имени пользователя, создавшего это вхождение.

 

В во всяких там свойствах объектов или столбцах менеджеров структур я смотрел - ничего подходящего не увидел (плохо смотрел?).

 

По модели данных цепочка получается примерно такая:

PSBomViewRevision <- PSOccurrence -> Item (это наш айтем, который входит в структуру)

 

Но у PSOccurrence нет поля даты/времени создания (есть поле lsd, но это не то, что нужно) и каких-либо полей, связанных с учётками пользователей.

Время последнего изменения у PSBomviewRevision это тоже совсем не то.

В плане пользователя, создавшего вхождения, PSBomviewRevision также не подходит, т.к. менять структуру могут разные пользователи (в зависимости от групповых прав и т.д.).

 

В общем можно ли узнать каким-то образом дату/время создания КОНКРЕТНОГО вхождения и пользователя, создавшего это вхождение?

 

P.S.: Если чисто на бытовом уровне, то можно так изложить - в приложении "Мой Teamcenter" видно, что в структуру какого-то item'а входит другой item. Можно ли узнать кто и когда этот item добавил в структуру?

Изменено 15 апреля 2016 пользователем Ленивый

[lexx174 373]

на уровне интерфейса все изменения прослеживаются в основном через свойство дата_модификации.

а так скорей всего в оракле можно отследить

[NeedMoreLODs 81]

В данном случае дата последней модификации с пользовательской точки зрения не подходит по той причине, что помимо item2 могут быть ещё целая куча item'ов добавлена в структуру после item2, и даты модификации и последнего пользователя ничего не скажут.

 

С системной точки зрения owning_user, last_mod_user,  last_mod_date и creation_date это свойства POM_application_object, который наследник от POM_object.

Проблема в том, что PSOccurrence тоже прямой наследник от POM_object, а значит этих полей у него нет.

Я понимаю, конечно, что проектировщики модели данных далеко не дураки и это обусловлено объективными причинами, но всё-таки иногда нужны относительно простые способы отслеживания а-ля "кто-виноват и что делать".

 

На уровне БД Oracle наверное можно (сложнее MySQL я ничего не трогал, поэтому без понятия) через какие-нибудь системные таблицы отследить, когда в таблице PPSOCCURRENCE появилась строчка с каким-то PUID, но это в моих условиях нереализуемый путь, да и решение получается БДзависимым.

 

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

А если встроенного стандартного решения нет, то нет так нет, хотя в таком случае печалька, конечно.

Изменено 15 апреля 2016 пользователем Ленивый

[lexx174 373]

попробуйте покапать в сторону расширенных системных логов если это вас устроит.

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

[Krusty 194]

покурить в сторону Audit Manager и механизма подписок на события

[Krusty 194]

Какая версия тимцентра ?

[NeedMoreLODs 81]

Teamcenter 9.

 

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

Но спросить то  я должен  был. :-)

На сервере я ничего сделать не смогу (т.к. не админ), а на встречу мне не пойдут.

Но руководство по Audit Manager для общего развития обязательно "полистаю", вдруг пригодится в будущем.

 

Спасибо!

[Krusty 194]

Teamcenter 9.

 

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

Но спросить то  я должен  был. :-)

На сервере я ничего сделать не смогу (т.к. не админ), а на встречу мне не пойдут.

Но руководство по Audit Manager для общего развития обязательно "полистаю", вдруг пригодится в будущем.

 

Спасибо!

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

[NeedMoreLODs 81]

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

 

Он может и есть, но не у меня.

Будет разве что в случае смены работы. 

 

В общем пробежался я по audit_manager.pdf.

Мощная система, конечно.

Половину я при беглом знакомстве просто не понял, даже несмотря на то, что объём руководства по аудиту совсем небольшой (по сравнению с другими руководствами из комплекта документации).

И система нужная в каких-то случаях

Но настройка аудита это задача уровня предприятия, а никак не технического иллюстратора. 

 

Ну и в целом - аудит всё-таки позволяет отследить изменения только НОВЫЕ, те что произошли ПОСЛЕ настройки аудита на какой-то конкретный тип/объект.

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

 

P.S.: Откуда вообще пошёл вопрос. Ситуация простая. Есть какая-то "структура". Местная или полученная откуда-то ещё - не суть. Над структурой может работать целый коллектив в разное время. В общем права на "изменение" структуры либо у группы, либо отдельно назначены у нескольких человек. Иногда может случаться такое, что человек по запарке назначил в структуру не тот элемент, либо назначил элемент не в ту структуру. Да и интерфейс и глючность приложений наподобие "Менеджер структуры" таковы, что шанс сделать что-то не то отличен от нуля сам по себе и безо всякого человеческого фактора. Не суть. Результат будет один и тот же - какой-то то элемент в структуре, про который непонятно, что он тут делает - то ли действительно должен быть, то ли это ошибка. И когда есть задача выяснить - а кто же это напортачил - начинается "я не я и пятая точка не моя". Опрашивать всех - очень долго, иногда бесполезно (особенно если это не ваша структура), а иногда и вовсе невозможно. Удалять элемент на собственное усмотрение - нельзя. Потом окажется, что он был нужен. Я то думал есть надежда, что система где-то такие сведения хранит - в таком случае сильно проще было бы знать с кем разговаривать. Но по модели данных получается что сведения не хранятся. Ну нет так нет.

 

Krusty, lexx174 - спасибо! 

Изменено 21 апреля 2016 пользователем Ленивый

[Krusty 194]

1. можно сделать, что бы TC слал вам почтовые отбивки о изменении состава

2. при "нечаянном" изменении состава и выходе из редактора структуры он спрашивает сохранять или нет.

3. можно включить режим markup для состава тогда вносимые изменения в состав буду запоминаться как предложения и сразу не станут оказывать влияния на структуру

4. используя т.н. "baseline" вы сможете делать снимки вашего состава на определённое к примеру число

5. порыть в сторону контекстов и механизма "condition" в бизнес-логике Teamcenter, например если пользователь не выбрал определенный контекст то запись в состав недопустима - защита от дурака.

6.попросите ваши программистов сделать примочку которая пару раз спросит пользователя "ты точно хочешь этого?", тоже как защита от дурака.

 

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

 

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

не торопитесь:) надо поглядеть внимательнее, у меня просто времени нет:(