Импорт файлов инкрементной полученной доставки
Если вы получили несколько ZIP-файлов доставки пакетов из системы-источника, вероятно, отправитель решил использовать инкрементную доставку относительно того, что было доставлено ранее. Процесс импорта файлов инкрементной полученной доставки аналогичен процессу импорта файлов полной полученной доставки. Однако тут следует учесть два аспекта:
• дополнительную информацию, содержащуюся в инкрементной доставке;
• порядок, в котором импортируются файлы полученной доставки.
В некоторых ситуациях вы можете получить последующую доставку из той же системы-источника с обновлениями содержимого, доставленного ранее. Можно получать полную доставку со всем содержимым, которое было доставлено ранее, или инкрементную доставку, включающую только информацию, которая изменилась после предыдущей доставки. Например, если ваша компания работает совместно с другой компанией и вам необходимо знать о любых изменениях в их сборке, вы можете запросить регулярные обновления, чтобы быть в курсе изменения данных.
В отличие от полной доставки инкрементная доставка сравнивается с базовой доставкой. Это сравнение предоставляет инкрементной доставке уникальную возможность отправлять информацию об объектах, соответствующих одному из следующих критериев.
• Удаленные: информация об объектах, которые были удалены из Windchill после отправки базовой доставки, поэтому эти объекты можно удалить из целевой системы. Во время импорта система пытается удалить эти объекты. Все объекты, которые нельзя удалить, указываются в отчете.
• Отсутствующие: информация об объектах, которые были отправлены в базовой доставке, но больше не входят в текущую доставку, потому не были включены в пакет. Возможные причины исключения: изменились опции сбора, использовавшиеся для создания пакета, объект больше не соответствует критериям, объект был явным образом удален из пакета. Действия предварительного просмотра и импорта сообщают о таких объектах, чтобы можно было выполнить действия с ними в зависимости от бизнес-процесса. Например, можно удалить их из системы, переместить в другой контекст или задать новое состояние жизненного цикла.
• Измененные: отправленные объекты, которые были каким-либо образом изменены. Возможные изменения: обновление файла содержимого, изменение в атрибуте, перемещение объекта в новую папку и т. д.
• Новые: отправленные объекты, которые являются новыми в Windchill или впервые включены в пакет.
 |
Инкрементные доставки не содержат информацию об объектах, которые не изменились после базовой доставки. К измененным объектам относятся как изменения, инициированные пользователем, так и изменения на уровне системы.
|
Инкрементные доставки также содержат измененную информацию о связи между CAD-документом и деталью. Здесь возможно исключение, когда изменение информации о связи не отображается очевидным образом.
Рассмотрим деталь с изображением, которая связана с CAD-документом и сдана на хранение в Windchill без компоновки (для настройки Компоновать деталь после связывания или опции Задать для одноуровневой сборки установлено значение Выкл.). Если пакет создан из таких объектов, то при импорте инкрементного пакета после удаления связи (см. раздел Правка связей между CAD-документами и деталями Windchill) в Windchill удаление связи между деталью и CAD-документом не будет чистым.
Поскольку инкрементные доставки создаются в системе-источнике путем выбора базовой доставки, по сравнению с которой оцениваются изменения, между этими двумя доставками часто есть зависимость. Всегда предпочтительнее импортировать ZIP-файлы полученной доставки в том порядке, в каком они были экспортированы, но для инкрементной доставки это особенно важно. Дополнительные сведения см. в разделе рекомендаций по импорту объектов полученной доставки в разделе Рекомендации по работе с полученными доставками.
|
|
Импорт пакетов BAC с помощью утилиты CCD (Windchill+) описан в разделе Импорт пакета BAC с помощью утилиты CCD
|
Управление атрибутами для инкрементной доставки
В некоторых бизнес-сценариях может потребоваться логика инкрементной доставки, чтобы игнорировать изменения в конкретных атрибутах при сравнении с базовой доставкой. Обновленная логика инкрементной доставки обеспечивает эффективный механизм для пакетов Windchill, чтобы включать и экспортировать только те объекты, которые были изменены с момента предыдущей доставки.
Пример сценария 1
Рассмотрим следующий пример, в котором базовый пакет включает две детали, Part1 A.1 и Part2 A.1. Существует изменение в детали Part1 A.1, и изменяется деталь Part1 A.2, а также описании контейнера (изделие/библиотека). Поскольку контейнер вносит вклад в экспортируемые метаданные детали, он рассматривается как встроенный объект. Пометьте контейнер как измененный объект и поместите его во все объекты, которые содержатся в контейнере как измененные, т. е. в этом примере Part1 A.1 и Part1 A.2, даже если экспортируемые метаданные не изменяются при сравнении с базовой доставкой. Дельта-логика расчета дополнительно ужесточена, чтобы обратить внимание на это и на экспортируемые метаданные. Таким образом, в результирующем пакете будет экспортироваться только деталь Part1 A.2, поскольку для детали Part1 A.1 экспортируемые метаданные остаются неизменными, как показано в таблице ниже.
|
Источник
|
Базовая доставка
|
Инкрементная доставка
|
|---|---|---|
|
Part 1 A.1
Part 2 A.1
|
Part.1 A.1 + Part2 A.1
Изменение
Part1 A.1 –> Part2 A.2
|
Part1 A.2 - дельта
|
Пример сценария 2
Рассмотрим другой пример, в котором основной пакет, упомянутый в предыдущем примере, включает дополнительную третью деталь Part3 A.1 с атрибутом LifeCycle1 (LC1), добавленным пользователем, например User1. В какой-то момент времени, если атрибут LifeCycle1 в третьей детали был изменен другим пользователем, например User2, на LifeCycle2 (LC2), в инкрементной доставке будут содержаться изменения, относящееся к детали Part1 A.1 ->Part1 A.2, а для Part3 A.1 LC1 -> LC2.
|
Источник
|
Базовая доставка
|
Инкрементная доставка
|
|---|---|---|
|
Part 1 A.1
Part 2 A.1
|
Part.1 A.1 + Part2 A.1
Изменение
Part1 A.1 –> Part2 A.2
Part 3 A.1-> LC1 в LC2
|
Деталь-1 A.2
Part3 LC2
|
Хотя система генерирует инкрементную доставку, сравнивая все измененное содержимое с базовой доставкой, можно также повлиять на логику инкрементной доставки, чтобы игнорировать атрибут во время экспорта.
Чтобы управлять информацией, экспортируемой в инкрементной доставке в соответствии с бизнес-процессами, можно задать конкретные настройки, используя настраиваемые свойства в XML-файле свойств на основе типа пакета.
Тег <elementName>, предоставленный как стандартный (OOTB) в файле свойств на основе типа WPTypeBasedPropertiesLoad.xml, позволяет указать атрибуты, которые должны игнорироваться при сравнении инкрементной доставки с базовой доставкой.
<XMLFilterTags>
<!-- example:
<elementName>No elements to exclude</elementName>
-->
</XMLFilterTags>
<!-- example:
<elementName>No elements to exclude</elementName>
-->
</XMLFilterTags>
Ниже приведен пример кода, который должен быть добавлен в файл WPTypeBasedPropertiesLoad.xml:
<WPTypeProperties typeId="com.ptc.windchill.cp.rep.ReplicationPackage">
.
.
.
<XMLFilterTags>
<elementName>lifecycleInfo</elementName>
<XMLFilterTags>
</WPTypeProperties>
В примере файла свойств на основе типа атрибут lifecycleInfo исключается из критериев, которые определяют сравнение инкрементной и базовой доставки.
В нашем примере сценария 2 задание lifecycleInfo приведет к тому, что Part3 A.1 игнорируется при экспорте в инкрементной доставке, поскольку lifecycleInfo все теги и все вложенные атрибуты будут игнорироваться.
<lifecycleInfo>
<lifecycleTemplateName>Basic</lifecycleTemplateName>
<lifecycleState>INWORK</lifecycleState>
<objectHistory><lifeobjectHistory>
<ObjectID><localId>wt.lifecycle.LifeCycleHistory:170223<localId></ObjectID>
<action>Enter_Phase</action>
<actorPrincipal><WTPrincipalReference.classType="wt.org.WTUser".fullName="Demo, User" isInternal="false" surname="Demo" .userEmail="demouser">
<ufid>uid=demo,o=narwhal145_ptms0ld,o=ptc|Ldap.ptcnet.ptc.com|Ldap.ptcnet.ptc.com</ufid>
<name>demo</name>
</WTPrincipalReference></actorPrincipal>
<lifeCycleName>Basic 1</lifeCycleName>
<phaseName>In.Work</phaseName>
<state>INWORK</state>
<teamTemplateIdentity> <teamTemplateIdentity>
<createStamp>1662546309000</createStamp>
<modifyStamp>166254309000</modifyStamp>
<lifeobjectHistory></objectHistory>
</lifecycleInfo>
Результат будет выглядеть так, как показано в приведенной ниже таблице, в которой теперь в инкрементной доставке экспортируются только изменения детали Part1 A.2.
|
Источник
|
Базовая доставка
|
Инкрементная доставка
|
|---|---|---|
|
Part 1 A.1
Part 2 A.1
|
Part.1 A.1 + Part2 A.1
Изменение
Part1 A.1 –> Part2 A.2
Part 2 A.1
Part 3 A.1-> LC1 в LC2
|
Деталь-1 A.2
|
После определения элементов в XML-файле можно загрузить файл, чтобы ввести настройки в действие. Аналогичные настройки можно задать для всех пакетов Windchill и для других опций доставки, таких как синхронизация инкрементных доставок.
|
|
Как правило, в системе отображаются участники пакета только на вкладке пользовательского интерфейса содержимого доставки. Дополнительные или зависимые объекты не отображаются в интерфейсе пользователя. По этой причине в системе отображаются основные участники, когда связанные дополнительные объекты изменяются и включаются в ZIP доставки в инкрементном пакете
Например, деталь отображается на вкладке пользовательского интерфейса содержимого доставки для обновлений представлений, включенных в ZIP; или документ EPM отображается для связанной таблицы семейства. Аналогично, если имеется обновление только в записи AXL для детали изготовителя, продавца или OEM, связанная деталь отображается на вкладке пользовательского интерфейса содержимого доставки.
|