Five things you need to know before you start importing sources

When importing sources into BlueDolphin, there are a few things you need to be aware of. In this article, you can find all the things you need to know when uploading sources to BlueDolphin.

1. Use a primary key

When importing a source, it is a best practice to use a primary key. This primary key won’t be used for creating objects within BlueDolphin. Its function is to match future imports to this key and update the records instead of adding new records to the existing source.

Even when you have no intention of updating a source ever again, it is a best practice to use it. A primary key basically means a unique way to identify a record. This helps with checking the data quality before you even import your data, especially when combined with the second best practice.

2. A BlueDolphin object Title is unique

All objects in BlueDolphin must be unique within its object definition. The uniqueness doesn’t come from the primary key of the source. However, it’s a best practice to set the primary key in uploading to the data field you want to use to create an object Title.

In the above screenshot, the primary key has been set to “Application-ID” (Application-ID). Although ID should be unique in the source, an ID or GUID most likely won’t be used to create an object Title in BlueDolphin. This can result in understandable but unwanted behavior as the application name might not be unique. When this happens, BlueDolphin will create only one object with the application name and merges its source records in this object, but there’s no way of telling which record will be used for other properties.

It’s better to set the primary key to, for example, “Application-Name” and use this field to create the BlueDolphin objects as well. The primary key ensures its uniqueness. This means for each record an object will be created or merged with an already existing object.

Unfortunately, not all sources ensure a name to be unique, so this might not always be possible.

3. Use a source upload for each object and relationship

BlueDolphin keeps track of which records of a source have been used. There are some ways to reuse a source a few times, but it can result in strange unwanted behavior when misused. Instead of explaining the complex rules about this, the best way is to use a source once.

However, you can import the same data a few times under a different source name in BlueDolphin.

In this example, I’ve imported “SELECT * FROM [AllAppsandImportDate.csv]” to BlueDolphin as target collection “Excel_Applicatielijst2”.

I also plan to create relationships from the same CSV, so I should import the same CSV again. I can use the same query and import all the information of the CSV again, which is fine to do.

However, you can also filter out the unneeded columns by changing the query to include only the needed columns.

SELECT Applicationname, BusinessFunction FROM [AllAppsandImportDate.csv]

This allows the relationship between an application and a business function in BlueDolphin to be created.

To ensure the business function exists in BlueDolphin, we can use the same CSV again to import it a third time. Again, the entire CSV could be loaded, but when you only need the unique values from one column, you can make them unique before you import, using the DISTINCT keyword:

SELECT DISTINCT BusinessFunction FROM [AllAppsandImportDate.csv]

4. Use a naming convention for your sources

This helps a lot when understanding how the sources are used. The naming convention should give information about the type of upload (scheduled or manual), the source application (if any), and the purpose of the upload.  

For example, all scheduled uploads start with “Auto_” and manual uploads don’t have prefixes.

Auto_VMware_VMs --- Uploads the virtual machines from VMware on a timed schedule.

Excel_Applications --- Uploads applications from Excel by manual upload.

Auto_Excel_Applications_Businessfunction_relations --- Uploads the relationships between applications and business functions from Excel on a schedule.

5. Do not enable the “Empty before update ?” checkbox

Last but not least: The “Empty before update ?” checkbox should never be enabled.

This setting is the cause of a lot of unwanted behavior. This drops an already existing source in BlueDolphin; it also drops existing configuration and information/properties about objects that might still be in BlueDolphin. Additionally, it doesn’t update records as the primary keys of those records have been dropped as well, instead of adding it an object as another source in the “source tab” of an object.