Considerations when deploying NodeGraph

Before jumping into the installer and start getting hands-on, you would benefit from understanding both the environment that should be depicted, and also how it should be used. While there is no technical limitation on what can be shown inside NodeGraph, there might exist other reasons for not putting everything into one place.

Understanding the environment

If the environment design is unknown, or complex, creating a simple container analyzing only a subset of the data involved could be beneficial in understanding the tool, the environment, and create a better understanding of how it should look in the bigger picture.

One approach could be targeting only one or two end reports or areas, seeing what NodeGraph is able to get from this.

Planning the configuration

Try to get a general feel for what should be included before adding the connectors. Questions that can be relevant are:

• Is there more than one environment?

• Is there more than one BI tool? Should they exist in the same container or should they be separated?

• What is the intended use of NodeGraph? Perhaps impact analysis for the DW team needs different information than the BI Team, or the business users?

• Are there security reasons to separate information?

It is very important to remember that it is only on container level that security can be applied. Any information within a container is accessible for users with access to the container.

Understanding Categories

Categories are recipients and holders of nodes. Categories are not complex, but because of their free role in a NodeGraph configuration, they can be misinterpreted as such.

When a connector finds information, it separates different types of information as node types, and depending on the rule setup, they are put into categories.

For an SQL database, these different node types may be Tables or Views, but in a BI tool it can be charts, reports, or file resources. Where you decide to put the information detected is entirely up to you. What is important is that it makes sense in respect to how the environment looks.

As the administrator of NodeGraph, you have complete control of what the categories are and what is in them. They are organized in the Dependency Explorer on a grid. A later topic will cover categories in depth, but for now, it is enough to know that their purpose is to organize the connector output.

Understanding Unmapped Categories

Unmapped categories is a concept that you will run into when working with NodeGraph. It is not a category, but you will encounter it on the category section in the connector rules. When a NodeGraph connector is parsing information, it separates between assets that are known to the connector, and assets that are unknown or external.

For instance, when the Tableau connector runs, we can identify the workbooks, projects, and other Tableau assets under the connector as they are part of the information sphere that Tableau knows of.

But Tableau can also refer to databases, data sources, web files and network shares where the data is fed into the Workbooks. These are assets that are not under Tableau’s control, so they are shown with as much information that can be presented, but they will be presented under the Category rule of Unmapped Assets, as the Tableau connector cannot and should not know of their metadata.

This also means that if you only have a BI Tool in NodeGraph and not the corresponding connector for the database side, you will still see the queries and tables/views and fields, although only those requested as any omitted information cannot be known on the BI tool side.

Working in increments

In the starting phase, it is recommended to work incrementally when adding information where it is applicable. Especially around the BI tools, adding smaller parts of the environment often brings up information that can be added in other connectors, such as databases or File structures, before the entire report environment is added. Not only is it easier to oversee, but it also allows more frequent reloads and you do not have to wait for the entire toolset to be parsed before you can start acting upon information.