Should I use CSApps or Transport for my WebReports?

Did you know that Content Server Applications Management (CSApps) and Content Server Transport don’t actually do the same thing? Or maybe you didn’t know CSApps is a thing, period? Either way, you’re in good company. It’s a commonly held assumption among Content Server users that these two products compete with each other, but the truth is that they’re not mutually exclusive. As one of the original developers of the CSApps product, and as someone who was party to the origin story for Transport, I’ll explain what they’re both for, and how they complement each other.

In a previous blog from 2021 about building Content Intelligence Apps with CSApps, I bemoaned the fact that CSApps seems to be a well-kept secret. During some customer conversations at OpenText World 2022 in October I became aware that this is likely still the case. The reason for this is that users don’t understand what CSApps does and when to use it. The flip side is that customers believe Transport replaces CSApps and by extension that they are mutually exclusive. Some partners and customers are not even aware of CSApps, which evolved to its current form around 2012, having been through multiple iterations as LiveApps, WebApps, RKTApps and finally CSApps. All of these variants were shared with our (Resonate) customers. 

The reality is that there’s a time and place for each of these products. While they have some overlap in functionality, CSApps and Transport use slightly different approaches to manage the transport of objects and are aimed at different use cases. I’ll touch on some of those use cases but first, here’s an explanation of each product: 

Transport is designed to move any Content Server objects, including WebReports, from one Content Server system to another. Moving objects is a relatively simple operation, but what makes it more complicated is that some of these objects have references to other objects being transported, which are vital to maintain. These dependencies use numeric "IDs" that are completely unique within an instance of Content Server. Unfortunately, the assignment of IDs on each Content Server system is completely different, thus moving objects to another system also has to manage the conversion of any ID references to the correct IDs on the new system. Transport provides a new approach to managing this problem.  

CSApps is part of the WebReports module and is designed to manage all of the requirements of Content Server based applications. An application in this context can be defined as any group of files, settings, and Content Server objects that collectively provide new functionality on Content Server.  Because the application includes objects such as WebReports, part of the CSApps functionality is also designed to aid in moving objects between systems. The CSApps software leverages some of the same code as Transport but uses an older approach to managing data ID dependencies. This is the part that overlaps with Transport, but besides this overlap, there are many other features that are not part of the Transport functionality, and that are designed to manage the various other requirements of a CS Application.  

To help with the distinction, it is worth noting that a typical application will have unique client code (for example, JavaScript libraries), along with items like custom sub-tags, language property files, and combinations of ActiveViews, Perspectives, Workflows, and forms, all interacting with WebReports to solve some unique business problems.

As you can imagine from this list of requirements, even a basic application is likely to have a variety of requirements besides object movement. Our aforementioned blog provides a thorough review of CSApps but here are some of its key features:

• Automatic application versioning, naming and descriptions captured in  a “manifest list” that catalogues all files, objects and settings. 
• Unique application-centric nicknames and special URLS to launch the application using a designated WebReport. 
• Initialization setting: runs a designated WebReport to perform setup tasks during installation. 
• Application property files to handle different language labels (using the APPPROPERTY sub-tag). 
• Installation and management of any custom sub-tags. 
• Client libraries, and image file management and packaging (installed along with the objects). 
• Automatic settings for ActiveViews and/or system INI settings. 
• Management of dependencies on modules and specific tag requirements. 

So if CSApps handles object movement, and provides all of these application specific functions, why use Transport or other products to move objects? 

In some cases you CAN use CSApps as a single holistic solution. The CSApps module doesn’t actually provide any unique transport code as it is simply using core functionality to export/import objects along with a basic framework for managing dependencies. Transport uses some of the same code, but Transport has added a new layer of code to manage dependencies that makes object movement more flexible and better able to resolve any missing dependencies on the target system.  

Here are some scenarios where Transport would be preferable to move application objects:

• Business workspace usage (particularly with Perspectives) can create some circular dependencies that can’t necessarily be managed by the code behind CSApps. 
• Where there is more than one destination folder or volume required. E.g. new style Perspectives need to go in the Perspective volume.
• Applications with any new objects (last 5-10 years) that have dependencies. 
• Imported objects that require decisions to be made pre-import such as selecting particular users and groups. 

So, if we’re using Transport to move an application, how can we use both products to complement each other — essentially have our cake and eat it too? 

At Ravenblack, we’re working on features within our Application Analyzer (WebReports IDE) to make it easier to create a CS Application that works in conjunction with Transport or other deployment technologies. In the meantime, we recommend that for any application on any system, even if you used Transport to install objects, you should also create a CSApp to define all of the objects, support files, property files, sub-tags, settings, etc. Apart from the previously mentioned benefits, this provides a place to identify all of the pieces that make up an application, in a single collection so that support personnel or developers can easily find any pieces that need enhancement or fixing.  

To learn more about CSApps, watch this video demonstration of some common application examples on our Ravenblack YouTube channel.