TIB Bwce 2.6.2 Concepts

TIBCO BusinessWorks™
Container Edition
Concepts
Version 2.6.2
May 2021
Copyright © 2015-2021. TIBCO Software Inc. All Rights Reserved.

2 | Contents
Contents
Contents 2
Overview 4
Key Concepts 5
Layout of the Concepts Guide 6
General Concepts 7
Applications 7
Modules 8
Application Modules 9
Shared Modules 11
Binary Shared Modules 12
Processes 13
Activities 16
Palettes 17
Transitions 17
Shared Resources 18
Additional General Concepts 20

Groups 20
Properties 22
Shared Variables 24
Fault Handlers 26
Components 27
Component Services 28
Component References 28
Services 29
Operations 29
SOAP Services 30
TIBCO BusinessWorks™ Container Edition Concepts

3 | Contents
REST Services 30
Policies 31
Policy Definitions and Concepts 32
Mapping Concepts to a Sample: Managing Books for a Bookstore 35
Design-time Concepts 36
Runtime Concepts 39
TIBCO Documentation and Support Services 41
Legal and Third-Party Notices 43

4 | Overview
Overview
TIBCO BusinessWorks™ Container Edition is an integration product suite for
applications.
With this software you can create services and integrate applications using a visual,
model-driven development environment, and then deploy them in the TIBCO
BusinessWorks Container Edition runtime environment.
It uses the Eclipse graphical user interface (GUI) provided by TIBCO Business Studio™
for BusinessWorks™ to define business processes and generate deployable artifacts in
the form of archive files.
With TIBCO Business Studio for BusinessWorks, you can model integration processes
of varying complexity using any of the following integration styles:
l Batch-oriented - provides non real-time integration for endpoints such as
databases or files, and uses records for data abstraction.
l Process-oriented - provides real-time integration for endpoints such as application
APIs and adapters, and uses APIs, objects, and messages for data abstraction.
l Service-oriented - provides real-time integration for endpoints such as web
services and APIs, and uses services and messages for data abstraction.
l Resource-oriented - provides real-time integration for endpoints such as mobile or
web applications and APIs, and uses resources for data abstraction.

5 | Overview
Key Concepts
The following image provides an overview of the key concepts that you encounter when
working with the product. Some of these concepts are applicable exclusively to design
perspective or runtime perspective, while some are applicable to both perspectives.
TIBCO BusinessWorks Container Edition consists of a design-time where you can
develop applications that implement business logic and the runtime envrionment where
you execute the applications.
TIBCO BusinessWorks Container Edition is based on open architecture, flexibility,
modularity, and support for standards.
Flexibility
TIBCO Business Studio for BusinessWorks is designed to make adding, upgrading, and
swapping of business components easy.
The flexible architecture is demonstrated by:
l A zero coding model with which you can select and drop activities onto the
Process Editor and configure the activities in the UI.
l Ability to build tightly coupled as well as loosely coupled services.
l Ability to build strongly typed as well as loosely typed service implementations.
l Ability to specify application configuration to be either hard-coded or late-bound.
l Encapsulation of configuration data, thus minimizing the configuration properties
exposed by the application.
Openness and Extensibility

Openness and extensibility features include:
l Public APIs with which you can develop custom activities and XPath functions.
l Integration with standard Java classes and OSGi Java services to supplement the
process or model driven approach.
l Extensible Eclipse-based design-time.
l Extensible OSGi based runtime.
Modularity
Modularity of the product supports:

6 | Overview
l Large teams and distributed development through modular constructs.

l Increased visibility and traceability metadata, such as Name, Version, Exported
Functionality, and Dependencies.
l Reusability with a consistent model across different technologies: Processes, Java
Classes, XSDs, WSDLs, and shared resources.
Standards-based
Supported standards include:
l Protocols and API: SOAP, JSON and REST, WSDL, HTTP, HTTPS, JMS, JDBC
l Data representation and transformation: Native support for XML, XSD, XPath,
JSON, XSLT
l Others: JNDI
Layout of the Concepts Guide
This guide presents the design-time, runtime, and administration concepts that are
useful to developers and administrators. These concepts are described in the following
sections:
l General Concepts: Explains the essential concepts such as applications,
application modules, shared modules, processes, activities, transitions, and
shared resources.
l Additional General Concepts: Explains additional concepts that can be used
when developing applications such as groups, properties, services, components,
and event handlers.
l Design-time Concepts: Introduces the design-time environment, TIBCO Business
Studio for BusinessWorks.
l Runtime Concepts: Explains the runtime concepts such as process instances and
jobs.
Sections that map concepts to bundled samples aim to enhance your understanding of
the concepts by mapping them to ready samples that can be viewed and executed.

7 | General Concepts
General Concepts
TIBCO BusinessWorks Container Edition applications developed to solve business
problems can range from simple to very complex solutions. These applications are
packaged in deployable artifacts in the form of archive files. Understanding these
general concepts is essential to both developers and administrators.
Applications
An application is a collection of one or more modules and can be executed in the
runtime. Applications are developed using TIBCO Business Studio for BusinessWorks.
An application contains one application module, which in turn consists of one or more
business processes. It can be executed in the runtime. Applications are developed using
TIBCO Business Studio for BusinessWorks
Applications are developed using features available in the product and can range from
simple to very complex. An TIBCO BusinessWorks Container Edition application
contains one application module (see Application Modules), which in turn consists of
one or more processes that define the business logic, and zero or more shared modules
(see Shared Modules). A process that is responsible for initiating the business logic at
runtime is used to implement a component in an application module.
Applications can also contain OSGi bundles that do not contain application artifacts. For
example, you can create an application that contains a Java OSGi bundle, which is also
referred to as a Java module.
Note: The term module is used interchangeably with OSGi bundle.
Elements of an application

Once an application is developed, you can either run or debug directly in TIBCO
Business Studio for BusinessWorks, or generate a deployable artifact (an archive file)
that can be deployed later in the runtime environment. The deployment artifact is the
only artifact that is handed over from the design-time to the runtime environment.
Modules
A module is an Eclipse project that is configured for TIBCO BusinessWorks Container
Edition.
Two types of modules are supported:
l Application modules: The smallest resource that is named, versioned, and
packaged as part of an application and is executed in the TIBCO BusinessWorks
Container Edition runtime. An application module cannot be deployed by itself in
the TIBCO BusinessWorks Container Edition runtime; it must be packaged as part

of an application.
l Shared modules: The smallest resource that is named, versioned, and packaged
as part of an application and can be used by other modules that are part of the
same application. A shared module cannot be deployed by itself; it must be
included as part of an application module.
Application Modules
The smallest resource that is named, versioned, and packaged as part of an application
and is executed in the TIBCO BusinessWorks Container Edition runtime. An application
module cannot be deployed by itself in the TIBCO BusinessWorks Container Edition
runtime; it must be packaged as part of an application.
An application module typically contains one or more processes. An application module

is configured and represented in TIBCO Business Studio for BusinessWorks, and can be
used by multiple applications. Each application module contains metadata that is
associated with it, such as name, version, dependencies, and so on.
An application module can include the following resources:
l Processes: Processes capture and represent the flow of business information
between different data sources and destinations. Processes are contained within a
process package. An application module can contain one or more process
packages, and each of the process packages can contain one or more processes.
l Service descriptors: Service descriptors consist of Swagger files and WSDL files
that provide the name of the service, interface, list of operations offered by the
service, the parameters expected by the operations, and the return types.
l Resources: Resources are reusable configuration data that can be shared within
an application. For example, Shared Resources.
l Schemas: Schemas define elements and attributes which can be used to define
structured data.
l Components: The main process that is responsible for initiating the execution of
the application logic is represented by a component. When the application logic is
spread across multiple processes, there can be one or more components in the
application module.
l Module Descriptors: Module descriptors provide information about the application
module such as module overview, configuration properties, dependencies,
components, and shared variables.

Use the Component section under the Module Descriptor node to

configure the components for this specific application module.
l src: Default source directory created when the project is Java enabled. A project
can contain multiple source directories which are used to contain the Java classes
and packages.
l JRE System Library: If your project is Java enabled, TIBCO Business Studio for
BusinessWorks includes the required JAR files in this folder.
Application modules can depend on shared modules, which can contain processes,
schemas, JSON, and WSDL files that can be used by a process in the application
module.
The application modules cannot export their functionality to other modules.
Structure of an Application Module

Shared Modules
The smallest resource that is named, versioned, and packaged as part of an application
and can be used by other modules that are part of the same application.
Shared modules export their functionality (processes, shared resources, and schema
namespaces) to application modules or to other shared modules. This means there is a
possibility that other modules in the system depend on a shared module for this
information.
Relationship Between Application Modules and Shared Modules
Shared modules can depend only on other shared modules and cannot depend on
application modules.
At the module level, a process can reference another process in a different module.
A process can also reference a WSDL or a schema defined in a different shared module.
Schemas that are intended to be exported from a shared module must be contained in
the Schemas special folder.

Two modules with the same package names cannot be used in the same
application. Package names must remain unique across multiple shared
modules and application modules within an application. If an application
contains two packages with the same name, rename of the packages, or
remove a package from an application.
For information on shared modules that can be exported for the purpose of sharing them
with other users, see "Binary Shared Modules" in TIBCO BusinessWorks™ Container
Edition Concepts.
Binary Shared Modules

Binary shared modules are essentially shared modules that you create to hide the
implementation details of a shared module from the consumers of the module. A binary
shared module is compiled into a binary format for use by another application.
A binary shared module can be used like any other shared module, except its end user
must use it as is without the ability to modify it in any way. When imported into a project,
the end user cannot see its process diagram or the implementation details of other
artifacts within the module.
Binary shared modules serve as a good vehicle when you have a standalone
functionality to share without exposing its details.

For more information on creating and using a binary shared module, see "Creating a
Binary Shared Module", and "Using a Binary Shared Module" in TIBCO
BusinessWorks™ Container Edition Application Development.
Processes
Processes capture and describe the flow of business information in an enterprise
between different data sources and destinations.
Processes comprise of activities that accomplish tasks. The flow of data between
activities in a process is represented using transitions, conditions, and mappings. TIBCO
Business Studio for BusinessWorks provides design palettes containing activities and
transitions that can be used to develop business processes.
Parent Process
A process can call another process, or a subprocess. The process that is making the
call is referred to as a caller process or a parent process.

Subprocess
A subprocess can be called by a parent process, or another subprocess. In the case
where a subprocess is calling another subprocess, the subprocess that is making the
call is the parent process. The called process is referred to as a subprocess or a child
process. At runtime, inline subprocesses are executed on the same engine thread as
the caller process while the non-inline subprocesses use different engine threads and
are executed on the new threads.
Component Process
The execution of a process is triggered by various events. Often the business logic
that is designed to react to a particular event is spread across multiple processes.
One of the processes is special and it reacts to the original event and triggers the
execution of the other processes. This special process is referred to as the
component process or main process. A component process is responsible for
initiating the job at run time.
A component process is designed to react to various events and these events are
triggered by Processes and Bindings.
Process Services
A process can provide services to other processes. A process service exposes the
operations provided by the process and is implemented using a WSDL or a JSON file.
When the process is implemented by a component, the process services are exposed
as component services, which then need to be configured using bindings.
Process References
A process can consume services provided by other processes or by external service
providers. A process reference exposes the operations consumed by the process and
is implemented using a WSDL or a JSON file. A process reference can be configured
to invoke a process or an external service.
When the process is implemented by a component, the process references that are
not configured to call a process or an external service through a binding are exposed
as component references, which then need to be configured using bindings.
Activator Process
An activator process is a special process that can be used to perform pre-processing
and post-processing tasks when the application is started and stopped respectively.
The activator process contains a process service with two operations: OnStartup and
OnShutDown.

The OnStartup operation is called when an application is started, but before

executing any other processes in the application. The OnStartup operation can be
used to implement any pre-processing tasks that must be performed for the
application before the regular processing starts. For example, the OnStartup
operation can be used to check if the database tables required by an application
exist, and create them if they do not exist. If this process instance faults due to an
unhandled exception, the application does not start.
The OnShutDown operation is called when an application is stopped, but after
stopping and completing all other processes in the application. The OnShutDown
operation can be used to implement any post-processing tasks that must be
performed for the application after the regular processing is complete. For example,
the OnShutDown operation can be used to send an email to administrators notifying
them that the application is being stopped.
The activator process can only be configured for an application module. There can be
only one activator process for an application module. However, the activator process
can invoke one or more sub-processes.
For information on how to create an activator process, see "Creating an Activator
Process" in TIBCO BusinessWorks™ Container Edition Application Development.
A simple business process can be developed by adding activities in sequence, and the
connecting the activities using transitions with or without conditions. Developing a
complex business process typically involves developing a component process and one
or more subprocesses. Use of subprocesses makes the complex business process
easier to understand and debug. At runtime, the in-line subprocesses do not create a
new job, but are executed on the job created by their calling process.

Note: For details about the TIBCO Business Studio for BusinessWorks
development environment, see Design-time Concepts.
Activities
Activities are the individual units of work in a process.
Activities generally interact with an external system and perform a task. Activities that
perform similar tasks are grouped in an entity called a palette. TIBCO Business Studio
for BusinessWorks provides various technology-specific palettes using which you can
build a business process.
Each activity in a palette is represented by an icon. For example, the database update
activity is represented by the icon. Often an activity icon is also decorated with an
additional symbol such as a green or a yellow pause sign to indicate the activity waits for
an event, an arrow to indicate the direction of the data flow, and so on. For example, the
arrow sign in the JMS Send Message icon indicates data is being
sent by this activity.
Note: Detailed descriptions of palettes are available in the TIBCO

BusinessWorks™ Container Edition Bindings and Palettes Reference guide.
Activities can be classified into three types:
l Regular Activities perform a specific task. Regular activities can have input and
output in addition to their configuration. Activities can also state the faults they can
throw at runtime. This allows the process to be designed to handle these faults and
perform the necessary actions. Regular activities can be further classified into
synchronous and asynchronous activities.
Synchronous activities are blocking. They block the execution of the process until
the activity task completes.
Asynchronous activities are non-blocking. They perform a task asynchronously
without blocking the execution of a process.
l Process Starter Activities are configured to react to events. They trigger the

execution of a process when the event occurs. Process starter activities can have
only outputs in addition to their configuration. For example, the HTTP Receiver
process starter activity starts a process when an HTTP request is received.
Note: For details about the TIBCO Business Studio for BusinessWorks
development environment, see the Concepts Guide.
Palettes
Palettes group activities that perform similar tasks. TIBCO Business Studio for
BusinessWorks provides various technology specific palettes that provide quick access
to activities when building a process.
Palettes are typically located to the right of the Process Editor in TIBCO Business
Studio for BusinessWorks. Depending on the process being designed and the stage of
process development, you can focus on the activities available under appropriate
palettes.
In TIBCO Business Studio for BusinessWorks, the Palette views displays the list of
activities contained in a palette and allows you to perform the following actions:
l Search for activities in palettes.
l Use multiple palettes and save them as grouped palette sets.
l Save palettes, or the grouped palette sets, as favorites.
l View recently used palettes.
l Create virtual palettes, which means that some activities can be taken from
unrelated palettes. This activity is called a custom shortcut.
Note: For more information about the TIBCO Business Studio for
BusinessWorks development environment, see Design-time Concepts.
Transitions
Transitions can be added to activities and groups in a process. They represent the flow
of execution from one activity or group to another.

In TIBCO Business Studio for BusinessWorks, transitions are displayed as an arrow

between two resources in a process. Transitions are unidirectional and cannot connect
to a previously executed activity or group. The control flow in a process must proceed
sequentially, beginning with the starting activity or group and ending with the last activity
or group in the process.
Transitions can have a one-to-many relationship with the activities. In a process, one
activity can simultaneously transition to multiple activities or groups. For example, if the
shipping schedule indicates a delay in shipping an order, you want to notify the customer
and enter the information into the customer service system. However, if there is no
delay, you want to enter the information into the customer service system without
notifying the customer.
Transitions can fall into one of the following categories:
l Transitions Without Conditions: Control automatically flows from one activity or

group to the next without any conditions.
l Transitions With Conditions: When an activity or group completes processing,
conditions specified on the transitions originating from that activity or group are
evaluated to determine whether the transition to the next activity or group should
be taken or not. All transitions whose conditions are met are taken.
l Error Transitions: Special transitions that specify the activities or groups to
execute in case of an error. When configuring an activity or group, you can select
one transition to take from the specified activity or group and the activities or
groups to be executed following the error transition.
Note: Error transitions take precedence over fault handlers. If an error is

encountered in a scope and it has both a fault handler and an error
transition, then the error transition is executed.
Shared Resources
Shared resources are resources that contain common configuration data that can be
referenced from multiple places.
You can define a shared resource and then reference it from multiple activities in the
same or different process.

Shared resources such as JDBC Connection, JMS Connection, HTTP Connection, are
available at design-time. At runtime, the referencing activities and event sources have
full access to their instances and configuration.
Shared resources can be grouped in packages, similar to the way process packages
and Java packages are presented in the file system.
When defined in an application module, shared resources are not visible to processes
outside the application module. However, when defined in a shared module, they are
visible to processes outside the shared module.
Shared Variables
Shared variables are used to define data for modules and jobs. There are two types of
shared variables: job shared variables and module shared variables. They are stored
separately.
Job Shared Variables

Job shared variables are used to share data within a job such as between a parent
and child process instance. At runtime, the engine allocates a new variable for each
job and the value of that variable is not visible outside the job to which it was
allocated.
Module Shared Variables
Module shared variables are used to share data across all processes in a module.
The module shared variable is visible to all process instances within the same
module.
The key difference between a job shared and a module shared variable is that when jobs
expand across module boundaries, a job shared variable is visible outside the module it
was set in, while the module shared variable is visible only inside the module in which it
was set.

20 | Additional General Concepts
Additional General Concepts

This section introduces the following additional concepts that help build complex
business processes.
Groups
Groups consist of one or more activities that are assembled together and executed
according to their type.
Groups enable you to put one or more activities together and configure the group as
needed. For example, defining a single error condition for the group, or creating a group
as a transaction that commits to a database only when all the activities in the group are
completed.
Every group contains a GroupStart element on the left and a GroupEnd
element on the right.
Groups can be classified into two categories: groups with conditions (repetitive groups)
and groups without conditions (non-repetitive groups).
Groups Without Conditions (Non-repetitive)

The following types of groups do not require any conditions to be defined for their
execution:
l Scope : A scope is a simple group that has no custom behavior. It can define

local variables and can also contain fault handlers and event handlers. A scope
with a single activity can be defined if you need to handle faults or catch
exceptions specific to an individual activity.
l Critical Section : Critical Section groups are used to synchronize jobs so that
only one job is acting on the group of activities at any given time. Any concurrently
running job that contains a corresponding critical section waits until the job
currently executing the critical section completes. Critical section groups are
useful to control concurrent access to shared variables. While a critical section
group can be used to synchronize jobs within a process, module shared variables
help synchronize jobs for multiple processes.
Groups With Conditions (Repetitive)

Loops are groups with conditions which follow a pattern at runtime: initialize the loop,
update the loop at each iteration, and test conditions for the loop to stop iterating. The
following types of loops are available:
l For Each : For Each is used to loop for a specific number of iterations with a
counter ranging from a start value to an end value.
l Iterate : This loop has a simple index variable that can be used to count each
iteration and the loop executes for the number of iterations specified.
l Repeat : This loop has a simple index variable that can be used to count each
iteration and has a conditional expression to determine when to stop. The loop
executes at least once and a test for the specified condition is performed at the
end of the loop. The Repeat loop continues to run until the condition evaluates to
true.
l Repeat on Error : This loop involves a retry mechanism: if any activity in the
loop displays a fault, the condition expression is evaluated to determine if the loop
should be repeated. An index allows the condition to be based on the number of
previous attempts, but any condition expression may be used.
l While : This loop has a simple index variable that can be used to count each
iteration and has a conditional expression to determine when to stop. The
condition for the While loop is tested at the beginning of each iteration and the loop
may never be executed if the condition is initially false. The While loop and
continues to execute as long as the condition holds true and stops when the
condition evaluates to false.

Note: For more information about the TIBCO Business Studio for
BusinessWorks development environment, see Design-time Concepts.
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.
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 Visible within a Literal, module Literal values cannot be

Properties process. property reference, modified at the module or
or a shared application level.
resource reference.
Module l Visible within the l Literal or a Cannot be assigned to an

Properties module. shared activity directly. You need
resource to reference a module
reference. property from a process
property, and then
reference the process
property from the activity.
Shared l Visible within the l Literal or a l Shared Module

Module module. shared Properties are
Properties resource module properties
l Visible within
reference. that come from a
projects that
Shared Module.
contain l Private
dependencies to module l Cannot be assigned
the Shared property to an activity
Module that the values cannot directly. You need
Shared Module be edited to reference a
Property came from the module property
from. Admin UI. from a process
property, and then
l Private module
reference the
properties
process property
cannot be
from the activity.
viewed from the
Admin UI. l Can be used for
activities, process
l Not visible or
properties, shared
changeable from
resources, and
the Admin UI.
SOAP Bindings.
Application l Only available l Literal. l Overrides module

Property Scope/Visibility Values Additional Information
Properties for an l Profiles can properties, thus

application and be used to enabling you to use
visible within the specify a new different values for
application. set of values the same module.
for the same
l Cannot add new
application.
properties at
application level.
Shared Variables
Shared variables are used to save the state, either at the module level or for the duration
of a job.
Using shared variables, you can share data across process instances associated with a
module or a job. A process instance can read or update the data stored in a shared
variable. The shared variable data updated by one process instance is accessible to
other process instances of a Module or Job.
There are two types of shared variables: module shared variables and job shared
variables. Both module and job shared variables are defined at the module level and can
be accessed in a process using the activities Set Shared Variable and Get Shared
Variable.
For more information on how to define and use shared variables, see "Using Shared
Variables" in TIBCO BusinessWorks™ Container Edition Application Development.
Module Shared Variables

Module shared variables are used to share the state at a module level and are visible to
all process instances created from the processes that are within a module. Module
shared variables can be read and updated by the process instances during execution.
Once the value is updated, the new value is available to all the process instances
created from the processes that are within the module. Consider an example where the
exchange rates are updated daily and the updated exchange rates should be accessible
to all processes in a module. You can create a module shared variable to hold the
exchange rate and use one process in the module for updating the exchange rate. All
other processes in the module that require the exchange rate can retrieve the current
value through the module shared variable.

Job Shared Variables

Job shared variables are used to share the state at the job level for the duration of a job.
A copy of the job shared variable is created for each new job and it is accessible to all
process instances associated with the job. Job shared variables can be used to share
data between all process instances of a job without creating an input or output schema
for the called process.
Sharing Job Shared Variables Between Inline and Non-Inline Processes
Inline subprocesses are executed as part of the caller (parent) process jobs and
therefore the current value of the job shared variable is passed from the caller process to
the inline subprocess. Non-inline service subprocesses, and direct subprocesses that
have been spawned, spawn a new thread and are not executed on the same job as the
caller process. Hence non-inline subprocess and direct subprocesses that have been
spawned, obtain a copy of the job shared variable and do not obtain the current value of
the job shared variable from the caller process.
At runtime, the engine allocates a new job shared variable for each new job and the
value of that variable is visible only to that job.
Shared Variable Synchronization

Multiple process instances can potentially access or update a shared variable at the
same time. For example, a module shared variable can be accessed by multiple jobs
concurrently. Without a synchronization mechanism, a process instance could update
the value of a shared variable while another process instance is trying to read the value.
This could result in an unpredictable value for the shared variable.
Critical Section groups can be used to synchronize access to shared variables. A
Critical Section group allows only one process instance to execute the Critical Section
group and its contents at any given time. To synchronize shared variables, use a Critical
Section group to contain the activities that access the shared variables (Set Shared
Variable and Get Shared Variable). Once a process instance begins executing a
Critical Section group, other concurrently running process instances that are associated
with that Critical Section group wait at the start of the group until the currently running
process instance exits the critical section group. This ensures that the value of the
shared variable is not modified while another process instance is accessing it. To
synchronize multiple critical section groups, use a shared lock. The shared lock can be
defined using a module or a job shared variable.

Fault Handlers
Errors (or faults) can occur when executing a process. Fault handlers allow you to catch
faults or exceptions and create fault-handling procedures to deal with potential runtime
errors in your process definitions.
Fault handlers are the recommended way to catch faults or exceptions in a process. Two
types of fault handlers are available: Catch Specific Fault and Catch All Faults.
Fault handlers can be defined at two different levels:
l Process level - When defined at the process level, allows you to catch fault in a
process.
l Scope level - When defined at the scope level, allows you to catch fault within a
scope.
Fault handlers when defined at the scope level, allows you to catch faults or exceptions
thrown by activities within a scope. To catch faults or exceptions specific to an individual
activity, you need to define a new scope for that individual activity and attach a fault
handler to the new scope.
At runtime, once a fault handler is executed, the associated scope is not completed due
to the error thrown. If a fault is not thrown in the fault handler, the process execution
continues with the first activity that follows the scope. If a fault is thrown in the fault
handler, then the engine looks for an enclosing scope that is designed to handle the
fault. If one is found, the engine executes it. Once the enclosing fault handler finishes its
execution, the engine executes the next activity following the scope. If no fault handlers
are found in the enclosing scopes, then the job terminates with a fault.
Consider the fault handlers defined in the sample process.

Sample Fault Handlers
If an exception is caught in the inner scope, the exception is logged and the scope is
completed. If an exception is caught in the outer scope, the exception is logged and the
scope is completed. The process execution completes successfully as there are no
following activities to be processed. An Exit activity inside the fault handler returns the
control out of the scope and the process.
Error Transitions can also be used to handle error conditions by using them to specify
transition to take in case of an error.
Note: Error transitions take precedence over fault handlers. If an error is

encountered in a scope and it has both a fault handler and an error transition,
then the error transition is executed.
Components
Components implement a process and provide information to the runtime on how to
instantiate the process.
Components are generated only for main processes and each main process initialized
by the engine must have a component associated with it. Components are required only
by main processes that are responsible to initiate the business logic. Subprocesses do
not require components as they are called by another parent process.

Component Services
Component services describe the binding information to receive an invocation from an
external consumer.
When a component implements a process that has a service, that process service is
exposed as a component service. The component service then must be configured
using bindings such as SOAP and REST.
The service-centric architecture supports self-contained services. Each service is
configured separately and can be deployed on a different machine. If one machine goes
down, all other parts of the process can continue to run. This loosely-coupled
architecture makes it easy to change individual components as needed.
Component References
Component references describe the binding information required to invoke an external
service.
When the component implements a process that has a reference, then the process
reference is exposed as a component reference. When configuring to invoke an external
service, the binding information that contains protocol details is not part of the process.
The service consumer needs to create a component that is an implementation of that
process and configure the binding along with protocol details. The Invoke operation
activity or a reference can be used to invoke a service.
References have the following characteristics:
l They can be public or private. Public references are visible from outside of the

process.
l They always reference one interface or port type.
Based on the availability of the target service name at design-time, you can use either
static references or dynamic references. Static references can be used when the target
service name is available at design-time and dynamic references are available when the
target service name is not available at design-time. This applies to target services
developed as a part of TIBCO BusinessWorks Container Edition as well as external
target services.
Services
TIBCO BusinessWorks Container Edition can function both as a server and a client in a
web services interaction. Services and references are defined at the process level while
the bindings are created at the component level.
The supported service classes are:
l REST (Representational State Transfer)-compliant services, where the primary
purpose of the service is to manipulate XML representations of web resources
using a uniform set of stateless operations. When using a stateless operation, the
state is managed by the job itself instead of by the engine.
l SOAP services, which are used for exchanging information in the implementation
of web services relying on XML message format sent over HTTP and JMS.
Web services are typically associated with the following characteristics:

l Interfaces that describe the operations available within a service. An interface is
analogous to a port type in a WSDL file. Each interface can contain multiple
operations.
l Operations define an action that can be performed by the service and the way the
message is encoded.
l Transport used for communication such as HTTP or JMS.
l Schema used for message exchanges such as XSD.
Operations
Operations define the action that can be performed by the process. Multiple operations
are supported in a process with multiple inputs, outputs, and faults.

There are two types of message exchange operations: one-way operations and request-
response operations.
SOAP Services
SOAP services are web services that use SOAP as the standard communication
protocol for XML-based message exchanges.
The standard HTTP protocol makes it easier for SOAP model to tunnel across firewalls
and proxies without any modifications to the SOAP protocol.
l The Web Services Description Language (WSDL) contains and describes the
common set of rules to define the messages, bindings, operations and location of
the Web service. A WSDL file is a formal contract to define the interface that the
Web service offers.
l SOAP services require less coding than when designing REST services. For
example, transactions, security, coordination, addressing, and trust are defined by
the WSDL specification. Most real-world applications are not simple and support
complex operations, which require conversational state and contextual information
to be maintained. Application developers do not need to worry about writing this
code into the application layer themselves.
l SOAP supports several technologies, including WSDL and XSD.
REST Services
Representational State Transfer (REST) is an architectural style of the World Wide Web
that is used in building services for distributed systems and networked applications.
RESTful APIs are increasingly preferred for enterprise, web and mobile integration use
cases.
The key abstraction of information in REST is a resource, with focus on components, the
constraints upon their interaction with other components, and their interpretation of
significant data elements. REST ignores the details of component implementation and
protocol syntax.
The supported features of REST architectural style are:
l Client-server architecture: Provides a separation of implementation details

between clients and servers.

l Stateless communication: Ensures that each request contains all of the
information required to understand it independently of any stored context on the
server.
l Cacheability: Provides an option to the client to cache response data and reuse it
later for equivalent requests, thus partially eliminating some client-server
interactions. This results in improved scalability and performance.
TIBCO BusinessWorks Container Edition currently, the following HTTP operations can
be performed on resources: GET, PUT, DELETE, and POST. Both XML and JSON are
supported as data serialization formats along with support for definition of custom status
codes, key-value parameters, and query parameters
Policies
A policy is a set of constraints that you can define and apply in TIBCO Business Studio
for BusinessWorks to manage and enforce cross-functional requirements within your
TIBCO BusinessWorks Container Edition application such as security, monitoring, and
compliance.
You can add policies to activities and bindings in a process to influence or alter actions
in the process flow. For example, you can add a policy on an existing HTTP Receiver
activity in your application to ensure that user credentials are authenticated, or verified
as correct, before the message can continue moving through the process flow. Any
request messages that cannot be authenticated are rejected, redirected, or handled in
accordance to policy details.
The following policies are examples of policies provided in TIBCO BusinessWorks

Container Edition:
Basic Authentication
Validates the user name and password credentials stored in the HTTP header of
REST, SOAP, or pure HTTP request messages.
Basic Credential Mapping
Automatically attaches appropriate credentials to request messages before they
reach services.

Web Services Security Provider (WSS Provider)

Acts on the server side to ensure the security of a message by enforcing
confidentiality, integrity, and time stamping.
Web Services Security Consumer (WSS Consumer)
Acts on the reference side to ensure the security of a message by enforcing
confidentiality, integrity, and time stamping.
Policy Definitions and Concepts

The following definitions and concepts are used to describe policies and policy
management.
Policy
A policy is set of constraints that you can define and apply in TIBCO Business Studio for
BusinessWorks to manage and enforce cross-functional requirements within your
application such as security, monitoring, and compliance. You can add policies to
activities and bindings in a process to influence or alter actions in the process flow.
Policy Types
Policies that are related or perform similar functions are categorized under policy types.
Policies that can be applied to the HTTP layer of SOAP, REST, and pure HTTP services
are categorized under the HTTP Security policy type. Policies that can be applied to the
SOAP layer are categorized under the SOAP Security policy type.
Activities
An activity is the individual unit of work in a process. You can add policies to activities to
influence or alter actions in a process flow.
For more information about activities, see "Application Development" in TIBCO
BusinessWorks™ Container Edition Getting Started.
Bindings
A binding is used to establish a connection between SOA Services and their consumers.
There are two types of binding components:
l Service Binding, which is used to create and expose a service to the external
world. The service can contain one or more operations. Once exposed, the service

can be consumed by its clients.

l Reference Binding, which is used to create a client that can connect and
communicate to an external service.
You can add policies to bindings to manage, modify and secure message exchanges on
the consumer side and provider side.
For more information about the types of bindings offered in the workspace, see "Binding"
in TIBCO BusinessWorks™ Container Edition Concepts.
Policy Association
When you add a policy on an activity or a binding, the relationship you create between
the resources is called a policy association. At runtime, policies are enforced on the
activities and their associated bindings.
Shared Resources
Policies reference shared resources. You can manage and configure shared resources
in your workspace. The following table describes shared resources that each policy
might reference.
Policy Shared Resource
Basic Authentication l XML

Authentication
Basic Credential Mapping l Identity Provider
WSS Provider l Subject Provider

l Keystore
Provider
l Trust Provider
l WSS
Authentication
WSS Consumer l Identity Provider

l Keystore
Provider

Policy Shared Resource
l Trust Provider
l Subject Provider
l WSS
Authentication
Note: You can define a shared resource and then reference it from a single
policy or multiple policies. For example, you could use a single Keystore
resource in the WSS Provider policy and the WSS Consumer policy.

35 | Mapping Concepts to a Sample: Managing Books for a Bookstore
Mapping Concepts to a Sample: Managing

Books for a Bookstore
The concepts introduced in sections General Concepts and Additional General
Concepts enable you to understand and design a resource-oriented solution such as the
Bookstore example.
Pre-requisites
The Bookstore sample requires the concepts introduced in the following sections:
l General Concepts
l Additional General Concepts
After going through these sections, you should be able to understand and execute a
resource-oriented solution such as the sample to manage books for a bookstore.
Bookstore Sample
The bookstore sample uses a RESTful service to add, delete, update, and retrieve
books from bookstore. The following REST methods are used:
l POST - Posts books to the bookstore
l GET - Get books from the bookstore
l PUT - Updates books to the bookstore
l DELETE - Deletes books from the bookstore
The Bookstore sample project is shipped with the product and can be accessed in
TIBCO Business Studio for BusinessWorks from Help > BusinessWorks Samples.
Next Steps
After completing this section, you should be able to design resource-oriented processes
with minimal assistance.

36 | Design-time Concepts
Design-time Concepts
Design-time concepts introduces TIBCO Business Studio for BusinessWorks, an
Eclipse-based integration development environment that is used to design, test, and
deploy applications.
TIBCO Business Studio for BusinessWorks provides Eclipse extensions such as

editors, palettes, and so on.
Development Environment
TIBCO Business Studio for BusinessWorks provides a workbench that can be used to
create, manage, and navigate resources in your workspace. A workspace is the central
location on your machine where all the data files are stored.
TIBCO Business Studio for BusinessWorks Workbench
The workbench consists of:

l Menu: Contains menu items such as File, Edit, Navigate, Search, Project, Run,
Window, and Help.
l Toolbar: Contains buttons for the frequently used commands such as New ,

Save , Enable/Disable Business Studio capabilities , Create a new

Application Module , Create a new Shared Module , Debug , Run ,
and so on.
l Perspectives: Contain an initial set and layout of views that are needed to perform
a certain task. TIBCO Business Studio for BusinessWorks launches the Design
perspective by default. You can change the perspective from the menu Window >
Open Perspective > <perspective_name>.
l Views: Display resources and allow for navigation in the workbench. For example,
the Project Explorer view displays the applications, modules, and other resources
in your workspace, and the Properties view displays the properties for the selected
resource. You can open a view from the menu Window > Show View > <view_
name>.
l Editors: Provide a canvas to configure, edit, or browse a resource. Double-click on
a resource in a view to open the appropriate editor for the selected resource. For
example, double-click a process (MortgageAppConsumer.bwp) in the Project Explorer
view to open the process in the editor.
l Palettes: Palettes group activities that perform similar tasks and provide quick
access to activities when building a process. For more information, see Palettes.
Explorers
TIBCO Business Studio for BusinessWorks consists of the following tabs in its left pane:
l Project Explorer: Displays the logical view of your entire workspace with all the
projects and the processes, service descriptors, resources, schemas, and module
descriptors for each project
l API Explorer: You can also view the APIs residing locally on your machine from
the API Explorer. Use the Settings dialog in the API Explorer to filter the APIs you
want to access
l File Explorer: Displays a view of selected folders in your local file system
l Outline tab: Displays a tree structure of the details of a selected artifacts in an
editor
l Module tab: Displays the module properties and shared variables used in the
module

Testing and Debugging

TIBCO Business Studio for BusinessWorks bundles some of the runtime components
so that you can run and debug an application in the design-time environment.
The menu option Run > Debug or the icon on the tool bar enable you to debug an
application. The menu option Run > Run or the icon on the tool bar enable you to
run an application.
Run configurations specify information such as:
l Bundles to be executed.
l Arguments such as the target operating system, target architecture, target web
services, and so on.
l Settings that define the Java Runtime Environment including the Java executable,
runtime JRE, configuration area and so on.
l Tracing criteria for the OSGi JAR file, if needed.
l Common options such as choosing to save the results either as local files or as
shared files, and also to display them in the menus (Debug and/or Run). It also
allows to define encoding for the result files.
Once created, an application can be run using a specific configuration. If a run

configuration is not specified, the project displayed in the editor area is launched by
default.

39 | Runtime Concepts
Runtime Concepts
Runtime refers to the AppNode and the .
AppNode
An AppNode (also called bwappnode) is an operating system process (JVM) that hosts
and executes TIBCO BusinessWorks Container Edition applications. An AppNode
consists of two key layers: the OSGI Framework and TIBCO BusinessWorks Container
Edition Engine. The high-level architecture of an AppNode is shown in the following
figure:
Application Node Architecture
The framework layer performs application life cycle operations, ensures that
dependencies required by the application are satisfied. The engine layer is responsible
for executing the application. The engine is multi-threaded and can execute multiple jobs
for the same or different applications concurrently.
At runtime, an AppNode launches the framework to validate and identify dependencies.

After the framework validates the modules and the application is deployed, the TIBCO
BusinessWorks Container Edition engine starts the underlying processes.
The binary file named bwappnode is packaged under the TIBCO_HOME/bw/version/bin
directory.
Process Instance
Execution of any process creates an execution scope for the activities that are a part of
the process and this scope is called a process instance. Each process instance has a
unique id which is referred to as "ProcessInstanceId".

40 | Runtime Concepts
The execution of a process is triggered by various events. For example, events can be
generated by a Timer that is scheduled to trigger at specific time intervals, or by changes
that occur in the file system, or by messages that are sent by a client over a specific
protocol (for example, HTTP), or simply by messages sent by other processes.
The TIBCO BusinessWorks Container Edition engine is a multi-threaded engine capable
of triggering the execution of the same process multiple times, concurrently, once for
each event. When the events that trigger the execution of a process occur concurrently,
the engine executes the same process multiple times, concurrently, once for each event.
And for each execution, the engine creates a process instance that provides an
execution scope for the activities that are a part of the process.
Job
Execution of a component process is called a job. Each job has a unique id referred to
as JobId.
When the business logic is spread across multiple processes, multiple process
instances are created and executed in conjunction with a particular event. Even though
these are separate process instances they are work together and can be executed as
part of the same job. A job can spawn multiple process instances and can provide the
execution context for activities that are part of multiple processes. The engine always
executes a job in one engine thread.
All the process instances that are part of the same job have the same JobId. A
component process instance and all of its in-line subprocess instances are also
considered to be a part of the same job. Non in-line subprocesses spawn a new engine
thread and are executed on a different job.

41 | TIBCO Documentation and Support Services
TIBCO Documentation and Support Services

For information about this product, you can read the documentation, contact TIBCO
Support, and join TIBCO Community.
How to Access TIBCO Documentation

Documentation for TIBCO products is available on the TIBCO Product Documentation
website, mainly in HTML and PDF formats.
The TIBCO Product Documentation website is updated frequently and is more current
than any other documentation included with the product. To access the latest
documentation, visit https://docs.tibco.com.
Product-Specific Documentation
Documentation for TIBCO BusinessWorks™ Container Edition is available on the TIBCO
BusinessWorks™ Container Edition Product Documentation page.
To directly access documentation for this product, double-click the following file:
TIBCO_HOME/release_notes/TIB_bwce_2.6.2_docinfo.html where TIBCO_HOME is the top-level
directory in which TIBCO products are installed. On Windows, the default TIBCO_HOME
is C:\tibco. On UNIX systems, the default TIBCO_HOME is /opt/tibco.
The following documents for this product can be found in the TIBCO Documentation site:
l TIBCO BusinessWorks™ Container Edition Release Notes
l TIBCO BusinessWorks™ Container Edition Application Development
l TIBCO BusinessWorks™ Container Edition Application Monitoring and
Troubleshooting
l TIBCO BusinessWorks™ Container Edition Bindings and Palettes Reference
l TIBCO BusinessWorks™ Container Edition Concepts
l TIBCO BusinessWorks™ Container Edition Error Codes
l TIBCO BusinessWorks™ Container Edition Getting Started
l TIBCO BusinessWorks™ Container Edition Migration
l TIBCO BusinessWorks™ Container Edition Performance Benchmarking and

42 | TIBCO Documentation and Support Services
Tuning
l TIBCO BusinessWorks™ Container Edition REST Implementation
l TIBCO BusinessWorks™ Container Edition Refactoring Best Practices
l TIBCO BusinessWorks™ Container Edition Samples
How to Join TIBCO Community

TIBCO Community is the official channel for TIBCO customers, partners, and employee
subject matter experts to share and access their collective experience. TIBCO
Community offers access to Q&A forums, product wikis, and best practices. It also offers
access to extensions, adapters, solution accelerators, and tools that extend and enable
customers to gain full value from TIBCO products. In addition, users can submit and vote
on feature requests from within the TIBCO Ideas Portal. For a free registration, go to
https://community.tibco.com.

43 | Legal and Third-Party Notices
Legal and Third-Party Notices

SOME TIBCO SOFTWARE EMBEDS OR BUNDLES OTHER TIBCO SOFTWARE. USE OF
SUCH EMBEDDED OR BUNDLED TIBCO SOFTWARE IS SOLELY TO ENABLE THE
FUNCTIONALITY (OR PROVIDE LIMITED ADD-ON FUNCTIONALITY) OF THE LICENSED
TIBCO SOFTWARE. THE EMBEDDED OR BUNDLED SOFTWARE IS NOT LICENSED TO BE
USED OR ACCESSED BY ANY OTHER TIBCO SOFTWARE OR FOR ANY OTHER PURPOSE.
USE OF TIBCO SOFTWARE AND THIS DOCUMENT IS SUBJECT TO THE TERMS AND
CONDITIONS OF A LICENSE AGREEMENT FOUND IN EITHER A SEPARATELY EXECUTED
SOFTWARE LICENSE AGREEMENT, OR, IF THERE IS NO SUCH SEPARATE AGREEMENT,
THE CLICKWRAP END USER LICENSE AGREEMENT WHICH IS DISPLAYED DURING
DOWNLOAD OR INSTALLATION OF THE SOFTWARE (AND WHICH IS DUPLICATED IN THE
LICENSE FILE) OR IF THERE IS NO SUCH SOFTWARE LICENSE AGREEMENT OR
CLICKWRAP END USER LICENSE AGREEMENT, THE LICENSE(S) LOCATED IN THE
“LICENSE” FILE(S) OF THE SOFTWARE. USE OF THIS DOCUMENT IS SUBJECT TO THOSE
TERMS AND CONDITIONS, AND YOUR USE HEREOF SHALL CONSTITUTE ACCEPTANCE
OF AND AN AGREEMENT TO BE BOUND BY THE SAME.
This document is subject to U.S. and international copyright laws and treaties. No part of this
document may be reproduced in any form without the written authorization of TIBCO Software Inc.
TIBCO, the TIBCO logo, the TIBCO O logo, TIBCO ActiveMatrix BusinessWorks, TIBCO
ActiveSpaces, TIBCO Business Studio for BusinessWorks, TIBCO Designer, TIBCO Enterprise
Message Service, TIBCO Hawk, TIBCO Rendezvous, and TIBCO Runtime Agent are either
registered trademarks or trademarks of TIBCO Software Inc. in the United States and/or other
countries.
Java and all Java based trademarks and logos are trademarks or registered trademarks of Oracle
Corporation and/or its affiliates.
This document includes fonts that are licensed under the SIL Open Font License, Version 1.1,
which is available at: https://scripts.sil.org/OFL
Copyright (c) Paul D. Hunt, with Reserved Font Name Source Sans Pro and Source Code Pro.
All other product and company names and marks mentioned in this document are the property of
their respective owners and are mentioned for identification purposes only.
This software may be available on multiple operating systems. However, not all operating system
platforms for a specific software version are released at the same time. See the readme file for the
availability of this software version on a specific operating system platform.

44 | Legal and Third-Party Notices
THIS DOCUMENT IS PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER
EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT.
THIS DOCUMENT COULD INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL

ERRORS. CHANGES ARE PERIODICALLY ADDED TO THE INFORMATION HEREIN; THESE
CHANGES WILL BE INCORPORATED IN NEW EDITIONS OF THIS DOCUMENT. TIBCO
SOFTWARE INC. MAY MAKE IMPROVEMENTS AND/OR CHANGES IN THE PRODUCT(S)
AND/OR THE PROGRAM(S) DESCRIBED IN THIS DOCUMENT AT ANY TIME.
THE CONTENTS OF THIS DOCUMENT MAY BE MODIFIED AND/OR QUALIFIED, DIRECTLY

OR INDIRECTLY, BY OTHER DOCUMENTATION WHICH ACCOMPANIES THIS SOFTWARE,
INCLUDING BUT NOT LIMITED TO ANY RELEASE NOTES AND "READ ME" FILES.
This and other products of TIBCO Software Inc. may be covered by registered patents. Please
refer to TIBCO's Virtual Patent Marking document (https://www.tibco.com/patents) for details.
Copyright © 2015-2021. TIBCO Software Inc. All Rights Reserved.

TIB Bwce 2.6.2 Concepts

Uploaded by

Copyright:

Available Formats

TIB Bwce 2.6.2 Concepts

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TIB Bwce 2.6.2 Concepts

Uploaded by

Copyright:

Available Formats

What are the different integration styles supported?

What are the different integration styles supported?

What are the key concepts encountered when working with TIBCO BusinessWorks?

What are the key concepts encountered when working with TIBCO BusinessWorks?

TIBCO BusinessWorks™

Copyright © 2015-2021. TIBCO Software Inc. All Rights Reserved.

Additional General Concepts 20

TIBCO BusinessWorks™ Container Edition Concepts

Mapping Concepts to a Sample: Managing Books for a Bookstore 35

TIBCO Documentation and Support Services 41

Legal and Third-Party Notices 43

TIBCO BusinessWorks™ Container Edition Concepts

TIBCO BusinessWorks™ Container Edition Concepts

Openness and Extensibility

TIBCO BusinessWorks™ Container Edition Concepts

l Large teams and distributed development through modular constructs.

Layout of the Concepts Guide

TIBCO BusinessWorks™ Container Edition Concepts

Note: The term module is used interchangeably with OSGi bundle.

TIBCO BusinessWorks™ Container Edition Concepts

TIBCO BusinessWorks™ Container Edition Concepts

An application module typically contains one or more processes. An application module

TIBCO BusinessWorks™ Container Edition Concepts

Use the Component section under the Module Descriptor node to

The application modules cannot export their functionality to other modules.

Structure of an Application Module

TIBCO BusinessWorks™ Container Edition Concepts

Relationship Between Application Modules and Shared Modules

TIBCO BusinessWorks™ Container Edition Concepts

Binary Shared Modules

TIBCO BusinessWorks™ Container Edition Concepts

TIBCO BusinessWorks™ Container Edition Concepts

TIBCO BusinessWorks™ Container Edition Concepts

The OnStartup operation is called when an application is started, but before

TIBCO BusinessWorks™ Container Edition Concepts

Note: Detailed descriptions of palettes are available in the TIBCO

Activities can be classified into three types:

TIBCO BusinessWorks™ Container Edition Concepts

TIBCO BusinessWorks™ Container Edition Concepts

In TIBCO Business Studio for BusinessWorks, transitions are displayed as an arrow

l Transitions Without Conditions: Control automatically flows from one activity or

Note: Error transitions take precedence over fault handlers. If an error is

TIBCO BusinessWorks™ Container Edition Concepts

Job Shared Variables

TIBCO BusinessWorks™ Container Edition Concepts

Additional General Concepts

Groups Without Conditions (Non-repetitive)

TIBCO BusinessWorks™ Container Edition Concepts

Groups With Conditions (Repetitive)

TIBCO BusinessWorks™ Container Edition Concepts

Relationship Between Properties

TIBCO BusinessWorks™ Container Edition Concepts

Features of Process, Module, Shared Module, and Application Properties

Process Visible within a Literal, module Literal values cannot be

Module l Visible within the l Literal or a Cannot be assigned to an

Shared l Visible within the l Literal or a l Shared Module

Application l Only available l Literal. l Overrides module

TIBCO BusinessWorks™ Container Edition Concepts

Property Scope/Visibility Values Additional Information

Properties for an l Profiles can properties, thus