The convedo Tech Talk Blog

The OpenText Process Suite ABC Glossary - Collaborative Workspace #2

Written by Sascha Cutura | 21 October 2015

Collaborative Workspace

Whenever you are developing components with the OTPS platform, you need to build and publish them first to the run-time environment of the OTPS platform in order to be able to test run them.

When you prepare the workspace for development, you need to create a folder structure that accommodates for both the development of the application as well as its deployment. While deploying the application, you have to make sure that the run-time components of the application do not clash (i.e. have exactly the same kind of name and deployment path) with other components already deployed in the run-time environment by other applications. If they do clash, the newly deployed components overwrite the existing ones, which effectively makes the other applications unable to run.

As a guideline, the first folder level in the project will start with the name of the type of component that you are developing, e.g. Case Models, Business Process Models, User Interfaces, etc. At this level you set the property Start Point of Qualified Name. The next sub folder levels typically start with the name of the domain, the name of the company or organisation for which the application is developed, and at the bottom level, the name of the application, e.g. com \ convedo \ demoappl. At the bottom level, you create the actual components itself, e.g. MyFirstProcess. Whenever build and publish the components, they are identified by their fully qualified name, which should make them unique. For example, with reference to the examples described here, the run-time process definition will be identified by: com.convedo.demoappl.MyFirstProcess. You can compare this with the next illustration of the DemoWorkspace:

To have different developers work and collaborate on the same project (i.e. application), you relate the workspace to a SCM (Software Configuration Management) system. The OTPS platform only supports SVN (Subversion) repositories. In a preferred scenario, each developer will work in a separate organisation and have their own workspace containing a copy of the developed contents and use the SVN repository to exchange the components that they develop and implement. This allows the developers to develop and publish whatever they wish within their own copy of the workspace, and when satisfied they can exchange the contents to and from the other developers. For this purpose the workspace toolbar contains two options:

      1. Incorporate changes from others

To copy and update the components that are stored into the associated SVN repository by the other developer(s) into the current workspace.

      2. Make changes available to others

To copy the changes of the current workspace to the associated SVN repository and makes these available to the other developers as well.

Any of the two options will prepare a list of components that will be created, updated or deleted from the current workspace (option 1) or in the associated SVN repository (option 2).

 

When you open the CWS by means of the Workspace Documents  artifact, it reads the Workspace contents from the OTPS CWS system repository. Whenever you save a component that you are working on, the definition of the component is saved in this repository. In the workspace you have the Synchronize option in the toolbar to synchronize the complete contents of the workspace to the file system of the OpenText Process Suite (OTPS) platform instance. The file system of the OTPS platform is also to exchange the contents between the SVN repository and the contents of the workspace that is saved in the OTPS CWS system repository. This means that you can have copies of the source of the application in different locations:

        1. Always in the OTPS CWS system repository.
        2. In the SVN repository (if workspace is related to an SVN repository).
        3. At the local file system of the OpenText Process Suite platform instance. You will find this in the OTPS install directory: \ cws \ sync folder. Refer to the topic File System for more details folders and files available at the file system of the OTPS platform server.

The CWS facilitates the developer with developing and testing the application and all the components to make the process executable. From the workspace, the developer can validate, build a single or number of components to generate the run‑time version and publish these to the run‑time environment to test their application. Once an application is deployed, you can reuse some of the components, processes, web services, user interfaces, etc. deployed by referring to these by means of run‑time references. This is how you can reuse components already deployed. Note that this creates a dependency between the applications, and when you want to deploy the application, the referenced components need to be deployed as well.

List of abbreviations 

Abbreviation Description
 ANSI  American National Standards Institute
 BAM  Business Activity Monitoring
 BER  Business Event Response
 BPML  Business Process Modeling Language
 BPMN   Business Process Modeling Notation
 BPMS   Business Process Management Suite (or System)
 CAL   Composite Application Logging (framework)
 CAP  Cordys / Composite Application Package (file extension)
 CARS  Cordys Admin Repository Server
 CMC   Cordys Management Console
 CWS  Collaborative Work Space
 DTAP   Development, Testing, Acceptance and Production
 ESB   Enterprise Service Bus
 HW   HardWare
 IDE   Integrated Development Environment
 IP   Internet Protocol
 JVM   Java Virtual Machine
 KPI   Key Performance Indicator
 LDAP   Lightweight Directory Access Protocol
 OMG   Object Management Group
 OTPS   OpenText Process Suite
 PIM   Process Instance Manager
 PMO   Process Monitoring Object
 RDBMS   Relational DataBase Management System
 SCM   Software Configuration Management
 SCXML   State Chart XML
 SOA   Services Oriented Architecture
 SOAP   Simple Object Access Protocol
 SSU   State Sync-Up
 SVN   SubVersioN
 SW   SoftWare
 WfMC   Workflow Management Coalition
 WSDL   Web Service Definition Language
 XML   eXtensible Mark-up Language
 XPDL   XML Process Definition Language

 

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