Inheriting Direct, Indirect, and Remote Dependencies
Inheriting Direct, Indirect, and Remote Dependencies
Inherit direct, indirect, and remote dependencies when you have complete information about the design-time and run-time applications.
You might have complete information about an application when you are the sole developer or the functional administrator for an application. When you make changes to the design-time application, you might expect all of the changes to be propagated to the run-time application to ensure that the run-time application mirrors the design-time application.
Example
You manage an application that contains workflows that run mappings which share different data objects. After you deploy the application and test the outputs, you edit one of the data objects.
To propagate the changes in the data object to every other application object that uses the data object, you create a patch that inherits direct, indirect, and remote dependencies. When you select the data object, the patch inherits any workflows and mappings that use the data object.
The following image shows how the inheritance appears in the Incremental Deployment wizard:
The following image indicates the selected object and the inherited direct, indirect, and remote dependencies:
To propagate the changes in the data object
Physical Data Object A
to the mappings and workflows that use the data object in the run-time application, you can also use a patch that inherits only direct dependencies. If you select the data object, the wizard identifies the mappings and workflows to be affected objects and the Data Integration Service updates the mappings and workflows during patch deployment.
A patch that inherits direct, indirect, and remote dependencies, however, provides more transparency about how the objects will be updated. It provides a higher guarantee that updated objects in the run-time application will transform data in the same way as the objects in the design-time application.