In this part of my series, we’re going to discuss configurations – what they are, why you might need them, and how to write the code to make them part of a VersionOne integration.

Here’s where we are in this series:

  • Part 1: Introduction
  • Part 2: Handling Configurations (YOU ARE HERE)
  • Part 3: Logging
  • Part 4: Parsing Data
  • Part 5: Using a HTTP Client
  • Part 6: Getting Data Out of VersionOne
  • Part 7: Submitting Data to VersionOne
  • Part 8: Calling VersionOne Operations
  • Part 9: Authenticating with OAuth
  • Part 10: Conclusion

Configurations are persisted values that can affect the behavior of an application, and they typically (or least should) live outside the source code of the application. For VersionOne integrations, configurations can be used for a variety of purposes including:

  • Setting the URL of the systems that are being integrated
  • Setting the credentials (username, password, etc.) used to access each system
  • Setting asset types and data fields that are being integrated
  • Setting log file configurations
  • Controlling the workflow of the integration

This is by no means a comprehensive list, as configurations that may be needed for an integration are bounded only by the needs of your particular workflow. The point is that most integrations require the ability to make use of values that are persisted outside of the core application code, and that can be easily modified without having to recompile your application.

There are many ways to persist configuration values such as in a database, XML, or some type of flat file. However, if you use one of those types of formats, you may find yourself having to write all the code that accesses them. Fortunately Java has a really simple and standardized way to handle properties with what is known as a “Properties” file. The core Java API has a class named java.util.Properties that can be used to access the data in a Properties file, as long as the data follows a certain format.

For example, here’s a simple Properties file entry for storing the URL of a VersionOne instance:

# The URL to the VersionOne instance.
instanceUrl={Server Base URI}

Note: The server base uri example used above is the full url to a VersionOne instance. See Server Base URI to learn more about how it is constructed.

Notice that the Property file entry is just a name-value pair, the content on the left of the equals sign is the property name; the content on right is the value.

To create a Properties file in a Java application, just create a new file and give it a .properties extension. Once you have your Properties file created, all you need to do to access its entries in your code is use a reader to load it into a Properties object like the following:

Properties properties;
try (FileReader reader = new FileReader("config.properties")) {
      properties = new Properties();
      properties.load(reader);
} catch (IOException e) {
      e.printStackTrace();
}

Once you have the properties loaded, you can then call the getProperty or setProperty methods to read and write the properties as in the following:

properties.getProperty("instanceUrl");
properties.setProperty("instanceUrl", "{Server Base URI}");

As you can see, using this approach makes handling configurations very easy. However, if you need to have more complex configurations than just name-value pairs, you may need to consider another approach such as storing your configurations in an XML file.

That said, an advantage of using the Properties file approach is that there are other Java libraries that make use of it as well, which we’ll see in the next article that discusses logging.

As always, stay agile my friend…

Join the Discussion

    There are currently no comments.

    6 + 2 =