[Deep Dive] WebReports Applications and Performance Concerns - Part 1

So far, most of the blogs we’ve posted have been very pro Content Intelligence (WebReports). However, we are now going to talk about some of the problems that WebReports customers may experience. More importantly, we’ll discuss how Ravenblack can help you to avoid these problems or remedy them. 

This blog is specifically going to touch on the area of performance. 

Some background 

One of the things that I believe made the WebReports suite of tools so successful was our basic approach to designing this product. We were building a business-friendly tool, somewhat in the model of existing products like Content Server WebForms and Content Server Workflow. That is to say, we created a system where non-developers could put together a working application. We saw it as providing similar business flexibility to these products but on the reporting side of the equation.  What we discovered early on was that reporting capability translated into presentation and UI opportunities. We were soon in a position to address a multitude of application requirements that would otherwise have been done with OScript modules. 

The problem with this technical expansion is that we had to make a decision between staying in the limited box of business user tools or allowing our customers enough flexibility to build powerful applications that could potentially be detrimental to overall system performance.  Typically, OpenText has a fairly  black and white approach to customization and configuration. On the one hand you have a very locked down capability where you can select a few options that might affect some visual or behavioral options. On the other, you have OScript modules where anything goes and developers can pretty much access any software in the system in any way they want. Essentially, there really aren’t any enforced rules. (Note that REST API and SmartView and their relative merits will be discussed in a future blog.)

Ultimately we chose to maintain an architecture that still had appeal to non-developers, but had enough flexibility to provide a viable alternative to OScript modules. The most important distinction that we provided was a very well defined interface to all of the functionality that we were presenting to customers.  This meant that for each upgrade of Content Server, most of the responsibility to ensure that developed applications still worked on a new release was handled by the WebReports development team.  As our customers started to realize that their WebReports based applications were easier to port to new software releases, the popularity of this approach grew and we continued to encourage it. We then also enabled our customers and developers to write pure OScript for situations where the tag paradigm was awkward or limiting while still maintaining the strict API.  

There are a few features of WebReports that can trip up developers or possibly make it easier for them to create performance problems. For this purpose, I’ve described  some of the features of WebReports that are designed to reduce performance issues and some of the features that can cause problems if misused. You can download it below in this handy PDF.

We at Ravenblack can help with pre-design or adaptive design considering things like application logic or code optimization. Contact us today to take advantage of any and all features that could help you with performance and any other areas of concern.