8.3.5. Displaying an Object’s Dependencies

Engineering Knowledge Manager

User's Guide | Chapter 8: Managing Repository Data | 8.3. Displaying Objects |

8.3.4. Displaying the Permissions on an Object |  | 8.3.6. Displaying an Object's Usage
Prev |  | Next

### 8.3.5. Displaying an Object’s Dependencies

Dependency tracking allows you to easily understand the interrelationships between objects. When a file or an analysis project depends on other objects, the Dependencies view helps you visualize its upstream and downstream dependencies, determine which objects have changed, and which objects need to be updated. For example, when working with an analysis project, you can see the input and output files of the analysis, and determine which files are out-of-date. (See Working With Analysis Projects for details.)

You can use the Edit Pedigree action to add upstream dependencies to a file (see Editing a File’s Pedigree). You can use the same action to add upstream or downstream dependencies to an analysis project (see Specifying Analysis Project Pedigree (Inputs and Outputs)). These are referred to as user-defined dependencies.

If a Workbench project contains files that have been imported from the repository, those files will automatically become dependencies of the project when you save the project to the repository. These are referred to as extracted dependencies. For more information, see Example 8.2: Dependency Diagram for a Workbench Project.

Both user-defined and extracted dependencies are displayed in an object's Dependencies view. To display an object's dependencies, select (More) > Display > Details (or the Details display tab if the object is already opened), then expand the Dependencies section. The diagram enables you to view and access the upstream and downstream dependencies of the object.

Note that only the immediate upstream and downstream dependencies are shown in the diagram. You can click on any node in the diagram to navigate the dependency tree and view dependencies of other objects.

Example 8.1: Dependency Diagram for a Comparison Report

Figure 8.6: Dependencies Diagram - Example shows an example of a Dependencies display for `Comparison Report` that will be used to highlight the features of dependency tracking in EKM. The dependencies in this example were defined using the Edit File Pedigree action, making them user-defined dependencies.

In the diagram, the `Comparison Report` object has the number 1, and its box is not shaded. This indicates that the `Comparison Report` object is the current object. Upstream dependencies are shown on the left of the current object, and downstream dependencies are shown on the right of the object.

Figure 8.6: Dependencies Diagram - Example

The `Comparison Report` object has two upstream dependencies: `waveguide1.aedt` and `OptimTee.aedt`, numbered 2 and 3 respectively. These two files determine the content of the `Comparison Report`. Therefore, if either the `waveguide1.aedt` or `OptimTee.aedt` file were to change, the `Comparison Report` would be need to be updated because it is dependent on those two files.

The `Presentation.pptx` object (numbered 4) is a PowerPoint presentation that contains data from the `Comparison Report`. This means that `Presentation.pptx` is a downstream dependency of `Comparison Report`. If the `Comparison Report` changes, the `Presentation.pptx` will need to be updated because it is dependent on the `Comparison Report`.

The objects in the diagram correspond to the dependency table. The table shows the details of all objects and their relationships. It includes columns for the ID, Path, Status, Dependency Type and Date Modified. You can filter the table according to any of the displayed properties. For details see Filtering the View.

If you click on one of the objects in the diagram or table, the dependencies for that object will be displayed.

If an upstream object has been modified, it is marked with an asterisk (*) in the diagram, and its status becomes “Newer than downstream” in the table. A version-controlled object will be shown as modified if a new version of the object is created, and the new version has modified content. In this case, the object's status will be “New version exists” in the table.

When an object has been modified, dependent downstream objects are marked with an 'attention required' icon in the diagram, and its status becomes “Out of date”. This indicates that the downstream object needs to be updated.

Example 8.2: Dependency Diagram for a Workbench Project

If a Workbench project contains a file that has been imported from the repository, and you subsequently save the Workbench project to the repository, the repository file will be displayed as a dependency of the Workbench project.

For example, let's say you are working on a project named design1.wbpj in Workbench, and use the Import Geometry > Browse from Repository option to import the repository file hood_assembly.agdb into the Geometry cell of the project schematic. When you save the Workbench project to the repository, the hood_assembly.agdb file automatically becomes a dependency of the project, as shown below:

The dependency in this example is an extracted dependency, and therefore cannot be modified using the Edit File Pedigree action.

Note:

- If you import a file from your My Data folder into a Workbench project, EKM assumes that you will also upload/save the project back into EKM. This is because Workbench stores the repository file path as a view path (for example, /Data/My Data/filename), not a system path (for example, /System/User Accounts/username/My Data/filename). When the project is uploaded/saved to the repository, EKM assumes that My Data in /Data/My Data/filename is the My Data folder of the person who uploaded the project, and looks for the dependency file there. If a file with that name does not exist in the uploader's My Data folder, the file will not be shown as a dependency of the project in EKM. If a file with that name does exist in the uploader's My Data folder, then that file will be shown as a dependency of the project, even though it may not have been used in the project.

- If a file that you have imported into a Workbench project gets moved in the repository, the file will not be found when you import the project into the repository, and will therefore not be listed as a dependency of the project.

- If you have imported a version-controlled file into a Workbench project, the version number will not be retained by Workbench. Therefore, when you import the project into the repository, EKM will set the current version of the file as a dependency, even if a different version was used in the project.

Contains proprietary and confidential information of ANSYS, Inc. and its subsidiaries and affiliates.

Prev | Up / Contents | Next

Release 18.2 - © ANSYS, Inc. All rights reserved.