Properties are used to define configuration. Depending on where and how they are defined and qualified, properties can be classified into
application properties, module properties, shared module properties, and process properties. The values for all three kinds of properties can be of one of the six primitive types (Boolean, Integer, DateTime, Long, Password, or String) or one of the available default shared resource type. These values are static and cannot be changed once an application has started execution. These values can only be changed at design time or deployment time.
The three levels of properties are hierarchical: application properties are in the outer most scope, followed by module properties, followed by process properties.
Properties defined in the inner layer can reference a property defined at its parent layer. For example, a process property can reference a module property instead of providing a literal value. Similarly, a module property value can be defined by literal values or source from its parent scope application property. Private properties are not visible to the encapsulating layers.
Any process property or module property that you define is available both in the activity configuration page and is also available to use as an input to an activity (from the
Data Source tab of the
Input tab for the activity).
The following diagram illustrates the relationship between the different types of properties:
Relationship Between Properties
Features of Process, Module, Shared Module, and Application Properties
|
Scope/Visibility
|
Values
|
Additional Information
|
Process Properties
|
Visible within a process.
|
Literal, module property reference, or a shared resource reference.
|
Literal values cannot be modified at the module or application level.
|
Module Properties
|
- Visible within the module.
|
- Literal or a shared resource reference.
|
Cannot be assigned to an activity directly. You need to reference a module property from a process property, and then reference the process property from the activity.
|
Shared Module Properties
|
- Visible within the module.
- Visible within projects that contain dependencies to the Shared Module that the Shared Module Property came from.
|
- Literal or a shared resource reference.
|
- Shared Module Properties are module properties that come from a Shared Module.
- Cannot be assigned to an activity directly. You need to reference a module property from a process property, and then reference the process property from the activity.
- Can be used for activities, process properties, shared resources, and SOAP Bindings.
|
Application Properties
|
- Only available for an application and visible within the application.
|
- Literal.
- Profiles can be used to specify a new set of values for the same application.
|
- Overrides module properties, thus enabling you to use different values for the same module.
- Cannot add new properties at application level.
|
Note: See
Design-time Concepts for details about the TIBCO Business Studio™ development environment.
Copyright © Cloud Software Group, Inc. All rights reserved.