While working on a government contract, I encountered the Physical Objects module from OpenText which allows encapsulating details about a physical archive (think old books, microfilms, file folders – the kind that contain paper, etc), and the management of loaning them out and tracking them.
One of my big tasks was to write WebReports to create for the client a User Interface that placed the data that was important to *them* at their fingertips. After many months, and several thousand lines of spaghetti code, spanning God knows how many WebReport and LiveReport objects, I delivered a working interface that managed the aspects of Physical Inventory that were important to them.
Ever since then, I’ve been looking at how I could have written a UI in WebReports that would be easier to maintain, with fewer peripheral objects, and fewer lines of spaghetti code. I believe the answer comes in the form of OpenText’s new REST API. I’ve learned from others that it is indeed possible to have a jQuery AJAX function within a WebReport consume the REST API. All you need to do is pass in the authentication token which is available from a WebReport tag, and the REST call is done as the same user that is executing the WebReport.
This got me thinking. Given that many of the steps in writing my own custom interface involved a lot of writing sub-reports, perhaps encapsulating what I had been doing in a REST API might be a worthwhile endeavor. Imagine writing a WebReport based UI that needs only a handful of reports to deliver key functionality instead of 20 or 30! Think of how much easier that is to transport between development and production environments! A REST API for Physical Inventory would also expose the functionality of the Physical Objects module to hand-held scanning devices, allowing dock workers to scan data into Content Server from the warehouse.
I have spent some time this week developing a REST API for Physical Objects. I have no idea whether OpenText has this on the roadmap – I believe that physical inventory management is not considered a growth industry. Nevertheless, within a few days, I was able to develop a REST API that can do the following:
- Get basic information about a physical object, including its borrow status and its physical properties
- Get or set any physical item property
- Borrow the item
- Return the item
- Get a list of valid media types that can be children of this object.
I would be curious to hear from others whether they see any large appeal to such an API. At this point, I’ve only invested a few days in this, but if this is something people want to see, I’m prepared to invest more time in it.