Why a simplified Java API for Asset Control is useful.
The requirement
Before I dive into how to implement a new simple Java API for Asset Control, let me outline some of the reasons for doing so. After all, there are already a number of ways to work with Asset Control programmatically. Among the most commonly used we have:
- ac_bl for static data (and meta data) manipulation
- amd_pr and dumpdata for working with timeseries
- Formula Engine for derived attributes, (price) consolidation, reports etc.
- AC Java API for pretty much anything
I believe, in an ideal scenario, there would be one way to work with Asset Control. However, I appreciate that for a number of reasons that is not the case and all of the methods listed above have use cases they support. Still, there is value in trying to come close to that ideal scenario, i.e. when writing custom code around Asset Control, and particularly when writing tests. For reasons of both simplicity and elegance, these tests should be written in a uniform way.
Looking at the list above, the first three are not flexible enough. They are there for specific - often very limited - purposes. Another problem is that they need to be run on the server to be (fully) functional. A lot of the time, I will want to be able to run my custom code and tests from the client side, e.g. my IDE.
That leaves the AC Java API (at the time I write this, the AC Java API is in version 4.4).
Why not the AC Java API?
On the plus side, the AC Java API is very comprehensive and certainly flexible enough. But it is also verbose and has a steep learning curve, especially if someone is not familiar with Asset Control yet. Even seemingly simple operations might involve a dozen classes and trying to call the correct one out of many overloaded methods.
In many cases, the object returned by a method call can be complex as it contains both the payload and meta information, so needs further processing. It then follows that if you want to keep your business logic clean and for your code to communicate the what over the how, you need to introduce an appropriate layer of abstraction.
The case for a simpler Java API
Day on day, there is usually only a limited set of operations I need to perform. I will need to search the system for ADOs fitting certain criteria, read and write static data and timeseries, run a snippet of Formula Engine.
This should all be possible in just a few lines of code. The supporting classes and methods should mirror the concepts of ADOs, attributes, values, trees etc. in order to be easily readable. The new layer will be a streamlined interface with AC, tailored to our needs.
I offer two versions of this API: Basic and Extended.
Basic Java API for AC
This version allows you to perform the most common operations around static and timeseries data, timeseries validation functions and executing Formula Engine code.
The main limitation is with regards to the Asset Control data types it supports:
- Only single-valued string, integer and floating point attributes.
- No support for multi-valued attributes, compounds etc.
You can find the source code on GitHub or you can just download the JAR file.
You have permission to use the Basic Java API as is. This explicitly includes commercial use. You may also extend the API yourself, however you are not permitted to redistribute the API.
Extended Java API for AC
If you like the Basic Java API and would like an extended version of it (e.g. support for other data types, additional functions etc.), please get in touch via email or on LinkedIn.
Thank you for reading.
To continue, you may want to refer to the articles here or go straight to Connect to AC.