TIBCO BusinessWorks™

Container Edition
Concepts
Version 2.7.1
February 2022

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

2 | Contents

Contents
Contents 2

Overview 4
Key Concepts 5
Flexibility 6
Openness and Extensibility 6
Modularity 6
Standards-based 7
Layout of the Concepts Guide 7

General Concepts 9
Applications 9
Modules 10
Application Modules 11
Shared Modules 13
Binary Shared Modules 15
Processes 16
Activities 19
Palettes 20
Transitions 21
Shared Resources 22
Shared Variables 23

Additional General Concepts 24

Groups 24
Groups Without Conditions (Non-repetitive) 25
Groups With Conditions (Repetitive) 25
Properties 26

TIBCO BusinessWorks™ Container Edition Concepts

3 | Contents

Shared Variables 28
Module Shared Variables 29
Job Shared Variables 30
Shared Variable Synchronization 30
Fault Handlers 31
Module Property 32
Components 33
Component Services 34
Component References 34
Services 35
Operations 36
SOAP Services 36
REST Services 36
Policies 37
Policy Definitions and Concepts 38

Mapping Concepts to a Sample: Mortgage Broker Service and Client 42

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

Design-time Concepts 45

Runtime Concepts 49

TIBCO Documentation and Support Services 51

Legal and Third-Party Notices 53

TIBCO BusinessWorks™ Container Edition Concepts

4 | Overview

Overview
TIBCO BusinessWorks™ Container Edition is an integration product suite for enterprise,
web, and mobile 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 run time 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.

TIBCO BusinessWorks™ Container Edition Concepts

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 environment where you
execute the applications.
TIBCO BusinessWorks Container Edition consists of a design-time where you can develop
applications that implement business logic, the runtime where you execute the
applications, and the administration component where you deploy and manage
applications in the runtime. The runtime is an ecosystem of entities that can be co-located
or distributed. You can deploy, monitor, and manage the applications by using the bwadmin
utility and TIBCO® Enterprise Administrator.

TIBCO BusinessWorks Container Edition is based on open architecture, flexibility,

modularity, and support for standards.

TIBCO BusinessWorks™ Container Edition Concepts

6 | Overview

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 Ability to manage the process state that is maintained across invocations either by
the run time container (process engine) or by the process implementation.
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 run time.
l Extensible administration framework based on TIBCO® Enterprise Administrator.

Modularity
Modularity of the product supports:
l Large teams and distributed development through modular constructs.

TIBCO BusinessWorks™ Container Edition Concepts

7 | Overview

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 TIBCO Products: TIBCO Rendezvous™, TIBCO Enterprise Message Service™ (EMS),
TIBCO AE Schema
l Others: FTP, JNDI, SMTP, TCP
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.

TIBCO BusinessWorks™ Container Edition Concepts

8 | Overview

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.

TIBCO BusinessWorks™ Container Edition Concepts

9 | 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.
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. An application contains one
application module which consists of one or more processes. Understanding the 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

TIBCO BusinessWorks™ Container Edition Concepts

10 | General Concepts

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

TIBCO BusinessWorks™ Container Edition Concepts

11 | General Concepts

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.

An Application module is the smallest unit of resources 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.

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

TIBCO BusinessWorks™ Container Edition Concepts

12 | General Concepts

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.

Note: 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.

TIBCO BusinessWorks™ Container Edition Concepts

13 | General Concepts

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.

TIBCO BusinessWorks™ Container Edition Concepts

14 | General Concepts

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.

TIBCO BusinessWorks™ Container Edition Concepts

15 | General Concepts

Note: 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.

TIBCO BusinessWorks™ Container Edition Concepts

16 | General Concepts

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.

TIBCO BusinessWorks™ Container Edition Concepts

17 | General Concepts

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 Process Starters, Signal-Ins, and Processes and Bindings.

Stateful Process
A process that relies on the TIBCO BusinessWorks Container Edition engine to maintain
its state across invocations is called a stateful process. As the engine maintains its state,
a stateful process does not require an external persistence store.

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

TIBCO BusinessWorks™ Container Edition Concepts

18 | General Concepts

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.

TIBCO BusinessWorks™ Container Edition Concepts

19 | General Concepts

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.

Note: The activator process in ActiveMatrix BusinessWorks 6.x provides the

same functionality as that of the OnStart and OnShutDown activities in
ActiveMatrix BusinessWorks 5.x.

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 activity is

represented by the 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

TIBCO BusinessWorks™ Container Edition Concepts

20 | General Concepts

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. Signal-in activities are always blocking.
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.
l Signal-in Activities wait for an asynchronous event in a process. They proceed with
executing the process instance when an appropriate event is received. Signal-in
activities require conversations to be configured. For more information, see
Conversations.

Note: For details about the TIBCO Business Studio for BusinessWorks
development environment, see the Concepts Guide.Design-time Concepts

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.

TIBCO BusinessWorks™ Container Edition Concepts

21 | General Concepts

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

TIBCO BusinessWorks™ Container Edition Concepts

22 | General Concepts

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. For example, you can define a JDBC Connection resource and then
use it in any of the JDBC activities in your process to connect to the database.
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.

TIBCO BusinessWorks™ Container Edition Concepts

23 | General Concepts

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.

TIBCO BusinessWorks™ Container Edition Concepts

24 | 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).

TIBCO BusinessWorks™ Container Edition Concepts

25 | Additional General Concepts

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.
l Local Transaction : Local Transaction group provides for activities such as
database updates. It performs auto commit on a local transaction at the end of the
group, making the use of transactional activities easier for users.

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.

TIBCO BusinessWorks™ Container Edition Concepts

26 | Additional General Concepts

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. 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

TIBCO BusinessWorks™ Container Edition Concepts

27 | Additional General Concepts

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

Property Scope or 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 resource application level.
reference.

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

Properties the module. shared activity directly. You need
resource to reference a module
l Private module
reference. property from a process
properties
property, and then
cannot be l Private
reference the process
viewed from the module
property from the activity.
Admin UI. property
values cannot
l Not visible or
be edited
changeable from
from the
the Admin UI.
Admin UI.

Shared l Visible within l Literal or a l Shared Module

Module the 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 directly.

TIBCO BusinessWorks™ Container Edition Concepts

28 | Additional General Concepts

Property Scope or Visibility Values Additional Information

Module that the values cannot You need to reference

Shared Module be edited a module property
Property came from the from a process
from. Admin UI. property, and then
reference the process
l Private module
property from the
properties
activity.
cannot be
viewed from the l Can be used for
Admin UI. activities, process
properties, shared
l Not visible or
resources, and SOAP
changeable from
Bindings.
the Admin UI.

Application l Only available l Literal. l Overrides module

Properties for an properties, thus
l Profiles can
application and enabling you to use
be used to
visible within the different values for
specify a new
application. the same module.
set of values
These properties
for the same l Cannot add new
are visible from
application. properties at
the Admin UI.
application level.

Note: For more information about the TIBCO Business Studio for BusinessWorks
development environment, see Design-time Concepts.

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.

TIBCO BusinessWorks™ Container Edition Concepts

29 | Additional General Concepts

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.
Persistent Module Shared Variable
The current state of a module shared variable is stored in memory by default and the state
of the module shared variable is lost in case the TIBCO BusinessWorks Container Edition
engine (or the AppNode) crashes. However, to preserve the current state in case of an
engine failure, the module shared variable can be configured to be persistent.
For more information on configuring module shared variables with persistent option, see
"Using Shared Variables" in TIBCO BusinessWorks™ Container Edition Application
Development.
When a module shared variable is configured as persistent, its current state is written to
the engine database and on engine restart the module shared variable state is restored.
Sharing Module Shared Variable Across Multiple Engines (AppNodes)
A module shared variable state can be accessible across multiple engines if the engine
persistent mode (bw.engine.peristentMode) is set to "group" and the module shared
variable is configured to be persistent.
For more information on configuring engine persistence, see "Engine Persistence Modes" in
TIBCO BusinessWorks™ Container Edition Administration guide.

TIBCO BusinessWorks™ Container Edition Concepts

30 | Additional General Concepts

Using the persistence option, the same TIBCO BusinessWorks Container Edition
applications running in multiple engines (AppNodes) that are part of the same engine
group can read or update the module shared variable state. Once the value is updated, the
new value is available to all engines (AppNodes) which are running the same application.

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,

TIBCO BusinessWorks™ Container Edition Concepts

31 | Additional General Concepts

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.

TIBCO BusinessWorks™ Container Edition Concepts

32 | Additional General Concepts

Sample Fault Handlers

If an exception is caught in the inner scope, the exception is logged to a file and the scope
is completed. The process execution then continues to the Write File activity, which is the
next activity in the process. 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. For more information, see Error Transitions.

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.

Module Property
Module property provides the default value for a module. Multiple process properties can
source their value from a single module property.

TIBCO BusinessWorks™ Container Edition Concepts

33 | Additional General Concepts

Module properties are defined at the module level and can be referenced by various
resources that are defined as a part of the module. Their values can also be sourced from
application properties at deployment time.

Note: A module property cannot be assigned directly to an activity. It must be

assigned to a process property in order to be used in an activity. The process
property inherits the value of the module property that is assigned to it. The
process property can then be used in the activity. Module properties can be used
directly only when configuring shared resources and policy resources.

The Module Properties editor can be used to create and manage module properties. You
can add a new property or logical groups which you can use to organize module
properties.

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.

TIBCO BusinessWorks™ Container Edition Concepts

34 | Additional General Concepts

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:

TIBCO BusinessWorks™ Container Edition Concepts

35 | Additional General Concepts

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.

TIBCO BusinessWorks™ Container Edition Concepts

36 | Additional General Concepts

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

TIBCO BusinessWorks™ Container Edition Concepts

37 | Additional General Concepts

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 allows the following HTTP operations to
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.
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:

TIBCO BusinessWorks™ Container Edition Concepts

38 | Additional General Concepts

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.

TIBCO BusinessWorks™ Container Edition Concepts

39 | Additional General Concepts

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.

TIBCO BusinessWorks™ Container Edition Concepts

40 | Additional General Concepts

Policy Shared Resource

Basic Authentication l LDAP

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
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.

Governance Agent
The governance agent is a TIBCO BusinessWorks Container Edition run time component
that dynamically enforces policies during runtime. A governance agent must be enabled on
an appnode to enforce policies applied to TIBCO BusinessWorks Container Edition
applications.

TIBCO BusinessWorks™ Container Edition Concepts

41 | Additional General Concepts

For instructions on enabling the governance agent, see "Enabling the Governance Agent" in
TIBCO BusinessWorks™ Container Edition Administration.

TIBCO BusinessWorks™ Container Edition Concepts

42 | Mapping Concepts to a Sample: Mortgage Broker Service and Client

Mapping Concepts to a Sample: Mortgage

Broker Service and Client
The concepts introduced in sections General Concepts, Groups, Conversations, and
Services together enable you to understand and design a service-oriented solution such as
the Mortgage Broker Service Client example.

Pre-requisites
The Mortgage Broker Service Client sample demonstrates the concepts introduced in the
following sections:
l General Concepts
l Groups
l Conversations
l Services
l SOAP Services

After reading these sections, you should be able to understand and execute a service-
oriented sample such as the Mortgage Broker Service Client.

Mortgage Broker Service Client Sample

In this sample, a service implements a simplified online mortgage broker application. The
borrower requests a loan through a broker. The broker processes the loan request using
one of the third-party partner services. The borrower can either specify the preferred third-
party provider or allow the broker to default to one. The third-party partner services
request credit rating of the borrower from a credit check service and in turn approves or
rejects the loan application based on the credit rating.
The Mortgage Broker Service Client sample project is shipped with the product and can be
accessed in TIBCO Business Studio for BusinessWorks from Help > BusinessWorks
Samples.
Next Steps

TIBCO BusinessWorks™ Container Edition Concepts

43 | Mapping Concepts to a Sample: Mortgage Broker Service and Client

After completing this section, you should be able to design service-oriented processes with
minimal assistance.

TIBCO BusinessWorks™ Container Edition Concepts

44 | 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.

TIBCO BusinessWorks™ Container Edition Concepts

45 | 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

TIBCO BusinessWorks™ Container Edition Concepts

46 | Design-time Concepts

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

TIBCO BusinessWorks™ Container Edition Concepts

47 | Design-time Concepts

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

TIBCO BusinessWorks™ Container Edition Concepts

48 | Design-time Concepts

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.

TIBCO BusinessWorks™ Container Edition Concepts

49 | Runtime Concepts

Runtime Concepts
Runtime refers to the Appnode and the TIBCO BusinessWorks Container Edition engine that
hosts and executes the TIBCO BusinessWorks Container Edition applications.

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 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".

TIBCO BusinessWorks™ Container Edition Concepts

50 | 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, JMS, and so on), 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.

TIBCO BusinessWorks™ Container Edition Concepts

51 | 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
The following documentation for this product is available on the TIBCO BusinessWorks™
Container Edition page:
l TIBCO BusinessWorks™ Container Edition Release Notes
l TIBCO BusinessWorks™ Container Edition Installation
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 Tuning
l TIBCO BusinessWorks™ Container Edition REST Implementation
l TIBCO BusinessWorks™ Container Edition Refactoring Best Practices

TIBCO BusinessWorks™ Container Edition Concepts

52 | TIBCO Documentation and Support Services

l TIBCO BusinessWorks™ Container Edition Samples

How to Contact TIBCO Support

You can contact TIBCO Support in the following ways:
l For an overview of TIBCO Support, visit http://www.tibco.com/services/support.
l For accessing the Support Knowledge Base and getting personalized content about
products you are interested in, visit the TIBCO Support portal at
https://support.tibco.com.
l For creating a Support case, you must have a valid maintenance or support contract
with TIBCO. You also need a user name and password to log in to
https://support.tibco.com. If you do not have a user name, you can request one by
clicking Register on the website.

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.

TIBCO BusinessWorks™ Container Edition Concepts

53 | 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, ActiveMatrix BusinessWorks, ActiveSpaces, Business Studio,
TIBCO Business Studio, TIBCO Designer, Enterprise Message Service, Hawk, 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
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.

TIBCO BusinessWorks™ Container Edition Concepts

54 | 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-2022. TIBCO Software Inc. All Rights Reserved.

TIBCO BusinessWorks™ Container Edition Concepts