Как лучше обрабатывать десятки тысяч объектов в TC?

[asterixik 6]

Собственно вопрос в заголовке темы.

Дело в том что есть десятки тысяч объектов с которыми надо провести те или иные преобразования (создать отношения, удалить отношения, переименовать, отредактировать атрибуты на связанных объектах и т.п.). Ранее мы пытались по возможности разобраться в БД и выполнить эти преобразования с помощью SQL запросов. Но документации по БД нет, т.е. все делалось путем мониторинга с помощью SQLTracker что деате ТС с базой, и попыткой разобратьсяв связях таблиц.

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

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

 

Например, сейчас стоит задача: Интеграторы из сторонней системы загружали в ТС данные, в итоге в сборки вместо item подобавляли по ошибке ItemRevision, т.е. существует несколько десятков тысяч сборок в которых на некоторых позициях ItemRevision, и соответственно если будет пересмотр ревизии, старая ревизия отклоняется, утверждается новая, правило конфигурирование не может нормально отработать. Короче говоря, надо заменить в этих сборках соответствующие ItemRevision на их Item. Вручную это делается с помощью Замены... (ReplaceOperation).

 

И вот делема, можно все это дело реализовать с помошью RAC plugins, но десятки тысяч объектов через плагин будут обрабатываться несколько недель. Наверное можно реализовать тоже с помощью приложения SOA, но полагаю что будет не на много быстрее (с SOA дела не имел пока). В принципе можно отредактировать все это дело запросами SQL, с помощью SQLTracker отследил что при ReplaceOperation происходит обновление соответсвующей записи в таблици PPSOCCURRENCE (меняются значения 2ух полей - идентификатора объекта и идентификатора класса), а также удаляется 1 запись в POM_BACKPOINTER (связь между occurrence и itemrevision) и создается новая (связь между тем же occurrence и теперь item). Но, вроде как лезть в базу ТС для изменений не через API TC плохой тон, и не понятно что может быть.

 

Короче говоря, глобальный вопрос: стоить ли править БД ТС на прямую, или всё же работать через API (RAC, SOA, ITK)? Кто какой опыт имеет, кто к чему пришел?

 

[lexx174 373]

Для TC в принципе официально не рекомендуется лезть в БД для редактирования, правки, это можно сказать запрещено для вашего же блага.

Читать напрямую с БД - есть смысл для определенных задач(в частности большие отчеты).

 

Для работы с объектами базы тимцентра есть всевозможные открытые API - ITK, JAVA, SOA API. Править БД TC через sql

это извращение.

 

десятки тысяч объектов - это не миллионы чтобы обрабатывались несколько недель. Думаю в течение  суток (ну может чуть больше) можно управится,если у вас серверная инфраструктура для БД тимцентра не тугая.

 

Оптимально будет написать ITK программу, и запускать потом одновременно на разных узлах, обрабатывая определенную порцию из списка обрабатываемых объектов.

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

 

Вам только предварительно нужно будет сформировать списки список(списки) объектов в базе для редактирования, разделить на подперечни, и пакетно обработать в параллельном режиме.

 

 

Цитата

в итоге в сборки вместо item подобавляли по ошибке ItemRevision

А что у вас за конфигурация сборок такая что нельзя ревизии добавлять? В ыже так или иначе работаете с ревизиями,и если добавлять компонент сборки - то добавляется ревизия.

Или имеется ввиду другой объект(не компонент) который должен быть добавлен как именно как Item к ревизии или Item сборки?

Изменено 29 января 2020 пользователем lexx174

[asterixik 6]

Да в том то и дело что слегка туговатая инфраструктура.

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

По поводу сборок: в менеджере структуры добавляем в сборки item-ы, и далее выбираем правило ревизии. И соответственно если в сборку добавлен item, была ревизия 1, потом её пересмотрели ревизией 2 (ревизию 1 отменили), то правило ревизий содержащее Имеет статус Утверждено отобразит нормально сборку, а вот если добавлена ревизия, то насколько я понимаю при выборе правила с Имеет статус Утверждено в сборке на этом элементе в идентификаторе ревизии будут ??? если добавленную ревизию пересмотрели (Отклонили).

 

Но это я не проверял, рассуждения.

[lexx174 373]

31 минуту назад, asterixik сказал:

.

По поводу сборок: в менеджере структуры добавляем в сборки item-ы, и далее выбираем правило ревизии. И соответственно если в сборку добавлен item, была ревизия 1, потом её пересмотрели ревизией 2 (ревизию 1 отменили), то правило ревизий содержащее Имеет статус Утверждено отобразит нормально сборку, а вот если добавлена ревизия, то насколько я понимаю при выборе правила с Имеет статус Утверждено в сборке на этом элементе в идентификаторе ревизии будут ??? если добавленную ревизию пересмотрели (Отклонили).

 

Но это я не проверял, рассуждения.

какая-то дичь прям

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

почитайте доки про работу с составом в тимцентре.

 

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

[asterixik 6]

Вы наверное меня не верно поняли.

Данные импортировались через PLM XML. Стандартными средствами ТС у Вас в принципе не получится вставить ревизию в сборку, туда всегда вставляется объект (можете посмотреть в БД вхождения (таблица ppsoccurrence поле rchild_itemu - даже название поля намекает что тут должен быть идентификатор item, и в поле rchild_itemc - идентификатор класса item), там puid item-а. А уже при просмотре в зависимости от выбранного правила ревизии система вам формирует сборку из нужных ревизий.

 

Но поошибке интегратора (он сам признал эту ошибку) в вхождения вошли itemRevision, повторюсь, штатно в клиенте вставить в сборку вместо item ревизию у Вас не получится (несмотря на то что в окне Замена... вы можете выбирать ревизию, фактически будет вхождение item-а). Но штатной заменой (ReplaceOperation) можно заменить в вхождении itemRevision на Item.

 

Так что это не наша дичь, это дичь интегратора, с которой увы надо что-то сделать, так как иначе не все правила ревизии нормально конфигурируют.

[lexx174 373]

26 минут назад, asterixik сказал:

 повторюсь, штатно в клиенте вставить в сборку вместо item ревизию у Вас не получится

Это что-то из области фантастики.все прекрасно вставляется.

Или может в 12й версии(у вас же она? у нас 10/11) что-то намудрили или у вас что-то не то.

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

 

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

[Wise_Owl 9]

@lexx174 полностью согласна.

@asterixik вы немного не понимаете как работают правила выбора ревизии. Им без разницы что именно вы копировали и вставляли в состав.

[lexx174 373]

@asterixik  покажите может на скриншотах если можно ваши "айтемы" в составе изделия в менеджере структуры?

Изменено 29 января 2020 пользователем lexx174

[asterixik 6]

Вы не эффективно читаете! Если Вы посмотрите связи в БД, то увидите что в Вхождениях (occurrence, таблица PSOCCURRENCE - содержатся Item-ы, и уже на основании этих Item-ов, в соответствии с выбранными вами правилами ревизий менеджер ревизий Вам отображает сборку, в которой естественно отображаются ревизии. Если Вы поменяете правило ревизии на другое то там будут отображаться другие ревизии. Но при этом реально, в вхождениях находятся Item-ы, и менеджер структуры опирается прежде всего на Item-ы, выбирая из них в соответствии с выбранным правилом ревизии  необходимые ревизии.

 

Если Вы в Мой Teamcenter будете просматривать у ревизии в псевдо-папке View входящие в сборку объекты, то там Вам будут отображаться Item-ы, а при загрузки этой сборки в Менеджер структуры, Вам уже в соответствии с выбранным правилом ревизии будет построена конкретная сборка состоящая из ревизий.

 

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

Если Вам действительно интересно разобраться как работает ТС, рекомендую все же посмотреть таблицу PPSOCCURRENCE в БД, о которой я писал выше. Хотя, если Вы работаете только через API, то оно вам возможно и не надо.

В частности посмотрел сейчас руководство по работе с менеджером структуры, раздел 5. Работа с вхождениями (по версии 12.2 руководство на русском языке), там как раз написано что вхождение содержит компонент (а не ревизию)! А у нас получилось что в результате неверной загрузки в вхождения вошли ревизии!

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

[lexx174 373]

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

 

речь о том что в плане работы со структурой изделия правильно оперировать именно ревизиями, сравнивать то что вы видите в псевдопапке и в менеджере структуры -в корне не верно - псевдопапка отображает лишь объекты связанные с ревизией отношением(d в данном случае view)

 

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

 

А puid айтема в таблице - это лишь технический аспект реализации связей в БД.

 

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

 

отсюда недопонимание мое и других людей.

 

тимцентр это ведь не типичная например самописная АСУ предприятия где все сводится к прямому работой с базой(чтение/запись) через sql запросы, вы используя бизнес моделлер,API, приложения толстого клиента работаете на верхнем уровне абстракции, а таблицы БД по задумке разработчиков - это некий черный ящик

21 минуту назад, asterixik сказал:

 

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

 

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

Изменено 29 января 2020 пользователем lexx174

[asterixik 6]

Зачем один, можно создать несколько :-)

Это не проблемная. У "проблемных" в View отображаются ревизии. Хотя возможно действительно это надуманная проблема, по сути... Те кто ставил задачу, сами не до конца понимают может ли данная ситуация (вставлены в сборки ревизии вместо компонентов) привести к чему-то нехорошему в дальнейшем. Просто визуально это заметно при просмотре в Мой Teamcenter

 

Но в целом, по основному вопросу - обработке большого количества объектов - суть понял: в базу лучше не лезть, работать через API. Но как же это медленно... :-(

[lexx174 373]

10 минут назад, asterixik сказал:

Это не проблемная. У "проблемных" в View отображаются ревизии. Хотя возможно действительно это надуманная проблема, по сути... Те кто ставил задачу, сами не до конца понимают может ли данная ситуация (вставлены в сборки ревизии вместо компонентов) привести к чему-то нехорошему в дальнейшем. Просто визуально это заметно при просмотре в Мой Teamcenter

 

Но в целом, по основному вопросу - обработке большого количества объектов - суть понял: в базу лучше не лезть, работать через API. Но как же это медленно... :-(

т.е в менеджере структуры нормально,а во view видны именно ревизии?верно? вас в первую очередь смущает то что в псевдопапке?

Изменено 29 января 2020 пользователем lexx174

[asterixik 6]

Во View у нас стандартно всегда видны были Item, а то что импортировали - теперь видны ревизии

[lexx174 373]

9 минут назад, asterixik сказал:

 

Но в целом, по основному вопросу - обработке большого количества объектов - суть понял: в базу лучше не лезть, работать через API. Но как же это медленно... :-(

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

 

у вас oracle или mssql?

Только что, asterixik сказал:

Во View у нас стандартно всегда видны были Item, а то что импортировали - теперь видны ревизии

попробую воспроизвести эту ситуацию

[asterixik 6]

Oracle. В принципе БД медленная конкретно у нас, дело в железе, ну и в настройках, надо бы согласно Best practices настроить, но DBA не я.

Запросы же я выполнял. Писал пока только RAC plugins

[lexx174 373]

5 минут назад, asterixik сказал:

Oracle. В принципе БД медленная конкретно у нас, дело в железе, ну и в настройках, надо бы согласно Best practices настроить, но DBA не я.

Запросы же я выполнял. Писал пока только RAC plugins

формально ITK должно быть быстрее, но если субд реально на медленном железе то тоже будут видны тормоза.

 

 

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

Изменено 29 января 2020 пользователем lexx174

[asterixik 6]

Тут если через RAC plugins реализовывать то надо последовательно находить по item_id головной объект (список "ошибочных" сборок можно sql запросом собрать), заггружать его BOMViewer -  BOMLine, находить в дочерних объектах неверно загруженные (вот тут пока не пойму как, возможно надо через вхождения) выполнять на них ReplaceOperation, сохранять структуру, закрывать. И так с несколькими десятками тысяч сборок. Ну и плюс еще надо снимать и после редактирования восстанавливать статусы на view-ах, если они там есть.

[lexx174 373]

7 минут назад, asterixik сказал:

Тут если через RAC plugins реализовывать то надо последовательно находить по item_id головной объект (список "ошибочных" сборок можно sql запросом собрать), заггружать его BOMViewer -  BOMLine, находить в дочерних объектах неверно загруженные (вот тут пока не пойму как, возможно надо через вхождения) выполнять на них ReplaceOperation, сохранять структуру, закрывать. И так с несколькими десятками тысяч сборок. Ну и плюс еще надо снимать и после редактирования восстанавливать статусы на view-ах, если они там есть.

ну работа большая, согласен.

 

а правил отображения нет никаких кастомизированных?

 

[NeedMoreLODs 81]

8 часов назад, asterixik сказал:

Вы не эффективно читаете! Если Вы посмотрите связи в БД, то увидите что в Вхождениях (occurrence, таблица PSOCCURRENCE - содержатся Item-ы, и уже на основании этих Item-ов, в соответствии с выбранными вами правилами ревизий менеджер ревизий Вам отображает сборку, в которой естественно отображаются ревизии. Если Вы поменяете правило ревизии на другое то там будут отображаться другие ревизии. Но при этом реально, в вхождениях находятся Item-ы, и менеджер структуры опирается прежде всего на Item-ы, выбирая из них в соответствии с выбранным правилом ревизии  необходимые ревизии.

 

Если Вы в Мой Teamcenter будете просматривать у ревизии в псевдо-папке View входящие в сборку объекты, то там Вам будут отображаться Item-ы, а при загрузки этой сборки в Менеджер структуры, Вам уже в соответствии с выбранным правилом ревизии будет построена конкретная сборка состоящая из ревизий.

 

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

Если Вам действительно интересно разобраться как работает ТС, рекомендую все же посмотреть таблицу PPSOCCURRENCE в БД, о которой я писал выше. Хотя, если Вы работаете только через API, то оно вам возможно и не надо.

В частности посмотрел сейчас руководство по работе с менеджером структуры, раздел 5. Работа с вхождениями (по версии 12.2 руководство на русском языке), там как раз написано что вхождение содержит компонент (а не ревизию)! А у нас получилось что в результате неверной загрузки в вхождения вошли ревизии!

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

Вообще вхождение может быть связано как с Item, так и с Item Revision.

И это очень даже штатная ситуация.

И руками это дело прекрасно воспроизводится - переключаете структуру в менеджере в точный режим и работаете(и будут вам связи с ревизиями).

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

 

Всё зависит от того в каком режиме у вас структура находится.

Если в обычном - вхождения будут связаны с Item.

Если в точном режиме - тогда вхождения будут связаны с Item Revision.

Руками исправить можно переключив режим с точного на обычный.

А как программно - извиняйте, не знаю, не программист Teamcenter я.

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

 

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

И знаков вопроса быть не должно(если подходящая под правило ревизия действительно есть хотя бы одна). 

[asterixik 6]

Если кому-то интересно по вопросу с вхождениями: Переговорил с представителем ОГТ. К менеджеру структуры вопросов у него нет. Но, когда используются точный вхождения (вставлены ItemRevision) то при просмотре в Мой Teamcenter в псевдо-папке view соответственно видны ревизии, и для того чтобы просмотреть какие ещё есть ревизии у данного объекта, какие на них статусы и т.д., надо отправлять эту ревизию в Мой Teamcenter, и там уже на объекте видеть все его ревизии. Ранее (до импорта данных в результате которых были созданы точный вхождения) в псевдо-папке View  были только Item и раскрывая их можно было тут же быстро увидеть какие у них есть ревизии и их статусы. Т.е. теперь трудоемкость работы при выверки, проверки и т.п. существенно увеличилась.

 

В принципе из такой как у нас получилось сборки с точными и неточными вхождениями можно получить загрузив сборку в менеджер структуры и выполнив над ней 2 раза (так как у нас изначально все сборки неточные) операцию Правка - Точная/Неточная, и сохранив структуру, в итоге получаем на всех позициях неточные вхождения (в псевдо-папке View видим только Item).