Dot your API’s and cross your t’s

And will you succeed? Yes indeed, yes indeed! Ninety-eight and three-quarters percent guaranteed!
Dr. Seuss
.

Linking keys are an important consideration for cross-referencing disparate data sets. And in OSS you have lots of disparate data sets to pull together. For example, every different NMS, EMS, BSS (and even other OSS tools) create / manage disparate data sets. Some of the greatest insights delivered by an OSS come being able to link / merge data sets.

Since the data sources are designed / created independently of each other, they often don’t have naturally occurring linking keys. This is where you can use free-fields to synthetically create linking keys.

Just one thing to check before excitedly jumping up and down at having found a way of linking data sets. The data source may allow you to create linking keys within its user interface, but if its API or data export tools don’t give access to all data objects (including free fields), then you may have difficulty accessing the linking key data.

When assessing your OSS interface, don’t forget to pay close attention to what information is exposed by the API. It is common for less than 100% (less than 98 and three quarters percent even) of data fields to be exposed, so don’t forget to check that the ones you need (eg your free-field text objects) are accessible.

PS. Thanks to David for a recent discussion that spawned this post! 🙂

PS2. Thanks to Mark for the helpful reminder that field lengths also need careful consideration (click on comments to see Mark’s notes)

If this article was helpful, subscribe to the Passionate About OSS Blog to get each new post sent directly to your inbox. 100% free of charge and free of spam.

Our Solutions

Share:

Most Recent Articles

No telco wants to buy an OSS/BSS

When you’re a senior exec in a telco and you’ve been made responsible for allocating resources, it’s unlikely that you ever think, “gee, we really

2 Responses

  1. Ryan,
    One of many things to check! This has caught me out at least once on real deployments. That, and also disparity between systems in the number of alternate names/free text fields, and the actual field lengths. It’s unpleasant managing CSV in these fields, that then gets truncated because of a 512 char limit!

  2. Great point Mark!
    Yes, field length can be very annoying …. particularly on the older technologies that were far less than 512 char sizes!
    It’s also one of those sneaky gotchyas when trying to prepare a naming convention (especially if your organisation insists on having a comprehensive naming convention!!). It’s a bit like the weakest link theory – any given object’s naming convention should only be as long as the shortest field length supported by your network/APIs for that object type. 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.