Properties

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
Property 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.
  • Private module properties cannot be viewed from the Admin UI.
  • Not visible or changeable from the Admin UI.
  • Literal or a shared resource reference.
  • Private module property values cannot be edited from the Admin UI.
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.
  • Private module properties cannot be viewed from the Admin UI.
  • Not visible or changeable from the Admin UI.
  • Literal or a shared resource reference.
  • Private module property values cannot be edited from the Admin UI.
  • 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. These properties are visible from the Admin UI.
  • 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: For more information about the development environment, see Design-time Concepts.