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
|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|
|IDE||Integrated Development Environment|
|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|
|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!