Category Archives: REST

REST API for TKL Table Management

Have you ever been asked to write a WebReport to manage tables for ADN or Attribute Extension Table Key Lookup (TKL) tables and values?  I had such a task for a client a few months back.  One of the key challenges was allowing users to add, delete, change values not just on items with TKL attributes but the values available in the TKL tables themselves.  Using “out-of-box” WebReports and LiveReports, it’s not the easiest thing in the world to write an app that can do updates to SQL tables that is both flexible (works for any possible TKL attribute), safe (not vulnerable to SQL injection), and multiplatform (works for all manner of special characters and quotes in all major databases).

In fact, I was not at all satisfied with the “out-of-box” WR app, and felt it could be done better and more cleanly if only I had an API to manage the TKL tables that is abstracted away from the Web Report. So, I wrote a REST API for TKL tables.  You have a bit of set up to do, i.e. defining any identity or logical delete fields in your tables, mapping default values for any queries, etc. but with this API, you can write a WebReport that can query TKL tables, and update the attribute values without the WR application needing to know anything about the underlying tables – all that is defined in the configuration.  Also, all the underlying SQL is done using bind variables rather than literal text, which is a safety feature against SQL injection. The calling app merely states to change/add/delete this value for this named attribute.

One obvious question would be why would a client want this. Why wouldn’t the DBA merely update the TKL tables in SQL Server Manager or JDeveloper or SQL+?  For this client, the answer is that the folks making decisions about TKL values were not DB admins and needed a business friendly way to manage the underlying tables that underpinned their metadata model.

I’d be curious to know if others see a use for such an API. So far, I’ve tested it on SQL Server 2012 and Oracle 11g for Content Server 10.0. I plan on releasing for other versions if there is sufficient interest.

REST For Content Server Physical Objects

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.

Just released : A REST API for Content Server Workflow

Today, I am happy to announce that Hugh Ferguson Consulting Ltd. is releasing our latest product: REST API Extensions for Content Server Workflow (RESTWF).  OpenText has been promoting the REST API as the new way to quickly write responsive User Interfaces.  The existing API allows for document/folder, category, and form operations. The one thing that is missing is Workflow.  With RESTWF, it is now possible to launch workflows, load tasks, upload/download attachments, read or set attributes, and read or send comments.  Although OpenText has workflow extensions on their product roadmap, they are not part of the latest 10.5 build.

In the interest of generating some comments, and soliciting feedback, here is an overview of the API. There are three main parts:

  • assignments – API to access WF assignments, and to interact with individual tasks
  • wfpackages – API to access workflow data in an assigned task such as comments, attributes, and attachments
  • workflow – API to initiate a workflow

I will be publishing the API in the coming days on the corporate website at hferguson.ca