Content Intelligence changes: Content Suite versions 22.1 to 23.1
This is the first time we’ve added a blog reviewing Content Intelligence changes in the quarterly Content Suite updates. As there isn’t value in re-stating the release notes, this is a commentary based on our observations and discoveries related to undocumented changes, or any issues we’ve found. Given that this is inherently selective, we decided to base this blog on a year’s worth of updates from 22.1 to 23.1, with a few references to changes prior to 22.1.
This is obviously not all encompassing, so if you find anything we’ve missed, please leave us a comment on LinkedIn or get in touch.
Application Management changes
Several changes have occurred to CSApps (application management). These are largely driven by a need to adapt CSApps to cloud deployments, particularly as some partners are trying to deploy CSApps for use in the OpenText ECM cloud product. These changes will only impact customers and partners who use this part of Content Intelligence, but it is interesting to see this WebReports companion getting some overdue attention. If you want a refresher on this functionality, read our blog explaining CSApps or our blog explaining the difference between CSApps and Transport.
One minor change we noticed (this was a gotcha for us) in version 22.3, the application management URL changed to ?func=csapps.ApplicationsManagement from ?func=csapps.ApplicationManagement.
On a related note, as of 22.4, there are REST requests available for some CSApp API functions, specifically:
POST | api/v2/csapplications/install
POST | api/v2/csapplications/uninstall
POST | api/v2/csapplications/delete
POST | api/v2/csapplications/upgrade
In version 22.3, there was a large change to the way that “support files” are handled for applications. By support files, we mean: images, javascript files, and other pieces that will primarily be used in the client (browser). These files have traditionally been stored under the file system: ./support folder (as with all other Content Server files of this type), specifically under/support/csapplications/<appname>. Starting with this version, support files for CSApps are now stored under the support asset volume.
This new feature will still handle any CSApps that were built with support files on the file system (under ./support), but you can no longer build a new app with support files directly stored on the file system. Also, if you rebuild an app under the new version, it will actually convert to the new system by moving any support files to the support asset volume. It will also edit your source code to change any APPSUPPORTDIR tag references to SUPPORTASSETDIR.
From the CSApp re-build page:
“Defining Support Files and Support Paths has been deprecated.
If your application uses any custom support files not in the Content Server build, they should be contained within a Support Asset Folder for your application within the Support Asset Volume.
Add the Support Asset Folder to the Content Server Source Objects section above.
The name of the Support Asset Folder must match the name of your application.
Support files in the Support Asset Folder can be accessed from an ActiveView or WebReport using the tag [LL_REPTAG_SUPPORTASSETDIR /].
Rebuilding the application will update any WebReports and ActiveViews in the application to use [LL_REPTAG_SUPPORTASSETDIR /] instead of [LL_REPTAG_APPSUPPORTDIR /].
All of the application's support files will be copied to the application's Support Asset Folder in the Support Asset Volume.”
Besides support files, .property files (for language labels) have also been relocated from the file system to a sub-folder of the main support asset folder (called properties).
If you look at one of these new CSApps, there are now two xml files created by the “Build Application” option: the original xml file that includes all of the CS objects, and now a second .xml file with _ SupportAssets appended to the name. This second file contains any support files that are now added as objects to Content Server. Note that the support asset system is designed to copy these files to the file system automatically under the ./appdata/supportasset folder. Support files for CSApps will further be stored under a folder named with the CSApp name.
Overall, this change is a good one, but this automatic conversion may not be desirable in all cases. To provide our own negative use case, we are building apps that we want to work on versions from 2020 to 2023 (potentially further back than that too). The support asset feature was deployed in 21.3 so any prior releases will not have the appData – Support Asset functionality. If our support files have been moved to the support asset volume then our CSApps will not work on these earlier versions. As we don’t want to maintain two different versions of our applications, we have to build them on 21.3 to create a version that works backwards and forwards in terms of software release numbers.
But wait, there’s more!
In version 23.1, the whole CS Application Management was given a long overdue facelift. This new interface is nice looking, and offers a slightly different paradigm (menus rather than multiple checkboxes) that is mostly a great improvement (though the columns may not line up on smaller screens). Perhaps more importantly, this screen doesn’t suffer from the long loading delays of the old interface. So far, the only issue we’ve seen with these changes is that CSApps that do not include any Content Server objects will not be installable. This might seem unimportant, but in one of our use cases we have a CSApp with a suite of sub-tags but no Content Server objects. As of version 23.1, this app cannot be installed. We have reported this to OpenText, but a workaround in the meantime is to manually add a CSCOMPONENTS section to the manifest file.
Changes to Constants
As of version 22.3, a couple of changes were made to WebReport Constants.
Firstly, the concept of a “secure constant” was created. The purpose of this (and the only one as far as I know) is to “store secret data that you can use with the LL_WEBREPORT_RESTCLIENT tag in either a WebReport or an ActiveView.” Once you define one of these constants you can use them in the RESTCLIENT tag using a { {constname} } syntax. To define these constants, you need to use the WebReports administration pages, and the “Manage Secure Constants” section is pretty self explanatory.
Note that you have to specifically assign these constants to one or more WebReport or ActiveView nodes from this Admin section. This is a different approach from normal constants where you assign constants from the specific WebReport; however, the normal Constants tab will show any secure constants that have been assigned.
In addition to this change in 22.3, there were also changes made to the normal Constants tab to aid in detecting duplicate constants that could occur when Global Constant files contain constant names that may also be defined in the Constants tab of a WebReport that is referencing the Global Constant file. This is a useful feature (and one that we’ve had in our Application Analyzer for a year or so), but it does not take account of duplication through inherited constants. This is not surprising as it is not possible to to see inherited constants without identifying the full tree of Sub-WebReport calls. Our Application Analyzer does identify inherited constants as we also include a feature that builds all of the relationships between WebReports and Sub-WebReports. Another feature provided by the Application Analyzer (that is not in the OpenText enhancement) is the ability to detect where there are constants with duplicate values, i.e. constants with different names that are pointing to the same object or string.
User interface improvements
Besides the previously mentioned improvements to the Application Management interface, one major improvement in version 22.3 is the addition of a “diff” (compare) tool to the WebReports editor.
This is also a feature that we’ve had in the Application Analyzer editor for more than a year so we were interested to see how this tool matched up to our version. While we’re impressed with the graphics in the OpenText diff tool, particularly in terms of connecting changes between the two views, our tool has better precision in terms of identifying the exact point on a line of code where a difference occurs. Either way, a compare tool is an important tool for any editor and is a good addition to the WebReports editor.
Tags and sub-tags
We’re not going to list the various new tags or sub-tags as they have been well documented in the various release notes; however, we can say at a high level, that functionality has been created to extend Information Governance and Protection features (RM, PO, etc.). This includes a new WebReports trigger for a “finalized record,” that includes new TRIGGER tags.
Are there any issues?
We mentioned above a minor issue with the CSApps enhancements, but in addition to this issue, another byproduct of the new CSApp work we’ve described above is a trace log issue in version 22.3. (This has been raised with OpenText by Kinematik who shared this with us).
This trace occurs on install of a CS application that contains
- An ActiveView with an ActiveView override enabled
- App must also have at least one file in support Assets
There are also patches available to fix this problem in this and subsequent versions, as follows:
Here’s another (less serious) issue we found in version 23.1:
This issue only occurs if you’re working with the builder (Eclipse) environment.
When using Eclipse, multiple temporary objects do not get created. As an example of the impact of this, no ActiveView overrides will be available when running with Eclipse. There are several other issues this can create, but this is the first symptom that we noticed.
What features have you found the most helpful in these releases? Tell us over on LinkedIn. Also, if you’ve discovered any interesting changes we’ve missed, let us know!
About the author
