Si se ha recibido más de un fichero ZIP de envío de paquete de un sistema de origen, es posible que el remitente optara por enviar un envío incremental de lo que se había enviado previamente. El proceso para importar ficheros de envío recibidos incrementales es idéntico al proceso para importar ficheros de envío recibidos completos. Hay, sin embargo, dos aspectos adicionales que se deben tener en cuenta:

En algunas situaciones, se puede recibir un envío subsiguiente del mismo sistema de origen con actualizaciones del contenido que se ha enviado anteriormente. Se puede recibir un envío completo con todo el contenido enviado anteriormente, o bien se puede recibir un envío incremental con solo la información que ha cambiado desde el envío anterior. Por ejemplo, si la empresa está colaborando con otra empresa y se deben conocer las modificaciones realizadas en su conjunto, se pueden solicitar actualizaciones periódicas para mantenerse al día de los datos modificados.

A diferencia de un envío completo, un envío incremental se compara con un envío base. Esta comparación permite a un envío incremental la oportunidad única de enviar información sobre los objetos que cumplan uno de los siguientes criterios:

Los envíos incrementales también transportan la información modificada sobre la asociación entre un documento CAD y un WTPart. Esta es una excepción cuando el cambio en la información de asociación no se muestra con claridad.

Considere un WTPart con una imagen que está asociada a un documento CAD y se archiva en Windchill sin crear (preferencia Crear pieza después de asociar o el conjunto de opciones Definir para creación de un solo nivel en Desactivado). Si se crea un paquete de estos objetos, al importar un paquete incremental después de quitar la asociación (consulte Edición de la asociación de documentos CAD y artículos Windchill) en Windchill, la eliminación de la asociación entre el WTPart y el documento CAD no está limpia.

Puesto que los envíos incrementales se crean en el sistema de origen seleccionando un envío base a partir del que se evalúan los cambios, a menudo hay una dependencia entre ambos envíos. Siempre es recomendable importar los ficheros ZIP de envío recibidos en el mismo orden en que los ficheros se han exportado, pero esta práctica es aún más importante para un envío incremental. Para obtener más información, consulte la sección Prácticas recomendadas para importar objetos de envíos recibidos en Prácticas recomendadas para trabajar con envíos recibidos.

En determinados escenarios empresariales, es posible que desee que la lógica de envío incremental ignore los cambios en atributos específicos durante una comparación con el envío de la instantánea. La lógica de envío incremental actualizada proporciona un mecanismo eficaz para paquetes de Windchill a fin de incluir y exportar solo los objetos relevantes que se han modificado desde el envío anterior.

Considere el siguiente ejemplo, donde en el paquete base se incluyen dos artículos: Part 1 A.1 y Part 2 A.1. Se ha producido un cambio en el Part 1 A.1 y se ha cambiado al Part 1 A.2; además, se ha cambiado la descripción del contenedor (producto/biblioteca). A medida que el contenedor contribuye a los metadatos del artículo que se exportan, el contenedor se considera como un objeto integrado. El cambio en la descripción del contenedor como un objeto modificado extrae todos los objetos contenidos en el contenedor como modificados, es decir, en este Part 1 A.1 y Part 1 A.2, aunque los metadatos exportados no se cambien en comparación con el envío base. La lógica de cálculo delta se ha afianzado aún más para prestar atención también a los metadatos exportados. Por lo tanto, el paquete resultante solo exportará el Part 1 A.2 como el Part 1 A.1. Los metadatos exportados no se modifican, tal como se muestra en la siguiente tabla.

Considere otro ejemplo, donde el paquete base mencionado en el ejemplo anterior incluye un tercer artículo adicional, digamos, el Part 3 A.1 con el atributo LifeCycle1 (LC1) que añadió, digamos, el usuario User1. En algún momento, si el atributo LifeCycle1 del tercer artículo lo modificó otro usuario, digamos el User2, al LifeCycle2 (LC2), normalmente el envío incremental contendrá los cambios que pertenecen al Part 1 A.1 –> Part 1 A.2 y al Part 3 A.1 –> LC1 a LC2.

Aunque el sistema genera el envío incremental comparando todos los contenidos cambiados con el envío base, también se puede influir en la lógica de envío incremental para desestimar un atributo durante la exportación.

Para controlar la información que se exporta en un envío incremental en función de los procesos de negocio, se pueden definir preferencias específicas mediante las propiedades personalizables en el fichero XML de propiedades basadas en el tipo de paquete.

La etiqueta <elementName> que se proporciona de fábrica en los conjuntos de propiedades basados en el tipo en el fichero WPTypeBasedPropertiesLoad.xml permite especificar los atributos que se deben desestimar cuando un envío incremental se compara con el envío de instantánea.

A continuación se muestra un ejemplo del código que se debe añadir en el fichero WPTypeBasedPropertiesLoad.xml:

En el fichero de propiedades basado en el tipo de ejemplo anterior, el atributo lifecycleInfo se excluye de los criterios que determinan la comparación entre los envíos incremental y de instantánea.

En el escenario 2 de ejemplo, si se especifica lifecycleInfo, se desestimará el cambio del Part 3 A.1 durante la exportación en el envío incremental, ya que se desestimarán las etiquetas lifecycleInfo completas y todos los atributos anidados.

El resultado será como el que se muestra en la siguiente tabla, donde solo los cambios en el Part 1 A.2 se exportan ahora en el envío incremental.

Una vez definidos los elementos en el fichero XML, se puede cargar el fichero para que se apliquen las preferencias. Se pueden definir preferencias similares para todos los paquetes de Windchill y para otras opciones de envío, como envíos incrementales de sincronización.

Para obtener más información, consulte la sección Reading and Loading Type-Based Properties XML File en Package Type-Based Properties.