Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved


Process Modeling Concepts : Projects, Packages and Processes

Projects, Packages and Processes
In TIBCO Business Studio there is a hierarchy consisting of project, package, and process:
Projects
TIBCO Business Studio supports the full project life cycle, bringing together all artifacts in a single place. The project is the container for these artifacts. As such, projects help to facilitate sharing and organization of resources.
For example, team members may have different responsibilities but need to use the same resources that are made available through the TIBCO Business Studio project.
You must create a project to use TIBCO Business Studio. Each project has a corresponding directory in the file system (specified when you create the project). Projects can also refer to other projects (see Project References).
Project Lifecycle
When creating a project, you can assign it a version using standard Eclipse format:
major.minor.micro.qualifier
The specified version will be the default for project artifacts such as process packages and organization models, and can be used to indicate revisions to the project. The exact use of project versions should be coordinated with the solution designer working on the project, however the following are general guidelines:
major  Incremented when the new version is incompatible with the previous version. Note that all references within a project to an organization model must be to the same major version of the model.
minor  Indicates a compatible revision.
micro  Indicates an internal change.
qualifier  Used to identify unique builds may use time format or other convention.
Consult with your solution designer to establish a common practice.
Packages
A package is a mandatory container for processes and their infrastructure (such as participants and data fields). The package and any processes stored in it are saved in XPDL format.
For example, in the insurance environment, separate packages could contain the processes used by the Claims Department, the Policy Origination/Maintenance Team and the IT Department. Processes can be shared between packages and projects so libraries of process components can be created and reused..
If the Data Fields folder is empty, it will be hidden by default. This is because the preferred usage is to define Data Fields at the Process level.
Processes
There are two types of process in TIBCO Business Studio, the business process and the pageflow process.
A business process models actual and future processes in your organization that usually involve more than one person. Business processes are short or long-lived.
A pageflow process is a short-lived process (always executed in a single sitting) designed to implement a user interface dialog. It is always executed by one person (the person that initiates the process instance).
The Process Editor provides tools on a palette that use Business Process Modeling Notation (BPMN). By creating your process this way, you can fully prepare it for implementation by a specialist in your organization.
Some objects such as business assets can be shared at the project level. Others such as data fields and participants can be created at either the package level (where they can be shared amongst processes in that package), or at the individual process level (where they can only be used by that process).
Pageflow Process Modeling
A pageflow process is a short-lived process designed to present user interface pages to the user in sequence. They are always executed by one person (the person that initiates the process instance).
All tasks that are available in a business process are available within a pageflow process with the exception of a business process user task. Pageflow processes have a special variant of a business process user task that does not have participants, and does not generate work items. These are referred to as pageflow user tasks.
A pageflow process is stored under the Processes branch of the Project Explorer alongside business processes.
For example:
In this example, the user is presented with the user interface page (in this case a form created using TIBCO Business Studio Forms) associated with pageflow user task one. When the form is submitted, the service task runs. When the service task is completed, and the user interface page associated with user task 2 is displayed. The user is not aware of the service task, and sees one form followed directly by the next one.
A user task in a pageflow process differs from a user task in a business process in several key respects:
There are also special considerations to observe when using pageflows, specifically:
Process Interface
A process interface specifies the events and their parameters that must be present in processes created using that interface. At runtime, any of the processes that implement the interface may be chosen based on data available at that time.
The use of a process interface allows the dynamic selection of sub-processes at runtime, promoting separation of the design-time and runtime environments.
A process interface consists of start events, intermediate events, and their associated formal parameters and errors.
Start Events
A process interface must have one or more start events (one is automatically created by default) that specify how a process instance is initiated.
When more than one start event is specified, a process implementing the interface can be invoked by any of the start events specified in the interface. As per BPMN, multiple separate start events are considered exclusive (each starts a new process instance).
The start event for a process interface can be of type None or Message:
If a process instance is invoked using this start event, the parameter FP1 must be specified.
Both input and output (including combined in/out) parameters can be associated with the event. Specifying output parameters means that these are the parameters should be returned when the process is invoked using this start event.
Intermediate Events
The intermediate events for a process interface can be of type None or Message:
None  Use this type of intermediate event for manual event triggering.
Message  Use this type of intermediate event for triggering using a message based interface (for example, a web service operation).
An intermediate event can be associated with input or input/output formal parameters that should be present when triggering the event, as well as with errors that will be translated into catch error end events in implementing processes.
Event Persistence
Because a process interface does not specify the intended location of the event within the flow of the process implementation, events are considered "persistent". As such, they can be triggered at any point in the process flow that is upstream of the event, or when the flow is paused waiting for the event to be triggered. For example:
The trigger for the intermediate event can be received while Task A or B is being processed, or when the flow is paused at the intermediate event waiting for the event to be triggered. In either case, Task C is not processed without an event trigger. If the trigger is received during processing of Task A or B, the trigger arrival is persisted, and the event is triggered immediately when it is reached in the flow.
Errors
TIBCO Business Studio allows you to specify errors that may be thrown by a process that implements the process interface. This is useful where:
Process Components
Process components represent reusable building blocks that encapsulate the management of a particular item in a business process. The process components form a reusable library that you can call upon in different contexts.
For example, you might have an item to "verify the caller’s address/contact details" in the business process for taking out an insurance policy. This could be implemented as a sub-process and this particular process component could be used in the context of renewing an insurance policy.
The following example shows a project and the associated packages and processes used in an insurance environment.
In this example, the Validate Policy process might call a sub-process in another package (for example, the Search Claim History process). This sub-process is in the same project in this example, but it could be located in a different project.
Process Migration
Process migration provides the ability to migrate a long running process instance from one version to another version of the same process. In other words, migrated process instances will continue execution using the new process definition.

Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved