Contents
Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Related Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv
TIBCO BusinessWorks Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv
Other Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv
How to Contact TIBCO Customer Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Chapter 3 Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Business Process Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
TIBCO BusinessWorks Solves Enterprise Integration Problems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Overview of Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Process Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Shared Configuration Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Subprocesses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Developing Process Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Chapter 4 Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Activity Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Activity Icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Advanced . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Process Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Mapping and Transforming Activity Input Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Process Starters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Start Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Figures
Tables
Preface
Topics
Related Documentation
Other Documentation
TIBCO BusinessWorks is bundled with other products. You will therefore find the
documentation for those products useful:
• TIBCO Designer documentation. TIBCO Designer is an easy to use graphical
user interface for design-time configuration of TIBCO applications. TIBCO
Designer includes online help for each palette.
• TIBCO Administrator documentation. TIBCO Administrator is the
monitoring and managing interface for new-generation TIBCO products such
as TIBCO BusinessWorks.
• TIBCO Adapter product documentation
For comments or problems with this manual or the software it addresses, please
contact TIBCO Product Support at:
http://support.tibco.com
Entry to this site requires a username and password. If you do not have a
username, you can request one. You must have a valid maintenance or support
contract to use this site.
TIBCO Designer is an easy to use graphical user interface for creating and
deploying integration projects. TIBCO Designer allows you to easily drag and
drop components into a project and then specify configuration information for
each component.
This chapter and the next give an introduction to TIBCO Designer and working
with projects. If you are unfamiliar with TIBCO Designer, these chapters
introduce you to the basic concepts needed before attempting to create automated
business process definitions.
Topics
How to start TIBCO Designer depends upon the platform you are using. The
following sections describe how to start TIBCO Designer and explains the options
available once TIBCO Designer starts.
Startup Options
When you launch TIBCO Designer, the startup window is displayed. Figure 1
illustrates the startup window.
Option Description
New empty Opens a new empty project in TIBCO BusinessWorks. An
project empty project includes
• Root folder displayed in the project tree panel.
• Schemas folder displayed in the project tree and the
design panel. Most schema resources are automatically
created during configuration. Advanced users define
schema using the resources in that folder.
Root folder
Schemas folder
Open existing Opens an existing project. See Opening Projects on page 22.
project
Option Description
Help Displays TIBCO BusinessWorks documentation. You may be
prompted for your browser if you are using TIBCO
BusinessWorks for the first time. Click Help in the dialog to
display the location in which browsers are installed by
default.
Show this If checked, the panel is only displayed during startup and
panel only on closed after you’ve made your selection.
startup
If unchecked, this panel reappears when no other TIBCO
BusinessWorks windows are open. Leaving the panel on
screen is useful for project maintenance.
The TIBCO Designer interface allows you to perform various functions. This
section describes the TIBCO Designer main window and explains what you see in
each of its panels.
Main Window
Figure 2 illustrates the TIBCO Designer main window.
Menu bar
Toolbar
Configuration
Palette
panel
panel
When you first start TIBCO Designer on a machine, it displays its default view.
You can then customize your display. Customization is saved and remains in
effect, even if you uninstall the product and install a different minor version.
ProcessNewComputer project
Resources
Resources are the components of a project. A simple TIBCO Designer resource
corresponds to an object in a TIBCO application, such as an adapter
configuration, an adapter service, a process definition, or an FTP activity. The
illustration below shows the resources of the ProcessNewComputer project in
both the project tree and the design panel.
Resources Resources
in project tree in design
panel
Resources can be complex and contain other resources, much like a folder can
contain other folders on your computer’s file system. For example, an adapter
configuration may contain multiple folders with multiple publisher or subscriber
service resources.
Most resources have context-sensitive help available for the configuration of that
resource. Right-click on the resource and choose What Is This? from the popup
menu for more information on configuring the resource.
Palette Panel
Palettes organize resources and allow you to add them into your project. You
select resources in the palette panel and drag-and-drop them into the design
panel to add them to your project.
TIBCO BusinessWorks contains a small number of native palettes. In addition,
each TIBCO application you install adds one or more palettes during installation.
Which palette is displayed depends on the resource selected in the project tree
and on your preferences (See Customizing the Display on page 8). In the default
view, the current selection in the project tree determines which palettes are
displayed in the palette panel.
For example:
• Select the root folder to see a palette for each installed adapter and some other
palettes for general resources.
• Select the Adapter Services folder of an adapter in the project tree to see a
palette of service resources. Drag any service resource into the design panel to
add that resource to that adapter.
Design Panel
The design panel displays the current resource selected in the project tree panel.
For resources that contain other resources, the contents of the selected resource
are shown in the design panel. For example, if you select a folder, its contents is
displayed.
Configuration Panel
The configuration panel allows you to specify configuration options for the
selected resource. The type and the purpose of the resource determine the
contents of the configuration panel. There are usually one or more tabs in the
configuration panel that allow you to access the various configuration options.
The tabs provide an organization to the options for the resource.
You can click the question mark icon (?) in the top right corner of the
configuration panel for online help on the current selection.
For each tab, you must click Apply after you have specified configuration
information before you can select another tab. If you decide you do not want to
add the configuration information, click Reset before you apply any changes to
return to the previous values for each field in the tab.
User preferences determine how TIBCO Designer displays palettes and the
panels. You can also add custom palettes to TIBCO Designer. This section gives an
overview of the most frequently used custom preferences.
Display preferences and other preferences are saved when you exit TIBCO
Designer, even if you do not save your project.
To return to Designer default settings, remove the preference file, which can be
found in the following locations:
• Windows 2000: C:\Documents and Settings\<userid>\.TIBCO
Project
panel
Design
panel
Configuration
panel
To navigate to palettes in this view, click the Palettes tab. The next diagram shows
the results of this action.
Select
Palettes
While in palette mode, you can close individual palettes using the Close button
on the right.
To redisplay a closed palette, choose Edit > Preferences > Palettes, then select the
palette and, in the bottom panel, the categories for which it should be displayed.
If you do not see Close buttons, choose Edit > Preferences > Palettes, then select
Show Close Buttons on Palettes.
Only All
currently resources
usable display in
resources each
display palette
Close
button
Choose one of the following methods to switch between category mode and
palette mode:
• Choose Edit>Preferences>Palettes, then select or unselect the Show
Category Palettes checkbox and click OK.
• Click the Switch Palette Modes button located in the tool bar.
Switch Palette Modes
Select
palette
Select or unselect
resource category
Select a palette, then click to select or unselect a resource category. If you unselect
all resource categories for a palette, the palette (or resources from that palette)
does not display in TIBCO Designer.
Projects are the key organizational principle for the configuration information you
specify with TIBCO BusinessWorks.
This chapter explains how to create, open, and save projects. It also discusses how
to use the project maintenance facility for backups.
It is not possible to have multiple projects open at the same time. You therefore
create new projects and open projects from the startup window.
Topics
Overview of Projects
Project Templates
A project template is a pre-built project. It can contain folders for organization,
configured resources, and partially configured resources. You can use a project
template as the foundation for other projects similar in nature. Using a template
you can leverage your work when performing similar configurations.
Project Maintenance
When you save a project for the first time, you are prompted whether you want to
keep backups. See Using Project Backups (Maintenance) on page 20 for more
information on backups.
Creating Projects
You create a new project using the startup window when starting TIBCO
BusinessWorks. Also, if you did not select the Display this window only on
startup check box in the startup window, you may close the current project to
return to the startup window and create a new project.
To save a server-based project, you must have full access privileges for the
domain. Users with administration privileges can perform user management,
including assigning full access privileges, using the TIBCO Administrator GUI.
For server-based projects, the user specified in the Create Project dialog
must have full access privileges for that domain to create a new project.
Saving Projects
If you used the Project>Save As menu, the tab corresponding to the menu
item you chose is selected.
3. Next, the Backup? prompt lets you choose to keep backups of your project.
— If you click Yes, TIBCO Designer keeps incremental backups of your
project. Each time you save a project, you are prompted for a label. TIBCO
BusinessWorks then keeps backups of the differences between versions of
the project. You can restore from any label you choose, as long as the
maximum storage limit has not been exceeded. See Customizing
Maintenance Settings on page 22
— If you click No, TIBCO BusinessWorks does not keep incremental backups
and does not prompt you for a label. If you later decide to keep backups,
supply a size for the project in the Project Maintenance dialog available
by way of the Maintain a Project option from the startup window.
Storage Tab
Once you have saved a project, you can select the Storage tab to view and to
copy/paste information about the project.
Field Description
Instance Type Either remoteRv for server-based repositories or
localFile for file-based projects.
• Use the TIBCO Designer Repository Finder tool to change the encoding for
the project to UTF-8. See the TIBCO Designer Repository Management Guide
available via Help> Help For > Repository.
Keeping Backups
To keep backup copies of a project that has never been saved before, follow these
steps:
1. After you exit the Save Project dialog, you are prompted whether you want
to keep backup copies. Click Yes.
2. Each time you save a project, you are asked for a label of that version. Provide
a label that helps you remember the state of the project later.
If you decide you no longer want to keep backups, set the Maximum Total
Backup Size to 0. To access it, choose the Maintain a project option in the
startup window.
When you restore a backup, all later versions of the project, including the most
recently saved version, are altered and can no longer be opened in TIBCO
Designer. Consider saving your project under a different name before you restore
a backed up version.
The most recently saved project is not in the list of backups that you can
restore. Instead, you can simply open that project. You select the backup from
the list by the date/time it was saved. Once selected, the backup label is
displayed.
5. Click Restore Project. A dialog informs you that when you select a backup, all
later versions of the project (including the saved project) are altered and can
no longer be used.
Increasing the size has no side effects, decreasing the size can remove backups to
fit the new size, and decreasing to 0 removes all backups
Opening Projects
You can open a project from the startup window when you launch TIBCO
BusinessWorks. If TIBCO BusinessWorks is already open, close the existing
project to return to the startup window. (If you selected the "Show this panel only
on startup" check box in the startup window, you must restart TIBCO
BusinessWorks to open a project.)
You can save the project to a local file or as a server-based project managed by a
TIBCO Administration Server. When you open a project, you are therefore always
given the option of opening a local file or a server-based project.
You can open projects or other repository files. It is not required that the project
was created in TIBCO Designer.
Local File
Allows you to open a project that has previously been saved in a file. A window
prompts you for the user name and location of the file. Click Browse to select the
file.
Server-based Project
Opens a server-based project. The server is a TIBCO Administration Server if you
are using TIBCO Designer as part of TIBCO BusinessWorks, or a TIBCO
Repository Server otherwise. If running TIBCO Designer in standalone mode, you
may need to start the Repository Server explicitly.
To open a server-based project, you must specify your user name and password.
You can only open a project if you have appropriate permissions.
For projects that are created as part of TIBCO BusinessWorks, username and
password are assigned using TIBCO Administrator.
A window prompts you for information. Click the Show Advanced button to
show TIBCO Rendezvous connection parameters. Note that in most cases, the
default is appropriate.
You can click Load Project List to retrieve a list of projects using the current
connection parameters.
Field Description
User Name of the user who wants to access the project.
Project Name Name of the project. Type in a name or click Load Project
List to retrieve a list of projects in the domain (or managed
by the server) specified above.
A TIBCO Administration Server (or TIBCO Repository Server) for a domain must
be running if you want to access remote repositories.
Importing a Project
When you import a project into another project, you add all the resources in the
imported project into the current project.
Once you have started TIBCO Designer, you can add resources to your project.
Adding resources involves finding the resource in the appropriate palette and
dragging and dropping it into the design panel.
You can also select the resource in the palette panel and choose Add This To The
Project from the right-button menu.
Drag into
design
panel
Ideally, all resources that cannot be dragged into the design panel should be
greyed out (palette mode) or not visible (resource mode). For some custom
palettes that may not always be true.
Be sure to choose the appropriate location for import. That is, you cannot import a
resource into another resource that cannot accept the imported resource.
For example, you cannot import a Sessions Folder or a Publisher resource into a
Sessions folder. You can only import Session resources and, optionally, their
associated endpoints.
Note that if a resource with the same name as the imported resource already exists
in the desired location, TIBCO Designer will not import the resource.
Once you have imported a resource, you can move the resource to a different
location, if you desire.
Global variables provide an easy way to set defaults for use throughout your
integration project.
For example, you could define a variable RvService and set its value to 7500. You
can then assign the variable to different sessions in your adapter. If you wish to
change the TIBCO Rendezvous service for your adapter, change only the global
variable and you do not have to edit each individual session.
3. When you want to use the global variable in the fields of a resource, enter the
variable name surrounded by %% on both sides. In the illustration below, the
variable RvServiceTest is used as the service.
When the project is deployed and the configured components run, TIBCO
BusinessWorks replaces all occurrences of the global variable name with the
global variable value. For example, RvServiceTest would be replaced with
7800.
Chapter 3 Processes
Topics
Most businesses choose the best application or environment for processing each
component of their core business. For example, in a typical enterprise, the flow of
information and processing between each application is what drives the
day-to-day operations of the business. For example, the order-entry application
receives and processes orders based on availability information taken from the
inventory system. The tracking system relies on order information and shipping
information. Also, accurate and up-to-date reporting information is required from
all systems.
Figure 9 illustrates an example enterprise computing environment with various
systems running in different environments.
Inventory
Reporting
Tracking
Many companies implement the business rules that tie the systems together using
custom-written code or by manual processes. Tying together different systems
from different vendors that run in different environments is a labor-intensive and
error-prone process that usually takes months of planning and implementation.
Also, because the task of creating the custom business logic is so complex,
businesses often rely on manual, paper-based processes instead of automating the
process for greater efficiency.
Figure 10 illustrates a business process flow, sometimes known as a workflow,
that describes the business rules between the various systems in an enterprise.
Tracking Reporting
CHECK ORDER STATUS GET SHIPPED ORDER FROG REPORT
Overview of Processes
Machine A
TIBCO Designer
Project
TIBCO BusinessWorks Process Engine
Process
Definition A Process
Instance A-1
Process
Instance A-2
Process
Definition B
Process
Instance B-1
Process
Instance B-2
Process
Instance B-3
Process engines are started using TIBCO Administrator after you deploy your
project. For more information about deploying a project, see the TIBCO
BusinessWorks Administrator’s Guide.
The remainder of this book describes how to create the process definitions that
eventually become running process instances.
Process Definitions
The process definition describes the business process. When the process
definition is executed, it is known as a process instance.
Process definitions consist of these components:
• Activities
• Transitions
• Groups
• Shared Configuration Resources
• Subprocesses
The following sections describe these components. See Developing Process
Definitions on page 40 for a description of how to develop your process
definitions.
Activities
Activities are the individual units of work within a process definition. Activities
are generally operations that interface to external systems, but activities can also
perform internal processing. Activities are available on the various palettes within
TIBCO Designer. Each palette has a set of activities that can be performed for that
palette.
For example, the Adapter palette has activities that can publish messages to a
specified adapter or invoke an operation by way of an adapter. There is also an
FTP palette that can invoke the PUT and GET commands on an FTP server.
Transitions
Having multiple branches within a process definition does not imply that each
branch is processed concurrently. Transitions describe control flow of the process
definition, not the concurrency of execution of activities. Process execution is
controlled by the process engine. See TIBCO BusinessWorks Administrator’s Guide
for more information about configuring the TIBCO BusinessWorks process
engine.
Each activity in a process definition must have a transition to it, or the activity is
not executed when the process executes.
Chapter 5, Transitions and Conditions, on page 61 describes transitions and
conditions.
Groups
Groups are used to specify related sets of activities. The main uses of groups are
the following:
• To create a set of activities that have a common error transition. Basically, this
is similar to a try...catch block in Java. This allows you to have a set of
activities with only one error-handling transition, instead of trying to
individually catch errors on each activity.
• To create sets of activities that are to be repeated. You can repeat the activities
once for each item in a list, until a condition is true, or if an error occurs.
• To create sets of activities that participate in a transaction. Activities within the
group that can take part in a transaction are processed together, or rolled back,
depending upon whether the transaction commits or rolls back.
Chapter 6, Grouping Activities, on page 67 describes groups and how to use them
within a process definition.
Shared configuration resources are specifications that are shared among activities.
These are resources, such as database connections, WSDL files, schema
definitions, and connections to other servers. Shared configuration resources are
created outside of process definitions, but they are used when specifying the
Configuration tab of some activities.
TIBCO BusinessWorks Palette Reference describes shared configuration resources.
Subprocesses
Business processes are often very complex and it is difficult to diagram the
complete process in one process definition. You can create several smaller process
definitions instead of one monolithic process definition. You can then call each
process definition from another process definition, when necessary. When you
call a process definition, the called process is known as a subprocess. Using
subprocesses helps to make more readable process diagrams and you can reuse
subprocesses across many process definitions.
Subprocesses cannot have process starters. That is, they must begin with the Start
activity, not any activity that receives an event from an outside source.
Pass customer ID to
CreditCheck
subprocess. The
subprocess returns
whether the customer
has sufficient credit.
Subprocess
Create Shared
Create Process Add Process
Configuration Add Activities
Definition Starter
Resources
Chapter 4 Activities
Activities perform the work within a process definition. This chapter describes
activities and how to use them in a process definition.
Topics
Activity Overview
Activities are the individual units of work within a process definition. Activities
are generally operations that interface to external systems, but activities can also
perform internal processing. Activities are available on the various palettes within
TIBCO Designer. Each palette has a set of activities that can be performed for that
palette. For example, the following activities are included in the ActiveEnterprise
Adapter palette:
The following are examples of palettes and some of the activities the palettes
contain:
• File
— Create File
— Remove File
— Write File
— Read File
• FTP
— FTP Put
— FTP Get
• JDBC
— JDBC Query
— JDBC Call Procedure
— JDBC Update
• Mail
— Send Mail
When you are within a process definition in TIBCO Designer, the activity palettes
are available to drag and drop activities into the process definition. Each activity
usually has two or more of the following tabs for specifying the characteristics of
the activity:
• Configuration — Used for general configuration of the activity. For example,
this tab specifies the adapter service to use for an Adapter activity.
• Advanced — Any advanced configuration parameters are specified here.
• Event — For activities that wait for incoming events, such as HTTP requests
or incoming TIBCO Rendezvous messages, this tab specifies the timeout for
the incoming event and a condition to determine whether the incoming event
is the correct one for the specific process instance.
• Schema — A data schema for the activity. This is used when the input or
output data is not known by the activity, and the user must specify their own
schema. Once specified, the schema becomes available on the Input, Output
or both tabs of the activity.
• Input — The output data from all activities that precede this activity in the
process definition is available for mapping to this activity’s input schema.
• Output — The activity’s data is output to activities that follow in the process
definition.
The sections that follow describe each tab used to specify an activity. There is a
chapter for each available activity palette. See the activity palette chapter for more
information about the specific activity you wish to use.
There are two activities that are included in a process definition by default: the
Start activity and the End activity. See Start Activity on page 58 and End Activity
on page 59 for more information about these activities.
Activity Icons
Each activity is represented by an icon in the palette and design panels. These
icons represent the function of the activity. There are some common elements of
activity icons that represent the type of activity and the direction of data between
the activity and the process.
Table 3 describes the various elements within activity icons.
Configuration
The configuration tab contains the general specifications for the activity. For
example, an FTP activity would contain specifications for the FTP session, such as
whether the type of data being sent is text or binary or whether the FTP server
resides outside of a firewall. Required fields on the configuration tab are
displayed in bold so that it is easy to see the minimum required information for
configuration of an activity.
In general, all activities allow you to specify a name for the activity and provide a
short description on the Configuration tab. Any other items on the configuration
tab are the required configuration elements you must specify to make the activity
work.
See the chapter for the palette you are interested in TIBCO BusinessWorks Palette
Reference for more information about the Configuration tab of the activities within
that palette.
Advanced
Event
The Event tab is available on activities that expect an incoming event. These are
activities that wait for an incoming event within a process. These activities cause
the process instance to suspend until the incoming event is received. An Event tab
has the following fields:
Field Description
Event Key Expression used to evaluate whether the incoming
message is appropriate for this process. This
expression is specified in XPath, and only data from
the incoming event is available for use in this XPath
expression. See Chapter 8, XPath, on page 105 for
more information about XPath expressions.
Table 4 describes the available activities with Event tabs. See the chapter for the
palette you are interested in for more information about tasks that have Event
tabs.
Schema
The Schema tab is used to specify a data schema for input or output of an activity.
This is useful when the data does not have a well-known structure. The Schema
tab is usually named for the type of schema you are creating. For example, the tab
may be named "Input Schema" or "Output Schema".
For example, an email message has a well-known data structure, and therefore
does not need a special datatype for its input. A JMS message, however, can have
application-specific properties of any datatype. The Schema tab allows you to
define the schema for any activities that require a specialized input or output
schema.
You can use a simple datatype, or you can define a group of data elements on this
tab. You can also reference XML schema or ActiveEnterprise classes stored in the
project. Once defined, the schema appears on the Input tab, the Output tab, or
both tabs of the activity. The data within the schema then becomes available to
other activities within the process definition.
The following illustrates the Schema tab. In this example, the Schema tab is
labeled "Output Schema" indicating this is the activity’s output.
To define a schema on this tab, use the buttons above the schema tree to add,
delete, or move data items. Then use the fields of the dialog to specify the
datatype of each item.
Field Description
Name The name of the data item.
Cardinality The qualification for the data item. Data items can be
specified as one of the following:
• Required — the data item is required and must be
supplied when the process is called.
• Optional — the data item is optional.
• Repeating, Zero or More — The data item is a list
that has zero or more elements.
• Repeating, One or More — The data item is a list
that has one or more items.
Field Description
Schema Name Stored XML schema that contains the element or type
you wish to reference.
Icon Description
Complex element. Container for other datatypes. This is a
branch in the schema tree.
Integer value. You can specify the size of the integer as one of
the following:
• Byte
• Short
• Int
• Long
• Unsigned Byte
• Unsigned Int
• Unsigned Long
• Integer
• Positive Integer
• Negative Integer
• Non-positive Integer
• Non-negative Integer
Icon Description
Floating point number. You can specify the size of the
schema item as float, double, or unlimited.
Boolean value.
Input
The Input tab allows you to map and transform output data from the previous
activities in the process (including the event that starts the process) to input data
for the activity. The Process Data area contains the output from all of the activities
that appear prior to the activity in the process definition. The Activity Input area
lists the current activity’s required and optional input data.
The following illustrates the input tab.
Process Variables
The Process Data area contains all process variables available to the activity.
Process variables are data that come from the process, the project, or from other
activities in the process. An activity has access to any data that is output from
other activities that execute before the activity in the process definition. Process
variables are named after the activity whose output they contain. Each process
variable begins with a dollar sign ($) to indicate it is a process variable.
There are two process variables that are available to all activities that accept input:
$_globalVariables and $_processContext. These variables allow you to access
global variables stored in the project as well as information about the currently
running process. describes these two process variables.
There is also an $_error process variable available to any activity that occurs
after an Error transition in a process definition. See Chapter 9, Error Handling, on
page 113 for more information about handling errors.
Output
The output tab displays the activity’s output schema. This name appears in
subsequent activities’ input tabs. The activity’s output data is displayed for
informational purposes only and cannot be modified or altered.
Process Starters
Some activities within a palette are used to start a process when an event occurs.
For example, in the File palette, there is an activity named File Poller. This activity
detects changes in a specified file and starts a process when the change occurs.
This kind of activity is known as a process starter. When a process starter is placed
into a process definition, it replaces the default Start activity, and becomes the first
activity in the process.
You can only have one process starter within a process definition. You will receive
a warning if you attempt to add more than one process starter to a process
definition. Table 6 describes the available process starters.
When you deploy your project, you can place processes with different process
starters on different machines. For example, you may wish to place all processes
with a Receive Mail process starter on the same machine as the mail server so that
the processes can poll the mail server more efficiently. See TIBCO BusinessWorks
Administrator’s Guide for more information about deployment and specifying on
which machine process starters are run.
Start Activity
Configuration
The configuration tab has the following fields.
Field Description
Name The name to appear as the label for the activity in the
process definition.
Output Schema
The Output Schema tab defines the data that the process is expecting as input.
Any process that calls this process definition must supply the data specified on
the Output Schema tab.
You can define your own datatype on this tab, and you can reference XML schema
or ActiveEnterprise classes stored in the project. Once defined, the data specified
on the Output Schema tab becomes the output schema of the Start activity. This
data then becomes available to other activities within the process definition.
See Schema on page 50 for a description of how to define a schema.
Output
The output for the activity is defined by the specified data elements on the Output
Schema tab.
End Activity
Configuration
The configuration tab has the following fields.
Field Description
Name The name to appear as the label for the activity in the
process definition.
Output Schema
The Output Schema tab defines the data that the process will output. Any process
that calls this process definition will receive this data when the process call
completes.
You can define your own datatype on this tab, and you can reference XML schema
or ActiveEnterprise classes stored in the project. Once defined, the data specified
on the Output Schema tab becomes the input schema of the End activity. You can
then map data from other activities within the process to the End activity’s input,
and this becomes the output of the process when the process completes.
See Schema on page 50 for a description of how to define a schema.
Input
The input for the activity is defined by the specified data elements on the Output
Schema tab.
Error Schema
The Error Schema tab defines schemas to contain data for errors thrown by the
process definition. You can define multiple schemas, each for use in specific error
cases.
You can define your own datatype on this tab, and you can reference XML schema
or ActiveEnterprise classes stored in the project. See Schema on page 50for a
description of how to define a schema.
See Chapter 9, Error Handling, on page 113 for more information on error
handling.
Transitions and conditions control the flow of activities in a process diagram. This
chapter explains how to create transitions and specify conditions on those
transitions.
Topics
• Transitions, page 62
• Conditions, page 64
Transitions
Having multiple branches within a process definition does not imply that each
branch is processed concurrently. Transitions describe control flow of the process
definition, not the concurrency of execution of activities. Process execution is
controlled by the process engine. See TIBCO BusinessWorks Administrator’s Guide
for more information about configuring the TIBCO BusinessWorks process
engine.
Each activity in a process definition must have a transition to it, or the activity is
not executed when the process executes.
Figure 15 illustrates examples of valid transitions in a process. Figure 16
illustrates an invalid transition.
Creating a Transition
To create a transition, follow this procedure:
1. First create or open a process definition that contains at least two activities.
2. Click on the Create Transition icon on the TIBCO Designer toolbar.
3. Position the cursor over the first activity.
4. Click and hold the mouse button.
5. Drag the mouse until the cursor is positioned over the activity that you would
like to transition to.
6. Release the mouse button.
Once the transition is created, the condition dialog is presented. The condition
dialog allows you to specify when this transition is taken. See Conditions on
page 64 for more information about specifying conditions.
Conditions
You must specify the type of condition, the following table describes each type.
There can be only one "Error" and one "Success if no matching condition"
transition out of each activity.
This chapter describes groups and how to use them for transactions,
error-handling, and looping.
Topics
Overview of Groups
Groups are used to specify related sets of activities. The main uses of groups are
the following:
• To create a set of activities that have a common error transition. Basically, this
is similar to a try...catch block in Java. This allows you to have a set of
activities with only one error-handling transition, instead of trying to
individually catch errors on each activity. See No Action Groups on page 72
for more information.
• To create sets of activities that participate in a transaction. Activities within the
group that can take part in a transaction are processed together, or rolled back,
depending upon whether the transaction commits or rolls back. See
Transaction Groups on page 73 for more information about transactions.
• To create sets of activities that are to be repeated. You can repeat the activities
once for each item in a list, until a condition is true, or if an error occurs. See
Overview of Loops on page 73 for more information about loops.
Groups have a Configuration tab and an Output tab. The output of all activities
within a group is available to any subsequent activities in the process definition. If
the group is to be repeated, only output of the last execution of each activity in the
group is available. For Iterate and Repeat Until True loops, you can optionally
accumulate the output of each execution of one activity in the group into a list.
This list becomes the group’s output and the list is available to subsequent
activities in the process definition. For other types of groups, no output is
available.
3. Choose View>UnGroup from the menu, or click the Undo the group icon.
Field Description
Name The name to appear as the label for the group in the
process definition.
Index Name The index variable for the loop. This variable will be
used to store the current iteration number of the loop.
The index starts at one and increments by one with
each execution of the loop.
See Index Variable on page 74 for more information.
Variable List The list you wish to use as the source of the iterations.
The group will iterate once for each item in the list.
Field Description
Accumulate Output Specifies that you wish to accumulate the output of one
of the activities in the group into a process variable.
By default, only the output of each activity from the last
execution of a loop is available to subsequent activities
in the process definition. With this option checked, each
execution of the loop stores the selected activity’s
output into the next position of a process variable. See
Accumulate Output on page 74 for more information.
Output Activity The activity within a group for which you wish to
accumulate output for each execution of the loop. You
may select only one activity within the group.
Output Name The name of the process variable to store the successive
output of the selected activity in the Output Activity
field.
Index Name The index variable for the loop. This variable will be
used to store the current iteration number of the loop.
The index starts at one and increments by one with
each execution of the loop.
See Index Variable on page 74 for more information.
Conditions The condition that specifies when the loop should stop.
The activities within the group are executed once, then
the condition is checked. If the condition evaluates to
false, the loop repeats, if the condition evaluates to true,
the loop stops. The loop continues to repeat until the
condition evaluates to true.
The condition is specified as an XPath condition and
the XPath formula builder is available to help to create
the condition. See Chapter 8, XPath, on page 105 for
more information.
Field Description
Accumulate Output Specifies that you wish to accumulate the output of one
of the activities in the group into a process variable.
By default, only the output of each activity from the last
execution of a loop is available to subsequent activities
in the process definition. With this option checked, each
execution of the loop stores the selected activity’s
output into the next position of a process variable. See
Accumulate Output on page 74 for more information.
Output Activity The activity within a group for which you wish to
accumulate output for each execution of the loop. You
may select only one activity within the group.
Index Name The index variable for the loop. This variable will be
used to store the current iteration number of the loop.
The index starts at one and increments by one with
each execution of the loop.
See Index Variable on page 74 for more information.
Conditions The condition that specifies when the loop should stop.
The activities within the group are executed once. If an
error occurs during the processing of the activities, and
that error does not have an associated error transition,
the condition is checked.
If the condition evaluates to false, the loop repeats, if
the condition evaluates to true, the loop stops. The loop
continues to repeat if unhandled errors are
encountered, until the specified condition evaluates to
true.
The condition is specified as an XPath condition and
the XPath formula builder is available to help to create
the condition. See Chapter 8, XPath, on page 105 for
more information.
Field Description
Suspend (If Still Suspends the process if the error still occurs when the
Error) specified condition is true. See Suspend If Still Error
Option on page 79 for more information about this
field.
No Action Groups
You can group a set of related activities, with a common set of transitions into and
out of the group. If you do not wish for the activities within the group to repeat,
specify the group action to be None. No action groups are primarily useful for
specifying a single error transition out of the group so that if an unhandled error
occurs within the group, you only need one error transition instead of an error
transition for each activity. This behavior is similar to a try...catch block in
Java.
The following process definition illustrates a no action group that has one error
transition out of the group to process any unhandled errors that occur when the
group’s activities execute.
Transaction Groups
A transaction group either commits or rolls back activities within the group when
the transaction completes. Only JDBC activities participate in the transaction, but
other activities can be part of the transaction group. If the transaction commits, all
JDBC activities within the transaction group commit, if the transaction rolls back,
all JDBC activities within the transaction group roll back.
The transaction group commits automatically if all activities within the group
complete and a non-error transition is taken out of the transaction group. If any
errors occur while processing the activities within the group, the transaction is
rolled back and the error is returned (you should have an error transition out of
the group to handle this situation).
Individual JDBC activities can override the default transaction behavior and
commit separately. See the description of the JDBC palette in TIBCO
BusinessWorks Palette Reference for more information about specifying JDBC
activities.
Overview of Loops
Loops allow you to execute a series of activities more than once. You can iterate
based on the items in an array stored in the process data, you can iterate until a
given condition is true, or you can iterate if an error is encountered while
processing. The following are the types of loops that are available:
• Iterate Loop
• Repeat Until True Loop
• Repeat On Error Until True Loop
When a loop completes executing, the output of the last execution of each activity
within the loop is available to any subsequent activity in the process definition. If
you map the output of an activity within a loop to the input of an activity later in
the process definition, the data that is mapped when the process is run is the data
that is output for that activity during the last execution of the loop.
Iterate and repeat until true loops allow you to accumulate the output of a single
activity within the loop for each execution of the loop. This allows you to retrieve
output from each execution of the activity within the loop. See Accumulate
Output on page 74 for more information about accumulating the output of each
iteration of a loop.
Index Variable
The index variable is used to hold the current number of times a loop has
executed. The iteration count starts at one the first time the loop is executed, and
the count increases by one for each iteration of the loop.
You can access this variable like any other process data by referencing it with a
dollar sign ($) in front of it. For example, if the index variable is i, and you want
to specify a condition that the loop should execute three times (for a repeat until
true loop), the condition would be $i=3.
Accumulate Output
For iteration and repeat until true loops, you can accumulate the output of one of
the activities within a group by checking the Accumulate Output field. If you
check this field, you can select one of the activities in the group, and each time the
loop is executed, the selected activity’s output is placed into a list. The list of
accumulated output for that activity is stored in a variable whose name is
specified in the Output Name field. This variable can be accessed in the same way
other process data can be accessed by other activities after the loop exits.
Because you can accumulate output from only one activity in a group, you should
design your group in such a way that there is only one activity within the group
that holds the data you wish to accumulate for each iteration. For example, you
may want to accumulate a list of customer names from repeated executions of a
JDBC Database Query task, or you may wish to accumulate the sum of the
amounts for line items within an order.
If there are several activities that you want to accumulate output from, you
should create a Java Code activity to concatenate the data into the output
parameters for the Java Code activity. You can then choose the Java Code activity
as the Output Activity to accumulate for each iteration of the loop.
The output for the selected activity is accumulated each time the activity is
executed. Therefore, if you choose to accumulate the output of the same activity
used in the condition of a Repeat Until True loop, the activity is executed and the
output is added to the list before the condition is checked. In this case, you may
wish to use a Mapper activity within the loop to accumulate the output. The
Mapper activity would be placed after the activity used for the condition of the
loop so that the loop exits before the value is accumulated. Alternatively, you can
place a Mapper activity outside of the loop to strip out the unwanted value from
the output list after the loop exits.
Iterate Loop
An Iterate loop repeats the series of grouped activities once for every item in an
existing sequence or list. The list can be items of any datatype. The following is an
example of an iterate loop.
The Repeat Until True loop repeats the series of grouped activities until the given
condition evaluates as "true". The activities are always executed once before
checking if the condition is true. After executing the series of activities, the
condition is checked, and the loop exits when the condition evaluates as "true".
The following is an example of a Repeat Until True loop.
1. A group of activities executes until the customer records have all been
queried. The group consists of:
b. A Java Code activity that outputs all the valid customer IDs. When all
valid IDs have been output, the activity will output -1 to indicate no more
records can be queried.
c. A JDBC Query activity that takes each ID and queries a database for the
record matching the ID.
d. A Send Mail activity that uses the customer information retrieved from the
database to send an email to the customer notifying the customer of new
product offerings.
For each iteration of the loop, the output of the QueryCustomer activity is
placed into a variable named customerList.
5. Once the condition of the loop evaluates to true, the loop stops executing and
transitions to the WriteCustomerList activity so that the customer list will be
stored in a file.
The condition looks at the value of CustomerID/ID_num. The Customer ID
activity outputs -1 when there are no more customers, so the condition
examines the value and when it is -1, the loop can exit.
The following is the configuration for this example Repeat Until True loop.
The Repeat On Error Until True loop allows you to repeat a series of activities in
the event that an unhandled error occurs. The activities are executed once, if there
are no unhandled errors, the loop is terminated. If an error occurs for which there
is no error transition, the condition of the loop is evaluated — if the condition is
true, the loop is exited, if the condition is false, the loop is repeated until there is
no error or the condition is true.
For example, you may wish to execute a series of activities and retry the execution
in the event of an unhandled error. However, you may wish to only retry the
execution three times, so that you can avoid an infinite loop if the error occurs
repeatedly. In this case, you would specify a repeat on error until true loop with a
condition that specifies the execution should stop after three tries.
The following illustrates a repeat on error until true loop.
The condition is specified as $i = 5, which means that when the index variable is
equal to five (that is, the fifth iteration of the loop), the loop exits. The condition is
only evaluated upon encountering an unhandled error within the group. If an
error is encountered, then the loop will exit if the condition evaluates to true. The
resulting behavior in this example is that the group of activities will execute and
loop until a successful completion of all activities or the group is executed five
times.
If the error persists, the process instance will continue to suspend. The
administrator can decide whether to resume or kill the process if the error cannot
be fixed.
For more information about deployment configuration and specifying actions to
perform if processes are suspended, as well as information about how to view
suspended processes and resume or kill them, see TIBCO BusinessWorks
Administrator’s Guide.
This chapter describes mapping data from a process to a specific activity’s input.
and how to transform the data using the activity’s input tab.
Topics
On the Input tab of an activity, you can see the available process data and the
activity’s input. The process data and activity input are represented as schema
trees. The process data is the list of available data within the process definition at
the point where the activity is located (an activity has access to all output data
from any activity that is executed before it in the process definition). The activity
input is the list of input values that are required or optional for the activity.
You can specify a formula for each item in the activity. XPath is the language used
for the formula, but you do not need detailed knowledge of XPath to create
simple formulas. For the most part, you can drag and drop items from the process
data schema to the activity input schema, and the correct XPath expression
appears automatically. This chapter describes how to create basic expressions; for
more advanced use of XPath, see Chapter 8, XPath, on page 105.
When you specify the input schema for an activity, the specification is represented
internally as Extensible Stylesheet Language Transformation (XSLT) code.
Normally, you do not need to examine the XSLT code generated by the mappings.
However, if you are familiar with XSLT and you wish to see the actual code, you
can right-click on any item in the input schema and choose Copy from the popup
menu. Then open a blank text document and choose Paste. The XSLT is displayed
in your text document.
You can also use your own XSLT documents to perform transformations instead
of using the techniques described in this chapter. The XSLT File shared
configuration resource and the Transform XML activity allow you to use your
own XSLT code. See TIBCO BusinessWorks Palette Reference for more information
and examples of using XSLT to perform mapping.
For more information about mapping and transformation, see the following
topics:
• Specifying Constants on page 87
• Mapping Data on page 88
• Effects of Mapping on page 90
• Transforming Data on page 97
• Modify Statement on page 97
• Set Substitution on page 102
Icon Description
Process Data Area
Allows you to specify a type for Process Data items that are
specified as the any datatype.
The any datatype can be assigned to a schema element which
can hold a value that is of "any" type, basic or otherwise, and
is made available in the repository. When a schema that
contains an any datatype appears in the Process Data
schema, you replace the any datatype with the actual
schema.
See Set Substitution on page 102 for more information about
this button.
Icon Description
Shows/hides the mapping formulas next to the input item.
Icon Description
Allows you to specify a type for input items that are
specified as the any datatype, choice datatypes (unions), or
subclasses (complex elements with an "Any Type" subclass).
The any datatype can be assigned to a schema element which
can hold a value that is of any type, basic or otherwise, and is
made available in the repository. This icon becomes available
for schema items whose datatype can be substituted for an
actual datatype. When you use this icon to replace the
datatype, the datatype of the item becomes the datatype you
specify.
See Set Substitution on page 102 for more information about
this button.
Invokes the XPath formula builder. You can use this editor to
create an XPath statement for this input item. See Chapter 8,
XPath, on page 105 for more information about XPath and
the XPath formula builder.
Schema elements also have a set of associated icons to indicate their type. Table 9
describes the icons used for schema items.
Icon Description
Sequence of elements. Container for other datatypes. This is
also called a branch in the schema tree.
Icon Description
Simple Date or Time. This can be any of the following
datatypes:
• Time
• Date
• Date & Time
• Duration
• Day
• Month
• Year
• Month & Year
• Day & Month
Schema elements are either in black or red text. Black text signifies that the
mapping for the item is acceptable. Red text signifies the mapping contains an
error. Errors can be caused by many things: required items are not mapped, the
XPath formula contains an error, and so on. Place the cursor in the schema
element that is red and consult the status message while the status information is
displayed for more information about the errors for schema elements that are red.
Schema elements can have an additional qualification of being required, optional,
or repeating. Table 10 describes the additional qualifiers that appear next to the
name of schema items.
Qualifier Description
? A question mark indicates an optional Item.
Qualifier Description
+ A plus sign indicates the item repeats one or more times.
Specifying Constants
For each item in the activity input schema tree, you can specify a constant.
Constants can be strings or numeric values. To specify a string, enclose the string
in quotes. To specify a number, type the number into the schema item’s mapping
field. The following illustrates specifying the string "USA" for the Country item
and 94304 for the PostalCode item of an input schema.
Constants can also be used within functions and search predicates. To learn more
about complex XPath expressions that use functions and search predicates, see
Chapter 8, XPath, on page 105.
is 55 minutes, 31 seconds and 112 milliseconds after 2pm on February 10th, 2002
in a timezone that is 8 hours, 0 minutes behind UTC.
2002-02-10T14:55:31.112Z
Mapping Data
You map data by selecting an item within the Process Data area, then dragging
and dropping that item into the desired schema element you wish to map in the
Activity Input area. When you perform mapping, an arrow appears as you drag
the data element to the Activity Input area. When you release the mouse, the
XPath expression for the desired data element from the Process Data area appears
in the expression field for the schema element you are mapping.
Figure 18 illustrates dragging and dropping a schema item from the Process Data
area to the Activity Input area.
Notice that the XPath expression starts with a dollar sign, indicating the root
nodes within the Process Data tree.
Evaluation Context
Each item in the Process Data area has a path to describe its location within the
process data tree. Each activity has a root node in the process data tree. Each item
below a root node is referenced by placing forward slashes between the items
within the path. For example, consider the following structure within the process
data tree and the activity input
.
- Branch1 - Branch4
NodeA NodeX
NodeB NodeY
NodeC NodeZ
+ Branch2 + Branch5
- Branch3 - Branch6
NodeD NodeP
Mapping Branch1 of the process data to Branch4 of the activity input sets the
evaluation context of Branch4 to $Branch1. Thus, if you choose to map
$Branch1/NodeC to NodeX of Branch4, the mapping will appear as "NodeC" in the
activity input area instead of "$Branch1/NodeC" because the evaluation context
for Branch4 is Branch1. The following illustrates the mapping:
Effects of Mapping
Elements in the process data and activity input trees can be either simple data or
branches.
• Simple elements are data items of a particular type (for example, string,
integer, or boolean).
• Branches are structures that contain other data items (branches can contain
either simple elements or other branches).
Both simple data and branches can be repeated. Repeating items contain multiple
elements, similar to an array or list. You can create a mapping between various
types of items.
Table 11 describes the effect of mapping simple elements and branches from the
process variables to the activity input.
Process
Variable ↓
Simple Maps the simple data from the Not a useful mapping.
Element process variable to the simple
data of the activity’s input.
Process
Variable ↓
The following sections are a series of examples of each of the possible useful
mappings.
Branch to Branch
Mapping a branch to a branch sets the evaluation context of the branch to the
process variable branch.
In the example below, the input schema item ShipName is mapped to the process
variable GetCustomerInformation. This sets the evaluation context of ShipName
to $GetCustomerInformation. Sub-items of ShipName can then reference
sub-items of GetCustomerInformation without specifying the complete path.
Therefore the mapping between ShipName/CustomerName and
GetCustomerInformation/Name is displayed as "Name" in the expression field of
the input schema item.
Any items in the Activity Input that have the same name as the items in the
process variable are automatically mapped. In the example above, Street, City,
and State have the same name, so they are automatically mapped when
GetCustomerInformation is mapped to ShipName.
In the special case where the branch schema input item is identical to the process
variable branch item, the mapping automatically creates a copy of the process
variable for the schema input items.
You are asked when creating this mapping if you wish to create a copy of the
input items. If any mappings exist for the sub-items, they are deleted. A dialog
appears asking you to confirm your action in either case:
Dialog when creating a copy Dialog when creating a copy and sub-items are
already mapped
When a copy is created, the Activity Input schema item changes to indicate the
kind of copy. If the branches have the same name, the item becomes a "copy-of", if
the branches have different names, the item becomes a "copy-contents-of". The
following illustrates both cases:
Copy-Of
Copy-Contents-Of
Non-Repeating to Repeating
Mapping a non-repeating item to a repeating item creates one input item. A
repeating item in the activity’s input creates one item for every item in the process
variable it is mapped to. Because the repeating input item is mapped to a single,
non-repeating item, one item is created.
In the example below, the OrderItem repeating schema input item is mapped to
the process variable branch GetOrderInformation/OrderDetails. This sets the
evaluation context of items in the repeating input item to
$GetOrderInformation/OrderDetails. The sub-items of OrderItem can refer to
any items with the process variable OrderDetails without referencing the full
path. One input element is created because the repeating item is mapped to a
non-repeating branch.
Repeating to Non-Repeating
Mapping a repeating item to a non-repeating item requires that you use a search
predicate to filter the repeating item and select which element of the repeating
item to map to the non-repeating item.
In the example below, the OrderDetails input schema item is mapped to the
repeating process variable GetOrderInformation/OrderDetails/OrderItem.
The branch must be mapped to a single value, so a filter expression must be used
to determine which element of the process variable should be mapped to the
simple element. In this example, the filter is [1], which means to select the first
element. You can create a more complex filter, for example [ProductId="3A54"]
which selects the element whose attribute ProductId is equal to "3A54". See
Search Predicates on page 108 for more information about using search
predicates.
Repeating to Repeating
Mapping a repeating item to a repeating item creates one input element for every
element of the repeating process variable.
In the special case where the repeating schema input item is identical to the
process variable repeating item, the mapping creates a copy of the process
variable for the schema input items. See Branch to Branch on page 92 for more
information about creating copies of input items.
Transforming Data
If you wish to change the data before it gets placed into the activity input schema,
you can use any valid XPath expression in the schema item’s expression field. You
can type in the XPath expression into the activity input item’s expression field, or
you can click the XPath formula builder button to create an XPath expression.
The XPath formula builder is a GUI tool for creating and manipulating XPath
expressions. See Chapter 8, XPath, on page 105 for more information about
creating XPath expressions and the XPath formula builder.
Modify Statement
The Modify Statement button allows you place a statement into the desired
element of the input schema. You can put any of the following statements into a
schema item for conditional mapping:
• If — allows you to map a schema item based on a condition.
• Choose — allows you to map a schema item based on one or more conditions,
and you can optionally specify an "otherwise" condition.
• List — allows you to handle items of a repeating schema element separately.
• Copy-Of — allows you to copy nodes with the same name and structure.
• Copy-Contents-Of — allows you to copy nodes with different names but the
same structure.
If Statements
If statements allow you to map data based on a condition. This is useful if you
wish to map an optional item based on whether the condition is true. If the
condition is false, the schema item remains unmapped.
For example, you might want to specify that if the customer has a state specified
in their address, then map the country for shipping to the constant "USA". If there
is no state specified, then do not map the country because the customer either has
an invalid address, or they are in a different country.
You can specify any valid XPath expression for the "If" condition or for the
mapping or transformation of the input schema items.
Choose Statements
You can create a Choose statement by selecting the "Choose" option of the Modify
Statement dialog. The Choose statement provides a set of conditions and the
mapping to use when the condition is true.
You can specify any valid XPath expression for the "When" conditions or for the
mapping or transformation of the input schema items.
List Statements
The List option of the Modify Statement dialog allows you to create a fixed
number of list items that you can treat individually. The List option provides a
series of mappings instead of one mapping for the whole list. An example of
using a list statement would be to create one mapping for the first element of the
list, and have a different mapping for the rest of the list. This would be useful if
you want to have a standard first element (for example, to qualify for a discount,
you must order the featured sale item for the month), and a variable list for the
rest of the elements.
Once you specify the number of items in the list, the input mapping tab
changes to have a series of list items instead of the original item in the schema.
5. Create mappings to the list items as you normally would create mappings.
That is, drag and drop schema elements from the Process Data panel to the
Activity Input panel.
In the example below, the first list item is mapped to a fixed product ID, quantity,
and price. The remaining list items are mapped to the process data.
Set Substitution
The Set Substitution button allows you to specify the datatype of schema items
that do not have a specific datatype. This includes items of the following types:
• ActiveEnterprise type any
• Choice (unions)
• Any Element
• items whose subclass is type Any Type
Using set substitution causes the schema element to become the datatype
specified. When you specify the actual datatype for the schema element,
mappings can be made using the items available in the actual schema that will
substitute for the any datatype at run time.
To use set substitution, place the cursor in the Process Variable or Activity Input
schema item that is of type any that you wish to specify. Then click on the Set
Substitution button. You will be presented with the following set substitution
dialog.
You can choose to substitute an XML Type or an AE Class for the schema element.
You can browse the elements available using the Browse button, and you can click
the Go To button to display the definition of the selected schema element. Once
you have chosen the substitution type, click OK. The schema element changes
from the any datatype to the datatype you specified in the substitution. You can
then map the substituted schema element as you would map any other schema
element.
Chapter 8 XPath
Topics
XPath Basics
TIBCO BusinessWorks uses XPath (XML Path Language) to specify and process
elements of data schema. These data schema are either process variables or input
schema for an activity. You can also use XPath to perform basic manipulation and
comparison of strings, numbers, and booleans. To use XPath in TIBCO
BusinessWorks, you need only be familiar with the basic XPath concepts, but you
may wish to learn more about XPath when building complex expressions. For a
complete description of XPath, refer to the XPath specification (which can be
obtained from www.w3.org).
The process data area of the example input tab illustrates the output schema of
the activities in the process. There are three output schema, each a root node in the
process data area: GetCustomerInformation, GetOrderInformation, and
GetOrderId. Each of these schema has its own associated structure, for example,
GetCustomerInformation has a set of simple values and GetOrderInformation
has simple data and other complex data.
To reference a particular data item in any of these schema, you start with the root
node and then use slashes (/) to indicate a path to the desired data element. For
example, if you wish to specify the Street attribute within the ShipName complex
element that is in the GetOrderInformation node, you would use the following
syntax:
$GetOrderInformation/ShipName/Street
The path starts with a dollar sign to indicate it begins with a root node, then
continues with node names using slashes, like a file or directory structure, until
the desired location is named.
Evaluation Context
XPath also has a method for referencing relative paths from a particular node. If
you have an evaluation context, or a particular starting node in a schema tree, you
can specify the relative path to other elements in the tree.
For example, if your evaluation context is $GetOrderInformation/ShipName,
then you can reference the sub-items of ShipName without specifying the entire
path. If you wish to reference $GetOrderInformation/RequiredDate, the
relative path would be ../RequiredDate. The path is relative to the evaluation
context — RequiredDate is one level higher in the schema tree than the elements
of ShipName.
See Evaluation Context on page 89 for more information about using the
evaluation context while mapping.
Namespaces
Some schema elements must be prefixed with their namespace. The namespace is
automatically added to elements that require this when creating mappings on the
Input tab of an activity or when dragging and dropping data in the XPath
Formula Builder.
Search Predicates
An XPath expression can have a search predicate. The search predicate is used to
locate a specific element of a repeating schema item. For example, the
$GetOrderInformation/OrderDetails/OrderItem item is a repeating element.
If you wish to select only the first item within the repeating element, you would
specify the following:
$GetOrderInformation/OrderDetails/OrderItem[1]
You can also use functions and expressions within the search predicate. For
example, if you wish to find all elements after the first, you would specify the
following:
$GetOrderInformation/OrderDetails/OrderItem[position()>1]
See the online documentation available within the XPath formula builder for a list
of the available operators and functions in XPath.
You can also build custom Java functions and make them available in XPath by
using the Java Custom Function shared resource. See the description of the Java
Custom Function shared configuration resource in TIBCO BusinessWorks Palette
Reference for more information about creating custom functions and making them
available in XPath.
The XPath formula builder can be used where XPath expressions are allowed,
such as when creating transformations on the Input tab of an activity. The XPath
formula builder allows you to drag and drop schema elements and XPath
functions to create XPath expressions. The schema elements, when dragged into
the XPath Formula field, automatically become valid XPath location paths for the
desired item. If a function is dragged into the XPath formula window, there are
placeholders for each parameter of the function. You can drag and drop schema
elements over the parameter placeholders to replace each placeholder.
Figure 19 illustrates using the XPath formula builder to drag and drop schema
elements into function placeholders.
Element Description
Data tab Displays the process data schema tree. All elements
in this tree are available to drag and drop into the
XPath Formula field.
Element Description
Functions tab Displays the available XPath functions. These are
categorized into groups and each function can be
dragged from the function list into the XPath
Formula field.
When the function is placed into the XPath formula,
placeholders are displayed for the function’s
parameters. You can drag and drop schema
elements from the Data tab into the function’s
placeholders.
The result of evaluating the function is displayed in
the "Expression Evaluates To" panel. If there are any
errors in the expression, they are listed there as
well.
For more information about XPath functions, see
the description of the function that is displayed
when it is selected in the XPath formula builder.
XPath Formula field Displays the XPath formula you wish to create. You
can drag and drop items from the Data tab or the
Functions tab to create the formula.
Figure 20 illustrates using the XPath formula builder to create a valid function.
The function concatenates the data elements $GetCustomerInformation/Street
and $GetCustomerInformation/City and places a space between the two
elements.
When executing business processes, activities can encounter errors. You may wish
to add procedures to your process definitions for handling any expected or
unexpected errors. This chapter describes error handling in process definitions.
Topics
Errors can occur during activity processing. For example, an error may occur
during a Send Mail activity if the specified mail host does not exist. You can
specify that one transition out of an activity is to be taken in the case of an error.
You then specify activities you wish to execute in the event of an error. This allows
you to create error-handling procedures for dealing with potential runtime errors
in your process definitions.
For example, the following illustrates a simple process that begins with an HTTP
request and updates a database based on the incoming request. If the update is
successful, the process ends. If an error is encountered (for example, the database
is down), an email is sent to a system administrator, and then the process ends.
Figure 21 illustrates this simple error-handling procedure. The error transition is
used to specify what activities should execute in case of an error.
Error handling can also involve significantly more complex processing. The
following sections describe error handling in more detail.
When an error transition is taken, the $_error process variable is available to all
subsequent activities in the process definition. The schema of the $_error
variable is the following:
The contents of each schema item are dependent upon the activity that throws the
error. The Data schema item contains an XML string with activity-specific error
information. You can use the Parse XML activity to parse this XML string and
view the error data for the activity.
When you create an error-handling procedure, you may find the data in the
$_error process variable useful. You can map data from this process variable into
Input items for activities in your error-handling procedure.
Error Propagation
Called processes and groups propagate any unhandled errors to the parent
process. Unhandled errors occur where there is no error transition that specifies
what activities to execute in the case of an error. Also, you can use the Generate
Error activity to create an unhandled error. The Generate Error activity does not
permit any transitions to another activity, so any error created by the Generate
Error activity is propagated to the parent process.
The following sections describe propagation of errors for groups and called
processes.
The process definition uses two group activities. The first group is an iterate
group that performs one update for each record. If any of the updates fail, an error
transition out of the group is taken to the WriteLogEntry activity. A second group
surrounds the iterate group to enclose all updates in a transaction. If the
transaction succeeds, the process ends. If the transaction fails, the error transition
is taken out of the transaction group to the SendMail activity.
The Generate Error activity is used to propagate an error outside of the
transaction group to the parent process. If the iterate group experiences an error,
the WriteLogEntry activity is executed, then the error transition from the Null
activity is taken to the Send Mail activity.
The Send Mail activity is reached if there is either an error when committing the
transaction or if the Generate Error activity is executed (because of an error in the
iterate group). The $_error process variable contains the error information for
the activity where the error occurred.
The Generate Error activity can use any error schemas defined on the process to
propagate a specific schema to the parent process. See Process Error Schemas on
page 117 for more information about process error schemas.
The GetCreditLimit process is called to check the credit limit of the customer that
places the order. If the credit limit check succeeds, the ProcessOrder process is
called. If the order processing is successful, a response is sent back to the customer
stating the order is complete and the process definition terminates.
The $_error process variable contains the default data returned in the event of an
error. You can define specific error schemas to hold error data when errors are
propagated from a group or a called process. Each process can define a number of
error schemas by creating these schemas on the Error Schema tab of the process
definition’s End Activity.
Error schemas are created like any other schema (see Schema on page 50).
However, the Error Schema tab of the End activity allows you to create more than
one error schema. Figure 24 illustrates the Error Schemas tab with two error
schemas. The left panel of the tab allows you to create or delete schemas. The
middle portion allows you to modify the selected schema. The right panel of the
tab allows you to modify each schema item.
Error schemas are used by the Generate Error activity. When the Generate Error
activity is executed, the specified error schema is propagated to the parent
process. Figure 25 illustrates the Configuration tab of the Generate Error activity.
The Select Error Schema field contains a drop-down list of error schemas defined
for the process.
If - Default - is chosen for the error schema, only the $_error process variable
contains the propagated error data.
If a process error schema is chosen, the schema appears in the Input tab for the
Generate Error activity and you can map data to the specified error schema. At
runtime, the Generate Error propagates the specified error schema to the parent
process in the $_error_<activity-name> process variable.
The process variable is named after the activity where the Generate Error
occurred. If the Generate Error occurs in a called process, the <activity-name>
portion of the process variable is the name of the Call Process activity. If the
Generate Error occurred within a group, the <activity-name> portion is the name of
the Generate Error activity within the group.
In the example described in Called Process Error Propagation on page 116, the
SendErrorInOrder activity will have access to the error schema supplied by any
GenerateError activity in the GetCreditLimitProcess. This process specifies two
error schemas, InvalidCustomer and NotEnoughCredit. Figure 26 illustrates the
process data available to the SendErrorInOrder activity.
The available error schemas for the GetCreditLimit process are presented as a
schema item of type Choice. This item will contain either the InvalidCustomer or
the NotEnoughCredit error schema. You can use XPath to determine which
schema is actually contained in the element, and then map the data in the schema
accordingly.
See TIBCO BusinessWorks Palette Reference for more information about the
Generate Error activity.
Executing process instances can communicate and can pass data between each
other. The General Activities palette contains the Wait and Notify activities and
the Receive Notification process starter for implementing inter-process
communication. This chapter describes inter-process communication and
provides examples of its use.
Topics
4. If your process engines are on different machines, ensure that you are using a
database to store process instance information. Wait/Notify information is
stored in a database so that process engines on different machines can share
information.
The following sections describe these steps in more details. See Examples of
Inter-Process Communication on page 125 for more specific examples of when
inter-process communication may be needed.
The Notify Configuration shared configuration resource defines the data that the
Notify activity passes to the corresponding Wait activity or Receive Notification
process starter. The schema for the data is defined in the same way as any other
schema is defined. See Schema on page 50 for more information on specifying
schemas.
The same Notify Configuration resource is used to configure the Notify activity as
well as the Wait activity and the Receive Notification process starter. The schema
in the Notify activity’s configuration appears in the Notify activity’s input
schema. This allows you to map process variables to the Notify activity’s input.
The Notify activity then passes its data to its corresponding Wait or Receive
Notification.
The Wait activity and Receive Notification process starter have output that
matches the Notify Configuration specified on their Configuration tab. This
allows you to use the data passed by the process with the Notify activity in
subsequent activities after the Receive Notification or Wait activities.
If you wish only to signal the waiting process to continue but not exchange data,
the Notify Configuration schema used by the Notify/Receive Notification/Wait
activities can be empty. However, the same Notify Configuration resource must
be specified by corresponding Notify and Receive Notification or Wait activities.
Only activities with the same Notify Configuration resource can communicate
with each other.
When configuring Receive Notification, Wait, and Notify activities, you must
specify a key to coordinate which actives correspond to each other. You can also
specify a timeout for how long the information about Wait and Notify activities is
kept before it is removed from storage. The following sections describe
configuring the key and timeouts for inter-process communication.
XPath expressions can be used to specify the key for Wait and Notify activities.
The Receive Notification process starter can specify a global variable or a fixed
string for its key.
The Notify activity executes immediately and transitions to the next activity in the
process definition. However, the timeout for the Notify activity specifies how
long the information about the Notify should be kept. If no corresponding Wait
activity executes before the specified timeout, the Notify information is removed.
Once Notify information is removed from storage, it cannot be accepted by the
corresponding Wait activity.
The Wait activity causes process execution to pause until a corresponding Notify
activity with a matching key executes. The Notify activity could execute before
the corresponding Wait activity and its information could be waiting in storage. If
the Notify has not executed, the process instance containing the Wait suspends
until the Notify occurs or the Wait activity’s specified timeout is reached.
The Receive Notification process starter does not have a timeout because it creates
a process instance only when a corresponding Notify activity executes.
In this process definition, new requests are submitted by way of a web interface.
A new process is started for each request, and a priority number (an ordered
sequence) is given with each request. The order with priority number "1" is
submitted, and processed immediately. When the first order is completed, a
Notify is sent with its key set to "1". All other orders transition to the Wait activity.
These orders are suspended until a Notify is executed whose key is equal to their
priority number minus one (that is, the order with the next highest priority
number).
Using this technique, orders are processed in the order of their priority, regardless
of when the order is submitted. All orders create a process instance and then
immediately suspend until the Notify is sent from the order with the next highest
priority.
The Wait/Notify activities would use the OrderID as the key to coordinate which
order the Notify corresponds to. In this case, it would be possible for more Notify
activities to execute than Wait activities. You must configure the Notify activities
to have an appropriate timeout so that the Notify information is removed if it is
not used by the associated Wait activity.
Ideally, you should create some mechanism so that incoming events are handled
outside of the process definition and then routed to only the correct process
definition. The Wait and Notify activities can accomplish this. You would replace
your "Wait for ..." activity with a Wait activity. Then, you create a new process
definition that contains a process starter to handle the incoming event. Your new
process would then use the Notify activity to send the data from the incoming
event to the correct process instance with the corresponding Wait activity.
This chapter describes the testing mode available for stepping through your
process definitions and examining process data.
Topics
Overview of Testing
Breakpoints
You can choose to select all of the activities by clicking the Select All button. You
can clear all set breakpoints by clicking the Clear All button.
You can also set or clear breakpoints on individual activities by right-clicking on
the activity and choosing Set/Clear BreakPoint Before/After from the popup
menu. Using the popup menu on the activity only sets the specified breakpoint,
you must use the Set Breakpoint dialog if you wish to specify a condition for the
breakpoint.
When a breakpoint is set on an activity, a red hexagon (a stop sign) appears next
to the task’s icon to indicate the task has a breakpoint. A breakpoint before the
activity appears to the top left of the activity, a breakpoint after the activity
appears to the top right of the activity. Figure 30 illustrates a process diagram that
has breakpoints set before and after two activities.
When you are testing process instances, the process definition can be displayed in
the design panel. When a process instance is stopped at a breakpoint, the
breakpoint icon becomes a stop sign inside of a yellow triangle to indicate where
the process instance has stopped. Figure 31 illustrates the example process
definition when the process instance is stopped at the breakpoint before the
ReadFile activity.
You can begin testing a process definition by selecting it in the project tree panel,
then clicking the Display Test Window button on the toolbar. The test
window displays process instances created during testing. Figure 32 illustrates
the test window.
You can select process instances in the test window and display the process
definition. See Process Instances During Testing on page 133 for more information
about process instances in the test window.
The test window has several buttons on its toolbar for manipulating process
instances. See Test Mode Buttons and Menus on page 137 for a complete
description of the buttons in the test window.
Entering test mode creates a process engine that loads the currently displayed
process definition and all of its dependent subprocesses. If you wish to load other
process instances into the process engine, you can use the Load Processes button
in the test window. When you start testing, you can create process instances
for all loaded process definitions.
If the loaded process begins with a Start activity that requires input, you can
supply input to the process starter by clicking on the Supply Input Data button
. This button is not available for processes that do not require input data on
the Start activity.
You can stop the execution of a process instance by selecting it and clicking the
Stop the Current Job button in the tester window.
You can delete any completed process instances from the test window by
selecting the process instances and clicking the Delete a Completed Job button .
You can browse or change any process definition or any activity’s configuration
while in test mode, but changes will not take effect during the current testing
session. You must exit test mode and re-enter test mode for changes to take
effect.
When you set a breakpoint in a process definition, the process executes all
activities up to the activity with the breakpoint. Once the breakpoint halts
processing, you can step through the process using the toolbar icons or menu
items. Stepping through the process allows you to examine the executing process
instance at your own pace. You can step to the next activity, step into or out of a
subprocess, or you can choose another activity later in the process definition and
execute from the current point to that later activity. See Test Mode Buttons and
Menus on page 137 for more information about the toolbar icons and menu items
that allow you to step through a process.
When stepping through a process definition, activities are executed as you pass
them. The currently highlighted activity is executed after you choose your next
step. If there are multiple paths within a process definition, all transitions that
evaluate to true are taken, but only one path is chosen to be highlighted as the
next activity when you choose Step to Next Activity.
When you choose to step through a process, breakpoints are still honored, no
matter which menu item or toolbar icon you choose. For example, if you are
currently within a subprocess and you choose the Step Out of a Subprocess menu
item or toolbar icon, execution continues until the next breakpoint occurs or
processing of the subprocess completes. If there is a breakpoint before the
subprocess completes, processing halts at that breakpoint, and you must choose
Step Out of Subprocess again to continue processing.
When you run a process definition in test mode, the elements of the process
change colors depending upon what is occurring in the executing process
instance. Table 14 describes the colors of each element in a process definition and
its significance.
Color/Element Description
Black transition arrow The transition has not yet been evaluated.
Color/Element Description
Green transition arrow The transition has been evaluated, and its
condition evaluates to true. Therefor the
transition is taken to the next activity.
Red transition arrow The transition has been evaluated, and its
condition evaluates to false. Therefore the
transition is not taken.
There are three buttons on the TIBCO Designer toolbar used when testing process
definitions. There is also a View->Test menu that performs the same actions as
the toolbar buttons. Table 15 describes these buttons and menu items.
Add Input Data Allows you to specify data for the process
starter’s input schema. This icon is enabled
only for process definitions that begin with a
Start activity that requires an input schema.
This brings up a dialog for creating an input
schema. You can use this dialog to save the
input data you supply to disk.
The test window also has several buttons for manipulating the process instances
during testing. The View->Test menu has menu items that perform the equivalent
actions as these buttons. Table 16 describes these buttons and menu items.
Button/ View->Test
Icon Menu Item Description
Button/ View->Test
Icon Menu Item Description
Stop Testing Kills the current engine and exits testing mode
(all process instances are removed from the
testing window). You must click the Start or Load
Process icon to start another engine if you wish to
resume testing.
There are also menu items on the popup menus for each activity within a process
definition. You can access these menu items by right clicking on the activity. These
are the popup menu items for activities that are used in testing: Set Breakpoint
Before, Set Breakpoint After, Clear Breakpoint Before, Clear Breakpoint After,
and Run To This Resource.
The Set/Clear Breakpoint Before/After menu items sets or clears the specified
breakpoint on the selected activity.
The Run To This Resource menu item executes the running process instance up to
the selected activity. For example, if a process instance is halted on a breakpoint,
selecting an activity later in the process definition and choosing the Run To This
Resource menu item resumes processing of the process instance and executes all
activities between the breakpoint and the selected activity. The process instance
pauses when it reaches the activity where you selected the Run To This Resource
menu item.
This chapter describes the process for creating a deployment configuration and
sending that configuration to the TIBCO Runtime Agent (TRA).
Topics
Overview of Deployment
Domain
MyProject
MachineA MachineB
ProcessEngine 2
TIBCO Adapter for
Disk Peoplesoft CPU
TIBCO Adapter for Monitor Monitor
Database
Deployment Overview
Deploying and starting your project involves these major steps:
1. Create the deployment configuration using TIBCO Designer. See Creating a
Deployment Configuration on page 143.
2. Send the deployment configuration to the TRA on each machine using the
Deploy icon in the TIBCO Designer toolbar. See Sending a Deployment
Configuration to the TRA on page 145.
Each TRA uses information stored locally on the machine where it runs. This
information includes how to restart the components on that machine and
what conditions on the machine to monitor. Do not modify the files that TRA
uses to store the deployment configuration.
3. Start the components on each machine. This is either done by rebooting the
machine (if the start on reboot option is checked for the component) or by
using TIBCO Administrator to start each component. See Starting
Deployment Components on page 147.
Deployment Configuration
Machine
Email
Any Failure Any Failure
Alert Custom
Restart Email Restart Email
Disk Monitor
Alert Custom Alert Custom
Email
Alert Custom
Each Process Engine resource must be uniquely named across all machines in
your deployment configuration. That is, you cannot have two Process Engines
with the same name anywhere within a deployment configuration.
Each process engine or adapter instance can specify actions to perform in the
event of a failure. These actions can be either in the Any Failure resource (that is,
perform the action for every failure that occurs), or they can be in a specific
Component failure event resource (Component failure event resources are
specified as First Failure, Second Failure, or Subsequent Failure).
Each machine can have any number of monitor resources that specify conditions
on the machine to monitor. When the condition is met, you can specify to perform
certain actions. For example, if CPU usage goes above 90%, an alert should be sent
to the administration server.
The Any Failure or Component failure event resources can also hold the actions to
perform in the event of a failure of a process engine or adapter. These actions
include restarting the process engine or adapter, sending email to a user, sending
an alert to the administration server, or executing an operating system command
or script. You can perform more than one of these actions in the event of a failure.
For more information about creating deployment configurations, see TIBCO
BusinessWorks Palette Reference.
The TIBCO BusinessWorks Quick Start document steps you through an example of
creating a deployment configuration.
Once the deployment configuration is created, you must send it to the TIBCO
Runtime Agent (TRA) on each machine within the deployment. TRA stores
information about how each component should be started and performs the
specified actions if the component experiences a failure.
4. You can select each machine on which you wish to deploy individually and
click the Deploy button, or you may click the Deploy all button to send the
configuration to all machines.
You will see the deployment configuration files within the directory where
TRA and TIBCO BusinessWorks are installed. Do not modify these files
manually.
5. If the deployment is successful, the TRA stores the information about each
component. If the deployment is not successful, errors are listed and must be
corrected before deploying.
Once a deployment is sent to the TRA, the components within the deployment are
not automatically started on the machine. The component is restarted the next
time the machine reboots if you select the corresponding check box in the
configuration panel.
If you wish to manually start the component without rebooting the machine, you
must use the TIBCO Administrator interface. See TIBCO Administrator User’s
Guide for more information about starting and stopping components.
Undeploying
When you attempt to undeploy a running component, you are warned that
the component is still running.
Your system may have limited memory or resources, or you may want to restrict
process instances to run sequentially. The Process Engine deployment resource
allows you to specify the maximum number of process instances that can
concurrently be loaded into memory. You can also specify that once a process
instance is loaded, it must remain in memory until it completes.
You can only specify options for process definitions that you load into the process
engine resource. That is, if you choose Select All on the Process Definitions tab,
you are not able to specify any options for each of the process definitions. If you
unselect Select All and then use the Browse button to load specific process
definitions, the selected process definitions appear in the list and you can specify
options for each process definition.
You can only specify process definitions that contain a process starter (not process
definition that begin with a Start activity). All dependent subprocess definitions
are automatically loaded, but you cannot specify options for subprocesses.
Specifying a value for Max Jobs causes the Process Engine to incur some overhead
for managing the paging of process instances to and from disk. If you have
sufficient system resources and do not expect incoming events to exceed the limits
of your system, you can specify Max Jobs as 0. This allows the process engine to
create an unbounded number of process instances and eliminates the overhead of
paging.
You can configure the location where TIBCO BusinessWorks process engines store
internal information. Most of the information a process engine stores is
information about each process instance’s state when a checkpoint is taken. There
is, however, some other internal information stored by the engine. You can specify
that this information is stored in the filesystem (the default) or in a database.
For some systems, using a filesystem for process engine storage may be sufficient.
However, some functionality is only available when using a database for process
engine storage:
• With a database for storage, fault-tolerant engines can recover process
instances up to a checkpoint. Without a database, running process instances
cannot be recovered to their last checkpoint.
• With a database for storage, Wait/Notify activities can be used to pass data
between process instances on different machines. Without a database, the wait
and notify activities cannot communicate across machines.
To configure the storage for your process engine, click on the Advanced tab of the
process engine in your deployment configuration. The field Check Point Recovery
Storage controls the location of process engine storage. The default location for
process engine storage is the filesystem.
If you wish to specify a database for storage, select the JDBC option in the Check
Point Recovery Storage field. You must also configure a JDBC Connection shared
configuration resource to connect to the database where you wish to store process
engine information. After configuring the JDBC Connection resource, specify the
resource in the Select a JDBC Shared Resource field on the Advanced tab of your
process engine.
TIBCO_domain_Marketing TIBCO_doarketing
TIBCO_domain_Direct_Marketing TIBCO_doarketing
Process Process
Definition PI3 Definition Standby
Configurations Configurations
PI2
PI1
heartbeat
In the event the master process engine fails, the secondary engine detects the stop
in the master’s heartbeat and resumes operation in place of the master. All
process starters are restarted on the secondary, and process instances are restarted
to the state of their last checkpoint. Figure 37 illustrates a failure and the
secondary restarting the process instances.
Process Process
Definition PI3 Definition PI3
Configurations Configurations
PI2 PI2
PI1 PI1
The following table lists and explains the predefined global variables. Some
global variables are automatically used within the system when an adapter
configuration is defined. For example, the RV Session shown above uses the value
defined for the RvService, RvNetwork and RvDaemon global variables.
Variable Description
Deployment Defaults to the TIBCO Designer project name. This value
can be any string value. This global variable is used by the
system to partially define the subject name defined for a
service.
DirLedger Used by the system when defining the path name of the
TIBCO Rendezvous certified messaging ledger file. The
default is root installation directory.
DirTrace Used by the system to partially create the path name for
log file used by the adapter. The default is the root
installation directory.
Variable Description
RvDaemon Used by the system to identify the TIBCO Rendezvous
daemon parameter. The parameter instructs the transport
object about how and where to find the Rendezvous
daemon and establish communication. The default value
is 7500, which is the default value used by the
Rendezvous daemon. See TIBCO Rendezvous Concepts for
details about specifying the daemon parameter.
Variable Description
TIBHawkNetwork Used by the system to identify the TIBCO Hawk network
parameter. See the TIBCO Hawk Installation and
Configuration manual for details about this parameter.
Index
B D
breakpoints 131 data
icon when set 132 sent across process instances 122, 123
business processes 32 database storage 150
fault-tolerance and 152
inter-process communication 125
table names 151
C debugging 129, 130
breakpoints 131
Call Process activity 39 icons 137
category mode 10 deployment configuration
checkpoints creating 143
database storage 150 illustrated 142
failover and 154 implementing 143
K modify statement 97
multiple events resuming a running process
key instance 126
incoming event 49
used for inter-process communication 122, 124
L no action groups 72
Notify activity 122
list statements 100 Notify Configuration shared configuration 123
loops 73
accumulate output 74
index variable 74
iterate 75 O
repeat on error until true 78
repeat until true 76 opening projects 22
M P
machines palette mode 10
fault-tolerance 152 palettes 7
main window 5 closing 12
mapping 81, 82, 88 custom 12
activity input 88 pinning process instances in memory 149
addressing schema elements 106 preferences 10
branch to branch 92 primary process engine 153
choose statements 99 process definitions 35
effects of different mappings 90 breakpoints 131
if statements 98 breakpoints for testing 131
Input tab icons 83 conditions 64
list statements 100 creating 40
modify statement 97 creating transitions 63
non-repeating to repeating 94 debugging 129, 130
non-useful mappings 96 effects of different mappings 90
repeating to non-repeating 95 grouping activities 68
repeating to repeating 95 handling errors 113
set substitution 102 index variable in loops 74
simple element to simple element 92 new 36
transforming data 97 process error schemas 117
XPath operators and functions 111 process starters 56
master process engnie 153 process variables 54
memory usage 148 propagating errors 115
T W
tables in database 151 Wait activity 122
technical support xv waiting for incoming events 49
templates 16, 19
test mode 129
testing process definitions 129, 130
breakpoint locations 131 X
colors in test mode 135
menus and toolbar icons 137 XPath 105
overview 130 basics 106
process instances 133 conditions 64
stepping through activities 135 editor 108
test window 132 evaluation context 89, 107
TIBCO Designer 2 example 111
implementing a deployment configuration 143 operators and functions 111
roadmap 4 search predicates 108
TIBCO Runtime Agent (TRA) specifying constants 87
sending deployment configuration 145
timeout
incoming events 49
inter-process communication 124
transaction groups 73
transforming data 82, 97
transitions 37, 62
conditions 64
creating 63
U
undeploying projects 147
ungrouping 68
V
variables, process 54