The OpenText Process Suite ABC Glossary - Business Process Model

Business Process Model

A business process model is a structured and measured set of activities designed to produce a specific output for a particular customer or market. It implies a strong emphasis on how work is done within an organisation. In contrast to a product focus’s emphasis, a process is thus a specific ordering of work activities across time and space, with a clear beginning and an end, as well as clearly defined inputs and outputs.

BPMN

The OpenText Process Suite (OTPS) platform includes a graphical editor to empower you to design business process models using BPMN (Business Process Model and Notation). This is a visual process notation standard from the OMG (Object Management Group) and endorsed by WfMC (Workflow Management Coalition), and broadly adopted across the industry. The BPMN standard defines the look of how the process definition is displayed on the screen. With the OTPS platform, you use the CWS (Collaborative WorkSpace) to both design the graphical business process model as well as implement the model and the different activities you have included in the model through web services, user interfaces, other process or other components. The implementation of a process is proprietary to the OTPS platform.

BPML

While you are designing and implementing your process model(s), you can validate, build and publish the process to test run the execution of your process. When building and publishing, the process design and implementation is translated into BPML (Business Process Modeling Language). BPML is used to represent the executable version of the process and can be run in the BPMS (Business Process Management Suite of the OTPS platform). When you run your process model, the system creates a process instance that can be administered by means of the PIM (Process Instance Manager)   artifact and/or monitored by means of the BAM (Business Activity Monitoring) capability of the OTPS platform.

While developing a process model, you can use different components to implement the activities modelled in the process, such as web service operations to connect to the available application systems or data sources, user interfaces to communicate to the users of the process, other processes used as sub-processes here, decision tables to structure the decision logic in the process, case models, etc. At any moment during development, you can validate, build and test run the process and use the PIM  artifact to exactly follow what has happened during execution of the process. The PIM illustrates the execution by means of a graphical view of the flow of the process model, and you can verify the complete execution path as all the process instances and their activities listed in the PIM overview:

An important property of the process model is the process execution mode defining whether the process is execution as long lived or short lived. When the process contains any kind of human interaction represented as a task in the process, the process is long lived and will run asynchronously. This means that as soon as the task in the process flow is reached, the task is added to a task queue and distributed to the associated users and the process instance is paused until the task is completed. A task represents any work that needs to be executed by any of the participant user(s) of the process. Long lived process instances are executed by multiple threads of the process engine. As soon as a task is reached the process engine will free the associated thread and assign it to another process instance. By default the process execution mode is initially set to long lived.

When the process does not contain any task oriented activity, you can define the process as short lived, in this case the process will run synchronously, from start to end and in a very short time with optimised process behaviour. The complete process flow in contrast to long lived processes is not saved in the PIM, only the completion of process. The process engine executes a short lived process instance by a single thread and completes the process in very short time, with respect to the maximum limit of time (30 seconds) defined by the default time-out property set with the OTPS platform. Short lived processes are typically applied with processes only including system interaction or processes with no human interaction other than delivering a message to the user(s) involved but not waiting for any response from the user(s).

With the OpenText Process Suite (OTPS) platform, application design starts with the design of the business process model(s) that are used as a starting point for the developer to implement the activities that have been modelled in the process. This is all done within the context of a project as defined in the CWS, when development is completed (or reached a certain level of maturity) the project is packaged into a CAP (Cordys Application Package) file and deployed on any next OTPS platform instance that is used as Test, Acceptance or Production environment.

The OpenText Process Suite ABC Glossary contains a description of the important keywords and concepts of the OpenText Process Suite (OTPS) platform. It is not meant to be a complete list but can help you to master and comprehend the most important concepts and technologies of the OTPS platform. You can also find a list of abbreviations below that are used with the descriptions of the listed keywords. 

List of abbreviations 

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