You might not need WebReports: So when should you use WebReports

Matthew Barben
Driver Lane
Published in
9 min readAug 31, 2021

So I have spent some time talking about how you might not need WebReports — so let's talk about when you should consider using a WebReports. Now every Developer / OpenText consultant will have their own approach — and what I am outlining is an approach that we use.

It is about the layers

The examples that we have used in previous posts on this topic we have tended to focus on web-based use cases where we extend the user experience in OpenText Content Server — this post is no different.

However, in each of these posts, we have used the following diagram as a rough guide as to how to approach these problems.

The layers

Now the obvious call out here is the Smart UI. However, I would contend — even if use the Smart UI WebReport widget to surface a UI customisation that you limit the actual WebReport tags functionality to the data layer.

Where I have seen WebReport solutions fail is when they do two things:

  • Using WebReports higher up the stack from the data layer into the business layer and the presentation layer
  • Replacing existing REST API with a bespoke array of WebReports (this approach suffers at scale).

Now there may be occasions where you are forced to have a WebReport move up the layers — but more often than not if you stick to this approach the outcome should be more resilient.

The Setup

To demonstrate this approach we are going to create a Form that will perform the following:

  • Create a connected workspace and populate it with Metadata
  • Register the Form along with the location of the workspace into the Content Server database.

Supporting Materials — Category

The category design will have three fields:

  • Category — which will be a database lookup
  • Sub Category — which will be a database lookup dependent on the Category
  • And Subject
The category that we will be using

Supporting Materials — Workspace

Using this (and some other materials e.g. classification) we can then define our workspace type.

Workspace Configuration

And the Workspace Template

Workspace Template

Supporting Materials — Form Template to capture entries

Next, we will create a basic form to capture the results of the user's input. To do this we will start with a Form Template to capture the following fields:

  • Category
  • Sub-Category
  • Subject
  • Workspace ID
Form Template that we will use

With the template created, we will want entries to be stored in the Content Server database. To do this we use the Manage Relational Table function.

Selecting Manage Relational Table

And select our database

Creating a database table.

Supporting Materials — Form for submitting entries

Finally, to complete our initial setup we will create our Form. We will use this to submit new entries into the database. For now, we are not creating a view — this will be done later once we have created our WebReport.

Creating a form from our Template
Selecting submission mechanism of SQL
And creating our form.

Let's make a WebReport

At a high level I plan for my form to use two WebReports:

  • that returns the metadata for the form
  • returns the node ids in the Content Server environment that I will need to make the REST API calls that I will need to use.

Metadata WebReport

This report will return the category and its related subcategory in one JSON message that will be consumed by the form.

There are many ways to cut this report, my approach for these ones is to start simple and build complexity on top. With this in mind we have two LiveReports:

  • One that returns all the categories
LiveReport returning Category Values
  • Once that returns the subcategories for a given category
LiveReport returning Subcategory values for a given category

Next, we will wrap a WebReport around these LiveReports

Sub-Category WebReport
Category WebReport

In this use case — as these attribute values are not constantly changing (and therefore static) my plan is to:

  • Create a WebReport that returns all of the category and subcategories that are related
  • Export the resulting JSON to a location that can be accessed by the form

Now running this report will return a value

Running WebReports returns value

Now that this report returns static values, so instead of using the REST API to access the WebReport directly, we can simply serve this JSON as a static asset.

The Support Asset Volume has been around since 16.2.10 of Content Server (September 2019), To use it you will need to make sure that you have configured the virtual folders on your webserver and pointed it to the right location.

To configure a location, browse Support Asset Volume and create a Support Asset Folder

Create a support asset folder
Our support asset folder is created

!!! Limitation Alert !!!

At the time of writing, you are not able to export a WebReport as a node in the Support Asset Volume 😥😥

No export to Support Asset Volume as a document

What about a version? No…..but also yes 😕😕. Firstly, I create two empty JSON files on my computer:

  • businessrequest.json — this will store the metadata information
  • constants.json — this will contain the various nodes that I will need to make my REST API requests

With those created, we create two Support Assets in a Support Asset Folder

Placeholder JSON files in our Support Asset Folder

Next if we go to our WebReport destination tab and select Content Server Version we find we cannot select the dummy files.

Not able to select documents to add a version
What gives!?

Ah — but we have constants. To work around this add the target JSON file as a constant to the WebReport.

Add the TargetJSON as a constant

Next in the destination tab, instead of browsing to the object in Content Server we instead use the [LL_REPTAG_$TargetJSON /] value.

Use the constant value instead of browsing for the node FTW

And now running this, we can see the version being added

Version successfully added

Testing this node via PostMan yields a correct JSON response 😁😁😁

Configuration WebReport

The configuration WebReport is produced in the same way — however in this case we will output the static constants that we will need to create our workspace namely:

  • Parent id — where we will be creating the workspace
  • Type — which in this case will be 848
  • The workspace type id, you can do this by browsing to the Workspace Type in the Connected Workspace configuration screens
  • and the template id — the id of the workspace that we are using to create.

Replaying the same steps we have out two static json files exported.

The constants.json file

Create a Form View and bring it all together

Before we start — given that we are doing this on a new install of Content Server there is one new WebReport dependency that we will need to discuss.

For new installs, the good old LLCookie is now an HTTP-only cookie. What this means is that it is no longer able to be accessed via JavaScript. To work around this we will break our cardinal rule and use a WR Power View.

Create a WR Power View
Name the View

Now instead of querying the LLCookie value we can use the `[LL_REPTAG_OTCSTICKET /]` tag in our WR Power View

Adding out OTCS Ticket value to our WebReport

However all the other logic, JSON values will be served statically. And using the HTML from my previous post I can tidy up the form.

Form with using the style enhancements from my previous post

The next thing we need to do is to change the input elements to select elements (to enable dropdown).

So we change this

<INPUT class="valueEditable dlvalidate" TYPE="text" NAME="_1_1_2_1" TITLE="Category" ID="_1_1_2_1" VALUE="[LL_FormTag_1_1_2_1 /]" SIZE="32" MAXLENGTH="32" ONCHANGE="markDirty();">

To something like this:

<select class="valueEditable dlvalidate binf-form-control" NAME="_1_1_2_1" TITLE="Category" ID="_1_1_2_1">
<option>Select Category</option>
</select>
Changed Inputs to selects

Bring in the static resources and populate dropdowns

Using an AJAX call I can bring in the static assets and populate the dropdowns and add the business logic.

We will upload this to our support folder as well

JavaScript in the support folder

And add a reference to the view, and now we have some dependent dropdowns

Dropdowns are now loading WebReport data

Add submit logic

Now that we have all the information that we require available on the screen we can go ahead and create out workspace creation logic and wire it up to the submit button.

Example of the final result

And maintaining the control of the business logic that I also retain a record of the entry.

Wrapping up

If there is one takeaway — if you have static values, assets (CSS, or javascript files) you should really be making use of the Support Asset Volume (knowing that many customers are still hosting their own content in the support volume).

It will mean that:

  • You can develop independently of Content Server (given that you only need to serve in a static resource).
  • It is performant (no API handshake or overhead)
  • And it will scale with the many nodes in your Content Server cluster (so you could deploy it to an OT Cloud-based Content Server)

Yes, it is becoming increasingly hard to avoid WebReports — however, with the right approach you can save some of the worse problems of WebReports and create more robust solutions.

Connect with Driver Lane on Twitter, and LinkedIn, or directly on our website.

--

--