You might not need WebReports — an introduction
Opentext Content Server (OTCS) is a document/record management application — it comes with a bunch of practical functionality that makes getting off the ground with basic compliance pretty simple. It does the basic stuff right (opening documents, version management, auditing, and compliance). But once you get beyond the basic use cases where configuration does si where you need to do some customisation— which is why you are here today. In this series I am looking at one of those methods of customisation that has grown in popularity in the OTCS sphere — WebReports.
In the past, changes to the UI or a workflow would be the domain of Oscript (a proprietary script and compile language for Content Server). But then came WebReports' which allowed end-users to start hacking are the edges to better hone the UI and UX experience that Content Server has to offer.
Over the last couple of years, we have Content Server product has matured — a new interface is now available (Smart UI) which is based on more modern web application patterns with a REST API layer which opens up new ways to enhance the UI and UX of the Content Server solution meaning that we are now at a point where you can reasonably ask… You might not need WebReports.
So in this series, I want to run through some use cases based upon real-life examples scenarios which hopefully better showcase some of the features and approaches that would have originally warranted WebReports — but instead could be done without. It is not definitive, but hopefully, it will give you a flavor for what is possible.
So what do WebReports do?
WebReport acts like a presentation layer for data that exists with Content Server. Now by itself that does sound like much, but in its simplicity comes its power.
What this means is that you can now present your content server data as:
- JSON, XML
- Microsoft Office (Word, Excel, RTF, CSV
- HTML
This is pretty cool — and in the hands of some crafty people, some amazing things can be done with this.
Where things get unstuck
So you have this tool which enables you to do some incredible things, what could possibly go wrong. In a lot of cases, nothing at all — everything will just tick along without anyone noticing.
But is important to most appropriate tool for the job. And in evaluating WebReports
- Does it exist in the product already? If you creating a custom solution using WebReports that extends the OpenText offering, the risk, and cost of supporting this is on you — not on OpenText. Conversely, if you use a standard offering (even if it is an API provided by OpenText) and something breaks — you at least have a recourse to go back to OpenText and ask them to fix their API.
- Does this need to scale (how many transactions would it need to process)? This is important as you might be introducing a flaw into your design which will make the overall solution less performant.
- Concurrency how many times concurrently will need to run? This ties into your scaling issue. WebReports are a “one and done” affair. That means that there is no replay, it runs one and if it does not get the data in time there might be some unexpected results.
- And how much technical debt are you introducing by using WebReports? A classic example is nesting sub-WebReports — how is that documented, if a new consultant comes along, will they be able to readily understand the context and the way that WebReport was supposed to be run.
- How maintainable is it? This last one is a bit of a catch-all. Can your IT support HTML and JavaScript? (I would hope so) How about nested web reports intertwined with WebReports? Will an upgrade of your system break WebReports?
There is a lot to consider here — but simply put we always try for a product (and therefore API) first approach.
Coming up in the next few weeks …
So over the next few weeks, I want to compile together real-life use cases where the temptation is to use WebReports is real, but not always appropriate.
In the next episode, I will take you through a basic Workflow / WebReport trap involving attachments.
