Using the BI Lineage Plug-in

About the BI Lineage Plug-in

The BI Lineage plug-in for SAS Management Console identifies connections between BI objects. To generate lineage information, you use the BI Lineage plug-in to run a scan on a subset of folders in the SAS Folders tree. The scan examines reports and information maps that are stored in the selected folders, and identifies other objects (regardless of their location) that are connected to those reports and information maps. The starting point for the scan can be any folder (other than the root folder) in the SAS Folders tree.

Scan results are stored in a tree structure that can be viewed on the Plug-ins tab, as shown in the following example:

Authorized users can navigate the tree for a particular scan, select a BI object that was included in the scan, and display the object's lineage or reverse lineage report. Here is an example of a lineage report for a report object, showing an information map and two tables that are connected to the report.

Information can also be displayed in graphical form, as shown here:

For details about information that is available in scan results, see Viewing the Results of BI Lineage Scans.

BI Lineage is similar to the impact analysis feature of SAS Data Integration Studio and SAS OLAP Cube Studio. The main difference is that BI Lineage analyzes objects starting with information maps and reports, and impact analysis starts with tables and cubes. If your deployment includes SAS Data Integration Studio or SAS OLAP Studio, then impact analysis data from that application is automatically incorporated into the BI Lineage scan results.

Administering the BI Lineage Plug-in

Running and Scheduling Scans

BI Lineage scans can be run only by an unrestricted administrative user (that is, a user who is in the SAS Metadata Server: Unrestricted role).

To run a scan, go the Plug-ins tab in SAS Management Console, right-click the BI Lineage node, and select New Scan. In the New Scan Wizard, specify a name for the scan. Then browse to a starting location, which can be any folder (other than the root folder) in the SAS Folders tree. The scan examines the reports and information maps that are stored in that folder and all of its subfolders, and identifies connected objects regardless of their location.

Because the lineage information is not generated in real time, it is important to keep the scan information updated. To make this task easier, you can create jobs and then schedule them to run at regular intervals. The plug-in can generate jobs for running, exporting, or deleting BI Lineage scans. After the jobs are generated, you can use the Schedule Manager plug-in to schedule the jobs. For details about these tasks, see the BI Lineage plug-in Help in SAS Management Console.

Granting Users Permission to View Scan Results

Scan results are stored in a special metadata repository called the BILineage repository. This repository is created automatically the first time an unrestricted administrative user logs on to SAS Management Console. The BILineage repository should not be used for any purpose other than storing scan results.

To give users permission to view scan results, you must update the BILineage repository's Default ACT to grant ReadMetadata permissions. Follow these steps to grant permission:

Log on to SAS Management Console as an unrestricted administrative user. On Plug-ins tab, select BILineage from the Repository drop-down list.
Navigate to Environment ManagementAccess Control TemplatesDefault ACT, and open the properties window for the Default ACT.
Select the Permission Pattern tab, and update the information as follows.
- If you want to give all registered users access to scan results, then grant ReadMetadata permission to the SASUSERS group.
- If you want to give access to a specific group of users, click Add and select the group. When you add the group, the Authorization Manager automatically grants it ReadMetadata permission.

Note: You cannot provide access by setting permissions on the BILineage folder that appears in the SAS Folders tree, because scan results are not stored in the folder.

Viewing the Results of BI Lineage Scans

To view scan results, expand the node for the BI Lineage plug-in, and then expand the node for the scan whose results you want to view.

Within the scan, expand the node for a particular object type (for example, Reports). Then select the folder that contains the object whose lineage information you want to view, as in the following example:

In the right pane, right-click the object whose lineage information you want to view, and select one of the following options:

Lineage

identifies the objects that contribute to a particular report or information map (including objects that are located outside of the scanned folder and its subfolders). For example:

The lineage information for a report identifies all of the information maps, tables, cubes, columns, filters, and stored processes that contribute to the report.
The lineage information for an information map identifies all of the tables, cubes, columns, filters, and stored processes that contribute to the information map.

Reverse Lineage

identifies the objects within the scope of the scan that might be affected if a selected object were to change. (Affected objects that are stored outside of the scanned folder and its subfolders are not identified.)

For example, the reverse lineage information for a table shows information maps and reports that use the table (excluding those that are stored outside of the scanned folder and its subfolders). You can use this information to determine which information maps and reports might be affected if the table were to change.

Properties

displays information about the object, as well as a list of the component objects that are members of the selected object (for example, the columns in a table, the data items in a cube, or the sections in a report).

Right-click any of the component objects to display a menu of options for that object. The options include the following:

High-level Lineage

identifies the high-level objects that contribute to a particular component object (such as a data item, column, or report section).

For example, high-level lineage for a report section shows all information maps and tables that contribute to the report section.

High-level Reverse Lineage

identifies the high-level objects within the scope of the scan that would be affected if the selected component object were to change. (Affected high-level objects that are stored outside of the scanned folder and its subfolders are not identified.)

For example, the high-level reverse lineage information for a data item shows all reports that use the data item (excluding reports that are stored outside of the scanned folder and its subfolders). You can use this information to determine which reports would be affected if the data item were to be changed.

Low-level Lineage

identifies other low-level member objects (such as data items, columns, and report sections) that contribute to a particular component object.

For example, low-level lineage information for a data item would show the column or columns that contribute to that data item.

Low-level Reverse Lineage

identifies other low-level objects within the scope of the scan that would be affected if a particular component object (such as a data item, column, or report section) were to change. (Affected objects that are stored outside of the scanned folder and its subfolders are not identified.)

For example, low-level reverse lineage for a data item shows report sections that would be affected if that data item were to change (excluding report sections that are stored outside of the scanned folder and its subfolders).

Properties

displays the general properties for the object.

You should be aware of the following limitations when using scans produced by the BI Lineage plug-in:

Reverse lineage and low-level reverse lineage information only identifies objects that are stored within the scanned folder and its subfolders. Objects that are stored outside the scope of the scan are not identified. For example, reverse lineage for a table shows reports and information maps that might be affected if the table were to change, excluding reports and information maps that are stored outside of the scanned folder and its subfolders.

(By contrast, lineage and low level-lineage information includes all objects, regardless of their location in the SAS Folders tree. For example, the lineage information for a report includes all tables and information maps that contribute to the report, including those stored outside the scope of the scan.)
If the data source for an information map is a table that was created by the SAS Information Maps LIBNAME engine, then only partial lineage information is provided for the map. The lineage information includes the table that the engine created. However, it does not include the original map that the engine accessed to create the table, nor does it include the table that was used to create the original map. Here is an example scenario:
- Table A was used as a data source for Map B.
- Map B was used as a data source by the Information Maps LIBNAME engine to create Table C.
- Table C was used as a data source to create Map D.
For Map D, the BI Lineage scan would provide the following lineage information: Map DTable C. The lineage information would not include Map B or Table A.

Note: The SAS Information Maps LIBNAME engine provides Read-Only access to data in an information map. For more information, see Base SAS Guide to Information Maps.
Prompts that are used by information maps are not included in scans.
Low-level lineages are not supported for sections of reports that directly use tables or cubes. Low-level lineages are supported only for report sections that are based on information maps.
BI Dashboards and their component parts (such as ranges and indicators) are not included in scans.

For more details about using the BI Lineage plug-in, see the plug-in Help in SAS Management Console.

Suggested Uses for the BI Lineage Plug-in

The BI Lineage plug-in is useful in the following types of situations:

A report consumer who wants to know where the data on a report originated can use lineage information to identify the information maps, cubes, and tables that provided the source data, as well as any stored processes that processed the data. If your deployment includes SAS Data Integration Studio, the lineage information also includes any jobs and transformations that were used to process the data.
If you modify a table, cube, or information map, you can use reverse lineage information to identify associated objects that might need to be retested or verified. For example, you can identify which information maps and reports (within the scope of the scan) use a particular table. In addition, you can use low-level reverse lineage information to identify which information maps, reports, or report sections (within the scope of the scan) use a particular column.
For project documentation, you can use the BI Lineage plug-in to create a printable list of the objects in the project and their relationship to one other.
BI Lineage can provide usage information to help set priorities and make support decisions. For example, you can find out how many cubes, information maps, or reports (within the scope of a scan) use a particular set of tables or a particular data column.

Note: The BI Lineage plug-in does not report the number of times that a particular object was accessed. This type of usage information can be obtained through tools such as the SAS Audit and Performance Measurement package (see http://support.sas.com/rnd/emi) and the Key User Action Log in SAS Web Report Studio (see Manage the Key User Action Log File in SAS Intelligence Platform: Web Application Administration Guide).
When troubleshooting security issues, you can use lineage information to identify which objects' permissions to examine. For example, if a user is having difficulty accessing a report, you can use lineage information to identify the information maps, tables, and cubes that the report depends on. To have full access to the report, the user must have the appropriate permission to the metadata and the physical data at each of these levels.