Developer Tool Guide

10.5.3
- 10.5.6
- 10.5.2
- 10.5.1
- 10.5
- 10.4.1
- 10.4.0

Back Next

Identify Affected Objects

An affected object is an object that the Incremental Deployment Wizard fetches from the run-time application in order to maintain the deployed application. Users who own the affected objects will not be able to run the objects while the Data Integration Service applies a patch.

The wizard fetches affected objects while you design the application patch. You can view the objects that are affected when you preview object impact.

The wizard fetches affected objects for the following reasons:

Change propagation: When you select objects in an application patch and the patch inherits other application objects, the wizard must decide how the changes in the objects will be propagated to their parent objects in the run-time application. The wizard identifies the parent objects to be affected due to the changes.

When you deploy the patch, the Data Integration Service does not replace the run-time instances of affected objects, but it updates the affected objects to consume any changes that are made to their run-time direct dependencies.

If a workflow is an affected object, the workflow is updated the next time that it runs. For example, if you modify a mapping and a workflow uses the mapping in a Mapping task, the workflow uses the modified mapping in subsequent executions.
Validity: The wizard must ensure that application objects in the run-time application will be valid after the Data Integration Service applies a patch. After the wizard decides how changes will be propagated to affected objects, the wizard validates the affected objects. An affected object might not be valid if it is not compatible with a modified object.

Any application patch type can result in affected objects. For example, when you create a patch that inherits direct, indirect, and remote dependencies, a remote dependency might have a direct dependency that the patch inherits. If the direct dependency is used by a different object in the run-time application, the parent object becomes an affected object.

After the Data Integration Service updates an affected object, the data in the affected object might not be consistent with the application design. Consider a run-time application that contains a mapping which uses a mapplet. If the modified mapplet uses a different transformation, the affected mapping might be valid but it might also transform the data in an unpredictable way.

If possible, try to select the objects that you want to update, or design an application patch to inherit the objects to minimize the number of affected objects and guarantee that the objects in the run-time application transform data in the same way as the objects in the design-time application.

Example. Change Propagation and Validity

You deploy a patch that modifies a data object. The wizard propagates the modifications in the data object to any other run-time objects that use the data object. As a result, an affected run-time mapping that uses the data object will use the modified data object after the Data Integration Service applies the patch.

If a mapping uses the modified data object and the data object contains fewer rows than before the patch was applied, the mapping might no longer be valid. The data object might not be compatible with the transformations in the mapping due to a fewer number of links between upstream and downstream transformations. If the affected mapping is not valid, you cannot deploy the patch.

Determine Application Object Impact

Deleted Objects

Example. Identifying Affected Objects

Download Guide

Watch

Comments

Communities

Knowledge Base

Success Portal