The OpenText Process Suite ABC Glossary - Collaborative Workspace #2

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:

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

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:

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 

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