You might not need WebReports: So when should you use WebReports
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.
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
Supporting Materials — Workspace
Using this (and some other materials e.g. classification) we can then define our workspace type.
And the 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
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.
And select our database
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.
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
- Once that returns the subcategories for a given category
Next, we will wrap a WebReport around these LiveReports
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
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
!!! Limitation Alert !!!
At the time of writing, you are not able to export a WebReport as a node in the Support Asset Volume 😥😥
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
Next if we go to our WebReport destination tab and select Content Server Version we find we cannot select the dummy files.
Ah — but we have constants. To work around this add the target JSON file as a constant to the WebReport.
Next in the destination tab, instead of browsing to the object in Content Server we instead use the [LL_REPTAG_$TargetJSON /] value.
And now running this, we can see the version being 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.
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.
Now instead of querying the LLCookie value we can use the `[LL_REPTAG_OTCSTICKET /]` tag in our WR Power View
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.
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>
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
And add a reference to the view, and now we have some dependent dropdowns
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.
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.
