The OpenText Process Suite ABC Glossary - File System part 2

File System

OTPS platform instance at file system

When installing the OTPS platform baseline (step 2 in the previous blog), the appropriate folder structure is created at the file system of the server, starting from the level you specified as the folder where to install the OTPS baseline. Refer to the above mentioned folder locations with Windows and Linux.

During installation of the baseline, all logging information is saved in the folder install_log. The file “Process Platform installation.log” contains an overview of the logging details saved during the installation process. When running the OTPS platform instance, all logging is saved in the folder Logs, which is used by de Composite Application Logging (CAL) framework for storing the log files and appending log messages to these files. Refer to the topic: CAL for more details on Composite Application Logging.

While running the OTPS platform instance, you have to ensure that the file system of the OTPS platform instance has enough space to accommodate for the files and growth of these files. As described the OTPS platform instance keeps log files in the Logs folder. By default, each next day a new log file is created to store the logs for that day, and the old log file is closed and saved with the date appended to its name. You need to make sure that these log files are regularly deleted and saved in another storage medium as these consume the space from the file system.

When the OpenText Process Suite platform instance is used as a development server, you will have an additional folder cws in the installation folder. Developers are working on the development of an application in a collaborative workspace (cws), hence the folder name. The cws folder contains two sub folders that both contain an additional sub folder level reflecting the different organisations that are created and managed within the OTPS platform instance:

• The build folder, contains the packaged application when packaging the application from the workspace. The application package will be deployed on a next OTPS server for test, acceptance and after the application is accepted by a number of key users, deployed at the production server.

• The sync folder, is used to exchange the development work of a team of developers through a shared SVN repository. Additionally, the sync folder facilitates the developers to use any kind of external editor to modify the file contents of the components and synchronise the updated contents back into the workspace again. For example, use the Eclipse Java IDE (Integrated Development Environment) to modify the Java source code at the file system and synchronise the updated source files with the collaborative workspace contents.

• File system organisational contents

  As described before, in the preferred scenario the developers work in the context of their own organisation, and components are published and tested only at the organisational level. As they have their own copy of the developed contents of the application, each developer modifies only the contents of  their copy of the workspace. This allows them to straightforwardly collaborate in the development of the application, initially developing and testing the modified contents in their copy. When tested to correct functioning they can make their contents available to the others, and vice versa, incorporate the changes from others in their own copy of the workspace. The Collaborative WorkSpace (CWS) feature of the OTPS platform is tightly integrated with the SubVersion source configuration management software.

  When deploying an application, you can use the Application Deployer artifact from the System organisation. You must have system administrative authorisation to be able to deploy from system. This makes the application generally available to each of the organisations as defined with the OTPS platform instance. In this case the application is deployed in the so-called shared space.

  Alternatively, you can only deploy the application with a single organisation by running the Application Deployer  artifact within the context of the organisation. You must have the organisational administrator role for this. This is called organisational level deployment, typically when developing or customising an application for a single organisation.

List of abbreviations 

Don't miss out on future blog posts! Subscribe to email updates today!