If you’ve spent much time on our Developer Community site, you’ve probably noticed that many of our code samples are geared toward .NET developers as for the most part, VersionOne is a .NET development shop. However, I’ve recently been tasked with building a new integration using Java, which is a language that I have not have the pleasure of working with until now.
As I ramp up on all the various facets of Java development with things like the Java API, Eclipse, Maven, and the wide variety of libraries available for data parsing and HTTP clients, I thought it might be worthwhile to share some of my learning with a larger audience that may be using Java to create applications in conjunction with the VersionOne Development Platform.
To that end, this is the first in a series of blog posts that will cover some of the basics of integrating with VersionOne using Java, and my plan is to hit on the following areas:
- Part 1: Introduction (YOU ARE HERE)
- Part 2: Handling configurations
- Part 3: Logging integration activity
- Part 4: Parsing data
- Part 5: Using an HTTP client
- Part 6: Authenticating with OAuth
- Part 7: Getting data out of VersionOne
- Part 8: Submitting data to VersionOne
- Part 9: Calling VersionOne operations
- Part 10: Conclusion
This list is subject to pivot as I continue learning and discovering new things, but my goal is to share what I have learned so that maybe others can jumpstart their own development efforts more quickly.
To get started, let’s set the context of what I’m trying to accomplish and why…
As with many modern Software as a Service (SaaS) applications, VersionOne provides a robust development platform that allows developers to access the data contained within the system, and perform many operations on that data. There are many different scenarios in which this is useful, but a common one is where you need to build an integration between VersionOne and some other external system. The external system could be an application from another software vendor, or it could be something homegrown that was developed in house and is unique to your organization. In any case, it can be useful to link and/or synchronize the two systems so that they can share data and better automate your internal workflow.
Of course no two integrations are ever the same, as they are often highly customized to an organization’s particular needs. For example, there may be differences in the types of data being synchronized, what triggers the integration to occur, and the workflow which the integration supports. However, there are common things that integrations share such as the need be configurable, to log its operations, to authenticate with external systems, and to access the data contained within the external systems, usually through some type of web service.
So in this series of articles, I’m going to discuss many of the basic building blocks of an integration, but before we get started, let’s spend a few minutes talking about the types of integrations that you can build. While I am currently working as a Platform Integration Specialist on the Platform team here at VersionOne, I was formerly a Technical Consultant on the Services team, and there had the opportunity to work with many different clients building all types of integrations. Some of the more interesting ones were:
- Data migration tools for extracting information from an external system and importing it into VersionOne
- Synchronizing defects between VersionOne and a QA team’s defect tracking tool
- Creating VersionOne requests, stories, and defects from a Customer Support team’s case management tool
- Creating VersionOne changesets from a development team’s source code management repository
- Creating custom reports based on project financial data imported into VersionOne from an external system
In all of the above scenarios, the thing that made them possible was the VersionOne Development Platform which includes a RESTful API that provides full CRUD (create, read, update, delete) access to any asset contained within VersionOne, plus operational functions that can be executed against those assets. I’ll be talking about the VersionOne API throughout the articles in this series, but I’ll dive deep once we reach Part 7 where I’ll start using it to query VersionOne for data about specific assets.
Note: When I mention “assets,” I’m talking about specific domain objects contained with VersionOne. Domain objects (or assets!) are essentially the primary data containers of VersionOne, both ones that represent agile artifacts such as Epics, Iterations, Stories, Defects, Tasks, Tests, etc.; and objects that are internal to VersionOne such custom fields, list types, and change history.
In the next article in this series, we’ll examine integration configurations – what they are and how to use them.
As always, stay agile my friend…