Best Practices

As the business requirements become more complex, so do the business processes that are designed to implement them. TIBCO provides some best practices to help design processes that are readable, reusable, and manageable.

Control Visibility with Scopes

A scope is similar to a block concept in programming languages and is useful to isolate or encapsulate process variables, thus avoiding conflicts with variable names used elsewhere in the process. Use of scopes helps reduce the number of module properties needed for the entire application, which must be unique for all lexical scopes. When designing or viewing a process in TIBCO Business Studio™ for BusinessWorks™, scope constructs can be collapsed to enhance readability of the process and reduce clutter.

Promote Reuse with Sub-processes

A sub-process is similar to a sub-routine in programming languages and is useful to keep a block of code small and maintainable. Sub-processes, if declared public, can be called from other processes, thus enabling the logic to be reused.

Consolidate Literal Values

Keep the number of literal values in process logic and activity configurations to a minimum by consolidating them on the Process Properties tab at the process level. This makes it easier to view and maintain the literal values. In addition, the process properties can be promoted to module properties, which can then be controlled at the application level.

Externalize with Module Properties


Configuration parameters can be externalized as module properties. At runtime, the values from the module properties are injected into process and activity configuration parameters upon application startup. This allows environmental specific application properties to be set at the time of deployment or in some cases, post deployment. Database password is a good example of a module property.

Use Profiles for Staging

You can group module properties with the current set of property values into a named profile. An application can have multiple profiles, each having its own set of property values. At run time, you can deploy the same application and stage it multiple times using different profiles.

Defining Service Contracts

When designing complex business processes, ensure that the service contracts on the interfaces are well-defined.

Avoid XML Collisions

Avoid defining schema (XSD) or WSDL components with the same qualified names in the same module. Doing so might result in XML collisions at the module level.

If, for some reason, you need to define schema or WSDL components with the same qualifies names, then define the schema or WSDL components in separate shared modules. Additionally, configure the process to have unique namespace by specifying the location of the schema document in the Dependencies section of the process.

Close Unnecessary Projects in Workbench

Keep the number of open projects in your Eclipse workbench to a minimum by closing the unnecessary projects. Having too many BusinessWorks Container Edition projects open in the Eclipse workbench might adversely affect the UI performance.

Use Project Clean

Sometimes TIBCO Business Studio for BusinessWorks reports incorrect validation errors that are not related to design or development issues. TIBCO recommends that you clean your project as it forces Eclipse to discard all build problems and states, and rebuild the projects from scratch. This option can be accessed from the menu Project > Clean.

Manage TIBCO Business Studio for BusinessWorks Workspaces

If you are working with multiple major, minor, or service pack levels of the product, use different workspaces for different versions.

Increase Log Levels

When debugging issues at design-time, increasing the log levels can provide additional information on the issues. You can customize the log levels for configurations like Debug and Run by editing the respective logback.xml configuration files.

The logging configurations are accessible from Run > Debug Configuration > Advanced > Logging Configuration. Permissible log level values are INFO, TRACE, DEBUG, WARN, and ERROR. These levels can be applied to activities, shared resources, bindings, engine, and so on.