Tibco Sriven

TIBCO
SRIVEN INFOTECH svit4info.com 1

SRIVEN INFOTECH
Enlightening the skills.

TIBCO
The power of Now

TIBCO

E A I

TIBCO

Enterprise Application
Integration
(E A I)

Introduction to EAI

Today information technology (IT) has become very critical for successful functioning of
any enterprise in this world. Every form of business thrives on some form of
automation. Earlier, the automation had been custom developed, but now days
everything seems to be through packaged applications, which in a way reduced the
amount of software development significantly. Unfortunately these packaged
applications, which are self-contained, have become stove-pipe applications. The
requirements for next-generation software systems mandate the integration of these
stove-pipe applications. The requirements for the next generation software systems
mandate the integration of these stove-pipes with new forms of business logic. The term
enterprise Application (EAI) has become a recent entrant into the jargon of the active
software industry. EAI is a buzzword that represents the task of integration of various
applications so that they may share information and processes freely. Thus EAI is the
creation of robust and elegant business solutions by combining applications using
common middleware and other viable technologies. With these realizations, EAI was
created by industry analysts to help information technology organizations to
understand the emergence of a type of software that eases the pains of integration. EAI
is the nexus of technology, method, philosophy and desire to finally address years of
architectural neglect.

Why EAI?

In the past, enterprise system architectures have been poorly planned. Many
organizations built systems based on the cool technology of the day without realizing
how these systems would somehow, someday, share information. There are a number
of organizations fitted with different types of open and proprietary systems. Each with
its own development, database, networking and operating system, thus resulted a
heterogeneous environment. Overcoming these ills affecting corporate, there came a
number of ad-hoc technologies and methods. But nothing seemed to be a perfect
solution considering the complexity associated with these systems. EAI has come as a
boon for enterprise architects to set right everything, which todays enterprises face. EAI
has become a sophisticated set of procedures with newly refined technologies, such as
middleware and message brokers that allow users to tie systems together using a
common glue code. There are powerful tools and techniques to perform EAI
successfully.

TIBCO
Another Important factor that is driving enterprises toward the promised land of EAI is
the broad acceptance of packaged applications, such as Enterprise Resource Planning
(ERP) applications. These, called as stovepipe applications that address and solve very
narrow problems within departments, has rule the enterprises for a long time and this is
the time that package vendors and enterprises have started to realize the importance of
applications integration to face the daunting tasks ahead. It has been found that EAI has
the wherewithal to link many disparate systems including ERP applications.

As organizations begin to realize the necessity of interconnection of disparate systems in
order to meet the needs of the business, the significance of integration technology is
being simultaneously felt. Thus it becomes a very important milestone for every
enterprise to effectively architect, design, and develops systems based on EAI
technology. As there are a number of excellent EAI technologies, it needs a steep
learning curve to acquire the knowledge and wisdom to identify when to apply EAI
technology, selecting appropriate technology, architect a solution, and they applying it
successfully to the problem.

Types of EAI?

An enterprise system is made up of business processes and data. So when an IT expert
contemplates to use EAI technology, he has to first understand how these business
processes are automated and the importance of all business processes. This
understanding will bring out a lot of useful hints for determining the amount of work
needed, how much time it will take, which business processes and data are to be
integrated etc. apart form this initial and first task for exploration, the primary
knowledge needed is at what level, the integration process has to be performed in an
enterprise application as there are mainly four levels, such as data level, application
interface level, method level, and user interface level in an application.

1. Data-level EAI is the process and the techniques and technology of transferring
data between data stores. This can be described as extracting information from
one database, if need, processing that information and updating the same in
another database. The advantage of data-level EAI is the cost of using this
approach. Because there may not be any changes in the application code and
hence there is no need for testing and deploying the application resulting in a
little expenditure. Also the technologies providing mechanisms to move data
between databases, as well as reformats that information are relatively
inexpensive considering the other EAI levels and their applicable enabling
technologies.

2. Application interface level EAI refers to the leveraging of interfaces exposed by
custom or packaged applications. Developers make use of these interfaces to
access both business processes and simple information. Using these interfaces,
developers are able to bring many applications together, allowing them to share
business logic and information. The only limitation that developers face is the
specific features and functions of the application interfaces.

This particular type of EAI is most applicable for ERP applications, such as SAP,
PeopleSoft and Bann, which will expose interfaces into their processes and
TIBCO
data, do so in very different ways. The most preferred EAI technology for this type
is message brokers as these can extract the information from one application,
put it in a format understandable by the target application and transmit the
information.

3. Method level EAI is the sharing of the business logic that may exist within the
enterprise. Applications can access methods on any other application. The
mechanisms to share methods among applications are any including distributed
objects, application servers, and TP Monitors. An ORB can take the call of one
application to methods stored in other applications. An application server can be
a shared physical server for a shared set of applications servers. Most of the
integration has been happening at this level as there are a number of robust
technologies to accomplish this type.

4. User interface level EAI is a more primitive approach. Architects and developers
are able to bundle applications by using their user interfaces as a common point
of integration. For example, mainframe applications that do not have database or
business process-level access may be accessed through the user interface of the
application. This type is not a preferred one even though on many occasions, this
is the only way of approaching integration task.

EAI Technologies?

As seen integration task can be accomplished successfully at different levels of an
application. Thus there are different compact and elegant technologies to fulfill these
goals. ere are various middlewares, Object Request Brokers, message brokers, Web
technology like XML etc becomes mandatory for an architect to have a solid
understanding of these technologies the merits and demerits of each technology , where
each shines and flexible and scalable before embarking on the grand task of integration.
There are point-to-point middleware, such as remote procedure calls (RPCs) and
message oriented middleware (MOM), database-oriented middleware, and
transactional middleware including TP monitors and application servers. Also
distributed object computing facilitated by Object Request Brokers and message brokers
are available now for successful EAI.

Also, there is a big hype about the newly crowned Web technology XML that can do
wonders as the standard integration mechanism.XML provides common data exchange
format, encapsulating both meta-data and data. This permits applications and databases
to exchange information without having to understand anything about each other. The
primary factor in using XML technology for EAI is that XML is portable data. Finally the
java factor in EAI is also making waves among the EAI architects.

Java, a revolutionary method for building Web-born applications, is now maturing
enough to be of benefit to the enterprise and to EAI. Java has become a solid technology
for coding enterprise-scale mission-critical applications, Java RMI is already the java
version of distributed object computing architecture and in the recent past, Sun
TIBCO
Microsystems has come out with a enterprise component model, referred to as EJB and
there came a number of robust EJB-compliant application server. As Java provides
portable code, it is bound to play a very important role in uniting enterprise
applications.

JMS for EAI JMS facilities EAI. It makes two applications to work in concert in order to
carry out some new form of transaction. MS and XML combines well to supplant the
relatively brittle and arcane client/server technologies that had until recently
dominated the integration landscape, marking healthy trend toward open, flexible
infrastructures as well as promoting reusable integration strategies that can be applied
to a idea variety of integration projects. Todays integration products frequently employ
something of a messaging infrastructure, along with data transformation and migration
tools. Java Message Service (JMS) APIs provides implementation-independent interfaces
for message-oriented middleware products, such as Progress SonicMQ and IBM
MQSeries.These enterprise messaging systems allow stovepipe applications to
communicate events and to exchange data while remaining physically independent.
Data and events can be exchanged in the form of messages via topics or queues, which
provide an abstraction that decouples participating applications, Thus there is a
growing number of activities in making Java-based enterprise technologies and services
as the able ally to EAI.

TheBusinessAdvantagesofEAI

There are quite a number of distinct benefits being accrued by business houses from EAI
.Here comes a brief of what a middleware-enabled EAI can to the Organizations.

Middleware-enabled EAI Enterprise Application Integration is the creation of new
strategic business solutions by combing the functionality of an enterprises existing
applications, commercial packaged applications, and new code using a common
middleware. Middleware refers to technology that provides application-independent
services that mediate between applications. Middleware also represents the software
products that implement these middleware services. There were mechanisms before the
arrival of these middleware technologies, such as COBRA, for integrating applications
in enterprises. But these mechanisms were found inflexible, requiring very high effort
and highly complex.

But middle has brought some spectacular benefits for enterprise to integrate their
applications without much complexity. Middleware is a software tool. Middleware
provides elegant and easy mechanisms by which applications can package functionality
so that their capabilities are accessible as services to other applications. Middleware is
able to hide the complexities of the source and target systems, herby freeing developers
from focusing on low-level APIs and network protocols and allowing them to
concentrate on sharing information. Information in different enterprise have not been
organized and formatted in the same manner. Thus the information to be shared among
applications in different places has to go through some translations and conversions as
it flows from one application to another.These capabilities are being provided by
present-day middleware technologies.

TIBCO
Finally the Middleware comes with mechanisms that help applications to coordinate
business processes.

EAI is attractive for developing new applications because few changes to existing legacy
or packaged applications are needed and because there is no necessity for extensive
programming or custom interfaces.EAI can make use of existing application
programming interfaces (APIs) and databases. Suppose there is no APIs exist, EAI may
access an applications functionality by mimicking normal users through the
applications user interface, using screen-scraping technology. Screen scrapping is the
copying of data from specific locations on character-based screens that are displayed on
an end-user computer.

The ultimate goal of EAI is to allow an organization to integrate diverse applications
quickly and easily. By employing EAI technologies effectively, an enterprise can
leverage its existing investments to provide new and advanced products and easy to use
services, to improve its relationships with customers, suppliers and other stake-holders
and to streamline its operations. EAI makes it possible for the enterprise to greatly
simplify interactions with other enterprise applications by adopting a standard
approach to integration in a long term perspective. Further, once an EAI infrastructure
has been put in place, new EAI-based applications can usually go online quickly than
traditionally developed applications because an enhanced technical infrastructure exists
on which to base future development. Thus EAI plays a very critical role in making an
enterprise competitive.

EAIforCriticalNewSolutions

Improving Customer Relationships Customers perceive that there are a number of
departments or line of business in an enterprise. Customers often want to be treated by
enterprises, which they do business with, as a royal quest. When dealing with one
department, they do not want to be required to provide information that they have
already supplied to another department. To overcome such kinds of irritations, an
enterprise seeks the help of EAI technologies, which can make the customers, to feel the
difference in the relationships with enterprises overnight. Sometimes the enterprise
wants to be able to take advantage of all that it knows about a customer. Knowing the
products that a customer previously has bought can create opportunities for selling
other products or additional services related to previous transactions. Also it does not
matter at all if the customer sometimes interacts with the enterprise via the Web, or via
a call center or in some occasions in person. That is, all the information should be
integrated. Achieving improved customer relationships demands application
integration. The information relevant for a customer should be available in an
integrated form, even though that information may be scattered in numerous stove-pipe
applications developed to support various line of business.

Improving Supply-Chain Relationships Apart from the customers, enterprises also want
to improve relationship with supply-chain partners and other outside organizations
through EAI technologies. There are a plenty of opportunities available for electronic
information exchange, sharing information, enterprises open new vista for effective
coordination. Partners can also leverage new technologies to create new services.
TIBCO
By establishing electronic links with its shipping partners, a retailer, for example, can
offer enhanced order status tracking.

Improving customer relationships and acquiring higher levels of integration with
supply-chain partners arises new security concerns. If the Internet is being used as a
communication channel, rather than dial-up or dedicated lines, an enterprise must take
necessary steps to ensure the confidentiality of information flow. Controls must be in its
place to ensure that a partner can not see information relevant to other status tracking.

Integration requirements for interactions with partners are similar to those for
interaction with customers. New applications often will be required to integrate with
several existing stove-pipe applications. The ability to support information exchange by
making use of technology such as the Extensible Markup Language (XML) is becoming
a key factor in automated business-to business such as EDI for automated exchanges
with newer Web-centric technologies, which include XML for automated exchanges and
Web interfaces for partners.

Improving Internal Processes Bringing improvement in an enterprises internal
processes happens to be a very important factor for EAI. EAI techniques can be used to
simplify information flow between departments and divisions of the enterprise. In some
organizations, EAI provides integrated information for decision making process. EAI
can be used to populate data warehouses towards analyzing market trends, evaluating
the effectiveness of a business initiative, and assessing the performance of organizations
within the enterprise. EAI makes easier the construction of a data warehouse by
mediating the flow of information from stove-pipe applications to the common
warehouse and by supporting the conversion of data from various applications formats
to a common format.

Employee self-service is also a vital application in improving business processes. Web-
enabled interfaces may provide employees with better access to the information they
need to do their jobs effectively. Employee self-service Web sites for benefits of
administration and other Human Resource (HR) functions are getting popular as a days
go by. Finally, EAI helps to eliminate manual steps in business processes and to avoid
redundant entry of data. Such application of EAI often employs a work-flow-
automation tool to bridge between the applications that are being integrated.

Reducing Time to Market Information Technology (IT) organizations are finding it
increasingly hard to maintain developing mission-critical application on time and on
stipulated budget. There are various difficulties in accomplishing these very important
requirements. EAI technology comes to rescue by reducing the time to market new
applications. EAI contributes to faster roll-out in several ways. First, EAI leverages the
capabilities of existing applications. For example, often the existing code does its job
very well and it has been debugged. The only requirement is to make the functionality
by this code accessible to new front-end channels like the Web or to new composite
applications. EAI helps immensely in this regard and shortens the time to market. Thus,
having the EAI architecture in its place, enterprises can reap the benefits in the long
term.

TIBCO
Integrating functionality that is hosted on diverse hardware and operating system
platforms is really the trickiest and most error-prone task. With the arrival of CORBA,
an EAI middleware, this task becomes relatively easy. Again, EAI reduces the amount
of code to be written for an application and helps developers to concentrate on the
business aspects of the mission-critical application rather on concentrating on
infrastructure. There are maintenance benefits as well.

EAIofLegacyandPackagedApplications

An enterprises legacy applications have become the repositories of the enterprises
corporate knowledge. Business rules embedded in legacy applications are often
documented nowhere else. As a result, it can be extremely difficult to replicate or re-
engineer the legacy applications. Thus, utilizing these applications to support new
requirements or to design newer applications out of these by integration technologies is
really a tremendous advantage and challenge also; also, legacy applications that run on
mainframe computers have many additional advantages. Mainframe computers are
ultra-reliable and can support extremely high transaction rates and a large number of
users simultaneously. Thus keeping applications on mainframes can help spread the
high fixed costs of that computing across a large number of applications.

In the recent past, most of the organizations have made very high investment to deal
with the Y2K problem in the mainframe computers and that resulted in much better
understanding and better documentation of their legacy applications. That is why,
legacy applications are there as jewels for the enterprises. Thus EAI is bound to play a
vital role in extracting the critical components from these legacies and to design new
applications to meet the advanced requirements from the customers.

Packaged applications, such as Enterprise Resource Planning (ERP) packages from SAP,
PeopleSoft, Oracle and other vendors, also figure prominently in the EAI landscape. In
the last decade, utilizing of packaged applications has grown significantly as they can
provide proven solutions to common business needs. Development of maintenance
becomes the problem for the vendor only and this helps the IT staff in the enterprises to
concentrate on the problems specific to their business. Here comes the need for EAI as
packaged products from a single vendor cannot meet all the requirements of an
enterprise and these products should be integrated with enterprise specific custom
applications and sometimes with other packaged products. Thus nowadays having
realized the importance of integration process, package vendors started to seek the help
of EAI technologies to make their products EAI-compliant.

TheWorldWideWebandEAI

The web has become a key factor in the emergence of EAI as an important technology.
There are several Web based applications that depend on EAI. The arrival of Web and
its related internet technologies are fundamentally necessary for EAI. Also the Web
happens to be a real revolution and has become the largest information base. There
came technologies to disseminate, communicate and share the information to anyone at
anytime from anywhere. The Web has brought quite a lot of innovations in commerce
and trade, information exchange, etc.
TIBCO

From the perspective of EAI, several aspects of the Web revolution are significant. The
Web provides universal connectivity, creates a whole new arena for business explosion
and ultimately gives the controlling power to the users. Thus, anyone with a Web
browser and an Internet connection can view the Web sites of those who are in the field.
Also a business can offer its customers revolutionary products and services through the
web and every business is being compelled to join the race to offer those products and
services. This provokes competition among the enterprises and results in a number of
benefits, such as extraction of the best service and price, for the users, such as
employees, supply chain partners and customers.

The Web affects any enterprise in two ways. One is, a business can offer its customers
revolutionary new products and services through the Web and the second one is
virtually every business is compelled to join the race to offer those new products and
services to face the competitions. The Web also can offer a new and better way to
perform an existing service. The web technology facilitates some novel services that are
otherwise impossible. Business partners can greatly improve their coordination through
Web-based exchange of information, streamlining the flow of goods and paperwork and
squeezing costs out of the supply chain.

The Web has opened the floodgates of customer expectations. Customers expect to find
a business on the Web. They expect to get information about products and services
being offered through the Web. The Web also enhanced customer relationships.
Customers like the feeling of control that they get from the best self-service sites.
Businesses also like customer self-service because it can significantly reduce the cost of
transactions.

Web-based application integration has moved from the experimental phase. It is
expected that this process is all set to gain momentum in the days to come. Effective
Web- based applications often depend on the integration of existing applications. The
information and services that todays enterprises want to exploit in their public Web
sites and their corporate intranets are locked up in existing IT applications. Thus EAI is
a must to Web applications that are competitive. Thus the emergence of Web has
provided a crucial incentive for enterprises to utilize the benefits of EAI.

Conclusion

Interest in EAI is driven by a number of important factors. With the pressures of
competitive business environment moving IT management to shorter application
services rather than recreate the same business processes and data repositories over and
over. EAI technology is maturing fatly and it has become a key topic for IT due to
business imperative. These include the emergence of the Web, the need to develop and
deepen relationships with customers and partners, streamlining internal business
processes, and more importantly reducing the time to market for new applications. In
fulfilling these requirements, enterprises are highly motivated to make effective use of
their existing custom-written legacy applications and commercial packaged
applications, which are currently the enterprises crown jewels. They are highly efficient
and robust and above all there represent an enterprises crown jewels. They are highly
efficient and robust and above all there represent an enormous investment.
TIBCO
But there are a lot of things to be understood before embarking on integration. They are
what applications need integration, platforms, data formats, protocols, what EAI
technology to be used etc.
Service oriented architecture lets you add and replace applications
without affecting the other applications. If you have five applications to integrate, youll
have just five integration points. Compared to the point-to-point solution, middleware-
based solutions easily support numerous integrated applications and require less
maintenance. In addition, middleware can perform complex operations - transforming,
aggregating, routing, separating, and converting messages - on the data passed from
application to application(s). The only downside: the added initial complexity of setting
up the middleware and converting existing applications to use the middleware APIs.

Integration methods

Once you have selected the logical EAI architecture, you next must choose the
integration method. EAI has five common integration methods:

Data level integration
User interface (UI) level integration
Application level integration
Method level integration

Datalevelintegration

With this method, you integrate the backend data stores that the integrated
applications use. Data-level integration can be push or pull based.
With push based, one application makes SQL calls (thru database links or stored
procedures) on another applications database tables. Push based data level
integration pushes data into another applications database. In contrast,
pull based data level integration utilizes triggers and polling. Triggers capture
changes to data and write the identifying information to interface tables. Adaptors can
then poll the integrated applications interface tables and retrieve the pertinent data.
Youd use pull-based data-level integration when an application requires passive
notification of changes within another applications data.

Use data-level integration when the application up for integration does not
provide any APIs or client interfaces, and you intimately understand how business
operations affect you applications data model. Data level integration typically
represents the only option with custom applications lacking application APIs.

In data level integration, changes propagated from dependent systems bypass
the integrated application, so all inserts, updates, and deletes are done to data that the
integrated application accesses. Developers typically implement data level integration
with database gateways or triggers and stored procedures. The major downside:
keeping the interfaced applications data intact. For example, some ERP (Enterprise
Resource Planning) systems include thousands of tables. One table might have
dependencies to others, and the integrated application may be the sole enforcer of those
dependencies.

TIBCO
UIlevelintegration

This method ties integration logic to user interface code. UI level integration is
scripting or proxy based. Scripting based UI level integration embeds integration
code into the UI component events, common with client/server applications such as
PowerBuilder or Vantive. For example, when you click the Submit button of an Add
Customer screen, data must be sent to the applications database and a JMS (Java
Message Service) topic. Proxy based UI - level integration uses the integrated
applications interface (through screen scraping) to pass data to and from the legacy
system.

Use UI- level integration when you cannot easily or directly access the database,
or when you business logic is embedded in the user interface. Mainframe and
client/server applications represent typical candidates for UI level integration.
Mainframes generally cannot access friendly data stores and usually do not provide
public APIs. For their part, many client/server applications embed the business logic in
the client. In these cases, UI level integration represents the only way to access and
maintain data integrity.

In most cases, UI level integration, is your last resort. Adding scripting logic to
catch events within client/server applications quickly becomes difficult to maintain as
the integration level increases and changes occur. In either case, UI changes can break
the integration triggers and logic. Moreover, tight coupling forever links UI
maintenance with the integration codes maintenance.

Applicationlevelintegration

This is probably the best way to integrate applications, uses the integrated
applications integration frameworks and APIs. Application interfaces let you invoke
business logic to preserve data integrity. Integration API examples include Siebels
JAVA Data Beans and SAPs JCA (J2EE Connector Architecture). Prefer application
level integration because it is transparent to the integrated application and preserves the
applications data integrity.

Methodlevelintegration

A less frequently used superset of application level integration, aggregates
common operations on multiple applications into a single application that fronts the
integrated applications.

Use method level integration when each integrated application provides a
similar set of API or functional methods. Typically, youd create an aggregating (front)
application, which fronts the aggregated applications using distributed components
(CORBA, Enterprise JavaBeans (EJB), DCOM (Distributed Component Object Model)
and so on). A front integration component may resemble:

TIBCO
//Code from a front application component
Add Customer (Customer Info ci)
{
ERPComponent.addCustomer (ci.getName (), ci.getAddress (), ci.getEmail ());
ECRMComponent.insertCustomer (ci.getName (), ci.getName (), ci.getAddress (),
ci.getEmail ());
}

Method level integration requires the integrated applications to support a RPC
(remote procedure call) or distributed component technology. All applications that
interact with the integrated applications do so through the front application. So, if a
client application wants to add a customer, it would call the front components
addCustomer () method. The component would then add the customer to the ERP and
CRM (customer relationship management) systems.

Method level integrations major disadvantage stems from the tight application
coupling in front components. Changes in the integrated application API break the front
application components and the applications that rely on them. Pursue method level
integration when you have CORBA based integration technology or a distributed
component technology. Because method level integration is a more complicated form
of application level integration, it usually makes more sense to pursue application
level integration using middleware.

Howtochooseanintegrationmethod

Selecting the proper integration method is usually an exercise in constraint
based modeling. To wit, look at each system and define the possible interfaces into that
application. In some cases, the application does not have any API; therefore the backend
data store represents the only option. In other cases, APIs and a CORBA infrastructure
may exist; so employ application level integration.

CoreIntegrationComponents

Now that we have looked at the different integration methods, lets look at the core
features and services present within most EAI solutions. The following core features
and services act as the building blocks of your integration solutions.

CommonXMLSchema

Once you have chosen an integration method for each target application, identify
a common integration XML Schema to encompass all integration objects and their
associated attributes. The integration schema you develop must consider each of the
integrated applications XML Schemas and future applications CML Schemas. Most
packaged ERP and CRM applications include their own XML schema to describe their
internal business objects. You will need to convert data extracted from these
applications into the integration XML format and then into the target applications XML
Schema from other applications. If you did not use an intermediate XML format, you
would have to define mappings from each application to the other applications and
back.
TIBCO

Datatransformation

Transformation converts XML or non XML data from one format into another.
Transformation, a major part of integration, is categorized into Datatype and semantic
transformations.

A Datatype transformation converts attribute values from one applications format to
another. For example, one application might use M and F to represent gender while
another application uses Male and Female. As another Datatype example
transformation, consider changing an XML element from:

<EMPLOYEE_ID>111</EMPLOYEE_ID>
To:
<EMPLOYEE_NUMBER>111</EMPLOYEE_NUMBER>

A semantic transformation, in contrast, converts the data from one format into another.
For example, Oracle stores customer names in first, last and middle initial fields. SAP,
on the other hand, stores a customer name in a single field with a last Name, first Name
format. Sending data from Oracle to SAP requires a semantic transformation to
concatenate a last name with a comma and first name.

Data transformations are typically part of the process definition.

DefineProcesses

Every application has well defined processes for completing business operations. The
same is true when integrating processes across applications. You must understand the
events, systems (source, intermediate, and targets), and routing requirements for the
integrated applications. For example, a large company may own 12 application that
store redundant customer data. When a new customer is inserted 9event) into one of the
applications, you must define a process to propagate the information to the other 11
systems. Each of the 11 systems may represent customer information in different
formats with different required fields. Sometimes youll route messages through
intermediate systems before ending at the target systems. You will eventually
implement this information in the physical integration architecture.

Physicalintegrationarchitectures

The physical integration architecture concerns the physical software components
necessary to implement a middleware based integration solution. Java based EAI
supports three architectures: message bus, centralized and JCA

TIBCO
Messagebusarchitecture
In this architecture, each application connects to a message bus. Each

integrated application associates with an integration node (also known as adapter)
connected to the multicast network. The integration node runs either on the Sam box as
the integrated application or on a box with client or API level access to the integrated
application (see figure). Each integration node uses multicast ot broadcast information
to other integration nodes. When an application wants to share information with its
peers, it sends a integration nodes pick up the message on the network.
Each message has an associated subject. Participating integration nodes pick up the
message and check whether they are interested in the subject. If they are, the integration
node processes the message by invoking some business logic on the application it is
integrating. The message bus architecture is common with Tibco Rendezvous.

Figure: Message bus architecture
Advantages:

With message bus architecture, you can propagate a single message to multiple clients.
When a multicast packet goes out, any interested application can pick up and process
the packet. If multiple clients require exactly the same data, you can send the data once,
and each interested application will pick up and process the information.

Disadvantage:

Message bus architectures often have security problems. It is difficult if not
impossible to support authorization based access to multicast packets. Multicast
based integration architectures drop packets on a network that any network
member can see.

App 1 App 2 App 3 Other Applications
Adapter Adapter Adapter Adapter
Network Segment
Foreign Network
Segment
Router
App 5
App 4
Adapter Adapter
Multicast
to unicast
Unicast to
Multicast
2
2
4
5
6
2
2
2
1
3
Multicast packet
Unicast packet
TIBCO
Message bus architectures also increase network traffic. Multicast packets negate
the intelligent routing behavior of switches and bridges. Every client in the same
network as the integration nodes processes multicast packets to the application
layer of the open system interconnection (OSI) model. Clients then waste CPU
cycles processing and discarding invalid packets.

The third disadvantage is a lack of centralized management. Each integration
node must utilize some type of RAID (redundant array of inexpensive disks)
configuration to support message log file integrity an expensive proposition.

As another disadvantage, consider the proprietary nature of message bus
architectures. Currently, Tibco is the only vendor that implements the message
bus architecture.

Finally, multicast packets cannot cross network boundaries without help from
protocol converters. If another application to be integrated resided in a separate
network or subnet, another process must pick the multicast packets, convert
them to unicast packets, and then forward the packets to another process in the
other network. That process in the remote network converts the unicast packets
back to multicast packets for the integration nodes on the remote network to
receive.

Centralizedarchitecture

As with the message bus architecture, in a centralized architecture each integrated
application associates with an integration node. Each integration node serves as a JMS
event listener/notifier and interface into the integrated application. JMS provides
message durability, message filtering, transactions, and ensures messages are delivered
and routed to targeted applications 9see figure). When an application must talk to other
applications, it publishes messages to JMS topics. Topic listeners (message-driven
beans) send the message to business processes applying business rules, transformation,
routing logic, and workflow management.

In contrast to the message bus architecture, with a centralized JMS
architecture, all integration nodes communicate with a JMS server instead of a multicast
network. In addition, the centralized architecture tends to be unicast-based. Unicast
packets allow applications in different networks and subnets to easily talk to each other
without protocol converters. Because switches and routers can intelligently route
unicast packets, clients receive only packets intended for them. That also keeps hackers
from sniffing network segments and obtaining integration-related information.
Moreover, a centralized architecture improves overall security. Most J2EE servers
support SSL (Secure Socket layer) and authentication to access JMS services. Finally, the
centralized architecture eases management by letting you manage your persistent
message and transaction logs in a single location.

TIBCO

Figure: Centralized JMS Architecture

Advantages:

First, a centralized architecture improves maintenance and management. In the message
bus architecture, each integration node protects log files related to certified and
guaranteed messaging. As a result, each message bus node ideally needs a RAID.
However, the centralized architecture only needs a RAID on the JMS server.

The business rules associated with routing and transformation are also located within
the centralized message service. Youll find debugging and problem resolution easier in
a centralized deployment because you can review log files and look for errors in one
place. The message bus architecture requires you to interrogate suspect integration
nodes, coordinate information, and resolve problems in multiple locations.

The centralized architecture also better utilizes network resources. Single messages are
rarely sent to multiple applications without transformation. That mitigates the benefits
of the multicast protocol for integration based applications. Switches and bridges can
take advantages of intelligent routing provided by the MAC (media access control)
address of a unicast frames. Network friendly unicast packets do not require protocol
converters to talk to applications in another network or subnet.

Finally, the centralized architecture supports standards based messaging like JMS,
allowing you to switch different vendor implementations and give developers a unified
interface into messaging.
Other Applications
on different
networks or
subnets
App 5
App 4
Open
Adapter
open Adapter open Adapter
open Adapter
open Adapter
open Adapter
J2EE application server
JMS messaging
Centralized Management
and monitoring
Routing Transformation
and Process Integration
App 1 App 2 App 3
TIBCO

Disadvantage:
The centralized architecture lacks standardized integration nodes 9adapter). Although

an integration node standard does not exist, the popular open adaptor open source
adaptor framework supports JMS, sockets, files, IBM Web Sphere MQ, Tibco
Rendezvous, and databases.

J2EEconnectorarchitecture

The JCA takes a radically different approach to integration by placing the integration
components within the J2EE application serer, giving you the centralized architectures
maintenance and management benefits. However, JCA adapters require remotable APIs
(see figure) classes that can invoke business logic on a remote host. Several remotable
APIs examples include CORBA, EJB, DCOM, JDBC, and RPC. JCA standardizes the
interfaces into enterprise information systems (EIS) so you can use a single JCA
compliant adapter in any J2EE compatible server. JCA 1.0 well supports transaction,
security, and resources management. However, because the JCA spec is at version 1.0, it
has many limitations. First, it lacks an asynchronous messaging mechanism. Second, all
requests are unidirectional. Third, it doesnt support event based processing. BEA
Web Logic has extended JCA 1.0 by adding support for events, but that solution is
proprietary.

Figure: The J 2EE Connector Architecture

Other Applications
on different
networks or
subnets
App 5
App 4
JCA
Adapter
JCS Adapter
JCA Adapter
JCA Adapter
JCA Adapter
JCA Adapter
J2EE application server
JMS messaging
Centralized Management and
monitoring
Routing Transformation and
Process Integration
App 1 App 2 App 3
TIBCO
Advantages:
The JCA boasts the same maintenance and management advantages as centralized
architecture, including centralized maintenance, management, and business rules. The
network friendly JCA directly supports J2EE services just like the centralized
architecture. JCA has the added advantage of standardized semantics for secure identity
propagation, transactions and resource pooling.

Disadvantages:
JCA 1.0s disadvantages relate to the specifications immaturity. First, JCA does not
support asynchronous call typically required in EAI solutions. Second, JCA 1.0 only
supports calls made from the application server to the EIS. Last, JCA 1.0 does not define
any semantics for receiving application events from EISs. JCA seems targeted towards
portal based integration with the portal driving the integration process. The JCA 1.5
spec addresses most of these concerns by adding support for JMS plug- ability, EIS
event notification, and asynchronous methods.

Key Components of middleware

Data
Transformatio
n
Repository
Adapter
SDK
Transport & Messaging
Off-the-shelf
adapters
Process
Flow
Manager
Administration
And
Monitoring
tool
Work flow
Manager
TIBCO
Types of Middleware

Transaction Processing (TP, TPM)
X/Open, XA, 2 phase commit
Remote Procedure Call (RPC)
Object-based (ORB)
CORBA, COM
Message Oriented Middleware (MOM)
Message queuing
Message passing

Different Types of EAI tools/PRODUCTS

There are so many types. Some of the following under below

I ) TI BCO
I I ) Web Methods
I I I ) SEEBEYOND
I V) NETVI EWER
V) MQ-Series
VI) MERKATOR
VI I ) BizTalk
VI I I ) WLPL
I X) WBP-PL
X) VI TRI A

We know before EAI we have TPs are there TPStands for translated programs
.these are written in c or c++

TIBCO

INTRODUCTION TO
TIBCO

TIBCO
TIBCO - INTRODUCTION
WhatisTibco?
TIBCO Software Inc. (Nasdaq:TIBX) is a leading provider of total business integration
solutions delivering infrastructure software that enables businesses to seamlessly
integrate business systems in real-time. TIBCO's products enable the real-time
distribution of information through patented technology called The Information Bus, or
TIB. TIBCO technology was first used to digitize Wall Street and has since been
adopted in diverse industries including financial services, telecommunications,
electronic commerce, transportation, logistics, manufacturing and energy. TIBCO's
global customer base includes more than 1,200 customers such as Cisco Systems,
Yahoo!, Ariba, NEC, Enron, Sun Microsystems, GE Capital, The Limited, Delta Air
Lines, Philips, AT&T and Pirelli. TIBCO is headquartered in Palo Alto, California.
TibcoDefinition
Tibco makes integration server software for enterprises. An integration server allows a
company to mix packaged applications, custom software, and legacy software for use
across internal and external networks. TIBCOs patented approach is called Information
Bus (TIB) and Tibco says that it has been used in financial services, telecommunications,
electronic commerce, transportation, manufacturing, and energy. Tibco competes with
See Beyond, Vitria, and web Methods among others.
Active Enterprise is TIBCOs integration server package that supports both message-bus
and hub-and-spoke integration server models. The message-bus model connects the
different applications to a common backbone using application adapters. The hub-and-
spoke model connects all applications to a central server. TIBCOs latest addition to
Active Enterprise is Business Works, which uses Web services technology.
Tibco is based in Palo Alto, California and is traded (TIBX) on the NASDAQ.
TIBCO provides business process management and business integration
software. This software integrates, manages, and monitors enterprise
applications and enables reliable and high-performance information delivery.
Their software products include applications for coordinating business process
and activities, securely exchanging information with trading partners, creating
and maintaining XML documents, and managing distributed systems.
The company's major competitors are web Methods, IBM, Microsoft, Oracle
Corporation, 29West
TIBCO
Architecture

TIBCOs main architecture is based on an information-bus oriented system concept.
Where as all the information that is used by the multiple systems pass through one
information-bus. Tibco commonly refers to this information-bus as the TIB.
Databases and applications interface the TIB through APIs supplied from Tibco.
Types of Interaction
TIB middleware software supports three distinct kinds of interaction among
applications in distributed environments:
Request/reply interactions, such as queries or transactions
Broadcast request/reply interactions, such as queries that may result in
several replies from one or more servers
Publish/subscribe interactions, such as general distribution of information
from many sources to many consumers

Architectural Benefits
Benefits of a TIB-based architecture include:
Easy to create new subsystems TIB allows developers to create new
subsystems, modify existing subsystems, and add new services without having to
change the UI or a subsystems code.

Easy to move subsystems A subsystem supplying data can be moved to other
geographic locations without changing the subsystems that consume the information it
supplies. This is important for fault tolerant operation where new subsystems can take
over immediately upon the failure of another subsystem.
Easier to develop applications Saves development costs and time because the
developers can use a tested API for communications rather than have to design,
develop, implement, test, and maintain their own infrastructure code.
TIBCO

Faster to develop Developers can concentrate on applications and business
requirements and not have to write and test an infrastructure. Applications will also be
faster to develop because they will be linked into existing and well-tested libraries.
Developers will not have to create code necessary for inter-subsystem connectivity

Easier to maintain Personnel can concentrate on the application code. The
middleware layers are enhanced and maintained by professionals who are specialists in
that type of software

Easier to change Changes will be easier to make to subsystems because they
will be independent of their data sources and their data consumers

Highly scaleable The system will be far more scaleable because subsystems and
hardware can be added easily and quickly to meet new user demands.

Location transparency The system cal exploit TIBs subject based addressing to
allow system components to be located dynamically, rather than being hard-coded.
This supports a range of system migration needs.

Easier to monitor The system can use TIB/Hawk for monitoring.

Error management The system will be able to log and respond to system and
business level errors by generating TIB-based notifications or advisories.

TIBCO
Why TIBCO?
High-Performance Infrastructure
Large organizations are facing the challenge of processing and capitalizing on a greater
volume of information moving at faster velocity between greater varieties of endpoints
than ever before. This trend means that while it's possible to move information using
standards like HTTP, .NET and web services, there are an increasing number of
situations where greater speed, scale or adaptability is required.
TIBCO has a 20-year legacy of delivering high-performance infrastructure software to
some of the world's leading companies and meeting the needs of the most demanding
distributed real-time computing environments. This complements legacy and
standards-based technologies with the ability to deliver information across businesses
with superior performance and flexibility.
No Rip and Replace
For over 20 years, TIBCO has been dedicated to delivering software that unlocks the full
value of existing applications, development environments, information sources,
networking technologies and even operating systems. TIBCO does not sell applications,
application servers, databases or hardware, so organizations don't have to worry about
being pushed to abandon the assets they already have in place or the investments they
have already made.
With TIBCO, there is no need to rip out and replace the systems that are working for
you now. You can leverage your assets and extend their value. You can choose the
platform, applications and processes that work best for your environment without the
constraints of vendor lock-in.
Quick Wins, Strategic Advantage
While many of our customers have adopted TIBCO technology as a strategic platform
for integration and IT in general, we didn't get there overnight. In many cases TIBCO's
software was used as part of a tactical project and TIBCO earned trusted advisor status
with success.
TIBCO's software is not only fully interoperable but also modular and each product can
stand on its own to solve specific business problems or technical challenges. With
TIBCO, you can achieve rapid return on investment while taking the first steps towards
a strategic architecture and approach that will make subsequent projects faster and
easier, ultimately resulting in lower total cost of ownership.
TIBCO solution

This is the only company every thing provided real-time business integration and the
process automation , work flow , B2B, application DB , enterprise portals , and high-
level services such as BAM (business access monitoring ) and optimization
TIBCO

Products

The current range of products includes a , Workflow, Business Intelligence
Solutions, enterprise messaging backbone, B2B integration and other software.
The company's best known products include TIBCO BusinessWorks (EAI),
TIBCO Rendezvous and TIBCO Enterprise Message Service (messaging), and
TIBCO Staffware Process Suite (BPM).

TIBCO Rendezvous is perhaps the most important and well known product. It is
an underlying messaging layer that provides publish-subscribe and request-reply
semantics. This Message Oriented Middleware was TIBCO's original product,
bringing the company a lot of early success in the pre-WWW IT industry. Partly
owing to this long track record, the TIBCO Rendezvous platform is still very
popular within the finance industry and has a large installation base. The
company was a key contributor to the Java Message Service specification and
supports the standard in the product.

The company's second best-known product is , which is a leading player in the
EAI space. is a business integration and web services tool kit supporting the
development, deployment and management of project-oriented business
solutions. is based on the same core technology as TIBCOs ActiveEnterprise
product suite.

The company also played a role in the growth of the enterprise portal space. In
the early 1990s, it invented a real-time, user-personalized, thick-client portal
product called MarketSheet, which was used pervasively in securities trading
rooms in the financial industry. When the web revolution arrived, this product
provided a vision that was subsequently implemented in the web world as user-
configurable portals such as My Yahoo!(TM). The company thinned down the
front end for its own portal products to applets and finally to DHTML. [1] is an
Ajax toolkit for building and deploying Rich Internet Applications (RIA),
components and portlets that look similar to desktop software.

TIBCO
WhichareasTibcoProductsused?

Business Optimization

This s/w that enables people to access, analyze ,and act on data ,participate in
processes and analyze business performance

2. Business ProcessManagement

This s/w that helps companies coordinate the execution of the task, activities
and transactions that make up their unique way of doing business

3. Business Integration

This s/w that gives companies the ability to connect and coordinate
applications throughout their organization across their extended enterprise and with in
their customers

4. Enterprise Backbone

This s/w helps companies establish and manage a highly efficient and scalable
flow of information across their enterprise

TIBCOProductsOverview

Application Integration
TIBCO ActiveMatrix BusinessWorks
TIBCO Adapters
TIBCO BusinessWorks SmartMapper

B2B Integration
TIBCO BusinessConnect
TIBCO BusinessConnect Remote
TIBCO BusinessConnect Trading Community Management

Business Activity Monitoring
TIBCO BusinessFactor
TIBCO OpsFactor

Business Intelligence
TIBCO Spotfire DXP Professional
TIBCO Spotfire DecisionSite
TIBCO Spotfire Analytics Server

TIBCO
Business Process Management
TIBCO iProcess Suite

Complex Event Processing
TIBCO BusinessEvents

Data Integration
TIBCO DataExchange

Enterprise Service Bus
TIBCO ActiveMatrix Service Bus

Mainframe Integration
Mainframe Adapters
i5/OS Integration
Mainframe Messaging
Substation ES
TIBCO Object Srevice Broker

Master Data Management
TIBCO Collaborative Information Manager

Messaging
TIBCO Enterprise Message Service
TIBCO Rendezvous
TIBCO SmartSockets

Portal
TIBCO PortalBuilder
Rich Internet Application
TIBCO General Interface
SOA
TIBCO ActiveMatrix BusinessWorks
TIBCO ActiveMatrix Policy Manager
TIBCO ActiveMatrix Registry
TIBCO ActiveMatrix Service Bus
TIBCO ActiveMatrix Service Grid
TIBCO ActiveMatrix Service Performance Manager

System Monitoring and Management
TIBCO Hawk
TIBCO Enterprise Management Advisor
TIBCO Enterprise RTView
TIBCO

TIBCO
BusinessWorks

TIBCO
Business Integration

TIBCO BusinessWorks is a scalable, extensible, and easy to use integration platform that
allows you to develop integration projects. TIBCO BusinessWorks includes a graphical user
interface (GUI) for defining business processes and an engine that executes the process.

TIBCO BusinessWorks also works with TIBCO Administrator, a web-based GUI for
monitoring and managing run-time components.

This chapter discusses what is required of an integration platform, and how TIBCO
BusinessWorks meets these requirements.

TheChallengeofApplicationIntegration

Application integration is one of the most pressing challenges of todays enterprise. An
enterprise may need to integrate back-office systems with the Internet, a purchase order
management system with the customer service management system, or any of the above with
legacy or ERP (Enterprise Resource Planning) systems.

An integration platform should allow you to design the business process, that is, the flow of
data. The business process should transparently receive and send data throughout the
enterprise and beyond.

IntegrationBenefits

The integrated enterprise works seamlessly. Different departments and groups share
communications and can together respond quickly to customer need. With less time spent on
administrative and manual tasks, employees become more productive and the integrated
system yields a significant return on investment. This return increases as the company grows.

The illustration below shows how TIBCO BusinessWorks connects to applications of
different types, databases, trading partners and exchanges, etc. This capability allows you to
use TIBCO BusinessWorks to integrate all aspects of your enterprise.

Figure1: TIBCO BusinessWorks communication throughout the enterprise

TIBCO

IntegrationPlatformRequirements

To be successful, your integration platform must meet the following requirements.

Short deployment cycle The integration project must be ready to go to production
within a realistic timeframe and deploying from development to a running project must
go smoothly.

Scalability and extensibility The project must be scalable (respond to increasing
demand) and extensible (allow integration of new applications or addition of new
business processes). Extensibility also means that the project must be flexible and
adaptable so you can potentially adapt it to multiple departments in the same company.

Ease of useIntegration projects are often developed by outside companies or
consultants. When the project is complete, the company itself becomes responsible for
maintenance and updates, and employees usually face a steep learning curve. If the
integration platform is easy to use, the project can be developed in house. Cost of
ownership is greatly reduced because the expertise is already there.

BusinessIntegrationScenario

To illustrate some of the functionality available as part of TIBCO BusinessWorks, the
rest of this manual uses a simple example scenario presented in this section. The section
starts with a problem definition, then discusses the run-time implementation.

ProblemDefinition

EasyWare Incorporated is a manufacturer of computer hardware. So far, the department
responsible for purchase order management has received orders by telephone and has
manually entered them into a PeopleSoft Order Management system. The customer
service department uses the information in the PeopleSoft system as well, but finds that
not all information they need is available there. An additional concern is that shipping
information is not included in the Order Management system. As a result, customers do
not receive notification when items are shipped and customer service representatives
must access the shipping information in a two-step process: first extracting the Order ID
from the
PeopleSoft system, then extracting the shipping information from the shipping log using
the Order ID.

Because a high volume of sales cannot be handled efficiently with this setup, and
because currently information available to the customer service department is
incomplete, customer satisfaction becomes an issue. Management decides to make the
following changes:
Make order entry possible by way of a secure web server outside the firewall which
communicates with an application server that supports JMS.
TIBCO
Add a Siebel customer service system that receives information about each purchase
order.

Before order fulfillment, require approval by a credit check specialist for orders over
$10 000.

Before the order is entered into the Siebel system, add information about shipping
date and time to each item. The information should be retrieved interactively from the
shipping companys web site via the Internet.
Customer service representatives can then have easy access to all ordering information.

AddressingtheChallenge

The challenge faced by EasyWare is to add the new capabilities to the business process
while, at the same time, reducing complexity for the end user. After careful deliberation,
the IT department decides to prepare a prototype using TIBCO BusinessWorks.

Design

The goal of the integration project is to allow EasyWare to receive orders either by
telephonewith direct access to PeopleSoft as beforeor from an application server.
The PeopleSoft Order Management system continues to be used, but data can be
entered manually as before or can arrive from the Internet via the application server. In
addition, the system must integrate with the Siebel customer service system.

This results in the following components of the integration project:

At the center is the business process, which interacts with the different services using
the appropriate messaging protocol.

An order is entered by way of a web application and the order is sent to the
PeopleSoft order-entry system through the PeopleSoft adapter. The PeopleSoft order-
entry system responds with a new order that includes an order ID. This part of the
process is a request-response service.

A ManualWork activity sends the order to the credit check specialist. The process is
on hold until approval has been made.

The business process accesses the shipping schedule by connecting to the shippers
web site using SOAP.

A Siebel adapter enters the complete order, including the PeopleSoft Order ID and the
shipping information, into the Siebel system.

Following Figure shows the components that are needed.

TIBCO
Figure2 : Example scenario components

ExampleScenarioRuntimeImplementation

At run-time, the project would proceed as follows
1. Orders arrive from the distributors on the Internet.

2. The orders are processed by a customized order capture system built on top of an
application server.

3. A TIBCO BusinessWorks JMS Queue Receiver activity receives the incoming order
document.

4. TIBCO BusinessWorks transforms the order, which was supplied in XML to a format
PeopleSoft expects and the PeopleSoft adapter submits the order to the PeopleSoft
Order Management system.

5. The PeopleSoft system accepts or rejects the order. When it accepts the order, it
includes an Order ID.

6. If the order amount is greater than $10,000, the order is sent out for credit check.
When the credit check is not successful, the customer is informed immediately and the
order placed on indefinite hold. Otherwise, if approval arrives, the process continues.

7. TIBCO BusinessWorks checks the shipping schedule using a web service activity and
adds the ship date to the order.

8. TIBCO BusinessWorks sends the information about the order, including the Order ID
and the shipping information, to a Siebel adapter. The Siebel adapter adds a new
customer service record to the Siebel system.

TIBCO
Figure3: Example scenario run-time implementation

The TIBCO BusinessWorks Integration Platform

This section introduces the TIBCO BusinessWorks integration platform by discussing
the following topics:

TIBCO BusinessWorks Key Components

TIBCO Administration Domain

TIBCO
TIBCOBusinessWorksKeyComponents

TIBCO BusinessWorks key components work together as follows:

The TIBCO Designer graphical user interface (GUI) supports adapter configuration,
process design, deployment configuration, and deployment of the integration project in
one easy to use interface. You can use TIBCO Designer in test mode to incrementally
verify your design during development. Rapid development and deployment are the
results.

The TIBCO BusinessWorks engine runs the business processes in test mode and at
runtime.

TIBCO Administrator supports security administration as well as monitoring and
management of processes and machines. TIBCO Administrator consists of the TIBCO
Administration Server and the web browser based TIBCO Administrator GUI.

The TIBCO Runtime Agent (TRA) runs on each machine and executes scripts, sends
alerts, and performs recovery as specified.

Optionally, TIBCO BusinessWorks interacts with TIBCO InConcert in its
implementation of ManualWork activities.

TIBCO BusinessWorks was designed using a plug-in architecture. As a result, plug-in
modules can be added to TIBCO BusinessWorks. The illustration below shows how the
components work together.

TRA is a prerequisite for TIBCO BusinessWorks and must be installed and configured
before TIBCO BusinessWorks is installed. TIBCO Administrator, TIBCO Adapters, and
TIBCO InConcert are separately purchased, installed, and configured. See the
documentation for each of these products for more information.

Figure4: TIBCO BusinessWorks components

TIBCO
TIBCOAdministrationDomain

The TIBCO administration domain combines the benefits of a distributed run-time
environment with centralized design-time deployment, and run-time monitoring and
management. This section discusses the TIBCO administration domain, the associated
security implementation, and how you monitor and manage the domain.

Administration Domain Overview

A TIBCO administration domain is a collection of users, machines, and TIBCO
BusinessWorks components that a TIBCO Administration Server monitors and
manages. There is only one Administration Server for each administration domain.
Components within an administration domain can communicate with systems outside
the domain, but the administration domain is the administrative boundary of an
enterprise integration project.

Note that when the Administration Server goes down, all process engines and adapters
continue to run.

Following Figure illustrates an administration domain and its contents.

Figure 5: Components of a TIBCO administration domain

A TIBCO administration domain consists of these elements, numbered correspondingly
in above Figure

TIBCO
1. TIBCO Administration ServerEach administration domain has one and only one
TIBCO Administration Server.

2. ComponentsComponent software includes the TIBCO BusinessWorks engine and
adapters.

3. MachinesEach TIBCO administration domain contains one or more machines. A
machine can be added to an administration domain when a TIBCO BusinessWorks
component or adapter is installed. By default, all machines within an administration
domain are expected to be in the same network subnet. You can, however, set up your
system to use TIBCO Rendezvous rvrd and can then use TIBCO BusinessWorks across
subnets.

4. User and Access InformationUser and authorization information is specified with
the TIBCO Administrator GUI and stored in the domain data store. See Security below.

5. ProjectsA project is created and with the TIBCO Designer GUI. You create an
Enterprise Archive file (EAR file) for the project with TIBCO Designer, thensend that file
to the machine where administration server resides. You can then deploy the project
with TIBCO Administrator. Once deployed, the project becomes visible in the TIBCO
Administrator GUI and its components can be started, stopped, and monitored from
there.

Security

The TIBCO Administration Server supports centralized authentication and
authorization. Using the TIBCO Administrator GUI, users with full administrative
privileges can define which users should have access to which part of the system.

AuthenticationThe verification of the identity of a person or process.

AuthorizationPermission to view or execute. An administrator gives users access
rights to the functionality of the product they need. For example, access rights are given
to view or to write to projects at design time from TIBCO Designer or to view or to
manage modules from the TIBCO Administrator console. The TIBCO Administration
Server controls that access.

TIBCO BusinessWorks supports authentication and authorization for both data
stores and components (process engines or adapters) in the administration domain. For
example, only authorized users may start or stop process engines or adapters. This fine-
grained user authorization scheme allows you to customize the system to your
companys needs.

TIBCO
MonitoringandManagingtheDomain

The TIBCO Administrator GUI allows you to monitor and manage the different
elements of the administration domain if you are authorized to do so.

View, add, and delete users and assign access privileges to each user.
Monitor and manage the machines in the administration domain.
Monitor deployments. This includes viewing component status and throughput and
looking at traces, which can also be exported to a file.
Manage deployments. This includes stopping and starting process engines and
adapters.

Architecture

This section explains the TIBCO BusinessWorks architecture at design time and
runtime. It discusses these topics:

Fundamentals
Design-Time Architecture
Run-Time Architecture

Fundamentals

The TIBCO BusinessWorks architecture is based on the following set of fundamentals:
Support for Standards
Integrated Development Environment
Extensibility and Scalability

SupportforStandards

Your integration platform must support standards for several reasons. A standards-
based integration platform supports you best as you add applications to your enterprise
or need to communicate with new business partners. Standards are essential as you are
planning for the future of the project because standards facilitate updates. Some of the
applications you use may already be using standards, and integration development will
be faster and easier. Support for standards also removes dependency on one companys
services and makes applications from different companies interact more easily.
TIBCO BusinessWorks supports the most widely used standards for the different
aspects of an integration project:

J2EE CompliantJMS, EJB, JNDI
ProtocolsWeb services (SOAP, WSDL), HTTP, HTTPS
MessagingJMS, TIBCO Rendezvous
Data DescriptionNative support for DTD, XSD, and TIBCO AE Schema
Data Representation and ExpressionsNative support for XML, XPath
Data TransformationXSLT
TIBCO BusinessWorks also supports a plug-in for B2B interactions.

TIBCO
IntegratedDevelopmentEnvironment

Your integration project must be supported by an integrated developmentenvironment
that spans all phases of the project. With TIBCO BusinessWorks, the process design,
deployment, and run-time environment are tightly integrated even though the run-time
environment supports a distributed architecture.

1. At design time, you use TIBCO Designer to configure services, such as adapters, and
design your business processes.

2. You can use the TIBCO Designer in test mode to debug the process definitions in your
integration project.

3. You can use TIBCO Administrator to deploy processes to process engines and to
deploy adapter services to adapters on the individual machines.

4. Optionally, you can configure manual activities using TIBCO Designer. When you
deploy the project, that information is then used by InConcert. The users authorized to
handle the manual activities can be specified in TIBCO Administrator, then exported to
TIBCO InConcert.

5. You can start the processes using the TIBCO Administrator GUI. You can then
monitor and manage all processes using TIBCO Administrator.

ExtensibilityandScalability

As your enterprise grows, new applications are added and volume of data increases.
Scalability to support higher volume and extensibility to support additional applications
or a larger number of process engines or adapter instances become paramount.
TIBCO BusinessWorks has been designed to be extensible and scalable. Working in a
distributed fashion, you deploy the different adapter services and business processes on
different machines in the administration domain. When the business process
applications volume increases, you add machines to the domain. As you acquire new
applications for your enterprise, you install the appropriate adapters into the domain.
You configure the adapter, modify your process definition, then deploy the adapter
service on the machine of your choice.

DesignTimeArchitecture

At design time, you work with the TIBCO Designer GUI to configure adapter services
and design business processes. You design a business process by dragging activities
(e.g. Read File or Send Mail) into the design window and joining the activities using
transitions. The TIBCO Designer test mode allows you to debug the business process.
You can provide input, add breakpoints, supply values for variables, and so on.
TIBCO
TIBCODesignerLayout

The TIBCO Designer main window has three or four panels that contain the design-time
components of an integration project. You can configure the TIBCO Designer GUI to
either display the project and palette panels separately or together.

Projects

A project consists of resources that contain the functionality needed for your integration
system. This includes services (producers and consumers of information) and any
business logic that may be applied to that information.
In TIBCO Designer, you click the project folder to display the projects resources. The
ProcessNewComputer project, shown in the project tree panel in Figure 7, consists of
several components:
A JMS shared resource (JMS Connection)
Two process definitions (ProcessOrder and ShippingSchedule)
A shared resource used by the SOAP activity (ShippingSchedule)
A Siebel adapter and a PeopleSoft adapter (SBLAccount and PSoft_ReqRep)
An Enterprise Archive file for the project (EAR file)

TIBCO

Resources

Resources are the components of a project. A TIBCO Designer resource corresponds to
an object in a TIBCO application, such as an FTP activity, a process definition, or a
specific adapter instance.

Palettes

Context-sensitive palettes organize resources into related groups. Which palette is
displayed depends on the currently opened resource and on your preferences. You drag
and drop resources from the palette into the design panel to add them to your project.

EnterpriseArchive

The Enterprise Archive resource allows you to create an Enterprise Archive file (EAR
file) that you can use to deploy the project. The EAR file contains shared archives and
process archives that you specify. These archives contain the adapter configurations and
process definitions you wish to deploy. After saving the Enterprise Archive file, you can
send it to the machine where the administration server resides. TIBCO Administrator
can use the EAR file to create a deployment configuration.

RunTimeArchitecture

When the integration project is deployed, the different process engines and adapters are
ready to run on the machines in the administration domain.
You start each component individually from the TIBCO Administrator GUI. After all
adapters and process engines have been started, process instances are created by
process starters. A process starter could be, for example, a File Poller or an Adapter
Subscriber activity waiting for incoming data. When data arrives, the process starter
creates a process instance using the process definition to which it belongs, and the
activities in the process are executed in sequence.
In following Figure, a JMS Queue Receiver activity creates an instance of the process
definition to which it belongs each time it receives input.

TIBCO

While different process instances are running, any alerts that were scheduled during
deployment configuration are sent to the specified recipient by the TIBCO
Administration server. In addition, the TIBCO Administrator GUI allows monitoring of
the running project at different levels of detail, and can collect tracing information for
later analysis.

For the example discussed in this manual, the process engine could perform these tasks:

Receive data from an application server via JMS, data from a PeopleSoft Order
Management System via the appropriate adapter, and data from a shipping service via
SOAP.

Enter data into a PeopleSoft Order Management system and data into a Siebel
customer service system via the appropriate adapters.

Send certain orders out for credit approval and receive approval or refusal.

All components are monitored and managed by way of TIBCO Administrator, which
also provides security and repository management. Users can access TIBCO
Administrator using the TIBCO Administrator GUI.

TIBCO

TIBCO BusinessWorks Features

This section discusses some TIBCO BusinessWorks features.

Messaging
Adapters
Business Process Modelling
Schemas and Data Mapping
Manual Activities

Messaging

To support your integration project at runtime, you need a messaging system that can
reliably handle the volume of messages that will be sent and received. The system
should have these characteristics:

Guaranteed delivery and fault toleranceMessage delivery must be guaranteed, and
the system must be fault tolerant. If a message cannot be delivered because the recipient
was unavailable, the messaging system must queue that message and continue to
operate. The queued message must then be redelivered as appropriate.

Distributed architectureA distributed, loosely coupled system is much more likely
to support the fault-tolerance you require than a monolithic system that depends on one
centralized server.

High throughputHigh throughput without performance degradation is needed.
Requirements vary throughout the day and throughout the business year, and you
cannot afford performance degradation at the time when business increases.

ScalabilityAs your business grows, you want to be able to update your business
integration in a simple and cohesive way. Furthermore, you want to be able to connect
your integration project with other departments using a similar system. The messaging
system must support this scalability.

TIBCO BusinessWorks is based on messaging standards with proven track records.
Supported protocols include TIBCO Rendezvous, JMS, and HTTP.

TIBCO
Adapters

Business information is distributed among different business applications (such as SAP
R/3 or PeopleSoft) or available from databases or files. Adapters help make this
information available to the business process by "adapting" the applications to a
common messaging system.

What are Adapters?

Adapters translate information into the appropriate format:

Adapters receive information from a source application and publish it to the business
process in a shared format.

Adapters subscribe to information from a business process and translate it to a format
the target application can understand.

Adapters can also be set up to work in a client/server mode (using remote
operations.)
The illustration below shows how a Siebel customer service system communicates with
the business process using an adapter publication service and the business process
communicates with the PeopleSoft Order Management system using an adapter
subscription service.

In TIBCO BusinessWorks, adapters provide services to activities inside the business
process.

TIBCO
Adapter Features

Companies in a wide range of industries have successfully used TIBCO adapters to
integrate different packages and custom applications. TIBCO BusinessWorks includes
second-generation adapters that are based on the same technology but have the
following new features:

Easy Configuration With Design-Time AdapterAll adapters included with TIBCO
BusinessWorks use a unified GUI that simplifies adapter configuration. A Design-Time
Adapter allows you to directly access the source application from the TIBCO Designer
GUI and specify the data the business process needs.

Easy Inclusion in Business ProcessesThe business process can communicate with
adapters by using activities found in the adapter palette. These activities interact with
each of the standard adapter services. For example, the Publish to Adapter activity
sends a message to an adapter subscription service.

Easy Deployment and MonitoringWhen you are ready to deploy your project, the
TIBCO Designer deployment palette allows you to assign each adapter to its own
machine. At runtime, the TIBCO Administrator GUI monitors each adapter in its own
panel. You can therefore easily see if one of the adapters is a bottleneck in the business
process flow.

TIBCOBusinessWorksAdapters

A fully integrated TIBCO BusinessWorks adapter can be installed into a TIBCO
administration domain and later monitored and managed from the TIBCO
Administrator GUI. TIBCO BusinessWorks fully integrates with the following adapters:

Technology adaptersIncludes adapters that access files or databases.

Application adaptersIncludes adapter for PeopleSoft, SAP R/3, Siebel, and others.

Other TIBCO Adapters can be loaded into TIBCO Designer and configured using the
Generic Adapter Configuration resources. These adapters can then be used in process
design and run as part of the integration project. They cannot, however, be installed into
the administration domain or monitored and managed via TIBCO Administrator.

TIBCO
BusinessProcessModelling

The business processes describe the actual flow of data inside the enterprise. It TIBCO
BusinessWorks, you use the TIBCO Designer GUI to design and test your processes.
Features include:

Configuration of adapter services.

A complete set of commonly used activities such as File Read, File Write, and File
Create, a set of email activities, timers, FTP activities, etc.

A transformation tool that lets you map the output of one activity to the input of
subsequent activities.

Conditional transitions supporting XPath syntax.

Grouping of activities.

An easy-to-use design-time process debugger.

Process Design Guide.

The illustration below shows a simple process that is part of the example scenario in the
design window.

TIBCO
SchemasandDataMapping

Different applications in your enterprise use different data representations. For
example, a purchase order in a PeopleSoft system differs from a purchase order in a
Siebel customer service system. TIBCO BusinessWorks allows you to view and
manipulate the data coming from and going into each service or activity using XML
schemas.

This section first gives a brief introduction to schema (Understanding Schemas), then
discusses "Schemas in TIBCO BusinessWorks."

UnderstandingSchemas

The example below shows a simplified XSD (XML Schema Definition) that includes an
Order ID element restricted to integer data. Incoming XML documents that use integers
for the Order ID are allowed, while an alphanumeric Order ID is rejected.

Schemas are especially useful if you are deploying a complex system. Schemas are used
by the running application but are not included in the code. The use of schemas makes
it possible to enforce that outgoing and incoming data strictly comply with the
prespecified data description.

TIBCO
SchemasinTIBCOBusinessWorks

In the TIBCO Designer GUI, you can define the schema for adapters and view and
manipulate the schema for each activity in the business process.
For business process activities, you can view the available process data and define the
input schema for each activity. The process data is the list of available data for that
activity. The input schema (required or optional) defines input values for an activity.
You can map the process data to the input data using a drag and drop interface.
You can specify conditional mapping using XPath, and you do not need detailed
knowledge of XPath for simple conditions

ManualActivities

TIBCO BusinessWorks includes a ManualWork palette with activities that you can add
to your business processes when the process requires user interaction for completion. In
our example, orders under $10 000 were processes automatically. For orders over 10 000,
an additional credit check is required.

In that case, the order is assigned to a pool of users for approval. One user accepts the
request, and approves or rejects it. If no one accepts the request, the manual approval
times out, and then the status of the request is checked. If no errors were returned, then
the work is still in the users queue, so the process waits for the completion of the
manual work. If errors were reported in the manual work, the work is marked as not
approved and the process completes.

TIBCO BusinessWorks allows you to:

assign a task to a pool of users,
check the status of the task,
change the status of the task,
download documents associated with a task,
or wait for the completion of a task.

The ManualWork palette works with TIBCO InConcert. Users and groups are defined
either in TIBCO InConcert or TIBCO Administrator (and then later exported to TIBCO
InConcert). An activity that assigns work creates a TIBCO InConcert job. The job can be
viewed and modified using TIBCO BusinessWorks web interface to manual tasks.

TIBCO

TIBCOBW
Methodology

TIBCO
BW Methodology

A TIBCO BusinessWorks integration project is developed in phases. Having a well-
defined methodology helps new users come up to speed quickly and allows different
developers to work together more easily.

Introduction

TIBCO BusinessWorks components are designed to support development in phases and
to let you seamlessly move from one phase to another.

Using TIBCO Designer, you configure services, for example, an adapter service.

You can then access the adapter service from activities inside the business process.

After youve configured adapter services and business processes, you can use
TIBCO Designer to assign adapter services to adapters and processes to process engines.
You assign each adapter and process engine to a machine in the administration domain
and deploy the project to the run-time environment.

You can then start and the adapters and process engines using the TIBCO
Administrator GUI and manage and monitor them from there.

Following the phases in sequence results in a fast deployment that closely meets the
specifications. Note that as a rule, you perform analysis, installation, and services
configuration only once, then iterate through the other phases until you have arrived at
the optimal configuration.

This section gives an overview of each phase, using examples from the example scenario
as appropriate

Phase 1: Analysis
Phase 2: Domain Setup and Installation
Phase 3: Services Configuration
Phase 4: Process Design
Phase 5: Deployment Configuration and Deployment
Phase 6: Production

TIBCO

Phase 1 Analysis
During the analysis phase, the different departments participating in the integration
project must come to a clear understanding of the requirements.
This chapter gives a brief introduction to elements of the analysis phase that typically
require special attention.

Step1:DefineandDelimittheProblem
The ultimate success or failure of your business integration depends on how clear you
are about the problem you are trying to solve. You can only succeed if you understand
the scope of the problem, the components involved, and the deployment parameters.
Before you start, it is therefore critical that you have a definition of the problem that is
as clear and precise as possible.
For example, a working definition of the example scenario could be the following:
EasyWare receives orders for computer hardware. The goal is to allow customers to
place orders through a web site, and to allow later expansion for other ways to
place orders.
Each order is processed by a customized order capture system built on top of an
application server.
The business process receives the incoming order document via JMS.
Each order is automatically entered into the PeopleSoft Order Management system.
Conversion to PeopleSoft format is required.
When the PeopleSoft Order Management system acknowledges acceptance of the
order, it includes an ID for the order.
Next, the business process checks the shipping schedule, which is available from an
external vendors web site.

TIBCO

7. If shipping is delayed, an email is sent to the customer.
8. Otherwise, the order is sent and all order information, including the generated
Order ID and the shipping information, is entered into a Siebel system. The
Siebel system creates a new customer service record based on the information.
Step2:IdentifyProcesses
A clean design of a complex process consists of a main process that calls subprocesses as
needed. The problem defined above lends itself to the creation of a process for each task
that is performed.
1. The main process listens for incoming data from the application server. When a
purchase order arrives, the main process calls the other processes in sequence.
2. The AddtoOrderMgmt process enters the order into the PeopleSoft Order
Management system. It returns the purchase order and the Order ID to the main
process.
3. The CheckShippingSchedule process accesses the web site of the shipping
company and sends an email to the customer if shipping is delayed. This process
could also update the status of the order in the Order Management system.
4. The AddtoCustMgmt process enters the order, including the Order ID generated
by PeopleSoft and the shipping information, in the companys Siebel customer
service system.
You can use TIBCO Designer to create the four processes and have the main process call
the other processes in the appropriate sequence.
Step3:IdentifyComponents
After you have identified the processes, you must understand the components of the
process. This section discusses some potential components.
Shared Resources
Services and Corresponding Activities
ManualWork Activities
Transitions and Conditions
Mapping
Exceptions
SharedResources
Some activities use shared resources. For example, a WSDL File shared resource is used
by SOAP activities and a JDBC Connection shared resource is used by JDBC activities.
TIBCO
ServicesandCorrespondingActivities
The business process uses services to retrieve or send data. There are two kinds of
services:
Adapter servicesThe source and target applications your enterprise uses
cannot directly talk to each other or to TIBCO BusinessWorks. To enable this
communication, you can use TIBCO adapters. Adapters can be configured using
TIBCO Designer.
Web servicesWeb services are external to TIBCO BusinessWorks but are
supported by several activities that are part of TIBCO BusinessWorks.
The example discussed in this manual requires the following activities:
An application server sends the incoming orders over JMS. The business process
uses a JMS Queue Receiver activity that receives the order.
A PeopleSoft adapter receives a request and sends data back to the process. For
the problem at hand, a request-response adapter service is well suited. The
business process uses an Invoke an Adapter Request-Response Service activity
to interact with the adapter.
A web service provided by the shipping company is invoked through a SOAP
Request Response activity.
A Siebel subscriber adapter service receives the order from a Publish to Adapter
activity and enters the order, including the Order ID assigned by PeopleSoft, into
the Siebel customer service system.
Other activities include a Send Mail activity that sends an email to the customer if
shipping is delayed.
ManualWorkActivities
The activities in the ManualWork palette are useful for automated business processes
that have a few steps which require user interaction. In many cases, the Assign Work
activity is appropriate for implementing the interaction. Other activities in the palette
include, for example, a Modify Work activity that allows administrators to perform
actions on a work item.
In order to use the activities in the Manual Work palette, TIBCO InConcert must have
been installed and users must have been created with TIBCO Administrator and
exported to InConcert.
See Step 5: Optionally, Add Manual Work Activities for some additional information.
TIBCO
TransitionsandConditions
Transitions go from each activity in the process to the next activity. Each activity must
have at least one incoming and at least one outgoing transition. Each activity can
potentially be called from several other activities or can conditionally call several
activities.
For example, if a credit check were included in a business process, the result of the
credit check outcome could determine the next activity. A negative credit check could
result in an email to the customer. A positive credit check could result in a different
email and placement of the order.
Mapping
For each activity in the process there is an appropriate input. For example, the Send
Mail activity needs input that includes information about the customer and the Order
ID. At times, the output of one activity directly maps into the input of the next activity
in the process. Very often, however, an activity requires a subset, or a superset of the
incoming process data, or data may need to be modified.
To give each activity the appropriate input, TIBCO BusinessWorks lets you map the
process data to the input of the activity. For example, the Send Mail activity uses the
customer email address and the Order ID but ignores the shipping address which is also
part of the order.
Exceptions
As you analyze your business problem, you should include as much information about exceptions
as possible. For the employees of your company, graceful exception management will result in a
noticeable increase in productivity. If exception handling is flawed, integration automation might
actually result in decreased productivity because a lot of time is spent on dealing with exceptions.
If exceptions are included in your initial design, you can make them part of the business process,
and ultimately deliver a more robust system faster.
Decide on exception handling standards across business phases to make it easier to identify
exceptions and understand how they are related.
Step4:DescribeBusinessEventsandObjects
Early in the analysis, you identified the business objects and events. At this stage of the
analysis, you must describe the events and objects in more detail. This includes:
Know the required data format at each place in the process (and how to get it).
Know the required data content (and how to get information that is not directly
available).
Understand what appropriate actions in case of a business or system-level error
could be.
TIBCO
Step5:DesignBusinessProcesses
After you have identified and described the components of the process, you can prepare
the actual design of the business process. This includes:
Activities involved. For example, the purchase order is received from a JMS
Queue Receiver activity and a Publish to Adapter activity sends the purchase
order to a PeopleSoft adapter subscriber service.
Data flow. Data flow includes both flow of data for the non-exception case and
for exception cases. Data flow may involve mapping, that is, putting the value
from one field into another. It could also involve transformation, that is,
translating data from one format to another. For example, PeopleSoft may store
phone numbers in a 10-digit format, while Siebel may use parentheses or dashes
as part of the phone number.
Part of massaging the data for each system requires transformation. You can set
up transformation using the mapper included with TIBCO Designer. Custom
java activities can be used to perform more complex transformation.
Exception flow. After you have identified the possible exceptions, you determine
what the system should do in case of an exception.
Step6:ConsiderDomainSetup
After youve completed the design of your business process, you should consider the
domain setup required to support it. For example:
What hardware is required to run the project? Is security an issue that might
influence platform choice?
What TIBCO software components do you expect to install?
o How many versions of TIBCO Designer and the TIBCO BusinessWorks
engine during design time.
o How many versions of the TIBCO BusinessWorks engine at runtime? If
you want to run in fault tolerant mode, you should plan on appropriate
hardware resources to support it.

TIBCO
Phase 2 DomainSetup

TIBCO BusinessWorks allows you to progress from project design to deployment and
production with minimal configuration and setup. To guarantee that the transitions will
be trouble-free, it is important that you understand setup of a TIBCO administration
domain and installation of different TIBCO products into the administration domain.

TIBCOAdministrationDomain
A TIBCO administration domain is a set of hardware and software resources. TIBCO
Administration Domain gives an overview of a domains elements.
Understanding the domain before installing the software is important because the
domain is set up during installation. Typically, the set-up depends on the phase of the
project:
During early stages, each developer typically installs the complete TIBCO
BusinessWorks package, including the TIBCO Administration server, on one
machine and develops and tests the project there.
Later, for final testing and production, the development team uses one TIBCO
Administration Server which manages different components (engines and
adapters) running on different machines.
The advantage of an administration domain is that the components of your integration
project automatically know about each other. They can be monitored as a group.
Security, that is, access to both processes and data stores, is shared across the
administration domain.
The administration domain is managed by a TIBCO Administration Server, which is
assisted by a TIBCO Runtime Agent running on each machine in the domain.
TIBCOAdministrationServer
The TIBCO Administration Server manages the administration domain. The server is
installed only on one machine in the environment and can be accessed with the
browser-based TIBCO Administrator GUI.

TIBCO
The Administration Servers main responsibilities are the following:
Enforce security for the domain. TIBCO BusinessWorks supports both authentication
and authorization of users that want view access or full access to the run-time
components.
Manage registration, that is, add deployed projects and machines to a domain.
Send appropriate information to each machines TIBCO Runtime Agent when a
project is deployed, and pick up alerts sent by those Runtime Agents.
Start and stop process engines and adapters.
Manage engines or adapters running in fault-tolerant mode if fault-tolerant setup
has been performed.
TIBCORuntimeAgent
When you install a TIBCO BusinessWorks component or a fully integrated TIBCO
ActiveEnterprise adapter on a machine, a TIBCO Runtime Agent (TRA) is automatically
installed. The TRA has two main functions:
Supplies an agent that is running in the background on each machine.
o The agent is responsible for starting and stopping processes that run on a
machine according to the deployment information.
o The agent monitors the machine. That information is then visible via
TIBCO Administrator.
Supplies the run-time environment, that is, all shared libraries including third-
party libraries.

TIBCO
Phase 3 Services
Configuration

The first phase in the actual business integration development is configuration of
adapter services. Adapters ensure that the different applications in your enterprise can
communicate in real time.

Introduction:TIBCOBusinessWorksServices
In TIBCO BusinessWorks, services are responsible for publishing or subscribing to
business data in a decoupled yet reliable manner. The business process receives data
from a service and routes data to a service. Examples of services are could be a
SendPurchaseOrder activity or a RequestShippingInformation activity. TIBCO
BusinessWorks supports web services for interaction with the Internet and adapter
services for interaction with files, databases, or different ERP (Enterprise Resource
Planning) applications.
Enterprise integration platforms typically use a tightly coupled architecture, where all
components of a business process are running on one server. If any component in the
system changes, the system no longer works. If the server goes down, all components of
the business process stop.
In contrast, a service-centric architecture supports self-contained services. Each service
is configured separately and can be deployed on a different machine. If one machine
goes down, all other parts of the process can still run. Service descriptions are stored
with the TIBCO Administration Server. The business process coordinates the services in
the appropriate way. For example, a process could contain a Publish to Adapter activity
that accesses an adapter subscriber service.
This loosely-coupled architecture makes it easy to change individual components as
needed.

TIBCO
ServiceCharacteristics
Thefollowingcharacteristicsareassociatedwithaservice:
Serviceinterface,forexampleWSDL/SOAPorAEServices
Transport,forexample,HTTP,JMS,TIBCORendezvous
Datasyntax,forexample,XMLorActiveEnterprisemessageformat
Dataschema,forexampleDTDorXSDschema
InvocationModes
Services can be invoked in several ways.
A one-way operation is executed once and does not wait for a response.
A request-response operation is executed once and waits for one response. In a
request-response service, communication flows in both directions. The complete
interaction consists of two point-to-point messagesa request and a response.
The interaction is only considered complete after the response has arrived.
Publication (notification) means an operation sends information on an as-needed
basis, potentially multiple times.
Subscription means incoming information is processed on an as-needed basis,
potentially multiple times.
Publication and subscription are driven by events, usually the arrival or creation of
data. Communication is in one direction (publisher to subscribers).
Service Types
TIBCO BusinessWorks includes both web services and adapter services. Web services
are accessed by SOAP activities. Adapter services are accessed by activities available in
the TIBCO Designer ActiveEnterprise Adapter palette that you can add to your business
process.
Web Services
TIBCO BusinessWorks supports Web Services Description Language, or WSDL. WSDL
is an XML-formatted language used to describe a Web service's capabilities as
collections of communication endpoints capable of exchanging messages.
You can use TIBCO BusinessWorks both to set up a web services server or to set up a
web services client. The activities you need are included in the SOAP palette.
TIBCO
Adapter Services
Adapter services allow your business process to publish data or subscribe to data used
by the enterprise. A publication service sends data to the business process, a
subscription service receives data from the business process.
Adapter services allow you to communicate with enterprise applications or interact
with other incoming and outgoing data. They include:
Technology adapters Allow publication to and subscription from files and
databases.
Enterprise application adaptersAllow you to interact with enterprise applications
such as Siebel, SAP R/3, and PeopleSoft.
AdapterServiceConfigurationSteps
Configuring an adapter service consists of these steps,
Step 1: Installing the Adapter
Step 2: Setting up the Design-Time Adapter
Step 3: Configuring the Run-Time Adapter
Step 4: Accessing the Adapter Service From the Process
Step1:InstallingtheAdapter
Different business processes have to connect to different enterprise applications. TIBCO
BusinessWorks therefore does not include adapters in its base package. Instead, you
install the adapter you need separately and add it to the TIBCO administration domain
during installation. Adapter installation therefore consists of these steps:
1. Install TIBCO BusinessWorks. As part of the installation, specify the name of the
TIBCO administration domain and specify the administrative user and password
for the administration domain.
You must establish the TIBCO administration domain and it must be running
and accessible before you install the adapter.
A TIBCO administration domain is a set of hardware and software resources. The
administration domain is set up to include one or more machines.
Install the adapter. During installation, specify the (already existing) TIBCO
administration domain and the administrative user and password.
After installation, a palette for that adapter becomes available from TIBCO
Designer the next time you start it.
TIBCO
Step2:SettinguptheDesignTimeAdapter
The TIBCO Designer GUI allows you to connect with the source or target application for
the adapter at design time using a design-time adapter. After you have established
design-time connection parameters, you can use the TIBCO Designer GUI to specify
schema information from the adapter.
To set up the design-time adapter, follow these steps:
Launch the TIBCO Designer GUI.
The appropriate adapter palettes should now be included.
2. Select the adapter palette and drag an adapter resource from the palette panel
into the design panel and name the adapter service.
Figure shows how you would drag a Siebel Adapter Configuration into the
design panel. The adapter service has been named SiebelPublisher.
Figure : Adding an adapter to the project

Specify connection information for the application you want to access so your
design-time adapter can connect.
In the project tree panel, double-click the adapter, then select its Adapter Services
folder to open it.
In the palette panel, the Services palette is displayed.
5. Drag an adapter service, for example, a publisher service, from the palette panel
into the design panel.
The configuration panel is updated to allow you to configure the service.

TIBCO
Figure : Adding a service to an adapter

From a command prompt, start the design-time adapter.
Specify the data the adapter should publish or subscribe to interactively.
8. Save the adapter.
Step3:ConfiguringtheRunTimeAdapter
With the design-time adapter running, you can configure the run-time adapter. You
configure each adapter service separately using the tabs in the configuration panel as
follows:
Specify run-time connection information using the Runtime Connection tab. You can
either specify the same information as that used by the design-time adapter, or
different information. For example, you can specify a different host machine or
user name or password.
Define adapter services and choose schema from the pop-up list provided via the
design-time adapter.
The exact process for defining services may vary slightly depending on the
adapter you are using.
Specify tracing information if desired. TIBCO Designer allows you to specify simple
tracing to a file or standard out using the configuration panel directly. You can
also specify advanced tracing, such as tracing to a network sink.
If your adapter uses advanced features, such as Advisory activities, you can configure
them using the Advanced folder of the adapter.
For additional information about adapter configuration, see the documentation for that
adapter, available via Help > Help For from TIBCO Designer.

TIBCO
Step4:AccessingtheAdapterServiceFromtheProcess
After you have configured the adapter service, you can access it from the process
definition. Creating a process is explained in Phase 4: Business Process Design. Once a
process is part of your project, you can access adapters as follows:

1. Select the process definition, then open the ActiveEnterprise Adapter palette.
Figure : Adding activities that access adapter services

Drag the activity that accesses the service you need into the design panel. You have
the following
choices:

TIBCO
Publish to AdapterPublishes data from the process to an adapter, which
subscribes to data coming from the process and passes the data to the
target application. In the example above, a Publish to Adapter activity
interacts with a Siebel subscriber.
Adapter SubscriberSubscribes to incoming data published by the adapter.
Invoke an Adapter Request-Response ServiceCommunicates (as a client)
with an adapter request-response service.
Adapter Request-Response ServerStarts a process based on the receipt of a
request from an adapter.
Respond to Adapter RequestSends a response to an adapter for a
previously received request.
Wait for Adapter MessageWaits for the receipt of a message from the
publication service of the specified adapter.
Wait for Adapter RequestWaits for the receipt of a request from a request-
response invocation service.
3. Specify the adapter information in the configuration panel.
Save your project.

TIBCO
Phase 4 Business
Process Design
This chapter discusses business process design. Using the TIBCO Designer GUI, you
create your business process using predefined activities and add conditions and
mapping as appropriate.
You can also display information about each resource by choosing its What is This
right-button menu command in TIBCO Designer.

Step1:DefineSharedResources
Shared resources allow activities to share information. For example, you can define a
JDBC Connection resource, then use it in any of the JDBC activities in your business
process.
You may also choose to define the process and create shared resources as needed.
Shared resources are available in some palettes and include Rendezvous Transport,
JDBC Connection, JMS Connection, and so on.
To define a shared resource, follow these steps:
In the palette panel, select the palette that contains the shared configuration
resource. For example, the JMS palette contains two shared configuration
resources, JMS Connection and JMS Application Properties.
2. Drag and drop the icon for the resource you need from the palette panel to the
design panel.
3. Name the resource and specify its configuration information in the configuration
panel, then click Apply.
You can now use the shared resource in any activity that requires it.
For example, the JMS Queue Receiver activity the example uses to connect to the
application server requires a JMS Connection shared resource.
TIBCO
Step2:CreateProcessDefinitions
In TIBCO Designer, you create process definitions by dragging Process Definition
resources from the palette panel to the design panel. You name each process definition
and give the process a description, then add activities to the process.
Figure Adding process definitions to your project
For simple business processes, activities are added in sequence, then transitions are
added as appropriate.
For complex business processes, it makes sense to design a main process and several
subprocesses. Using subprocesses makes your process easier to understand and debug.
Subprocesses also potentially allow reuse of business process components.
Our example program includes several different processes:
In the main process, which is called ProcessOrder, a JMS Queue Receiver waits
for input. When it arrives, the main process first interacts with the Order
Management system, then calls the ShippingSchedule process:
The ShippingSchedule process retrieves information about the shipping schedule
from the Shipping web site and adds shipping information to the order. It sends
an email to the customer if shipping is delayed, otherwise enters the order into
the Siebel system right away.

TIBCO

Step3:AddaProcessStarter
A process starter waits for input from an external process and creates a process instance
each time the input arrives. For example, the process could be waiting for a document
that arrives from an application server using JMS. A process starter could also be
polling a directory and start whenever a file is added.
To add a process starter, follow these steps:
Choose the process to which you want to add the process starter
2. Select the palette for the process starter in the palette panel.
In our example, the JMS Queue Receiver is the process starter.
3. Drag the process starter into the design panel.
The process starter activity replaces the default Start activity.
4. Specify configuration information, then click Apply.

TIBCO
Figure: Adding a process starter

Note that the default Start activity that is included with each process you instantiate is
not a process starter. A Start activity must be called explicitly from another process
Step4:AddActivities
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.
When you select a process definition, activities become available on the various TIBCO
Designer palettes. Each palette has a set of activities that can be performed for that
palette. For example, the ActiveEnterprise Adapter palette has activities that can publish
messages to a specified adapter or invoke an operation by way of an adapter. The JMS
palette includes activities such as JMS Queue Sender and JMS Queue Receiver.
A general-purpose Java Code activity allows you to write and execute standard Java
code to perform custom processing within your process definition.
To add an activity to the process definition in TIBCO Designer, follow these steps:
Select the appropriate palette. If the palette is not visible, make sure you have
selected the appropriate parent resource and make sure the palette has not been
closed.

TIBCO
Drag the activity into the design panel.
Select the activity and specify configuration information about it, for example, the
originator and address for a Send Mail activity.

Figure: Adding activities

Step5:Optionally,AddManualWorkActivities
The activities in the Manual Work palette are useful for automated business processes
that have a few steps that require user interaction. This could include handling of
unexpected situations or other activities such as credit approval or handling of
customers from abroad if the company usually deals with local customers. The
functionality is implemented by two shared configuration resources and four activities:
SharedConfigurationResources
Workflow SchemaThe data associated with a ManualWork task. This is the
data a user needs to complete the task. The user can change any of the data
associated with a task. A workflow schema supports string, int, date, and
document data types.
Workflow Connection The connection to the TIBCO InConcert workflow
server. This server is used to track and manage manual tasks.
TIBCO
ManualWorkActivities
Assign WorkCreates a new task (with associated data) and assigns it to the
specified pool of users. A user then acquires the task, views the data supplied by
the activity, and completes the work.
The process definition can either wait for the user to complete the work or it can
continue processing and later query for the status of the task.
Download DocumentManual work schemas can contain elements to hold
documents. An example of a document is a loan application that must be
attached to a credit request. The document may be any type, for example,
Microsoft Word, PDF, and so on.
Documents can be uploaded or downloaded to a manual work task by way of the
web interface TIBCO BusinessWorks provides for managing manual work tasks.
This activity allows you to download a document from an existing manual work
task into a process variable.
Get Work StatusRetrieves the current status of a task that was previously
created with the Assign Work activity. Normally you use this activity to
determine if the task has been completed or if there are any errors.
Modify WorkThis activity allows administrator users to change the status of an
existing task created with the Assign Work activity to one of the following:
o Update modifies the data associated with an uncompleted task
o Complete completes the task
o Reassign reassigns the task to a pool of users
Wait for CompletionWaits for the completion of the task for the specified
period. This is useful if the timeout for the Assign Work activity has passed and
you wish to wait for an additional amount of time.
Step6:CreateTransitionsBetweenActivities
You use transitions to connect activities to form a process flow. A transition is
represented by an arrow between two activities. Arrows are unidirectional, and you
cannot draw a transition to a previously executed activity. Control flow in a process
definition must proceed sequentially beginning with the starting activity and ending
with the End activity.
Conditions
A transition can optionally specify a condition. The condition determines whether a
transition is taken when an activity completes processing. After an activity completes,
all transitions whose conditions are met are taken. You can have transitions from one
activity to many other activities.
For example, if the shipping schedule indicates a delay in shipping the order, you want
to notify the customer and enter the information into the customer service system. If it
does not, you just enter the information into the customer service system.
TIBCO
AddingTransitions
To add transitions, click the transition tool on the menu bar to draw transitions between
activities. You use XPath syntax to define conditions.
If your process definition includes cyclical subprocesses (loops), you can group them
using the GUI.
Step7:PerformMappingandTransformationforEachActivity
As data flow through your business process, different activities require different
components of the data. On the Input tab of each activity, TIBCO Designer displays the
available process data and the activitys input represented as schema trees.
The process data is the list of available data items within the process 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.
For each activity, you map the process data to the activity input.
Each item in the activity input schema has an expression field for specifying the
contents of the item. You can conditionally map the process data to the input using
XPath expressions. You do not need detailed knowledge of XPath to create simple
expressions. 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.
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
node 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.
For example, when the ShippingSchedule process fails, an email is sent upon return to
the main process. The email address information could be mapped from the original
order to the mail activitys input fields.

TIBCO
Step8:Optionally,GroupActivitiesAsNeeded
Groups are used to specify related sets of activities. Grouping allows you to create
loops. The main uses of groups are the following:
Create a set of activities with only one condition for the group. This allows instead of
trying to individually catching errors on each activity. This type of group is
similar to a try...catch block in Java.
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.
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.
Step9:TesttheProcess
Once the process definition is complete, you can perform preliminary testing from
TIBCO Designer. In test mode, a TIBCO BusinessWorks engine is started to perform the
processing specified in the process definition.
The TIBCO BusinessWorks testing environment allows you to step through your
process models and find sources of errors. Entering the testing environment starts a
TIBCO BusinessWorks engine. The engine starts process instances based on the process
definitions stored in your project. The testing environment displays the running process
definitions and highlights the currently executing activity.
Testing a process definition typically involves these steps:
1. Select the process definition you wish to test in the project panel.
Click the Start Test Mode icon on the toolbar. This starts a TIBCO BusinessWorks
engine that will execute the processes.
2. Once the engine is started, the test mode icon displays on the toolbar to let you
know you are in test mode. Once you are in test mode, you cannot change your process
definition. You must exit test mode to make changes.
3. Set breakpoints in the process definition at points where you wish to stop a
running process and examine its state.
4. If necessary, supply input data to the process starter.
5. Click the Start/Resume Testing icon to create a process instance from the
displayed process definition.
TIBCO
Start a process by creating an event that the process starter is expecting. For example,
if the process starter is listening for a TIBCO Rendezvous message, publish a
message on the expected subject.
If you started multiple process instances, select the desired process instance from the
list of processes in the toolbar. Examine the process data by selecting any of the
activities in the process. The activitys current data is displayed on the Input and
Output tabs.
Use the toolbar buttons (Pause Testing, Step to Next Activity, Step Into
SubProcesses, Stop Testing, Start/Resume Testing) to either continue through the
process instance or to stop the current process instance.
When your process definition operates as expected, you can go on to deployment, the
next step in your integration project,

TIBCO
Phase 5 Deployment

For the success of your integration project, ease of deployment is at least as important as
ease of design. Because TIBCO BusinessWorks uses the TIBCO administration domain
and allows you to perform deployment configuration from the TIBCO Designer GUI,
deployment is a relatively simple task.

Introduction
When you have completed and tested the first prototype of your integration project in
the development environment, you are ready to deploy it to a testing environment.
In a traditional business integration project, domain configuration is a labor-intensive
process that is likely to require multiple iterations before all components are in place.
The administrator must tweak the configuration files for different components on
different machines. To optimize the configuration, administrator must manually keep a
record of the different configurations that were tested.
TIBCO BusinessWorks, in contrast, allows you to use the TIBCO Administrator GUI to
create a deployment configuration and then deploy the project.
You use the TIBCO Designer GUI to create an Enterprise Archive file (EAR file)
containing the adapter configurations and process definitions you wish to
deploy.
TIBCO Administrator uses the EAR file when creating the deployment
configuration.
You can deploy the project in TIBCO Administrator and the necessary scripts and
other information is sent to the machines within the deployment.
TIBCOBusinessWorksProjectPhases
When process design is complete and all testing from the TIBCO Designer GUI results
in success, the project is ready for deployment.
The illustration below shows how a project moves through the development and
deployment phases.

TIBCO
Figure: Project development phases

1. Using TIBCO Designer, the developer configures adapter services and saves the
project with configured adapters. Different adapters could potentially be
configured by different developers and included in one project.
2. Using TIBCO Designer, the developer configures activities for the business
process(es) and saves the project, which now includes process definition(s).
The built-in test mode is used for preliminary testing and debugging of the business
process(es).
Using TIBCO Designer, the developer prepares the Enterprise Archive File (EAR file)
by creating Enterpirse Archives containing the desired adapter configurations
and process definitions.
At this stage, the developer moves from the TIBCO Designer development GUI to the
TIBCO Administrator run-time GUI and performs these tasks:
1. From TIBCO Administrator, the deployment configuration is created and
deployed. The TIBCO Administration Server sends all necessary information to
the individual machines. All components now become visible in the TIBCO
Administrator GUI (but are not started).
2. From TIBCO Administrator, the developer starts each component (adapter and
process engine). As a result, all process starters are waiting for the events that
cause them to create process instances.
3. Each time an event arrives that triggers a process starter, the TIBCO
BusinessWorks engine creates a process instance, which uses the associated
process definition to process the incoming data.
4. Using TIBCO Administrator, the developer can monitor the different processes
running on the different machines.
If appropriate, the project can be modified and saved from TIBCO Designer. In that
case, you must create a new EAR file and place the new file into the deployment
configuration. You must then stop and restart the desired deployment for the changes to
take effect.
.
TIBCO
Phase 6 Production
During the production phase, you monitor and manage TIBCO BusinessWorks
deployments. The TIBCO Administration Server and the TIBCO Administrator GUI
together support your deployed TIBCO BusinessWorks products at runtime. This
chapter gives an overview of available functionality.

Introduction
After the integration development team has configured and deployed the integration
project, you can use the TIBCO Administrator GUI for monitoring and management.
This chapter gives an overview of the architecture and of the user management,
administration domain monitoring and management, and deployment management
options.
Architecture
TIBCO Administrator consists of the TIBCO Administration Server and the TIBCO
Administrator GUI. The Administration Server includes an application server
component for HTTP communications and a repository server component for data store
management. All three server components run as a single process.
The Administration Server interacts with each machine in the administration domain by
way of the TIBCO Runtime Agent (TRA) running on that machine.
The Administration Server receives information about CPU and memory usage,
alerts, and the process instances and components running on each machine and
makes them available via the TIBCO Administrator GUI.
The TIBCO Administrator GUI allows users to start and shut down components.
Start and shutdown commands are sent from the Administration Server to the
appropriate TRA, which in turn starts or stops the process.
The illustration below shows an administration domain with 3 machines in the domain.
The first machine runs the Administration Server, which contains an embedded
Repository Server for managing data stores. Machines outside the administration
domain can view the TIBCO Administrator GUI using a web browser. Each user
sees only the components for which s/he is authorized.
TIBCO
The second machine runs two adapters. The adapters are started via the TIBCO
Administrator GUI. The information entered in the GUI is sent by the
Administration Server to the TRA on the machine running the adapter. The TRA
starts and stops the adapter and also sends information about component and
machine status to the Administration Server for access via the GUI.
The third machine runs a process engine. Just like the adapters, the process
engine is managed by the Administration Server via the TRA.
Figure: Communication inside a TIBCO administration domain

MonitoringandManagementOptions
At runtime, TIBCO Administrator allows you to remotely access all deployments in
your administration domain. Depending on your security privileges, you may be able to
perform one or more of the following tasks.
User ManagementAdd users and passwords to the administration domain for
authentication, then give each user view or execute privileges for TIBCO
Administrator GUI elements or project repositories (data stores).
Domain Monitoring and ManagementView the status of machines and
components running on machines in the domain. Start and stop components as
needed.
Deployment monitoringMonitor the status of each deployment component
(process engine and adapter) and process instance and the status of the machines
executing them. View trace files and throughput.
Deployment managementView all running components and stop and restart
them as needed.
These aspects of monitoring and management are supported by TIBCO Administrator,
which includes the TIBCO Administration Server and the TIBCO Administrator GUI

TIBCO

Variables

TIBCO
Variables
There are several types of variables in TIBCO Business Works, each with their own
purpose and usage. TIBCO Business Works provides the following types of variables:
Global Variables these variables allow you to specify constants that can be
used throughout the project. The constants can be specified and changed while
designing and testing your project.
Process Variables these variables allow you to access various data in your
project.
For example, there are predefined process variables containing the process ID,
project name, and other information. You can also create user-defined process
variables for containing process-specific data.
Shared Variables these variables allow you to specify data for use across
multiple process instances. Because multiple process instances can access the
same variable, you can also synchronize access across processes when setting or
retrieving the shared variable.
GlobalVariables:

Use the global variables editor to create or modify global variables, mark variables as
settable from TIBCO Administrator, and assign a type to a variable.

The global variable editor:

TIBCO

Global Variable Attributes:

Name Provide a name for the variable.

Value Provide a value for the variable, depending on the type you select.

Deployment Select the deployment check box to make the variable visible and
settable when deploying using TIBCO Administrator. If the check box is clear, the
variable is not visible in TIBCO Administrator. Make certain that all variables used in
TIBCO BusinessWorks process definition have this field checked.

Service Indicates that the variable should be included when the Include all service
level global variables option is selected when building the enterprise archive file. A
variable that is settable on a per-service basis can be set for each adapter service. This
option is used for TIBCO adapter archives. TIBCO BusinessWorks does not use this
setting.

Type Click in the field to select the variable type, String, Integer, Boolean, or
Password. If Password is selected, the value you provide is obfuscated in the repository.

Constraint For String and Integer types, provide a range of allowed values. The
constraint field for Strings is an enumeration, for example, one, two, three. The
constraint field for Integers is for a range, for example, 1-100. Note that constraints are
currently not implemented in TIBCO Administrator.

Description Provide a description of the variable.

To find where global variables are used:
Click Tools > Find Global Variable Usages.
Changing Global Variable Values at Runtime
You can change the value of a global variable when you deploy your project
in TIBCO Administrator.

Changing when starting a process engine on the command line.
Specify the following as a command line argument when starting the
process engine:
-tibco.clientVar.<variablePathAndName> <value>

Example: -tibco.clientVar.myGroup/item1 500

TIBCO
ProcessVariables:

Process variables are data structures available to the activities in the process.
There are four types of process variables:
Activity Output
Predefined Process Variables
Error Process Variables
User-Defined Process Variables
ActivityOutput:
Activities have access to any data that is output from previously executed activities in
the process definition. An activitys output is placed into a process variable with the
same name as the activity (with a dollar sign placed in front of the name to indicate it is
a process variable).
PredefinedProcessVariables
There are two process variables that are available to all activities that accept input:
$_globalVariables:
1. contains the list of global variables defined on the Global Variables tab of
the project
2. Only global variables that have the Deployment option checked (on the
advanced editor dialog) are visible in the $_globalVariables process
variable.
$_processContext:
$_processContext contains general information about the process, such as the
process
ID, the project name, whether the process was restarted from a checkpoint,
and so on.
ErrorProcessVariables
When an error occurs in a process, the data pertaining to the error is placed into
process variables.
1. $_error : contains general error information
2. $_error_<activityName>: the activitys error variable is populated with the
appropriate error schema.
UserDefinedProcessVariables
You can define your own process variables and assign values to them in your process
definition. Process variables are defined on the Process Variables tab of the Process
Definition resource.

TIBCO
Creatingaprocessvariable

To assign a value to a user-defined process variable, use the Assign activity. Assign
allows you to specify which process variable you wish to modify. Only user-defined
process variables can be modified. You can then specify a new value for the process
variable in the Input tab of the Assign activity.

Assigningavaluetoauserdefinedprocessvariable

All process variables in a running process instance are stored in memory and therefore
consume system resources.

TIBCO
SharedVariables
A shared variable is a shared configuration resource in the General Activities palette.
There are two types of shared variables:
Shared Variable
Job Shared Variable
Shared Variable
A Shared Variable resource allows you to share data across process instances. All
process instances can read and update the data stored in a shared variable.
This type of shared variable is useful if you wish to pass data across process instances or
if you wish to make a common set of information available to all process instances.
Job Shared Variable
A Job Shared Variable resource is similar to a Shared Variable, but its scope is
limited to the current job. A copy of the variable is created for each new process
instance. This type of shared variable is useful for passing data to and from sub-
processes without creating an input or output schema for the called process.
You can use the Get Shared Variable and Set Shared Variable activities to access
the data instead of mapping data to a called process input or output schemas. New
process instances receive a copy of the Job Shared Variable, so data cannot be shared
across process instances.

TIBCO

XPath

TIBCO
XPath
XPath (XML Path Language) is an expression language developed by the World Wide
Web Consortium (W3C) for addressing parts of XML documents. XPath also has basic
manipulation functions for strings, numbers, and booleans.
TIBCO BusinessWorks uses XPath as the language for defining conditions and
transformations. For a complete description of XPath, refer to the XPath specification
XPathBasics
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
TheXPathFormulaBuilder
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.
Following Figure illustrates using the XPath formula builder to drag and drop schema
elements into function placeholders.

TIBCO
DescribethedifferentareasoftheXPathformulabuilder.
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.
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 functions
parameters. You can drag and drop schema elements
from the Data tab into the functions 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.
Constants tab Displays the constants available for use in XPath
expressions. These are categorized into groups and
each constant can be dragged from the constants list
into the XPath Formula field.
Constants are useful for inserting special characters,
such as tabs, symbols, and so on, into XPath formulas.
Constants are also defined for commonly used items,
such as date formats.
Documentation panel Describes each selected function. As you click on a
function in the Function tab, the documentation panel
gives a brief description of the function and one or
more examples.
Evaluation Context field Displays the evaluation context of the expression field
that the editor was invoked from. See Evaluation
Context for more information about the evaluation
context.
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.
Expression Evaluates To Panel Displays the result of evaluating the formula shown in
the XPath Formula field. If there are errors in the
formula, they are displayed here.

TIBCO

Following Figure 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.
Figure Creating an XPath formula

AddressingSchemaElements
All process data and activity input are represented as an XML schema. Regardless of
where the data comes from or its format, TIBCO BusinessWorks represents the data as a
schema tree. The data can be simple (strings, numbers, booleans, and so on), or it can be
a complex element. Complex elements are structures that contain other schema
elements, either simple elements or other complex elements. Both simple and complex
elements can also repeat. That is, they can be lists that store more than one element of
the given type.
XPath is used to specify which schema element you would like to refer to. For example,
the following schema may be available for an activitys input:
TIBCO

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 in 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.
EvaluationContext
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.
TIBCO
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.
SearchPredicates
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 in the repeating element, you would specify the
following:
$GetOrderInformation/OrderDetails/OrderItem[1]
The [1] specifies the first element of a repeating item.
Sub-items can also be examined and used in a search predicate. For example, to select
the element whose ProductId is equal to "3A54", you would specify the following:
$GetOrderInformation/OrderDetails/OrderItem[ProductId="3A54"]
You can also use functions and expressions in 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 in 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.
TestingForNil
Some elements can be explicitly set to nil. You can test an element to determine if it is set
to nil or not. For example, the following XPath expression returns true if the
$Order/Item/OnSale element is set to nil:
$Order/Item/OnSale/@xsi:nil="true"
TIBCO
Comments
You can add comments to XPath expressions using the XPath 2.0 syntax for comments.
The syntax is:
{-- <comment here> --}
For example, the following XPath expression contains a comment:
$GetOrderInformation/ShipName/Street {-- returns the street --}
StringRepresentationsofDatatypes
When data must be represented in the input or output of an activity, the data is
represented as a string. For example, writing the output of an activity to a file requires
that numeric data be serialized into string form. Also, supplying a floating point
number to an XPath function in the Input tab of an activity often involves typing the
number as a string into the input element. TIBCO BusinessWorks follows the XPath 1.0
standard for representing all numeric datatypes. TIBCO BusinessWorks follows the
XML Schema canonical format for all other datatypes.
The following sections describe the string representations of datatypes.
NumericDatatypes
Numeric datatypes include all types derived from xs:integer, xs:decimal, xs:float, and
xs:double.
All decimal, float, and double numbers are compressed to an integer when represented,
if there are only zeros following the decimal point (for example, "1.000" is represented as
1). Scientific notation is never used to represent a floating point number as a string (for
example, "xs:double(1.234E05)" is represented as 123400). Data is truncated if the
number of digits exceeds the maximum precision for the datatype (for example,
"xs:float(1.23456789)" is represented as 1.2345679).
Both zero and negative zero are represented as 0. Positive and negative infinity are
represented as Infinity and -Infinity. Not a number is represented as NaN.
Boolean
The boolean datatype is used to indicate a true or false state.
xs:boolean(true) and xs:boolean(1) are represented by true. The XPath function true()
is also represented as true.
xs:boolean(false) and xs:boolean(0) are represented by false. The XPath function
false() is also represented as false.
TIBCO
DateDatatypes
Activities in TIBCO BusinessWorks implement dates in one of two ways. Either a date is
stored as the number of milliseconds since January 1, 1970, or the date is implemented
according to the XPath 2.0 or XQuery 1.0 standards as a set of normalized components
(xs:date, xs:time, xs:dateTime, and so on) with an optional time zone offset. Activities
that are associated with Java (for example, Java Code, Java Method, and so on) use the
first implementaton. Activities that are associated with XML (for example, Mapper,
Parse XML, and so on) use the second implementation. The second implementation
supports arbitrary precision of the seconds component.
Conversion between these representations may result in a loss of information either
because of the difference in time zone representation or the precision of the seconds.

Dates output by the Java Code activity contain the time zone. Other Java activities (Java
Method, Java to XML, and so on) do not use the time zone. Therefore mapping a date
output by a Java Code activity to the input of any other Java activity will result in the
loss of the time zone information.
DateandTimeFunctions
There are some functions in the XPath formula builder that allow you to parse or format
strings that represent dates and times. These functions are:
format-dateTime(<<format>>, <<dateTime>>)
format-date(<<format>>, <<date>>)
format-time(<<format>>, <<time>>)
parse-dateTime(<<format>>, <<string>>)
parse-date(<<format>>, <<string>>)
parse-time(<<format>>, <<string>>)

The format parameter of these functions is based on the format patterns available for the
java.text.SimpleDateFormat Java class. In the format parameter, unquoted alphabetic
characters from A to Z and a to z represent the components of the date or time string.
You can include non-pattern alphabetic characters in the string by quoting the text with
single quotes. To include a single quote, use .
Following Table describes the alphabetic characters and their associated presentation in
a date or time string.

TIBCO
Table Formatting characters in date or time strings
Letter Description Example
G Era
Four or more Gs return the full name of the era.
AD
y year
Two ys return two-digit year.
2003; 03
M Month in year
Three or more Ms return text name.
August; Aug; 08
w Week in year 48
W Week in month 3
D Day in year 254
d Day in month 28
F Day of week in month 3
E Day in week
Four or more Es return the full name of the weekday.
Friday; Fri
a AM/PM marker
Four or more as return the full name.
AM
H Hour in day (0-23) 23
k Hour in day (1-24) 1
K Hour in AM/PM (0-11) 11
h Hour in AM/PM (1-12) 1
m Minute in hour 59
s Second in minute 48
S Millisecond 456
z Time zone represented as a GMT offset. GMT-08:00
Z RFC 822 four-digit time zone format -0800
all other letters Reserved
For any format pattern letter that returns a numeric value (for example, w, h, and m),
the number of letters in the format pattern represents the minimum number of digits.
For formatting functions, if the date or time has fewer digits than the number of pattern
letters, the output is padded with zeros. For parsing functions, when the date or time
has fewer digits than the number of characters in the format pattern, the extra characters
are ignored, unless they are needed to determine the boundaries of adjacent fields.

TIBCO

Following Table illustrates some example date and time format patterns and the
resulting string.

Table Example date and time format patterns
Date/Time Pattern Result
"yyy.MM.dd G at
HH:mm:ss"
2003.3.11 AD at 09:43:56
"EEE, MMM d, yy" Tue, Mar 11, 03
"hh oclock a, zzzz" 9 oclock AM, GMT-8:00
"K:mm a" 0:08 PM
"yyMMddHHmmssZ" 010704120856-700

TIBCO

Error Handling

TIBCO
Error Handling
Errors can occur during activity processing. We can specify that one transition out of an
activity is to be taken in the case of an error. We have to specify activities to execute in
the event of an error. This allows us to create error-handling procedures for dealing
with potential runtime errors in 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. Fig
illustrates this simple error-handling procedure. The error transition is used to specify
the activities to execute in case of an error.
Fig A simple error-handling procedure

Error handling can also involve significantly more complex processing. The following
sections describe error handling in more detail.
TheErrorProcessVariables
When an error transition is taken, error data is available to activities that execute after
the error transition.
There are two types of process variables that contain error data,
1. $_error process variable and the activity error variables.
2. Activity error variables are named $_error_<activityName>,
All activities that have an error transition are available in the Process Data panel
after an error transition is taken. We can use the data in these process variables to
perform the desired processing, depending upon what error occurred.

TIBCO
The following sections describe the two kinds of error process variables.
$_errorProcessVariable:
The $_error process variable contains general information about the process in which
the error occurred. 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 activity-specific error information.
When we create an error-handling procedure, we may find the data in the $_error
process variable useful. We can map data from this process variable into Input items for
activities in error-handling procedure.
$_error_<activityName>ProcessVariables
Each activity has one or more predefined error schemas. The error schemas are
displayed on the activitys Error Output tab. Typically, there are two or three types of
exceptions an activity can encounter, and these are represented as a choice element in
the error output schema. For example, the following illustrates the error output schema
of the Create File activity:

When an error is encountered, the $_error_<activityName> process variable is created
and populated with the error data. The name of the process variable is dependent upon
the activitys specified name.
TIBCO
We can obtain the error by examining the $_error_<activityName> process variable in
subsequent activities after an error transition. The following illustrates the Process Data
panel that is available after the activity named MyCreateFile encounters an error:

We can use the msgCode element to determine the kind of error that occurred. TIBCO
BusinessWorks Error Codes lists all error codes that activities can return.
We should use the error code instead of the error message text to detect and handle
errors. The error code should remain constant from release to release, but the text of
the message may change.
ErrorPropagation
Groups and called processes define the scope of an exception.
1. An exception that occurs within a group or a called process causes processing to
halt.
2. Any unhandled exceptions are propagated to the next highest exception scope.
3. Unhandled errors occur where there is no error transition or Catch activity that
specifies the activities to execute in the case of an error.
4. Also, we 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 next
highest exception scope.

TIBCO
The following sections describe propagation of errors for groups and called processes.
GroupErrorPropagation
Unhandled errors halt the execution of a group and the error transition out of the group
is taken. Fig illustrates a process definition that waits for new text files, parses the files
into an XML schema, then inserts the records into a database table.
Fig: Propagating errors from a group

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 next exception scope. If the iterate group experiences an error, the
WriteLogEntry activity is executed, then the error transition out of the group is taken to
the Send Mail activity.
The transition to the Send Mail activity is taken 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 variables contain 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.
TIBCO
CalledProcessErrorPropagation
When a process definition calls another process definition, the called process can
encounter errors. Any unhandled errors encountered when executing the called process
cause the called process to halt execution and return the error to the next highest
exception scope. Fig illustrates a process definition that waits for an incoming HTTP
request that contains an order.

Fig: propagating errors from a called process

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.
If the GetCreditLimit or ProcessOrder processes encounter an error, a response is sent
back to the customer stating there was an error in the order and the process definition
terminates.
The error process variables contain the error information for the activity where the error
occurred. Also, a process can define an error schema and use the Generate Error activity
to propagate specific data to the parent process.
ProcessErrorSchemas
The error process variables contain the default data returned in the event of an error.
We 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 definitions End Activity.
Error schemas are created like any other schema. However, the Error Schema tab of the
End activity allows We to create more than one error schema. Fig illustrates the Error
Schemas tab with two error schemas. The left panel of the tab allows We to create or
delete schemas. The middle portion allows We to modify the selected schema. The right
panel of the tab allows We to modify each schema item.

TIBCO
Figure: The Error Schemas tab

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

Fig The Generate Error Configuration tab

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 We can map data to the specified error schema. At run time, the
Generate Error propagates the specified error schema to the parent process in the
$_error_<activity-name> process variable.
The process variable is derived from 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 in a
group, the <activity-name> portion is the name of the Generate Error activity in the
group.
TIBCO
In the example described in Called Process Error Propagation, the SendErrorInOrder
activity has access to the error schema supplied by any GenerateError activity in the
GetCreditLimitProcess. This process specifies two error schemas, InvalidCustomer and
NotEnoughCredit. Fig illustrates the process data available to the SendErrorInOrder
activity.
Figure: Example of process data for error schemas

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. We can use XPath to determine which schema is
actually contained in the element, and then map the data in the schema accordingly.
UsingtheCatchandRethrowActivities
We can place a Catch activity in our process definition to deal with unhandled
exceptions. The Catch activity allows us to create a track that handles the exception and
proceeds to the end of the current scope; either the end of the process definition or the
end of a group. We can use the Catch activity as an alternative to individually handling
exceptions for each activity, or We can use error transitions to handle some exceptions
and the Catch activity to handle others.
Fig illustrates the Catch activity. The process waits for incoming orders sent by way of
HTTP requests. When an order arrives, each line item is checked for availability in the
ForEveryLineItem group. If an error occurs while checking the inventory, execution
transfers to the CatchInventory activity. A log file entry is written, and then the
transition is taken to the end of the group. If the inventory is available, the order is
processed, a confirmation email is sent, and the response is sent back to the HTTP client.
If the inventory is not available, a response is sent back to the HTTP client stating that
one or more items are not available. If an error occurs outside of the ForEachLineItem
group, execution transfers to the CatchAllOthers activity.

TIBCO
Fig Example of using the Catch activity

The Catch activity can specify the type of exception that should be caught. A list of
exceptions that can be raised in the current scope are available on the Configuration tab
of the Catch activity. We can have more than one Catch activity in the current scope, but
each one must handle a different exception type. Any exceptions that are not already
handled by an error transition or Catch activity can be handled by a Catch activity that
specifies the Catch All option on the Configuration tab.
Transitions cannot be drawn to a Catch activity. Also, we cannot draw transitions from
any activity on the path of the Catch activity to any activity on the regular execution
path. Activities on a Catch path can, however, have transitions to other activities on
other Catch paths. The Rethrow activity allows us to throw the exception currently
being handled by a Catch path. This is useful if we wish to perform some error
processing, but then propagate the error up to the next level.

TIBCO

WEB SERVICES

TIBCO

WEB SERVICES

Overview

The diagram above is the schematic for this example. There are two Business
Works Process Engines, one that exposes an HTTP Receiver and performs a SOAP
Request/Reply to the second engine, which is the SOAP Server that encapsulates the
actual service. This second engine is comprised of a SOAPEventSource, a Java Code
Task, and a SOAPSendReply. The HTML Client POSTs three elements the principle,
the interest rate, and the number of months for the loan. The WebService does the
calculation and returns the monthly loan payment. To simplify matters, I will omit the
HTML and Browser aspects of the example.
WebServicesMethodologywithBusinessWorks5.X
There are two ways to approach building this project you can pseudo-code
the process, or wing it! If you chose the pseudo-code route, you will notice that you
have: two processes, a complex schema that outlines the inputs and outputs (or two
schemas one for input and one for output), two WSDL files, two HTTP Connections,
and two Process Definitions one for the SOAP Client and one for the SOAP Server. If
you know what you need, it is simpler if you have the objects at hand, so you can
create them now! If you wished, you might want to drag & drop these elements into
the project, otherwise, just follow along.
TIBCO
SchemasfortheSOAPServer
As the Service Description for the Service (concrete) depends on the SOAP
Server (abstract), it makes sense to start this project with this process engine (Server
Process Definition). We know that we need three inputs and a single output, so we
create an XSD to represent our schema. Note that you must include a target Namespace
for use in WSDL. In TIBCOs Turbo XML, this is available under File->Schema
Properties.

Create appropriately names folders for your project. I have folders named:
Communications
WebServicesProcessDefs
WSDLs
Start by opening up the WSDLs Folder, and accessing the XML Tools Palette. Drag &
Drop a Schema Object into the folder. As shown below, I have named this schema
loanpayWS.

In BusinessWorks 5.X, targetNamespace is entered under the Configuration Tab as shown below:

TIBCO

Double-click on the Schema Icon, and you will see a spreadsheet-like interface with
which to build your XSD. Note that the Input Element has as its contents the other
elements used in the SOAP client.

Here is the source of this XSD:

TIBCO
UsingtheSchemaintheWSDLEditor
Open up the WSDL Palette and Drag & Drop a WSDL object into your WSDLs Folder.
You can Copy from URL, Browse UDDI, or you can double click to make your own
WSDL next, we will double-click and use the XSD we created in the last section. As
this will be the Service WSDL, name it AbstractDocLiteral, and then Drag & Drop two
Message Objects and a PortType and name the messages appropriately. Take the first
message, and associate the input aspect of the Schema in five easy steps:

1. Click the Plus sign to add a Part to the Part Table
2. Name the Part inputString
3. Choose Element
4. Pick the Binoculars to browse the resources and pick the schema in Part Details
5. Navigate to the XSD, and highlight the element input, click O.K. then Apply.
For the Output message, perform the same process, but in the XSD, choose the element
answertext.

Next, double-click on the PortType, and Drag & Drop an Operation Ive called this one
OperationOne. In a similar fashion to assignment of the messages, you will use the
process to add an input type, an output type, and an optional fault type to the Message
Table, and then associate each kind with the specific type of message you just built
earlier.

TIBCO
Here you see that Ive created an input type for the Message Table that is associated
with the inputMessage that we created for this WSDL. Repeat for the output type.

Now we are done with our Abstract WSDL creation! We will use this WSDL to create
the Service, and with the addition of some communication specifics, we can derive the
Concrete WSDL for our Client. Here is the WSDL Source:

TIBCO
ProcessDefinitionfortheSOAPServer

Open the WebServiceProcessDefs Folder (or whatever you called it), and Drag & Drop a
Process Definition Object into the folder, and name it WebSvcDocLitLoanPay. Next,
Drag & Drop a SOAP Event Source, Java Code Activity, and SOAP SendReply
Activities, and connect them as shown. Label them appropriately. We will need to go
back to the project view and create a single HTTP Connection in the Communications
Folder you created earlier this configuration is as simple as picking a Port number that
is not in use, I used Port 88.
Configure the SOAPEventSource by using the two binoculars on the Configuration Tab,
and choosing the namespace and Port Type of the Abstract WSDL we just created, and
check that it has both an Input and an Output. The second binocular will let you
browse the Transport, and you will pick the HTTP Connection you just configured.
SOAP Event Source

Configure the SOAP SendReply by simply taking the default, which is to [Reply To:
SOAPEventSource].
TIBCO
JavaCodeActivityastheEngineoftheService
Configure the Java Code Activity by creating inputs and outputs that will map to the
equivalent message parts of the WSDLs.

Open the Code Tab, and you will see two radio buttons Invoke Method Body and Full
Class. Using the Invoke Method Body format, cut and paste the following java code
below the comment lines:

float PRIN = Float.parseFloat(prin);
float INTEREST = Float.parseFloat(interest);
int MONTHS = Integer.parseInt(months);
double FIRST = Math.pow((1+INTEREST/1200),(-MONTHS));
float PART = (float)FIRST;
float PAYMENT = PRIN/((1-PART)/(INTEREST/1200));
/* answertext is the answer */
answertext = (String.valueOf(PAYMENT));

Next, press the Compile
TIBCO
Button

With your code successfully compiled, you need to do some very simple mapping to
associate the SOAP Event Source with the Java Code Activity. Move to the Input Tab,
and expand both sides to expose the elements, and drag & drop as shown below:

TIBCO
SOAP Send Reply
Next, move to the SOAPSendReply activity; in the Configuration Tab, you will
associate this with the SOAPEventSource of this process. Open the Input Tab and
configure the SOAP message to contain the output of the Java Code Activity. This map
is a single line!

Andwe are finished with the Web Service! Now, on to the Client
SOAPClient
By taking the schema and building an Abstract WSDL, we set the foundation for a Web
Service by the addition of adding a Transport for Binding to the PortType. The result is
a service with a port, and then you have a Concrete WSDL. By opening the WSDL
Source Tab, you expose the Concrete WSDL. Highlight the Text and cut/paste into
your favorite text editor and save. Next, go to Project Import Resources from File,
Folder, URL Import the WSDL you just saved into the WSDLs Folder. Ive called it
DocLitConc. Alternately, you can drag & drop a new WSDL object, click the source
button in the tool bar and then paste/apply/save.
TIBCO

RetrieveResourcesOptional
Another way of retrieving the Concrete WSDL is to build a Retrieve Resources
process in the Web Service Business Process. You will call this from an HTTP URL.

The configuration is straightforward, with explicit values for:
resourcePath
filter
hostname
port
TIBCO

The mapping in the HTTP Response is simple dont forget to put in text/xml as the
Content-Type.

TIBCO
You can run both the Web Service and the Retrieve Resource processes, and then
retrieve the Concrete WSDL from a browser to test that it works

BuildingaSOAPClient
In another project, or in the same project, create a WSDL Object and associate it with the
Concrete WSDL we just described. You can do this by importing, cut/paste, or via the
Retrieve Resource URL.
Next, create a Process Definition that includes a SOAPRequestReply. Optionally, you
can include some HTTP activities if you want to interact from a form in a Web Browser,
but the simplest is to build a process like this one:

TIBCO
The configuration steps are simple you follow the same steps as you did when
configuring the SOAPEventSource, but this time, you pick the Concrete WSDL rather
than the Abstract one! The screen shot should look like this:

If you arent using a Browser, I find it useful to create input via the Output Editor in the
Start Activity, and then mapping it appropriately to the inputs of the
SOAPRequestReply.

TIBCO
MultipleOperationPortType
Simply build out your WSDL with additional related Messages and then associate
them in Operations within a PortType. You can optionally group Operations under
multiple PortTypes. In the screenshot below, Ive created a WSDL with four Operations
under a single PortType, called FinancialServices, with operations of DoLoanPay,
DoAccruedSavings, DoCompoundInterest, and DoLoanInterest (I imported the related
XSDs not shown):

You pick the Operation in for the SOAPEventSource, like before, but now you have a
choice:

TIBCO

PALLETES

TIBCO
PALLETES

Process Palette:

Process Definition: The Process Definition resource allows you to define business
processes. Drag and drop the Process Definition resource into the design panel to create
a new process definition.

ProcessVariables: The Process Variables tab allows you to specify user-defined process
variables for the process definition. You can assign a value to the process variables with
the Assign activity.

Active Enterprise Adapter Palette:

The Active Enterprise Adapter palette contains activities for communicating with
configured TIBCO Active Enterprise adapters.

CommonFeaturesacrossActiveEnterpriseActivities:

Support for Message Filter Resources: An Adapter Configuration resource can use a
Message Filter resource. Message filters are used to provide custom, user-written code
to transform the messages sent or received from an adapter, call out to TIBCO Adapter
SDK functions, or perform other tasks.

Transport Tab: Transports specify the underlying communication characteristics for
messages sent and received by adapter services. Normally, the activities of the Active
Enterprise Adapter palette use the same transport configuration as the adapter service
with which they are communicating. However, in some situations, you may wish to
override the transport configuration of the adapter service and use different transport
parameters.

Transport Type: (No) The transport on which the incoming request will be received.
This is normally the transport used by the adapter service, but you can override this by
specifying different transport parameters.

TIBCO
The possible values for this field are:

Adapter Service Default
Tibrv Reliable
Tibrv Certified
Tibrv Certified Message Queue
JMS Topic
JMS Queue

Service: (Yes) The service parameter of the transport of the incoming request.

Network: (Yes) The network parameter of the transport of the incoming request.

Daemon: (Yes) The daemon parameter of the transport of the incoming request.

Delivery Mode: Persistent or non-persistent.

AdapterRequestResponseServer:

Starts a process based on the receipt of a request from an adapter. The
adapter sends a request using a preconfigured request-response invocation service, and
the process that is started acts as the implementation of the request. The process sends
any required responses back to the adapters service using the Respond to Adapter
Request activity.

AdapterSubscriber:

Starts a process based on the receipt of a message from the publication
service of the specified adapter. Publication services are configured during adapter
configuration, and the activity uses the information in the adapter configuration to fill in
most of the fields of this activity. See your adapter documentation for more information
about creating adapter configurations and creating adapter publication services.

TIBCO
InvokeanAdapterRequestResponseService:

The Invoke an Adapter Request-Response Service activity is used to
communicate with an adapters request-response service. This service invokes an
operation with input and output by way of the adapter. Request-response services are
configured during adapter configuration, and the activity uses the information in the
adapter configuration to fill in most of the fields of this activity

PublishtoAdapter:

The Publish to Adapter activity publishes a message that can be
received by an adapters subscription service. Subscription services are configured
during adapter configuration, and the activity uses the information in the adapter
configuration to fill in most of the fields of this activity.

RespondtoAdapterRequest:

The Respond to Adapter Request activity is used to send a response
to an adapter for a previously received request. For example, you may have a Wait for
Adapter Request activity in a process definition. The incoming adapter request may
require a response from your process. The Respond to Adapter Request is used to send
that response.

SendExceptiontoAdapterRequest:

The Send Exception to Adapter Request activity is used to send an
exception to an adapter for a previously received request. For example, you may have a
Adapter Request-Response Server process starter in a process definition. An error may
occur while attempting to perform the requested operation. The Send Exception to
Adapter Request activity allows you to return an exception to the adapter service with
information about the exception.

TIBCO
WaitforAdapterMessage:

Waits for the receipt of a message from the publication service of the
specified adapter. Publication services are configured during adapter configuration, and
the activity uses the information in the adapter configuration to fill in most of the fields
of this activity.

WaitforAdapterRequest:

Waits for the receipt of a request from an adapter request-response
invocation service. The adapter sends a request using a preconfigured service, and the
process definition acts as the implementation of the request. The process sends any
required responses back to the adapters service by placing the Respond to Adapter
Request activity at a later point in the process definition. Adapter request-response
invocation services are configured during adapter configuration, and the activity uses
the information in the adapter configuration to fill in most of the fields of this activity.

TIBCO
File Palette:

The File palette is used to read, write, delete, or create files. This palette also has a
process starter that allows you to poll for files and start a process based on the presence
of a file.

CreateFile:

The Create File activity creates a new file or directory with the specified
name. When creating a file, you can also provide the file contents.

FilePoller:

The File Poller process starter polls for files or directories with the given
name and starts a process when the specified change (creation, modification, deletion) is
detected.

ListFiles:

The List Files activity returns information about files or directories, or a
listing of all the files in the specified directory.

ReadFile:

The Read File activity is used to read a file and place its contents into the
activitys output.

RemoveFile:

The Remove File activity removes the specified file. This activity can also
remove empty directories. If a directory that is not empty is specified, an exception is
thrown.

TIBCO
RenameFile:

The Rename File activity is used to rename or move files. This activity
can also rename directories, but you cannot use this activity to move a directory to a
new location.

WaitforFileChange:

The Wait for File Change activity waits for a file creation, modification, or
deletion event to occur during process execution. When this activity is executed, the
process instance suspends and waits for the specified change to occur before resuming.

WriteFile:

The Write File activity writes content to the specified file.

TIBCO
FTP Palette:

The FTP palette is used to issue FTP commands.

FTPChangeDefaultDirectory:

The FTP Change Default Directory activity changes the current default
directory on the remote machine to the specified directory path.

FTPConnection:

The FTP Connection shared configuration resource describes a
connection to an FTP server. FTP connections are used when configuring activities in
the FTP palette. (Host, Port, Username, Pwd)

FTPDeleteFile:

The FTP Delete File activity issues an FTP delete or mdelete command
to remove one or more files from the remote server.

FTPDIR:

The FTP DIR activity provides a listing of files in the specified directory
of the FTP server. (NLST)

FTPGet:

The FTP Get activity issues an FTP get or mget command to the
specified server. The content of the remote files can be placed in the activitys output or
written directly to local storage. If you choose to place the contents of a remote file into
the activitys output, you can only retrieve one remote file (FTP get command) and the
files content will be stored in memory as part of the activitys output. If you choose to
TIBCO
write the contents of the retrieved files to local storage, you can retrieve one or more
files (FTP get or mget commands).

FTPGetDefaultDirectory:

The FTP Get Default Directory activity retrieves the name of the current
remote directory. The default remote directory is operating system-dependent and
determined by the remote FTP server. On UNIX systems, the default remote directory is
usually the home directory of the user account that is used to establish an FTP
connection. The current remote directory may be different from the default directory,
because you can use the FTP Change Default Directory or FTP Quote activities to issue
an FTP command to change to a different directory. This activity returns the currently
set remote directory.

FTPMakeRemoteDirectory:

The FTP Make Remote Directory activity creates the specified directory
on the remote FTP server.

FTPPut:

The FTP Put activity issues an FTP put or mput command to the
specified server. You can use process data as the content of the file to send to the remote
server or you can send files in local disk storage. If you choose to use process data, you
can place only one file on the remote server (FTP put command). If you use locally
stored files, you can place one or more files on the remote server (FTP mput command).

FTPQuote:
The FTP Quote activity sends an arbitrary FTP command to the FTP
server. You can determine which FTP commands are supported by using the Available
Commands button on the FTP Connection shared configuration resource. FTP
commands vary by operating system and by FTP version and configuration, so you
should determine which commands are available on the remote server before using this
activity.

TIBCO
FTPRemoveRemoteDirectory:

The FTP Remove Remote Directory activity deletes the specified
directory from the remote FTP server.

FTPRenameFile:

The FTP Rename File activity renames the specified file on the remote
FTP server.
FTPSysType:

The FTP Sys Type activity retrieves the FTP servers operating system
type.

TIBCO
General Activities Palette:

The General Activities palette contains several general-purpose activities and process
starters. For example, the Timer process starter is used to start a process at
a specific time. This chapter describes the activities contained in the General Activities
palette.

Assign:

The Assign activity allows you to assign a value to a user-defined
process variable. When the Assign activity is executed, the entire schema for the selected
process variable is replaced with the specified values. Elements that do not have a value
specified in the Input tab are set to null. Therefore, be certain to set all necessary values
when using the Assign activity to set a process variable.

CallProcess:

The Call Process activity calls and executes an existing process
definition. The input to the called process is defined in the Start activity of the called
process. The output of the called process is defined in the End activity of the called
process.

You should only call processes that have Start activities. It is possible to call processes
that have process starters, but this could cause behavior that you may not have intended
in your process definition.

You can use the Process Name Dynamic Override field on the Configuration tab to
specify an XPath expression that determines which process to call. This is useful for
calling a different process depending upon the value of the XPath expression.

Checkpoint:
The Checkpoint activity performs a checkpoint in a running process

instance. A checkpoint saves the current process data and state so that it can be
recovered at a later time in the event of a failure. If a process engine fails, all process
instances can be recovered and resume execution at the location of their last checkpoint
in the process definition. Only the most recent state is saved by a checkpoint. If you
have multiple checkpoints in a process, only the state from the last checkpoint is
available for recovering the process.

TIBCO

CheckpointsandTransactions

Checkpoints cannot be taken in or in parallel to a transaction. So, place the checkpoint
activity outside of any transaction group. Also, make sure that if you have multiple
paths in your process definition, the checkpoint activity does not occur in parallel with
a path that has a transaction group. Instead, any checkpoint activities should be placed
at points that are guaranteed to be reached before or after the transaction group is
reached.

CalledProcesses

Checkpoints save the state of the entire process instance. By default when a process
calls another process, the subprocess is executed in the same process instance as the
calling process. If the called process spawns a new machine process, however, the
called process is a new process instance. When a checkpoint occurs in a called process,
the checkpoint saves the state of the current process instance. If no called processes
spawn new process instances, then a checkpoint in any called process saves the state
of the process instance, including state from the parent process(es) of the current
process. In the case of a called process that spawns a new process instance, only the
spawned process instance is saved.

RecoveringAfteraCrash

If a process engine crashes, all process instances are recovered up to the point of their
last checkpoint. You must be careful with certain types of process starters or incoming
events when placing your checkpoint in a process definition.

For example, if the process starter is waiting for an incoming HTTP request, and a
checkpoint is taken after the process starts but before the response to the request is sent,
the process cannot respond to the request when the process instance is restarted. The
socket for the HTTP request is closed when the process engine crashes, therefore the
Send HTTP Response activity in the restarted process returns an error. In this case, place
the response activity before the checkpoint so that any response is sent before a
checkpoint is taken.

There are other examples of situations where an incoming event must be handled before
the checkpoint is taken. The following lists some of these circumstances:

An email message is received, and then deleted from the email server.
An HTTP request is received.

Make certain that the process has all of the data required to continue at the time of the
checkpoint so that in the event of a failure, a restarted process does not attempt to access
resources that no longer exist.

TIBCO
By default, checkpointed process instances are restarted when the engine restarts. If the
engine encounters errors during startup, the restarted process instances continue to be
processed and may eventually be lost depending upon the type of error at startup. You
can specify to shut down the process engine if any errors are encountered during
startup so that checkpointed jobs are not lost in the event of an error. The custom engine
property named Engine.ShutdownOnStartupError controls this behavior. By default,
the value of the property is false. Setting the property to true shuts the engine down if
errors are encountered when the engine starts.

CheckpointsandtheConfirmActivity:

In the case of confirmable messages (for example, a confirmable TIBCO Rendezvous or
Adapter message is received), you must consider the consequences of performing a
checkpoint before or after a Confirm activity. If the checkpoint is taken before the
Confirm activity, then a crash occurs after a checkpoint but before a confirm, the
original message is resent. In this case, the restarted process can no longer send the
confirmation. However, a new process is started to handle the resent message, and
you can implement your process to handle the restarted and new processes
appropriately. If the checkpoint is taken after a Confirm activity, there is potential for
a crash to occur after the Confirm but before the checkpoint. In this case, the message
is confirmed and therefore not redelivered. The process instance is not restarted,
because the crash occurred before the checkpoint. You must consider the type of
processing your process definition performs to determine when a checkpoint is
appropriate if your process definition receives confirmable messages.

Confirm:

The Confirm activity confirms any confirmable messages received by
the process instance. For example, if a process is started because of the receipt of an
RVCM message, the Confirm activity can send a confirmation message to the publisher
of the RVCM message.

ConfirmEvent

The message you wish to confirm. This is a drop-down list of any process starter or
activity that expects an incoming event in the current process definition.

You can only confirm messages from confirmable message sources, for example,
RVCM, RVDQ, or JMSmessages. Select only the event that sent the confirmable message.
If you select an event from the list that does not correspond to a confirmable message (for
example, a Wait for File Change event) or if you try to confirm the same message more
than once, no message is confirmed.

TIBCO
EngineCommand:

The Engine Command activity allows you to retrieve statistics and
information about process definitions, process instances, and activities. This activity also
lets you perform engine maintenence, such as suspending and resuming process
instances and shutting down the engine.

Before using this activity, the Hawk.Enabled property must be set to either true or
local.
Below commands accept a process definition name.
GetActivityStats
GetProcessInstanceInfo
ResumeProcessStarter
SuspendProcessStarter
Below commands not accept a process definition name
GetProcessDefinitionStats
GetProcessStarterStats
ResumeProcessInstance
ResumeProcessStarter
Shutdown
SuspendProcessInstance
SuspendProcessStarter

ExternalCommand:

The External Command activity allows you to execute an operating
system command. This activity waits for the command to complete before transitioning
to the next activity. Optionally, the command output and any errors can be included in
this activitys output schema, written to a file, or both.

GenerateError:

This activity generates an error and causes an immediate transition to
any error transitions. If there are no error transitions, the process instance halts
execution. This activity is useful in a group or in a called process. If you would like to
catch and raise your own error conditions, you can use this activity to do so.

TIBCO
For example, for a process that calls a subprocess to check the credit of a customer, you
can use the Generate Error activity to raise an error for any error conditions, such as the
customer does not exist, or the customer has no credit available. In the called
subprocess, create a transition to the Generate Error activity after detecting the error
condition and the called process terminates. Processing continues with an error in the
calling process. An error transition on the Call Process activity can handle the error.

GetSharedVariable:

The Get Shared Variable activity retrieves the current value of a
Shared Variable or Job Shared Variable resource. If you are using this activity to retrieve
the value of a Shared Variable resource, you may want to use a critical section group to
ensure that no other process instances are altering the value of the shared variable at the
same time.

Inspector:

The Inspector activity is used to write the output of any or all activities
and process variables to a file and/or stdout. This is particularly useful when
debugging process definitions and you wish to see the entire schema instead of
mapping specific elements to the Write File activity. You can use the inspector activity
to write the output of any activity or process variable in the current process. Activities
and process variables in a subprocess are not available to the Inspector activity (but the
output of a Call Process activity can be written using the Inspector activity). If you wish
to obtain the output from one or more activities or process variables in a subprocess,
place the Inspector activity in the process definition of the subprocess.

JNDIConfiguration:

The JNDI Configuration shared configuration resource provides a way
to specify JNDI connection information that can be shared by other resources. This
resource can be specified in any resource that permits JNDI connections. For example,
JDBC Connection and JMS Connection can use JNDI connections.

TIBCO
JobSharedVariable:

A Job Shared Variable shared configuration resource allows you to
store data for use by each process instance. A copy of the variable is created for each
new process instance. This resource is useful for passing data to and from sub-processes
without creating an input or output schema for the called process.

You can use the Get Shared Variable and Set Shared Variable activities to access the data
instead of mapping data to a called processes input or output schemas. New process
instances receive a copy of the variable, so data cannot be shared across process
instances. Therefore, if a called process has the Spawn configuration field checked, a
new process instance is created and the process instance receives a new copy of the job
shared variable.

Label:

The Label resource allows you to create a generic label so that you can
provide documentation and comments in your process definition. The Label is not an
activity, because you cannot draw transitions to or from it, and it does not perform any
action. You use the label to create a descriptive tag that you can place anywhere in a
process definition. Labels can also be resized to cover an area. You can apply a border to
the area by selecting a value in the Border Type and Border Thickness fields. You can
also apply a background color to the area by selecting a color in the Background color
field. This allows you to annotate your process definition and provide colors and
borders to visually group related activities in your process definition. The text of the
label remains in the top left of the label area, but you can edit the text either in the
design panel or by editing the Description field.

LockObject:

Lock Object shared configuration resources are used by Critical Section
groups to ensure that only one process instance executes the activities in a critical
section group at a time. The Lock Object resource can be used to synchronize process
instances from more than one process definition in the same process engine, or it can be
used to synchronize process instances across multiple process engines.

TIBCO
Mapper:

The Mapper activity adds a new process variable to the process definition.
This variable can be a simple datatype, a TIBCO ActiveEnterprise schema, an XML
schema, or a complex structure. You can map data values from the current list of
process variables to the elements of the variable added with the Mapper activity.

Notify:

The Notify activity allows a process instance to send data to a corresponding
process instance containing a Wait activity or Receive Notification process starter. The
Notify Configuration resource specified on the Configuration tab and the key specified
on the Input tab create the relationship between the Notify activity and the
corresponding Wait or Receive Notification. The data specified in the Notifys input is
sent to the Wait or Receive Notification that specifies the same Notify Configuration
resource and has the same value for the key. The Wait, Receive Notification, and Notify
activities allow running process instances to communicate.

NotifyConfiguration:

The Notify Configuration resource specifies a schema to use for
passing data between executing process instances. Corresponding Receive Notification,
Notify, and Wait activities use the same Notify Configuration resource to define the
data for inter-process communication. The schema can be empty, if you do not wish to
pass data between processes.

Null:

The Null activity is an activity with no action performed. This activity
has a name and a description specified on the Configuration tab, but there is no input or
output for the activity.
This activity is useful if you wish to join multiple process flows. That is, when you have
multiple transitions out of an activity and each transition takes a different path in the
process definition, you can create a transition from the activity at the end of each path to
a Null activity to resume a single flow of execution in the process.

TIBCO
OnEventTimeout:

The On Event Timeout process starter specifies a process to execute
when a Wait For ... activity discards an incoming event due to a timeout. A Wait For ...
activitys event timeout is specified by the Event Timeout field on the Event tab of the
activity. The default behavior for an event timeout is to confirm and then discard the
event. You can override the default behavior by creating a process definition using the
On Event Timeout process starter. You can specify an On Event Timeout process
definition for a specific event source (that is, a specific Wait For... activity). You can
specify one or more On Event Timeout process definitions for specific event sources, but
you should not create more than one process definition for the same event source. Once
a Wait For... activity experiences a timeout, that timeout can only apply to one On Event
Timeout process definition. You can also specify that an On Event Timeout process
definition applies to any event source that experiences a timeout. If there is no On Event
Timeout specified for a particular event source, the process engine calls the On Event
Timeout process definition whose Any Event Source field is checked.

OnShutdown:

The On Shutdown process starter specifies a process to execute when
the process engine shuts down, after all process instances are executed. The On
Shutdown process starter can be useful for specifying any post-processing that must be
done before shutting down the engine. For example, your application may back up a
database table then purge the data. Also, you may wish to send email to administrators
notifying them that the process engine is shutting down. Typically, you create one
process definition that uses the On Shutdown process starter and place all post-
processing activities into that process definition. However, you can have more than one
process definition that uses the On Shutdown process starter. All process definitions
with the On Shutdown process starter execute in no specific order when the process
engine shuts down.

OnStartup:

The On Startup process starter specifies a process to execute when the
process engine starts, before any incoming events are processed. In the event that the
process engine is restarting and attempting to recover checkpointed process instances,
the On Startup process definition must complete its execution before any recovered
process instances execute. The On Startup process starter can be useful to specify any
pre-processing that must be done before regular processing starts. For example, your
application may check that the required database tables exist and create them necessary.
TIBCO
Also, you may wish to send email to administrators notifying them that the process
engine is starting. Typically, you create one process definition that uses the On Startup
process starter and place all pre-processing activities into that process definition.
However, you can have more than one process definition that uses the On Startup
process starter. All process definitions with the On Startup process starter execute in no
specific order when the process engine starts. All On Startup process definitions must
complete successfully before normal processing can begin.

ReceiveNotification:

The Receive Notification process starter starts a process when another
process executes a Notify activity with a matching key and Notify Configuration
resource. The key specified in the Key field of the Configuration tab creates a
relationship between the Receive Notification process starter and the corresponding
Notify activity. The same Notify Configuration shared configuration resource must be
specified by corresponding Receive Notification and Notify activities so that data can be
passed from the process containing the Notify activity to the process started with
Receive Notification. The schema in the Notify Configuration resource can be empty, if
you do not wish to pass data between processes.
The Wait, Receive Notification, and Notify activities allow running process instances to
communicate.

SetSharedVariable:

The Set Shared Variable activity allows you to change the value of a shared variable. If
you are using this activity to set the value of a Shared Variable resource, you may want
to use a critical section group to ensure that no other process instances are altering the
value of the shared variable at the same time.

SharedVariable:

A Shared Variable resource allows you to share data across process
instances. All process instances can read and update the data stored in a shared
variable. This resource is useful if you wish to marshal data across process instances or
if you wish to make a common set of information available to all process instances. For
example, you may have a set of approval codes for incoming orders that change daily
for security purposes. You can create a shared variable to hold the approval codes and
create one process definition for setting the codes. You can then retrieve the shared
variable in all processes that require the current approval codes.
TIBCO
Sleep:

The Sleep activity suspends the process on the current transition for the
given amount of time. If you have multiple control flows in your process, only the
current execution branch of the process is suspended.

Timer:

The Timer process starter starts a process at a specific time. You can also
specify that processes are to be started periodically.

Wait:

The Wait activity suspends execution of the process instance and waits for
a Notify activity with a matching key to be executed in another process instance. The
key specified in the Notify Configuration resource specified on the Configuration tab
and the Key field of the Input tab creates a relationship between the Wait activity and
the corresponding Notify activity. The same Notify Configuration shared configuration
resource must be specified by corresponding Wait and Notify activities so that data can
be passed from the process instance containing the Notify activity to this process
instance. The schema in the Notify Configuration resource can be empty, if you do not
wish to pass data between processes. The Wait, Receive Notification, and Notify
activities allow running process instances to communicate.

WriteToLog:

This activity writes a message to the log. The logs are stored in the TIBCO
BusinessWorks installation directory under the logs subdirectory. There is one log file
for each process engine.

TIBCO
CustomPropertiesfortheWriteToLogActivity:
In some situations, you may wish to specify which messages are sent to the log file. You
can use custom engine properties to specify which roles are enabled or disabled for log
messages. You may configure the following properties:

Trace.<roleName>.Log Setting this property to false disables writing messages for
the specified role name to the log.

Trace.<roleName>.* Setting this property to false disables all messages for the
specified role. The specified role can be one of the following system roles: WARN,
TRACE, DEBUG, or INFO.

Trace.Role.<roleName> Setting this property to false disables all messages for the
specified user-defined role. Setting Trace.Role.* to false disables all messages to all user-
defined roles.

Trace.Role.* Setting this property to false disables all messages for all user-defined
roles.

TIBCO
HTTP Palette:

The HTTP palette allows you to send and receive HTTP requests.

HTTPConnection:

The HTTP Connection resource describes the characteristics of the
connection used to receive incoming HTTP requests. This resource is used when TIBCO
BusinessWorks expects to receive an HTTP request on a specific port where a process
engine is running. For example, the process starters HTTP Receiver and SOAP Event
Source and the signal-in activity Wait for HTTP Request receive HTTP requests.
There can be at most one process with an HTTP Receiver or Wait for HTTP Request that
uses the same HTTP Connection resource. This restriction allows the HTTP server
listening for incoming requests to dispatch the request to the correct process. There can
be more than one SOAP Event Source that uses the same HTTP Connection. Also, SOAP
Event Source and HTTP activities can use the same HTTP Connection resource and the
HTTP server correctly dispatches the incoming request to the correct process.
The HTTP Connection resource can specify that the HTTPS (secure sockets layer or SSL)
protocol must be used by clients. If this is enabled, you can configure the SSL
parameters for the HTTP server using the Configure SSL Button.

CustomPropertiesfortheHTTPPalette:
In some situations, you may wish to alter the configuration of the HTTP server that
receives incoming HTTP requests for TIBCO BusinessWorks. There are two custom
properties that you may configure:

bw.plugin.http.server.minProcessors the minimum number of threads available
for incoming HTTP requests. The HTTP server creates the number of threads specified
by this paramter when it starts up.

bw.plugin.http.server.maxProcessors the maximum number of threads available
for incoming HTTP requests. The HTTP server will not create more than the number of
threads specified by this parameter. By default, the minimum number of threads is 10
and the maximum is 75. If you have a large number of incoming requests, you may wish
to change these values to handle more incoming requests concurrently.

When a client sends a request that cannot be processed because no threads are
available, TIBCO BusinessWorks returns a ConnectionRefused exception to the
client.

TIBCO
HTTPReceiver:

Starts a process based on the receipt of a HTTP request.

ProxyConfiguration:

The Proxy Configuration resource is used to specify a proxy HTTP
server when HTTP requests are sent outside of a firewall.

SendHTTPRequest:

The Send HTTP Request activity sends a HTTP request to a web
server.
This activity can send a request to a server that complies with either the HTTP 1.0 or 1.1
specifications. You do not need to specify the HTTP version of the server you are
sending the request to. TIBCO BusinessWorks automatically sends the request using the
correct version based on the version supported by the HTTP server.

SendingDataintheHTTPRequest:

There are several HTTP methods that can be used in an HTTP request. Each method
sends data in the request in a different manner. For example, the GET method uses the
query string of the request URI to pass parameter/value pairs. Other methods use the
HTTP message body to send data in the request. The Send HTTP Request activity has
three input elements for sending data in a request:

PostData correspond to the body of the HTTP message. All methods except the
GET method accept data in this element.

QueryString corresponds to the query string of the request URI. You can use this
input element to dynamically construct the query string using an XPath expression
when you do not know the names or number of input parameters for the request until
the activity executes.

Parameters correspond to parameters defined in the Parameters field on the
Configuration tab. This is useful if you have a fixed set of parameters that you send with
the request. For requests that use the GET method, these parameters are passed as the
query string of the request URI.
TIBCO
For requests that use the POST method, these parameters are usually sent as the body of
the HTTP message, but they can also be included in the query string. For some methods,
these input elements are mutually exclusive.

For example, for POST requests, you can specify parameters on the Configuration tab
and in the parameters input element or you can specify a PostData input element.
However, you should not specify both input elements. In the case of a POST request, the
PostData input element is ignored when parameters are specified on the Configuration
tab.

For GET requests, you can specify parameters on the Configuration tab and in the
parameters input element or you can specify a QueryString input element. Typically, if
you know the list of parameters for the request, you should configure the parameters on
the Configuration tab. If the list of parameters is not known until the activity executes,
you should use the QueryString element. However, when all parameters on the
Configuration tab are specified as Optional, you can use the QueryString input element
instead of the parameters input element (but if any elements in the parameters element
contain an expression, the QueryString element is ignored).

SendHTTPResponse:

Sends a response to a previously received HTTP request. This
activity is used in conjunction with the HTTP Receiver process starter or the Wait for
HTTP Request activity.
The default status line returned by this activity is "200 OK".

WaitforHTTPRequest:

Waits for an incoming HTTP request in a process definition. The
process instance suspends until the incoming HTTP request is received.

TIBCO
Java Palette:

The Java palette has activities and shared configuration resources for executing Java
code as well as converting between Java objects and XML documents.

JavaCode:

You can add custom code to your process definition with the Java
Code activity. This activity allows you to write standard Java code that can manipulate
any of the process data or perform any action you choose. The Java Code activity
automatically creates an invoke () method in which you place the code you wish to
execute. This method is called when the engine processes the Java Code activity. When
you specify input and output parameters for the Java Code activity, get/set method
code is automatically generated for the activity. You can use the get/set methods in
your Java code, and you can display the code for the get/set methods when you select
the Full Class radio button on the Code tab.

JavaCustomFunction:(Mostimpactivity)

The Java Custom Function resource allows you to create custom
functions to use when mapping data in an activitys input tab. These functions are also
displayed when using the XPath Editor to build an XPath expression. To create a custom
function, you must write the function as a method of a Java class and compile the code
into a Java class file. You then load that class file into the project using this resource.
When the class is loaded using this resource, TIBCO BusinessWorks inspects the
contents of the class and only the class methods that meet the following restrictions are
made available in XPath:

Only methods declared as public and static are loaded.
The input parameters and return values must be of one of the types described
The return value of the function cannot be void.
The method cannot be a constructor.
The method cannot explicitly throw an exception. Runtime exceptions are allowed,
however.
Method names cannot be overloaded in a class or any imported classes in a single Java
Custom Function resource. You can load methods of the same name into separate
classes in separate Java Custom Function resources and use the Prefix field to
differentiate between the methods.
If you make references to any imported class files, these classes must be available in
the classpath configured for TIBCO BusinessWorks. The easiest way to make the
imported classes available is to place them in the TIBCO/bw/2.0/lib directory.
Inner classes are not supported.
TIBCO
TIBCO BusinessWorks provides detailed online help for each XPath function. To
provide online help for Java Custom Functions, create a two-dimensional array named
HELP_STRINGS in your class. The element containing a string matching the function
name is used as the help for that function. See below Example Java Function for an
example of creating the HELP_STRINGS array.

ExampleJavaFunction
The following Java code implements custom Java functions. The example illustrates
which methods of the class meet the restrictions and are therefore available as custom
functions in XPath. The example also illustrates methods which do not meet the
restrictions, and therefore are not available as customfunctions. package com.tibco;

public class Sample
{
protected int mInternalValue;

/** The following method will not be available because it is a constructor. */
public Sample(int value)
{
mInternalValue = value;
}
/**
* This method is used to concat two strings together. It must be declared as public static
to be made available in TIBCO BusinessWorks. */
public static String stringConcat(String s1, String s2)
{
return s1 + s2;
}
/**
* This method is used to add two ints together. Note, that it takes both an int type and
an Integer object.*/
public static int intAdd(int lhs, Integer rhs)
{
return lhs + rhs.intValue();
}
/**
* The following method will not be available because it throws an exception. */
public static int badAdd(int lhs, int rhs)
throws Exception
{
long result = lhs + rhs;
if (result > Integer.MAX_VALUE) {
throw new ArithmeticException();
}
return new Long(result).intValue();
}
/**
* The following method will not be availabe because it returns nothing: its void. */
TIBCO
public static void returnsNothing(String s)
{
System.out.println(s);
}
/**
* The following method will not be available because it is not static. */
public int add(int rhs)
{
return mInternalValue + rhs;
}
/**
* The following method will not be available because it is not public. */
protected static int protectedAdd(int lhs, int rhs)
{
return lhs + rhs;
}
/**
* The following is a two-dimensional array that provides the online help for functions
in this class. Declare an array named HELP_STRINGS. */
public static final String[][] HELP_STRINGS ={
{"stringConcat", "Joins two strings.",
"Example", "stringConcat(\"test/testDict\",
$input/key)"},
{"intAdd", "Adds two integers.",
"Example", "intAdd(5, $input/myInt)"},

JavaGlobalInstance:

The Java Global Instance shared configuration resource allows you
to specify a Java object that can be shared across all process instances in a Java Virtual
Machine (JVM). When the process engine is started, an instance of the specified Java
class is constructed. When the process engine is shut down, if specified, a cleanup
method is invoked on the object and the object is released before the engine shuts down.
Any Java Method activity can be configured to access the shared Java Global Instance
when the process engine runs. Any Java Code activity can access the shared Java Global
Instance by invoking the static methods of the configured Java class. If multiple process
instances access the shared Java Global Instance, you may wish to ensure that only one
process instance can access the object at a time. You can accomplish this by either
declaring the methods of the configured class as synchronous or by using a critical
section group.

TIBCO
JavaMethod:

The Java Method activity allows you to invoke a method contained
in a Java class. You can construct an instance of the specified Java class, if you choose to
invoke the constructor for the class. The Java class file must be located in the classpath
for TIBCO Designer and the TIBCO BusinessWorks process engine. Update the
designer.tra and bwengine.tra file to contain the directory where your Java class files are
located.

JavaSchema:

The Java Schema shared configuration resource allows you to specify
a Java class that is used to configure a Java To XML or XML To Java activity.
The Java class is converted to an XML schema using the following rules:

Only the public data members of the Java class are mapped to XML elements. Private
and protected members are not included.
The Java class member public variable name is mapped to an XML element with the
same name. For example, a Java class member variable declared as public int ZipCode is
mapped to an XML element named ZipCode.
Java Bean accessors and modifiers are mapped to appropriate XML element names.
For example, a Java class method public int getBalance() or public void setBalance(int
Balance) are mapped to an XML element named Balance.
Only one XML element is created regardless of how many members of the Java class
share the same name. For example, there may be an attribute named MySalary and
accessors named getMySalary() and setMySalary(). This translates to one element
named MySalary in the resulting XML document.
Conversion is case-sensitive. For example, if you have a data member declared as
public int zipCode and a accessor method declared public void setZipCode(int
NewZipCode), there will be two elements in the resulting XML schema, zipCode (for
the data member) and ZipCode (for the
accessor). You must make sure to use the correct element when using the resulting XML
in Input mappings of subsequent activities.
All Java primitive types are supported. Datatypes that extend java.util.Collections are
also supported (for example, List, ArrayList, andVectors). Arrays (for example, int[] and
string[]) are also supported.
The datatype java.util.Map or any types that extend java.util.Map are not supported.
For example, HashMap is not supported.

TIBCO
JavaToXML:

The Java To XML activity allows you to convert a Java objects data
members into an XML document. See Java Schema on page 252 for the conversion rules.
If the class does not have a public data member and only has a Java Bean modifier that
sets the data, the input schema will contain an element for the modifier, but the
resulting XML document will not have a value set for the corresponding element.

For example, the Java object has a method declared as public int setID(), but there is no
method for getting the ID and the data member ID is not public. In this case, there will
be an element named ID in this activitys output schema, but that element will not have
a value because there is no public mechanism for getting the data.

XMLToJava:

The XML to Java activity allows you to create an instance of a Java object
based on data from an XML document. The XML schema for providing input to the Java
object is created from the Java object or Java Schema specified on the Configuration tab
of this activity. The specified Java class must meet the following requirements:

The Java class must have a public default constructor (that is, a constructor with no
arguments).
The Java class must be serializable (that is, the class must implement or be a subclass
of a class that implements java.io.Serializable).

If the class does not have a public data member and only has a Java Bean accessor that
retrieves the data, the input schema will contain an element for the accessor, but the
resulting Java object will not have a value set for the member.

For example, the object has a method declared as public int getID(), but there is no
method for setting the ID and the data member ID is not public. In this case, there will
be an element named ID in this activitys input schema, but mapping a value to the
element will not result in setting the ID member of the output Java object because there
is no public mechanism for setting the data.

TIBCO
JDBC Palette:

The JDBC palette contains activities and shared configuration resources for querying,
updating, or calling stored procedures in a database.

JDBCCallProcedure:

The JDBC Call Procedure activity calls a database procedure using
the specified JDBC connection. If this activity is not part of a transaction group, it is
committed after it completes. If this activity is part of a transaction group, it is
committed or rolled back with the other JDBC activities in the group at the end of the
transaction. See TIBCO BusinessWorks Process Design Guide for more information
about creating groups for transactions. If you wish to override the default behavior of
transaction groups for certain JDBC activities in a transaction group, you can check the
Override Transaction Behavior field on the Advanced tab. This specifies that the activity
is outside of the transaction and is committed when it completes, even if it is in a
transaction group. The Refresh button on this activity allows you to synchronize the
activity with the contents of the database. This is useful if you make a change to the
database while you are editing a process definition containing this activity in TIBCO
BusinessWorks.

JDBCConnection:

The JDBC Connection resource describes a JDBC connection. JDBC
connections are used when specifying activities from the JDBC palette.

JDBCQuery:

The JDBC Query activity performs the specified SQL SELECT
statement. If this activity is not part of a transaction group, it is committed after it
completes. If this activity is part of a transaction group, it is committed or rolled back
with the other JDBC activities in the group at the end of the transaction. If you wish to
override the default behavior of transaction groups for certain JDBC activities in a
transaction group, you can check the Override Transaction Behavior field on the
Advanced tab. This specifies that the activity is outside of the transaction and is
committed when it completes, even if it is in a transaction group.

TIBCO
JDBCUpdate:

The JDBC Update activity performs the specified SQL INSERT,
UPDATE, or DELETE statement. If this activity is not part of a transaction group, it is
committed after it completes. If this activity is part of a transaction group, it is
committed or rolled back with the other JDBC activities in the group at the end of a
transaction. If you wish to override the default behavior of transaction groups for
certain JDBC activities in a transaction group, you can check the Override Transaction
Behavior field on the Advanced tab. This specifies that the activity is outside of the
transaction and is committed when it completes, even if it is in a transaction group.

SQLDirect:

The SQL Direct activity executes a SQL statement that you provide.
This activity allows you to build a SQL statement dynamically (using other activities),
then pass the SQL statement into this activitys input. This activity also allows you to
execute SQL statements that are not supported by other activities in the JDBC palette.
For example, DDL commands (for example, CREATE TABLE) are not available by using
any other activity. If this activity is not part of a transaction group, it is committed after
it completes. If this activity is part of a transaction group, it is committed or rolled back
with the other JDBC activities in the group at the end of the transaction. If you wish to
override the default behavior of transaction groups for certain JDBC activities in a
transaction group, you can check the Override Transaction Behavior field on the
Advanced tab. This specifies that the activity is outside of the transaction and is
committed when it completes, even if it is in a transaction group.

TIBCO
JMS Palette:

Java Message Service (JMS) is a specification for how messages are sent and received
between applications in a Java environment. The JMS palette is used to send and receive
JMS messages in a process definition. Both the JMS point-to-point (queues) and
publish/subscribe (topics) models are supported.

GetJMSQueueMessage:

The Get JMS Queue Message activity retrieves a message from the
specified queue. This activity allows you to perform a receive operation on the queue as
opposed to waiting for a queue message to be delivered to the Wait for JMS Queue
Message activity or the JMS Queue Receiver process starter.

AcknowledgeMode:

The acknowledge mode for incoming messages. Can be one of the following:

Auto the message is automatically acknowledged when it is received.

Client the message will be acknowledged at a later point by using the Confirm
activity. If the message is not confirmed before the process instance ends, the message is
redelivered and a new process instance is created to handle the new incoming message.
Ensure that your process definition confirms the message when using this acknowledge
mode.

TIBCOEMSExplicitClientAcknowledge this mode behaves exactly the same as
the Client mode, except the session is not blocked and one session can handle all
incoming messages.

Dups OK the message is acknowledged automatically when it is received. JMS
provides this mode for lazy acknowledgement, but TIBCO BusinessWorks
acknowledges messages upon receipt.

Transactional this mode is used when a transaction that can process JMS messages
is included in the process definition. The message is acknowledged when the
transaction commits.

TIBCO
JMSApplicationProperties:

The JMS Application Properties resource describes any JMS message properties that a
JMS application expects. These properties can then be added to a JMS message on the
Advanced tab of a JMS activity. These properties will appear as "OtherProperties" on the
Input or Output tab of the activity.

JMSConnection:

The JMS Connection resource describes a JMS connection. This
resource is used when specifying activities on the JMS palette.

JMSQueueReceiver:

Starts a process based on the receipt of a message for the specified
JMS queue.

LoadBalancingofIncomingMessages

One common application of a JMS queue is to distribute queue messages across
multiple receivers, thus balancing the processing of the messages on the queue. To
achieve this goal, both the JMS server and TIBCO BusinessWorks must be configured
properly. The JMS server must allow the queue messages to be distributed across
multiple receivers. For example, in TIBCO Enterprise Message Service, the exclusive
property on the queue controls whether messages can be delivered across receivers or
not. In TIBCO BusinessWorks, the process definition containing the JMS Queue Receiver
must be deployed across multiple process engines. This creates multiple queue receivers
for the same queue. When you attempt to balance incoming messages across TIBCO
BusinessWorks engines, you should ensure that one engine does not attempt to accept
and confirm a large number of incoming messages before other engines can receive the
messages. In general, most JMS servers balance the load by distributing messages in a
round-robin fashion to all queue receivers. However, there are situations that can cause
an uneven distribution of messages across queue receivers. If you set the Acknowledge
Mode field to "Auto" on the Configuration tab of the JMS Queue Receiver, the process
starter confirms messages as it receives them. When process engines are started at
different times, this can lead to one process engine receiving all queue messages and
paging them to disk, depending upon how the engines Max Jobs and Activation Limit
properties are set when the engine is deployed. If you are using TIBCO Enterprise
Messaging Service, you avoid this problem by setting the acknowledge mode to TIBCO
TIBCO
EMS Explicit and then use the Max Jobs (Flow Limit) property in the deployment
configuration to control the number of process instances created by the process starter.
If you are not using TIBCO Enterprise Messaging Service, set the Acknowledge Mode
field to "Client". In this mode, a process engine can only receive as many messages as it
has sessions specified in the Max Sessions field. Once a process engine reaches the
maximum number of sessions, another process engine can begin to accept incoming
messages. A process engine cannot receive more messages until the messages have been
acknowledged by using the Confirm activity. Once the message is acknowledged, the
session is released and the process engine can accept a new message.

JMSQueueRequestor:

The JMS Queue Requestor activity is used to send a request to a JMS
queue name and receive a response back from the JMS client.

JMSQueueSender

: The JMS Queue Sender activity sends a message to the specified JMS
queue.

JMSTopicPublisher:

The JMS Topic Publisher sends a message to the specified JMS topic.

JMSTopicRequestor:

The JMS Topic Requestor activity is used to communicate with a JMS
applications request-response service. This service invokes an operation with input and
output. The request is sent to a JMS topic and the JMS application returns the response
to the request.

TIBCO
JMSTopicSubscriber:

Starts a process based on the receipt of a message for the specified
JMS topic.

Acknowledge Mode(Yes): The acknowledge mode for incoming messages. Can be one
of the following:

Auto the message is automatically acknowledged when it is received.

Client the message will be acknowledged at a later point by using the Confirm
activity. If the message is not confirmed before the process instance ends, the message is
redelivered and a new process instance is created to handle the new incoming message.
Ensure that your process definition confirms the message when using this acknowledge
mode.

TIBCO EMS Explicit Client Acknowledge this mode behaves exactly the same as
the Client mode, except the session is not blocked and one session can handle all
incoming messages.

Dups OK the message is acknowledged automatically when it is received. JMS
provides this mode for lazy acknowledgement, but TIBCO BusinessWorks
acknowledges messages upon receipt.

Transactional this mode is used when a transaction that can process JMS messages
is included in the process definition. The message is acknowledged when the
transaction commits.

ReplyToJMSMessage:

The Reply To JMS Message activity sends a reply to a previously
received JMS queue or topic message. The list of possible activities that can receive JMS
messages is given on the Configuration tab. The activity that you select determines
which message the reply message is in response to.

TIBCO
WaitforJMSQueueMessage:

The Wait for JMS Queue Message waits for the receipt of a message
for the specified JMS queue.

WaitforJMSTopicMessage:

The Wait for JMS Topic Message waits for the receipt of a message for the specified JMS
topic.

TIBCO
Mail Palette:

The Mail palette is used to receive incoming email or send outgoing email.

ReceiveMail:

The Receive Mail process starter polls a POP3 mail server for new
mail. When new mail is detected and retrieved, the Receive Mail process starter starts a
new process for the process definition it resides in and passes the mail data to the next
activity in the process flow.

SendMail:

The Send Mail activity sends an email by way of a SMTP server.

TIBCO
Manual Work Palette:

The Manual Work palette is useful for automated business processes that have a few
steps that require user interaction. The Manual Work palette works with TIBCO
InConcert to provide some workflow capability in automated business processes.

WorkflowSchema:

The data associated with a manual work task. This is the data a user needs to complete
the task. The user can change any of the data associated with a task. A Workflow
Schema can be used to provide "extended details" for a particular manual work task.
The schema specified for extended details provides a mechanism to pass information
when a task is delegated or routed to another user.

WorkflowServerConnection:

The connection to the TIBCO InConcert workflow server. This server is used to track
and manage manual tasks.

AssignWork:

This activity creates a new task (with associated data) and assigns it to
the specified role. A user then acquires the task, views the data supplied by the activity,
and completes the work. The process definition can either wait for the user to complete
the work or it can continue processing and later query for the status of the task.
The Assign Work activity creates a manual work task and assigns it to the specified role.
Users can view tasks assigned to their role by logging into the Manual Work web
interface provided with TIBCO BusinessWorks.
An Assign Work activity creates a standard TIBCO InConcert task. If you wish to do
more sophisticated task processing, all TIBCO InConcert tools and APIs can be used to
handle tasks created with the Assign Work activity.

DownloadDocument:

Workflow schemas can contain elements to hold documents. An
example of a document is a loan application that must be attached to a credit request.
The document may be any type, for example, Microsoft Word, PDF, and so on.
Documents can be uploaded or downloaded to a manual work task by way of the web
interface TIBCO BusinessWorks provides for managing manual work tasks. This
activity allows you to download a document from an existing manual work task into a
process variable.
The Download Document activity downloads any documents that have been uploaded
to the specified manual task created with the Assign Work activity.
TIBCO
GetWorkStatus:

Retrieves the current status of a task that was previously created with
the Assign Work activity. Normally you use this activity to determine if the task has
been completed or if there are any errors. You can use the status to determine where to
conditionally transition to in the process definition. If the status is Complete, you may
want to transition to the next step of the business process. You may want to put the Get
Work Status in a loop to check the status periodically and transition out of the loop
when the status is marked as complete or an error is returned.
The Get Work Status activity is used to retrieve the current status of the specified
manual task from the TIBCO InConcert server.

WorkflowSchema:

The Workflow Schema resource defines a schema that can be used by
activities in the Manual Work Palette. This resource defines data for use in a manual
task.

WorkflowServerConnection:

The Workflow Server Connection resource defines a connection to a
TIBCO InConcert server that can be used by activities in the Manual Work palette.

ModifyWork:

The Modify Work activity is used to change the status of a manual task
created by the Assign Work activity. This activity changes the status to one of the
following: Complete, Reassign, or Update.

WaitforCompletion:

The Wait for Completion activity is used to wait for an existing
manual task (created with the Assign Work activity) to complete. The Assign Work
activity specifies a time out, if the activity is specified to be performed asynchronously.
When that timeout expires, the Wait for Completion activity can be used to wait
additional time for the completion of the manual task.
TIBCO
Parse Palette:

The Parse palette provides shared configuration resources and activities for parsing and
rendering formatted text. This is useful if you wish to transform formatted lines of text
into a data schema. This is also useful if you wish to transform a data schema into a
formatted text string. The text lines can be formatted either by delimiters separating
each field or offsets can be specified to determine where each field begins and ends

DataFormat:

The Data Format resource contains the specification for parsing or
rendering a text string using the Parse Data and Render Data activities. This shared
configuration resource specifies the type of formatting for the text (delimited columns or
fixed-width columns), the column separator for delimited columns, the line separator,
and the fill character and field offsets for fixed-width columns. You must also specify
the data schema to use for parsing or rendering the text. When parsing text, each
column of an input line is transformed into the corresponding item in the specified data
schema. The first column of the text line is turned into the first item in the data schema,
the second column is transformed into the second item, and so on. Each line is treated as
a record, and multiple lines result in a repeating data schema containing the lines of the
input text string.

When rendering text, each record in the input data schema is transformed into a line of
output text. The first item of the data schema is transformed into the first column of the
text line, the second item is transformed into the second column, and so on. Each record
in a repeating data schema is transformed into a separate line in the output text string.
Rendering a data schema into a text string is exactly the opposite process of parsing a
text string into a data schema. Rendering is the reverse of the process illustrated in
Above Figure

TIBCO
ParseData:

The Parse Data activity takes a text string or input from a file and
processes it, turning it into a schema tree based on the specified Data Format shared
configuration. You can use any mechanism to obtain or create a text string for
processing. For example, you can use the Read File activity to obtain text from a file, or
you can retrieve a text field from an adapter message. You can also specify a text file to
read using this activity. You might use this activity in a number of situations. For
example, you may have a file that consists of multiple lines of comma-separated values
(as in data obtained from a spreadsheet). You may also want to insert that data into a
database table. To do this, read and parse the file into a data schema with the Parse Data
activity. Then use a JDBC Update activity to insert the data schema into a database
table.

RenderData:

The Render Data activity takes an instance of a data schema and renders
it as a text string. The schema processed is based on a specified Data Format shared
configuration. You may wish to use this activity in a number of situations. For example,
you may retrieve a result set from a database table. You may then wish to format this
result set as a formatted text string (with line breaks between each row in the result set),
and then write that text string out to a file. You would use the Render Data activity to
render the data schema as a formatted text string. Then you would use the Write File
activity to write the string to a file.

TIBCO
Rendezvous Palette:

The Rendezvous palette allows you to send and receive TIBCO Rendezvous messages.

RawRVMsg2Schema:
The RawRVMsg2.xsd file specifies the RawRVMsg2 schema. To add this schema to your
project, perform the following procedure:

Locate the bw/5.1/lib/palettes/plugins.jar file in your TIBCO
BusinessWorks installation directory.

The RawRVMsg2.xsd file is contained in the plugins.jar file. You can
extract this file in a number of ways, depending upon your operating
system. For example, on Windows, you can open up plugins.jar using
WinZip and extract the RawRVMsg2.xsd file.

Once you have obtained the RawRVMsg2.xsd file, copy this file into your
TIBCO BusinessWorks project directory. You can copy this file into the
root project directory or to a subdirectory in your project.

Open your project, and the RawRVMsg2 schema should be located in the
folder where you placed it. If you already have your project open in
TIBCO Designer, you can choose Resources > Refresh from the menu to
display the newly placed file in your project tree.

PublishRendezvousMessage:

The Publish Rendezvous Message activity publishes a TIBCO
Rendezvous message on the given subject with the given message content.

RendezvousSubscriber:

The Rendezvous Subscriber process starter creates a process when a
TIBCO Rendezvous message on the given subject is received.

TIBCO
RendezvousTransport:

The Rendezvous Transport resource describes a TIBCO Rendezvous
transport. This resource is used when specifying activities from the Rendezvous palette.

ReplytoRendezvousRequest:

The Reply to Rendezvous Request activity is used to send a reply to a
received TIBCO Rendezvous message.

SendRendezvousRequest:

The Send Rendezvous Request activity publishes a TIBCO
Rendezvous message on the given subject with the given message content, and it
expects a reply to the message on the given reply subject and with the given reply
message content. This activity waits for a reply on the reply subject and outputs the
content of the reply.
This activity uses the INBOX mechanism to ensure that reply messages are received
only by the process that sent the request.

WaitforRendezvousMessage:

The Wait for Rendezvous Message activity waits to receive a TIBCO
Rendezvous message with the given subject.

TIBCO
RMI Palette:

Remote Method Invocation (RMI) is a protocol for calling operations on remote Java
objects. TIBCO BusinessWorks can act as server for incoming RMI calls, or TIBCO
BusinessWorks can use RMI to retrieve a remote object. For client interactions, either a
remote Java object on an RMI server or an Enterprise Java Bean (EJB) can be retrieved.
For server interactions, a client can make an RMI call to TIBCO BusinessWorks that
initiates a process instance.

RMILookup:

The RMI Lookup activity retrieves a reference to a remote object from the
specified registry server. The object reference output by this activity can be passed to a
Java Code or Java Method activity to invoke methods on the remote object.

RMIServer:

The RMI Server process starter registers the specified remote object name
with the specified registry server and then creates process instances to handle incoming
requests for the object. The process definition acts as the implementation of the specified
object. You can specify an output schema on the Output editor tab to extract expected
fields from the incoming request object. The data in the output schema is then available
to subsequent activities in the process definition. The request and reply Java objects are
also output and available to activities that can accept Java objects as input (for example,
Java Code or Java Method). You can send a reply to the client by invoking the
appropriate methods on the reply object, if the client requires a reply.

TIBCO
SOAP Palette:

Simple Object Access Protocol (SOAP) is a lightweight protocol for the exchange of
information between web services. The SOAP palette allows you do the following:

create web services by using process definitions
generate WSDL files for web service clients
invoke one-way, request/reply web services
use either HTTP or JMS as the transport for web services
send or receive SOAP requests with attachments

RetrieveResources:

The Retrieve Resources activity generates a WSDL file containing a
concrete service description of any process definition that has a SOAP Event Source
process starter. This allows clients to access the WSDL for a web service that is
implemented by a TIBCO BusinessWorks process definition. The client can then use the
WSDL file to invoke the web service. The Retrieve Resources activity can also be used to
retrieve any other resources, including XSDs and WSIL.

SOAPEventSource:

The SOAP Event Source process starter creates a process instance
for incoming SOAP requests. SOAP is a standard protocol for invoking web services.
This allows you to create a web service using process definitions.

At runtime, a client can retrieve the WSDL file for a process containing this process
starter using an HTTP request (see the description of the Retrieve Resources activity for
more information). Once the WSDL is retrieved, the client can perform a SOAP request
to invoke the web service.

WSDLFileandSOAPEventSource:

A WSDL File specifies the characteristics (input message, output message, fault
message, and so on) of a web service. The SOAP Event Source process starter
configuration determines the concrete WSDL file that describes the web service that the
process definition implements. The Configuration tab of this process starter requires
that you specify a Port Type. This port type is taken from a WSDL file resource. Instead
of creating a new WSDL File resource, you can use an existing concrete service
description. However, the concrete description of the service will be generated based on
the configuration of this process starter.

MIME part is repeating element holds the list of attachments in SOAP msg.
TIBCO
SOAPRequestReply
:
The SOAP Request Reply activity performs a request on the
specified web service and optionally expects a reply from the web service. You can
invoke both document and RPC web services with this activity.

SOAPSendFault:

The SOAP Send Fault activity sends a SOAP fault to the client if an
error occurs during processing of a SOAP request. This activity is used when the SOAP
Event Source process starter handles incoming SOAP requests. The WSDL file for the
request can have one or more fault messages defined for an operation. The SOAP Send
Fault activity can use the fault schema to send application-specific data about the fault
back to the client that made the SOAP request.
This activity cannot be used if the SOAP request is one way.
SOAP faults are required to send the fault code and the fault string. These values are
required input items on the Input tab. For example, "Client" can be used for client faults
and "Server" can be used for server faults. (Faultcode, faultstring, faultactor, detail are
i/p)

SOAPSendReply:

The SOAP Send Reply activity sends a reply to an application that
sent a SOAP request. This activity is primarily used in process definitions that
implement web services. When a SOAP Event Source is used as the process starter, the
SOAP Send Reply activity is used to send the reply to the request that starts the process
instance. This activity cannot be used if the SOAP request is one way.

SOAP Messages over the JMS Transport: The HTTP transport does not provide
guaranteed message delivery. The SOAP protocol is not specific to any transport, so
SOAP messages in theory can be bound to any transport. JMS provides a highly reliable
transport that can guarantee message delivery. TIBCO BusinessWorks supports sending
and receiving SOAP messages over the HTTP and JMS transports. As of Release 5.2.0,
there is no standard specification for SOAP messages over JMS. TIBCO has proposed a
specification with the following features:

Only JMS queues are supported but not JMS topics
Only one-way and request/response operations are supported
The support is based on SOAP 1.1 and WSDL 1.1

TIBCO
TCP/IP Palette:

The TCP/IP palette provides activities and resources that can send and receive data
using the TCP/IP protocol. TCP/IP is often the underlying communication layer for
higher-level protocols such as HTTP or FTP. You could use the resources in the TCP
palette to communicate with HTTP or FTP severs, but the activities in the HTTP Palette
or FTP Palette are best suited for this purpose. This palette is intended for use when
communicating with TCP/IP and there is no corresponding TIBCO BusinessWorks
palette for the protocol. For example, you may have a custom application that
communicates with other applications by way of TCP/IP. You could use the TCP/IP
palette to handle incoming and outgoing data from this application.

UsingtheTCP/IPPaletteActivities:

The general sequence of events when using the TCP/IP palette resources is the
following:

1. Create a TCP Connection shared configuration resource that describes the connection
information.

2. One of the following occurs depending upon whether the process definition is a
TCP/IP client or server:
a. When a process definition acts as a TCP/IP client communicating with a TCP/IP
server, a connection must be opened using the TCP Open Connection activity.
b. When a process definition acts as a TCP/IP server waiting for incoming TCP/IP
requests, the process either starts with a TCP Receiver process starter or has a Write TCP
Data that waits for an incoming connection request.

3. In the process definition the Read TCP Data and Write TCP Data activities are used to
read and write data to the TCP connection.

4. Once all processing is complete, the TCP Close Connection activity is used to close the
TCP connection.

ReadTCPData:
The Read TCP Data activity reads data from an open TCP connection.
The connection must be opened by an activity or process starter that executed
previously in the process definition. Activities that can open a TCP connection are: TCP
Receiver, TCP Open Connection, and Wait for TCP Request. The activity that opens a
TCP connection places a handle to the open connection in its connectionKey output
element. The connectionKey is mapped to this activitys input.
TIBCO
TCPCloseConnection:

The TCP Close Connection activity closes a TCP connection opened
by a previously executed activity or process starter. Activities that can open a TCP
connection are: TCP Receiver, TCP Open Connection, and Wait for TCP Request. The
activity that opens a TCP connection places a handle to the open connection in its
connectionKey output element. The connectionKey is mapped to this activitys input.

TCPConnection:

The TCP Connection is a shared configuration resource that specifies
the connection information for the TCP server. This resource is used when a process
definition acts as a TCP client connecting to a remote server or when a process
definition acts as a TCP server accepting incoming TCP connections.

TCPOpenConnection:

The TCP Open Connection activity opens a connection to a TCP
server. After establishing the connection, the activity places a handle to the open
connection in the connectionKey output element. This connection key can be used by
subsequent activities in the process definition to read data from, write data to, or close
the connection.

TCPReceiver:

The TCP Receiver process starter starts a new process when a client requests a TCP
connection. When a connection request occurs, the process starter places a handle to the
open connection in the connectionKey output element. This connection key can be used
by subsequent activities in the process definition to read data from, write data to, or
close the connection.

TIBCO
WaitforTCPRequest:

The Wait for TCP Request activity waits for a TCP client connection
request. When a connection request occurs, the activity places a handle to the open
connection in the connectioney output element. This connection key can be used by
subsequent activities in the process definition to read data from, write data to, or close
the connection.

WriteTCPData:

The Write TCP Data activity sends data on the specified TCP
connection. The connection must be opened by an activity or process starter that
executed previously in the process definition. Activities that can open a TCP connection
are: TCP Receiver, TCP Open Connection, and Wait for TCP Request. The activity that
opens a TCP connection places a handle to the open connection in its connectionKey
output element. The connectionKey is mapped to this activitys input.

TransactionPalette:

Transactions allow you to perform a group of activities as a single unit of work. All
activities in the group either complete or commit together or one or more failures in the
group cause the transaction to roll back or undo the changes made during the
transaction.

JTAUserTransactionConfiguration:

The JTA UserTransaction Configuration shared configuration
resource contains the information required to communicate with a Java Transaction API
(JTA) transaction manager. This resource is used by transaction groups that use the JTA
UserTransaction type.

TIBCO
TransactionState:

The Transaction State activity can be used in a transaction group to
obtain the current state of the transaction or to set the transaction to a rollback only
state. When a transaction is set to the rollback only state, the only outcome of the
transaction that is permitted is a rollback.

XATransactionManagerConfiguration:

The XA TransactionManager Configuration shared configuration
resource contains the information required to communicate with an XA-compliant
transaction manager. This resource is used by transaction groups that use the XA
Transaction type.

TIBCO
WSDL Palette:

The WSDL palette is used for creating, editing, validating, importing, and viewing
WSDL (Web Service Description Language) files. These files are shared resources that
describe web services. The WSDL palettes resources are used to create and reuse
abstract definitions, namely:

Messages, which describe the data being exchanged
portTypes, which define a set of operations and operations, which describe the
activities supported by the web service

WSDL: A WSDL file is an XML instance of the WSDL XML Schema, found at
http://schemas.xmlsoap.org/wsdl/. A WSDL resource is composed of a series of
definitions that describe the format and roles of messages used in web services. To
create a new WSDL resource (with an empty set of definitions), drag the WSDL icon
from the palette panel into the project panel. Once the WSDL resource has been created
and selected in the project, the key components of abstract WSDL definitions
messages, portTypes, and operations become available in the WSDL palette.

Message: The Message component is used to define the type of information being
exchanged in a web service. One or more Message components can be added to a WSDL
resource selected in your project.

PortType: The PortType component describes the operations that are supported by the
web service. One or more PortType components can be added to a WSDL resource
selected in your project. Once the portType component has been created and selected in
the project, the Operation component becomes available in the WSDL palette.

TIBCO
XML Activities Palette:

The XML Activities palette provides activities for parsing XML strings into schemas
and rendering schemas into XML strings.

ParseXML:

The Parse XML activity takes a binary XML file or an XML string
and processes it, turning it into an XML schema tree based on the XSD or DTD
specified.
The preferred way to parse XML files is to use a Read File activity set to binary mode to
read the XML file. Then pass the binary file contents to the Parse XML activity.

RenderXML:

The Render XML activity takes an instance of an XML schema element
and renders it as a stream of bytes containing XML or an XML string. The schema is
processed based on the XSD file specified.

TransformXML:

The Transform XML activity allows you to transform an input XML
document into the output specified by the given XSLT File shared configuration
resource. Normally, transformation of data occurs by mapping process variables to an
activitys input and applying XPath expressions to perform any transformation. If you
have an XSLT file that you are using for transformations, or if an outside source
supplies an XSLT file, this activity allows you to use the XSLT file instead of manually
creating the mappings.

XSLTFile:

The XSLT File resource allows you to load an XSLT file to use to
transform XML schemas using the Transform XML activity. A transformation expressed
in XSLT is called a stylesheet. A stylesheet contains a set of template rules. Each
template rule has two parts: a pattern that is matched against nodes in the source
document and a template that can be instantiated to form part of the result document.
TIBCO
A transformation expressed in XSLT describes rules for transforming a source document
into a result document. The transformation is achieved by associating patterns with
templates. A pattern is matched against elements in the source document. A template is
instantiated to create all or part of the result document. The structure of the result
document can be completely different from the structure of the source document. In
constructing the result document, elements from the source document can be filtered
and reordered, and arbitrary structure can be added.

Load balancing:

A TIBCO Administrator client can be served by multiple TIBCO Administration
Servers. The primary server allows read and write operations, while all secondary
servers only support read operations. Load balancing is implemented through the use of
the TIBCO Rendezvous distributed queue protocol (RVDQ) and therefore not available
for HTTP.
To get the load balancing and fault tolerance benefit with HTTP, you must either use an
IP redirector or explicitly point to a backup server to be used when a server fails.
Failure recovery
You can use a load-balanced server for failure recovery, where secondary servers
continue serving requests even with the primary server down.

By default, all machines within an administration domain are expected to be in the
same network subnet. You can, however, set up your system to use TIBCO Rendezvous
rvrd so the server can communicate with components on different subnets.
Part of library builder resource:
BW process & shared configuration resource.
Schemas, Identities and SSL certificates

TIBCO

Enterprise Message Service
(EMS)

TIBCO

TIBCO's Messaging solutions

TIBCO provides messaging solutions based on patented distributed architecture
(TIBCO Rendezvous), server- and queue-based architectures (TIBCO
SmartSockets), and Java (TIBCO Enterprise Message Service).

This complete set of solutions enables virtually every conceivable type of
synchronous and asynchronous communication including publish/subscribe;
request/reply, broadcast, multicast, and PGM (Pragmatic General Multicast).

TIBCO offers a range of options for quality of service including reliable,
guaranteed, and transactional, all with optional encryption, and supports the
distribution of information over both local and wide area networks.

TIBCOsMessagingProducts

TIBCO Ajax Message Service
TIBCO Rendezvous
TIBCO SmartSockets

TIBCO

(EMS)

TIBCO Enterprise Message Service is standards-based messaging software that
supports the implementation of SOA by enabling efficient synchronous and
asynchronous system-to-system communications across a wide range of
technologies such as Java EE, .NET, MQSeries, C, C++, TIBCOs own TIBCO
Rendezvous and TIBCO SmartSockets messaging software, with Cobol and
Assembler on the mainframe, with transaction systems including CICS and IMS;
and with implementations of JMS (Java Message Service) .

Application programming interfaces (APIs) are available in Java, C, C++, Perl
and COM.

A distributed message bus with multi-protocol support for Java Message Service
(JMS), TIBCO Rendezvous and TIBCO SmartSockets.

EMSArchitecture

TIBCO
EMSConcepts
JMS
Messages
Destinations
EMS Server & Administrator
EMS Config files
EMS Applications (API)
EMS & RV
EMS & Smart sockets
EMS & JNDI
Routing and fault tolerance

Java Message Service (JMS)

Java Message Service 1.1 (JMS) is a Java framework specification for messaging
between applications. Sun Microsystems developed this specification, in
conjunction with TIBCO and others, to supply a uniform messaging interface
among enterprise applications.
The JMS framework (an interface specification, not an implementation) is
designed to supply a basis for MOM development.
TIBCO Enterprise Message Service implements JMS and integrates support for
connecting other message services, such as TIBCO Rendezvous and TIBCO
SmartSockets.
TIBCO Enterprise Message Service 4.4 is compliant with the JMS 1.1 specification.
JMS is based on creation and delivery of messages.
Messages are structured data that one application sends to another.
The creator of the message is known as the producer and the receiver of the
message is known as the consumer.
The TIBCO EMS server acts as an intermediary for the message and manages its
delivery to the correct destination.
JMS supports two messaging models:
Point-to-point (queues)
Publish and subscribe (topics)

PointtoPoint

Point-to-point messaging has one producer and one consumer per message. It
uses a queue to store messages until they are received.

TIBCO
The message producer sends the message to the queue; the message consumer
retrieves messages from the queue and sends acknowledgement that the message
was received.

More than one producer can send messages to the same queue, and more than
one consumer can retrieve messages from the same queue.

The queue can be configured to be exclusive. If the queue is exclusive, then all
queue messages can only be retrieved by the first consumer specified for the
queue.

Regardless of whether the queue is exclusive or not, only one consumer can ever
consume each message that is placed on the queue.

PublishandSubscribe

In a publish and subscribe message system, producers address messages to a
topic. In this model, the producer is known as a publisher and the consumer is
known as a subscriber.
Many publishers can publish to the same topic, and a message from a single
publisher can be received by many subscribers.
Subscribers subscribe to topics, and all messages published to the topic are
received by all subscribers to the topic. When a message is published to that
topic, all subscribed consumers receive the message.
This type of message protocol is also known as broadcast messaging because
messages are sent over the network and received by all interested subscribers,

DurableSubscribersforTopics

By default, subscribers only receive messages when they are active. If messages
arrive on the topic when the subscriber is not available, the subscriber does not
receive those messages.

TIBCO
The EMS APIs allow you to create durable subscribers to ensure that messages
are received, even if the message consumer is not currently running. Messages
for durable subscriptions are stored on the server as long as durable subscribers
exist for the topic, or until the message expiration time for the message has been
reached, or until the storage limit has been reached for the topic.

When an application restarts and recreates a durable subscriber with the same
ID, all messages stored on the server for that topic are published to the durable
subscriber.

Messages

JMS messages have a standard structure. This structure includes the following
sections:
Header (required)
Properties (optional)
Body (optional)
Message properties are provider-specific and can include information on specific
implementations or enhancements to JMS functionality. i.e., EMS adds additional
properties to JMS Messages and it has its own properties also.

EMS extensions to JMS message properties are:
The JMS standard specifies two delivery modes for messages,
PERSISTENT and NON_PERSISTENT. EMS also includes a
RELIABLE_DELIVERY mode that eliminates some of the overhead
associated with the other delivery modes.

For consumer sessions, you can specify a NO_ACKNOWLEDGE mode so
that consumers do not need to acknowledge receipt of messages, if
desired. EMS also provides an EXPLICIT_CLIENT_ACKNOWLEDGE and
EXPLICIT_CLIENT_DUPS_OK_ACKNOWLEDGE mode that restricts the
acknowledgement to single messages.

EMS extends the MapMessage and StreamMessage body types to allow
EMS to exchange messages with TIBCO Rendezvous and ActiveEnterprise
formats that have certain features not available within the JMS
MapMessage and StreamMessage.

These are extensions and therefore not compliant with JMS specifications.
Extended messages are tagged as extensions with the vendor property tag
JMS_TIBCO_MSG_EXT.

TIBCO
JMSMessageHeaderFields

The header contains ten predefined fields that contain values used to route and
deliver messages.

1. JMSDestination Destination to which message is sent
2. JMSDeliveryMode

Persistent or non-persistent message. The default is persistent.
EMS extends the delivery mode to include a
RELIABLE_DELIVERY mode.
3.JMSExpiration Length of time that message will live before
expiration. If set to 0, message does not expire.
The time-to-live is specified in milliseconds.
4. JMSPriority Uses a numerical ranking, between 0 and 9, to define message
priority as normal or expedited. Larger numbers represent
higher priority.
5. JMSMessageID Value uniquely identifies each message sent by a provider.
6. JMSTimestamp Timestamp of time when message was handed off to a provider
to be sent. Message may actually be sent later than this
timestamp.
7. JMSCorrelationID This ID can be used to link messages, such as
linking a response message to a request message.
Entering a value in this field is optional.
8.JMSReplyTo A destination to which a message reply should be sent. Entering
a value for this field is optional.
9.JMSType message type identifier
10.JMSRedelivered If this field is set, it is possible that the message was delivered to
the client earlier, but not acknowledged at that time.

MessageBody(JMSMessageTypes)

Message This message type has no body. This is useful for simple event
notification.
TextMessage A java.lang.String.
MapMessage A set of name/value pairs. The names are java.lang.String objects, and
the values are Java primitive value types or their wrappers. The entries
can be accessed sequentially by enumeration or directly by name. The
order of entries is undefined.
BytesMessage A stream of uninterrupted bytes. The bytes are not typed; that is, they
are not assigned to a primitive data type.
StreamMessage A stream of primitive values in the Java programming language. Each
set of values belongs to a primitive data type, and must be read
sequentially.
ObjectMessage A serializable object constructed in the Java programming language.
TIBCO

MessageDeliveryModes

PERSISTENT

When a producer sends a PERSISTENT message, the producer must wait
for the server to reply with a confirmation. The message is persisted on
disk by the server.
This delivery mode ensures delivery of messages to the destination on the
server in almost all circumstances. However, the cost is that this delivery
mode incurs two-way network traffic for each message or committed
transaction of a group of messages.

NON_PERSISTENT

Sending a NON_PERSISTENT message omits the overhead of persisting
the message on disk to improve performance.
If authorization is disabled on the server, the server does not send a
confirmation to the message producer. If authorization is enabled on the
server, the default condition is for the producer to wait for the server to
reply with a confirmation in the same manner as when using PERSISTENT
mode.
Regardless of whether authorization is enabled or disabled, you can use
the npsend_check_mode parameter in the tibemsd.conf file to specify the
conditions under which the server is to send confirmation of
NON_PERSISTENT messages to the producer.

RELIABLE_DELIVERY

EMS extends the JMS delivery modes to include reliable delivery. When
using RELIABLE_DELIVERY mode, the server never sends the producer a
receipt confirmation or access denial and the producer does not wait for it.
Reliable mode decreases the volume of message traffic.

When you use the reliable delivery mode, the client application does not
receive any response from the server. Therefore, all publish calls will
always succeed (not throw an exception) unless the connection to the
server has been terminated.
TIBCO

In some cases a message published in reliable mode may be disqualified
and not handled by the server because the destination is not valid or
access has been denied. In this case, the message is not sent to any
message consumer. However, unless the connection to the server has been
terminated, the publishing application will not receive any exceptions,
despite the fact that no consumer received the message.

PersistentMessagesinEMS

NON_PERSISTENT and RELIABLE_DELIVERY messages are never written to
persistent storage. PERSISTENT messages are written to persistent storage when
they are received by the EMS server. Persistent messages sent to a queue are
always written to disk.
Should the server fail before sending persistent messages to subscribers, the
server can be restarted and the persistent messages will be sent to the subscribers
when they reconnect to the server.

Persistent messages published to a topic are written to disk only if that topic has
at least one durable subscriber or one subscriber with a fault-tolerant connection
to the EMS server. In the absence of a durable subscriber or subscriber with a
fault-tolerant connection, there are no subscribers that need messages resent in
the event of a server failure. In this case, the server does not needlessly save
persistent messages.
You can set the failsafe property on a topic or queue to specify that persistent
messages for the topic or queue be synchronously written to disk. When failsafe
is set, the producer remains blocked until the server has completed the write-to-
disk operation.
TIBCO

MessageAcknowledgement

The following describes the steps in message delivery and acknowledgement:
1. A message is sent from the message producer to the machine on which the EMS
server resides.

2. For persistent messages, the EMS server sends a confirmation to the procedure that
the message was received.

3. The server sends the message to the consumer.

4. The consumer sends an acknowledgement to the server that the message was
received. A session can be configured with a specific acknowledge mode that specifies
how the consumer-to-server acknowledgement is handled.

5. In many cases, the server then sends a confirmation of the acknowledgement to the
consumer.

The JMS specification defines three levels of acknowledgement for non-
transacted sessions:

CLIENT_ACKNOWLEDGE specifies that the consumer is to acknowledge
all messages that have been delivered so far by the session. When using
this mode, it is possible for a consumer to fall behind in its message
processing and build up a large number of unacknowledged messages.

TIBCO
AUTO_ACKNOWLEDGE specifies that the session is to automatically
acknowledge consumer receipt of messages when message processing has
finished.

DUPS_OK_ACKNOWLEDGE specifies that the session is to "lazily"
acknowledge the delivery of messages to the consumer. "Lazy means that
the consumer can delay acknowledgement of messages to the server until
a convenient time; meanwhile the server might redeliver messages. This
mode reduces session overhead. However, should JMS fail, the consumer
may receive duplicate messages.

EMS extends the JMS acknowledge modes to include:
NO_ACKNOWLEDGE
EXPLICIT_CLIENT_ACKNOWLEDGE
EXPLICIT_CLIENT_DUPS_OK_ACKNOWLEDGE

NO_ACKNOWLEDGE
NO_ACKNOWLEDGE mode suppresses the acknowledgement of
received messages. After the server sends a message to the client, all
information regarding that message for that consumer is eliminated from
the server. Therefore, there is no need for the client application to send an
acknowledgement to the server about the received message. Not sending
acknowledgements decreases the message traffic and saves time for the
receiver, therefore allowing better utilization of system resources.

EXPLICIT_CLIENT_ACKNOWLEDGE
EXPLICIT_CLIENT_ACKNOWLEDGE is like CLIENT_ACKNOWLEDGE
except it acknowledges only the individual message, rather than all
messages received so far on the session.

EXPLICIT_CLIENT_DUPS_OK_ACKNOWLEDGE
EXPLICIT_CLIENT_DUPS_OK_ACKNOWLEDGE is like
DUPS_OK_ACKNOWLEDGE except it lazilyacknowledges only the
individual message, rather than all messages received so far on the
session.
SynchronousandAsynchronousMessageConsumption
The EMS APIs allow for both synchronous and asynchronous message
consumption. For synchronous consumption, the message consumer
explicitly invokes a receive call on the topic or queue. When
synchronously receiving messages, the consumer remains blocked until a
message arrives.

The consumer can receive messages asynchronously by registering a
message listener to receive the messages. When a message arrives at the
destination, the message listener delivers the message to the message
consumer. The message consumer is free to do other operations between
messages.

TIBCO
Destinations

Destinations for messages can be either Topics or Queues. A destination can be
created statically in the server configuration files, or dynamically by a client
application. Servers connected by routes exchange messages sent to temporary
topics.

You can create server-based bridges between destinations of the same or different
types to create a hybrid messaging model for your application. This allows all
messages delivered to one destination to also be delivered to the bridged
destination. You can bridge between different destination types, between the
same destination type, or to more than one destination.

A destination name is a string divided into elements, each element separated by
the period character (.). The period character allows you to create multi-part
destination names that categorize destinations.

You can set the properties for topics and queues directly in the topics.conf or
queues.conf file or by means of the setprop topic or setprop queue command in
the EMS Administrator Tool.

Staticdestinations
Static destinations let administrators configure EMS behavior at the enterprise

level. Administrators define these administered objects, and client programs use
themrelieving program developers and end users of the responsibility for
correct configuration.

Static destinations support concurrent use. That is, several client processes (and
in several threads within a process) can create local objects denoting the
destination, and consume messages from it.

Administrators create static destinations using EMS server administration tools
or API.

Client programs lookup static destinations by name. Successful lookup returns a
local object representation of the destination.

A static destination remains in the server until an administrator explicitly deletes
it.

Configuration information for static destinations is stored in configuration files
for the EMS server.

TIBCO
Dynamicdestinations
Dynamic destinations give client programs the flexibility to define destinations as

needed for short-term use.

Dynamic destinations support concurrent use. That is, several client processes
(and in several threads within a process) can create local objects denoting the
destination, and consume messages from it.

Client programs create dynamic destinations, if permitted by the server
configuration.

Client programs lookup dynamic destinations by name. Successful lookup
returns a local object representation of the destination.

Dynamic destinations do not appear in the configuration files and exist as long as
there are messages or consumers on the destination.

A dynamic destination remains in the server as long as at least one client actively
uses it. The server automatically deletes it (at a convenient time) when all
applicable conditions are true:

Topic or Queue all client programs that access the destination have
disconnected
Topic no offline durable subscribers exist for the topic
Queue queue, no messages are stored in the queue

Temporarydestinations
Temporary destinations are ideal for limited-scope uses, such as reply subjects.

Temporary destinations support only local use. That is, only the client connection
that created a temporary destination can consume messages from it. However,
servers connected by routes do exchange messages sent to temporary topics.

Client programs create temporary destinations.

A temporary destination remains in the server either until the client that created
it explicitly deletes it, or until the client disconnects from the server.

TIBCO
Destinationproperties

1. failsafe
2. secure
3. maxbytes
4. maxmsgs
5. overflowPolicy
1. default
2. discardOld
3. rejectIncoming
6. Global
7. sender_name
8. sender_name_enforced
9. flowControl
10. trace
11. import
12. export
13. maxRedelivery
14. exclusive
15. prefetch
16. expiration

1. Failsafe
Determines whether the server writes persistent messages to disk
synchronously or asynchronously.

set failsafe using the form: failsafe

When failsafe is not set, messages are written to the file on disk in
asynchronous mode to obtain maximum performance.

2. Secure
When enabled for a destination, it instructs the server to check user
permissions whenever a user attempts to perform an operation on that
destination.

set secure using the form: secure

If the secure property is not set for a destination, the server does not check
permissions for that destination and any authenticated user can perform
any operation on that topic or queue.

TIBCO
3. Maxbytes
For Topics and queues specify the maxbytes property in the form:
maxbytes=value[KB|MB|GB]
where value is the number of bytes. For example: maxbytes=1000

If maxbytes is zero, or is not set, the server does not limit the memory
allocation for the queue.

For queues, maxbytes defines the maximum size (in bytes) that the queue
can store, summed over all messages in the queue. Should this limit be
exceeded, messages will be rejected by the server and the message
producer send calls will return an error

For topics, maxbytes limits the maximum size (in bytes) that the topic can
store for delivery to each durable subscriber on that topic. That is, the limit
applies separately to each durable subscriber on the topic.

4. Maxmsgs
Topics and queues can specify the maxmsgs property in the form:
maxmsgs=value

where value defines the maximum number of messages that can be waiting in a queue.

5. OverflowPolicy
Set the overflowPolicy using the form:

overflowPolicy=default|discardOld|rejectIncoming

If overflowPolicy is not set, then the policy is default.

For topics, default specifies that messages are sent to subscribers, regardless of
maxbytes or maxmsgs setting.

For queues, default specifies that new messages are rejected by the server and an
error is returned to the producer if the established maxbytes or maxmsgs value
has been exceeded.

For topics, discardOld specifies that, if any of the subscribers have an
outstanding number of undelivered messages on the server that are over the
message limit, the oldest messages are discarded before they are delivered to the
subscriber.

For queues, discardOld specifies that, if messages on the queue have exceeded
the maxbytes or maxmsgs value, the oldest messages are discarded from the
queue and an error is returned to the message producer.

TIBCO
For topics, rejectIncoming specifies that, if any of the subscribers have an
outstanding number of undelivered messages on the server that are over
the message limit, all new messages are rejected and an error is returned
to the producer.
For queues, rejectIncoming specifies that, if messages on the queue have
exceeded the maxbytes or maxmsgs value, all new messages are rejected
and an error is returned to the producer.
Examples :
setprop queue myQueue maxmsgs=1000,overflowPolicy=discardOld
setprop topic myTopic maxbytes=100KB,overflowPolicy=rejectIncoming

6. global
Messages destined for a topic or queue with the global property set are
routed to the other servers that are participating in routing with this
server.
You can set global using the form: global

7. sender_name
The sender_name property specifies that the server may include the
senders username for messages sent to this destination.
set sender_name using the form: sender_name

8. sender_name_enforced
The sender_name_enforced property specifies that messages sent to this
destination must include the senders user name.

set using the form: sender_name_enforced

If the sender_name property is also set on the destination, this property
overrides the sender_name property.

9. flowControl
specifies the target maximum size the server can use to store pending
messages for the destination. If the number of messages exceed the
maximum, the server will slow down the producers to the rate required by
the message consumers.

set flowControl using the form: flowControl=size[KB|MB|GB]

The flow_control parameter in tibemsd.conf file must be set to enable
before the value in this property is enforced by the server.

10. trace
Specifies that tracing should be enabled for this destination.

set trace using the form: trace[=body]

TIBCO
Specifying trace (without =body), generates trace messages that include
only the message sequence and message ID. Specifying trace=body
generates trace messages that include the message body.

11. Import
Allows messages published by an external system to be received by a EMS
destination (a topic or a queue), as long as the transport to the external
system is configured.

set import using the form: import="list
Where list is one or more transport names, as specified by the [NAME] ids
in the transports.conf file. Multiple transport names in the list are separated by commas.
For example: import="RV1,RV2.

12. export
allows messages published by a client to a topic to be exported to the
external systems with configured transports.

You can set import using the form: export="list
where list is one or more transport names, as specified by the [NAME] ids in the
transports.conf file. Multiple transport names in the list are separated by commas.
For example: export="RV1,RV2

13. maxRedelivery
specifies the number of attempts the server should make to redeliver a
message sent to a queue.

set maxRedelivery using the form: maxRedelivery=count
Where count is an integer between 2 and 255 that specifies the maximum
number of times a message can be delivered to receivers.
A value of zero disables maxRedelivery, so there is no maximum.

14. exclusive
The exclusive property is available for queues only. When set for a queue,
the server sends all messages on that queue to one consumer. No other
consumers can receive messages from the queue. Instead, these additional
consumers act in a standby role; if the primary consumer fails, the server
selects one of the standby consumers as the new primary, and begins
delivering messages to it.

set exclusive using the form: exclusive

By default, exclusive is not set for queues and the server distributes
messages in a round-robinone to each receiver that is ready.

TIBCO
15. prefetch
The message consumer portion of a client and the server cooperate to
regulate fetching according to the prefetch property. The prefetch property
applies to both topics and queues.
set prefetch using the form: prefetch=value

Value

2 or more - The message consumer automatically fetches messages from
the server. The message consumer never stores more than the number of
messages specified by value.

1 - The message consumer automatically fetches messages from the
serverinitiating fetch only when it does not currently hold a message.

None - Disables automatic fetch. That is, the message consumer initiates
fetch only when the client calls receiveeither an explicit synchronous
call, or an implicit call (in an asynchronous consumer).

0 - The destination inherits the prefetch value from a parent destination
with a matching name. If it has no parent, or no destination in the parent
chain sets a value for prefetch, then the default value is 5.

When a destination does not set any value for prefetch, then the default
value is 0 (that is, inherit the prefetch value).

16. expiration
If set for a destination, when the server delivers a message to that
destination, the server overrides the JMSExpiration value set by the
producer in the message header with the time specified by the expiration
property.

set the expiration property for any queue and any topic using the form:
expiration=time[msec|sec|min|hour|day]
Where time is the number of seconds. Zero is a special value that indicates
messages to the destination never expire.

For example: expiration=10min
Means 10 minutes.

When a message expires it is either destroyed or, if the
JMS_TIBCO_PRESERVE_UNDELIVERED property on the message is set
to true, the message is placed on the undelivered queue so it can be
handled by a special consumer.

TIBCO
Creating&Modifyingdestinations

create a queue using the create queue command and a topic using the create
topic command.
to create a new queue named myQueue, enter: create queue myQueue
To create a topic named myTopic, enter : create topic myTopic

Properties can be specified when creating or modifying an existing queue or topic
using the addprop queue, addprop topic, setprop queue, setprop topic,
removeprop queue, and removeprop topic commands.

The setprop queue and setprop topic commands remove properties that are not
explicitly set by the command. For example, to change maxmsgs to 100 and to
remove the overflowPolicy parameter, enter: setprop queue myQueue
maxmsgs=100

To create a secure queue, named myQueue, to which only users "joe and "eric"
can send messages and "sally" can receive messages, in the EMS Administration
Tool, enter:

set server authorization=enabled
create queue myQueue secure
grant queue myQueue joe send
grant queue myQueue eric send
grant queue myQueue sally receive

Wildcards

You can use wildcards when specifying statically created destinations in
queues.conf and topics.conf. The use of wildcards in destination names can be
used to define "parent" and "child" destination relationships, where the child
destinations inherit the properties and permissions from its parents.

the use of the two wildcards, * and >.

The wildcard > by itself matches any destination name. When > is mixed
with text, it matches one or more trailing elements. For example: foo.>
Matches foo.bar, foo.boo, foo.boo.bar, and foo.bar.boo.

The wildcard * means that any token can be in the place of *. For example:
foo.* Matches foo.bar and foo.boo, but not foo.bar.boo. foo.*.bar Matches
foo.boo.bar, but not foo.bar.
All destination properties are inheritable for both topics and queues. This means that a
property set for a "wildcarded" destination is inherited by all destinations with
matching names.

TIBCO

For example, if you have the following in your topics.conf file:
foo.* failsafe
foo.bar
foo.bob
Topics foo.bar and foo.bob are failsafe topics because they inherit failsafe from their
parent, foo.*. If your EMS server were to dynamically create a foo.new topic, it too
would have the failsafe property.

Configfiles

1. tibemsd.conf
2. users.conf
3. groups.conf
4. topics.conf
5. queues.conf
6. acl.conf
7. bridges.conf
8. factories.conf
9. transports.conf
10. tibrvcm.conf
11. durables.conf
12. routes.conf

1.Tibemsd.config
The main configuration file controls the characteristics of the EMS server.
It allows to set the following parameters for EMS server :

Global System Parameters
Storage File Parameters
Connection and Memory Parameters
Detecting Network Connection Failure Parameters
Fault Tolerance Parameters
Message Tracking Parameters
TIBCO Rendezvous Parameters
TIBCO SmartSockets Parameters
Tracing and Log File Parameters
Statistic Gathering Parameters
SSL Server Parameters
LDAP Parameters
Detecting Network Connection
Failure ParametersDeprecated

TIBCO
2. users.conf
This file defines all users. The format of the file is:
username:password:"description"
Example
admin: $1$urmKVgq78:"Administrator"
Bob::"Bob Smith"
Bill::"Bill Jones"

3. groups.conf
This file defines all groups. The format of the file is: group-
name1:"description"
user-name1
user-name2
group-name2:"description"
user-name1
user-name2
Example
administrators: "TIBCO Enterprise Message Service administrators"
admin
Bob

4. topics.conf
This file defines all topics. The format of the file is: topic-name property1,
property2,...
For example, you might enter:
business.inventory global, import="RV01,RV02", export="RV03", maxbytes=1MB

5. queues.conf
This file defines all queues.
The format of the file is: queue-name property1, property2, ...
example, you might enter: test failsafe,secure,prefetch=2

6. acl.conf
This file defines all permissions on topics and queues for all users and
groups.

The format of the file is:
TOPIC=topic USER=user PERM=permissions
TOPIC=topic GROUP=group PERM=permissions
QUEUE=queue USER=user PERM=permissions
QUEUE=queue GROUP=group PERM=permissions
ADMIN USER=user PERM=permissions
ADMIN GROUP=group PERM=permissions

Example
ADMIN USER=sys-admins PERM=all
TOPIC=foo USER=user2 PERM=publish,subscribe

TIBCO
7. bridges.conf
This file defines bridges between destinations.
[destinationType:destinationName] # mandatory -- include brackets
destinationType=destinationToBridgeTo1
[selector="message-selector"]
destinationType=destinationToBridgeTo2
[selector="message-selector"]
...
The destination-name can be any specific destination or a wildcard pattern to
match multiple destinations.
Example
[topic:myTopic1]
topic=myTopic2
queue=myQueue1

8. routes.conf
This file defines routes between this TIBCO Enterprise Message Service
server and other TIBCO Enterprise Message Service servers.

[route-name] # mandatory -- square brackets included.
url=url-string
zone_name=zone_name
zone_type=zone_type
[selector]*
[ssl-prop = value]*
Example
[test_route_2]
url = tcp://server2:7222
ssl_verify_host = disabled

9. factories.conf
This file defines the connection factories for the internal JNDI names.
The file consists of factory definitions with this format:
[factory-name] # mandatory -- square brackets included
type = generic|xageneric|topic|queue|xatopic|xaqueue|
url = url-string
metric = connections | byte_rate
clientID = client-id
[connect_attempt_count|connect_attempt_delay|
connect_attempt_timeout|reconnect_attempt_count|
reconnect_attempt_delay|reconnect_attempt_timeout = value]
[ssl-prop = value]*
Example
[north_america]
type = topic
url =tcp://localhost:7222,tcp://server2:7222
TIBCO
clientID = "Sample Client ID
ssl_verify_host = disabled

10. transports.conf
This file defines transports for importing messages from or exporting
messages to external message services, such as TIBCO Rendezvous and
TIBCO SmartSockets.

[transport_name] # mandatory -- square brackets included
type = tibrv | tibrvcm | tibss # mandatory
[topic_import_dm = TIBEMS_PERSISTENT |
TIBEMS_NON_PERSISTENT |
TIBEMS_RELIABLE]
[queue_import_dm = TIBEMS_PERSISTENT |
TIBEMS_NON_PERSISTENT |
TIBEMS_RELIABLE]
[export_headers = true | false]
[export_properties = true | false]

transport-specific-parameters

If type = tibrv
, the extended syntax is:
[service = service]
[network = network]
[daemon = daemon]
[temp_destination_timeout = seconds]

If type = tibrvcm
, the extended syntax is:

rv_tport = name # mandatory
[cm_name = name]
[ledger_file = file-name]
[sync_ledger = true | false]
[request_old = true | false]
[explicit_config_only = true | false]
[default_ttl = seconds]

If type = tibss, the extended syntax is:
[username = name]
[password = password]
[server_names = single_or_list_of_servers]
[project = name]
[delivery_mode = best_effort | gmd_all | gmd_some | ordered]

TIBCO
[lb_mode = none | round_robin | weighted | sorted]
[override_lb_mode = enable | disable]
[gmd_file_delete = enable | disable]
[import_ss_headers = none | type_num | all]
[subscribe_mode = all | exact]
[preserve_gmd = always | receivers | never]

11. tibrvcm.conf
This file defines the TIBCO Rendezvous certified messaging (RVCM)
listeners for use by topics that export messages to a tibrvcm transport.

The format of this file is
transport listenerName subjectName

Example
RVCM01 listener1 foo.bar
RVCM01 listener2 foo.bar.bar

12. durables.conf
This file defines static durable subscribers.
The file consists of lines with either of these formats:
topic-name durable-name
[route]
[clientid=id]
[nolocal]
[selector="sel"]

Example
topic1 dName1
topic2 dName2 clientid=myId,nonlocal
topic3 dName3 selector="urgency in (high,medium)"

TIBCO
DevelopinganEMSClientApplication

EMS implements the JMS 1.1 specification.In the JMS 1.1 specification,
applications using the point to point (queues) or publish and subscribe (topics)
models use the same interfaces to create objects. The JMS specification refers to
these interfaces as common facilities

JMS 1.1 Programming Model

1.ConnectionFactory Object used to create connections to EMS server.
2.Connection A connection encapsulates a physical connection with a
provider (server). Connections are used to create sessions.
3.Session A session is a single-threaded object that creates instances
of message producers, message consumers, messages and
transacted message groups.
4.MessageProducer A message producer is an object created by a session that
is used for sending messages to a destination.
5.MessageConsumer A message consumer is an object created by a session that
receives messages sent to a destination.
6.MessageListener A message listener is an object that acts as an
asynchronous event handler for messages. Message
listeners must be registered with a specific
MessageConsumer.
7.MessageSelector Message selectors are optional filters that can be used by
the application. They transfer the filtering work to the
message provider, rather than the message consumer.
A message selector is a String that contains an expression.
8.Message Several types of message bodies are available for queues
and topics.
TIBCO
9.Queue / Topic The destination that messages can be sent to or received
from.
Normally these are created and managed by the server,
but clients can create destinations dynamically by using
methods on the Session object.

CreatingEMSappusingJAVAAPIs
Install the EMS software release, which automatically includes the EMS jar files
in the clients/java subdirectory.

Add the full pathnames for the following jar files to your CLASSPATH:
jms.jar
jndi.jar
tibjms.jar
If SSL is used for communication, add the following files to the CLASSPATH:
tibcrypt.jar
jnet.jar
jcert.jar
jsse.jar
Import the following packages into your EMS application:
import javax.jms.*;
import javax.naming.*;

Step1:ConnectionFactories

A client must connect to a running instance of the EMS server to perform any
JMS operations. A connection factory is an object that encapsulates the data used
to define a client connection to an EMS server. The minimum factory parameters
are the type of connection (e.g., generic for JMS 1.1 connections and topic or
queue for JMS 1.0.2b connections) and the URL (host name, transport protocol
and port id) for the client connection to the EMS server.

A connection factory is either dynamically created by the application or obtained
from a data store by means of a naming service, such as a Java Naming and
Directory Interface (JNDI) server or a Lightweight Directory Access Protocol
(LDAP) server.

Third party servers which have been tested with TIBCO Enterprise Message
Service are:
JBoss 3.2.3 and 3.0.4 from JBoss.org
Borland Enterprise Server 5.1 from Borland
WebLogic 8.1, 7.0 and 6.1 with Service Pack 1 from BEA
IBM WebSphere Application Server Version 5
Sun Java System Application Server 7
To dynamically create a TibjmsConnectionFactory object in a Java client:

TIBCO
ConnectionFactory factory
= new com.tibco.tibjms.TibjmsConnectionFactory(serverUrl);

The serverUrl parameter has the form:
serverUrl = protocol://host:port
The supported protocols are tcp and ssl.

For example: serverUrl = tcp://server0:7222
For a fault-tolerant connection, you can specify two or more URLs. For example:
serverUrl = tcp://server0:7222, tcp://server1:7344

To set Factory inforamation :

ConnectionFactoryInfo cfi
= new ConnectionFactoryInfo("tcp://server0:7222", null, QUEUE_TYPE, params
);

Use the TibjmsConnectionFactory objects setConnAttemptCount(),
setConnAttemptDelay(), and setConnAttemptTimeout() methods to establish
new connection failure parameters:
factory.setConnAttemptCount(10);
factory.setConnAttemptDelay(1000);
factory.setConnAttemptTimeout(1000);

Step2:ConnectingtotheEMSServer

A connection with the EMS server is defined by the Connection object
obtained from a Connection Factory.

Use the TibjmsConnectionFactory objects createConnection() method to
create a Connection object:

Connection connection = factory.createConnection(userName,password);

Step3:CreatingaSession

A Session is a single-threaded context for producing or consuming
messages.
Connection objects createSession() method is used to create a Session
object.
For example, to create a non-transactional Session that uses the
AUTO_ACKNOWLEDGE delivery mode:

Session session =
connection.createSession( false, javax.jms.Session.AUTO_ACKNOWLEDGE);

TIBCO

The EMS extended acknowledgement modes, such as NO_ACKNOWLEDGE,
require that you include the com.tibco.tibjms.Tibjms constant when you specify
the EMS delivery mode. For example, to create a non-transactional Session that
uses the NO_ACKNOWLEDGE delivery mode:

Session session =
Connection.createSession(false,com.tibco.tibjms.Tibjms.NO_ACKNOWLEDGE);

Step4:SettinganExceptionListener

Implement an ExceptionListener.onException method, use the Connection
objects setExceptionListener method to register the exception listener, and
call Tibjms.setExceptionOnFTSwitch to call the exception handler after a
fault-tolerant switchover:

public class tibjmsMsgConsumer implements ExceptionListener
{ .....
public void onException(JMSException e)
{ /* Handle exception */ }
.....
connection.setExceptionListener(this);
com.tibco.tibjms.Tibjms.setExceptionOnFTSwitch(true);

Step5:DynamicallyCreatingTopicsandQueues

Use the Session objects createTopic() method to create a topic as a
Destination object:
Destination topic = session.createTopic(topicName);

Use the Session objects createQueue() method to create a queue as a
Destination object:

Destination queue = session.createQueue(queueName);

Step6:CreatingaMessageProducer

Use the Session objects createProducer() method to create a
MessageProducer object:
MessageProducer QueueSender =
session.createProducer(queue);

TIBCO
Step7:ConfiguringaMessageProducer

Use the MessageProducer objects setDeliveryMode() method to configure
your Message Producer with a default delivery mode of
RELIABLE_DELIVERY:
QueueSender.setDeliveryMode( com.tibco.tibjms.Tibjms.RELIABLE_DELIVERY);

To configure the Message Producer with a default delivery mode of
NON_PERSISTENT:
QueueSender.setDeliveryMode(javax.jms.DeliveryMode.NON_PERSISTENT);

Step8:WorkingwithMessages

EMS works with the following types of messages:

Messages with no body
Text Messages
Map Messages
Bytes Messages
Stream Messages
Object Messages

There is a separate create method for each type of message.
Use the Session objects createTextMessage() method to create a TextMessage:
TextMessage message = session.createTextMessage("Hello");

Step9:SettingandGettingMessageProperties

Use the Message objects setBooleanProperty() method to set the
JMS_TIBCO_PRESERVE_UNDELIVERED property to true:
message.setBooleanProperty("JMS_TIBCO_PRESERVE_UNDELIVERED, true);

Use the getStringProperty() method to get the user ID of the
JMS_TIBCO_SENDER:
userID = message.getStringProperty("JMS_TIBCO_SENDER");

Step10:SendingMessages

Use the MessageProducer objects send() method to send a message to the
destination specified by the MessageProducer object:
QueueSender.send(message);
Use the following form of the send() method to send a message to a
specific destination:

MessageProducer NULLsender = session.createProducer(null);
.... NULLsender.send(topic, message);
TIBCO
Step11:ReceivingMessages

Use the Connection objects start() method to start the connection:
connection.start();
Use the MessageConsumer objects receive() method to receive a message.
This is typically used in a loop for the duration the client wishes to receive
messages:
Message message = QueueReceiver.receive();
When the client has finished receiving messages, it uses the Close()
method to close the connection: connection.close();

EMSandTIBCORendezvous.

TIBCO Enterprise Message Service (release 4 and later) can exchange messages
with TIBCO Rendezvous (release 6.9 and later).

EMS can import and export messages to an external system through an
EMS topic.
EMS can import messages from an external system to an EMS queue (but
queues cannot export).

tibemsd uses definitions and parameters in four configuration files to guide the
exchange of messages with Rendezvous.

tibemsd.conf

The parameter tibrv_transports globally enables or disables
message exchange with Rendezvous. The default value is disabled.
To use these transports, you must explicitly set this parameter to
enabled.

TIBCO
transports.conf

Transport definitions (in the configuration file transports.conf)
specify the communication protocol between EMS and the external
system

topics.conf & queues.conf

Destination definitions can set the import and export properties to
specify one or more transports:

import instructs tibemsd to import messages that arrive on
those transports from Rendezvous, and deliver them to the
EMS destination.
export instructs tibemsd to take messages that arrive on the
EMS destination, and export them to Rendezvous via those
transports.

Transportconfiguration

transports.conf contains zero or more transport definitions. Each definition
begins with the name of a transport, surrounded by square brackets. Subsequent
lines set the parameters of the transport.
These examples from transports.conf illustrate the syntax of transport definitions.

[RV01]
type = tibrv
topic_import_dm = TIBEMS_RELIABLE
queue_import_dm = TIBEMS_PERSISTENT
service = 7780
network = lan0
daemon = tcp:host5:7885

[RV02]
type = tibrv
service = 7890
network = lan0
daemon = tcp:host5:7995
temp_destination_timeout = 60

TIBCO
Topic&Queueconfiguration

Topics can both export and import messages.
Queues can import messages, but cannot export them.

addprop topic myTopics.news import="RV01,RV02"
addprop topic myTopics.news export="RV02

Rendezvous messages with subject myTopics.news arrive at tibemsd over
the transports RV01 and RV02. EMS clients can receive those messages by
subscribing to myTopics.news.

EMS messages sent to myTopics.news are exported to Rendezvous over
transport RV02. Rendezvous clients of the corresponding daemons can
receive those messages by subscribing to myTopics.news.

MessageTranslation

EMS supports the ten predefined JMS header fields
These header fields are special cases:

JMS header JMSDestination corresponds to Rendezvous subject.
JMS header JMSReplyTo corresponds to Rendezvous reply subject.
JMS header JMSExpiration corresponds to the time limit of the
Rendezvous certified message.

When importing a Rendezvous message to an EMS message, tibemsd does not
set any JMS header fields, except for the special cases

When exporting an EMS message to a Rendezvous message, tibemsd groups all
the JMS header fields (except for the special cases) into a single submessage
within the Rendezvous message. The field JMSHeaders contains that
submessage. Fields of the submessage map the names of JMS header fields to
their values.

tibemsd ignores any JMS header fields that are null or absentit omits them
from the exported message.

TIBCO
EMSandTIBCOSmartSockets.

TIBCO Enterprise Message Service (release 4 and later) can exchange messages
with TIBCO SmartSockets (release 6.5 and later).

EMS can import and export messages to an external system through an
EMS topic.
EMS can import messages from an external system to an EMS queue (but
queues cannot export).

tibemsd uses definitions and parameters in four configuration files to guide the
exchange of messages with SmartSockets .

tibemsd.conf

The parameter tibss_transports globally enables or disables
message exchange with SmartSockets. The default value is disabled.
To use these transports, you must explicitly set this parameter to
enabled.

transports.conf

Transport definitions (in the configuration file transports.conf)
specify the communication protocol between EMS and the external
system.
topics.conf & queues.conf

Destination definitions can set the import and export properties to
specify one or more transports:
import instructs tibemsd to import messages that arrive on
those transports from SmartSockets , and deliver them to the
EMS destination.
export instructs tibemsd to take messages that arrive on the
EMS destination, and export them to SmartSockets via those
transports.
TIBCO

Transportconfiguration

transports.conf contains zero or more transport definitions. Each definition
begins with the name of a transport, surrounded by square brackets. Subsequent
lines set the parameters of the transport.
These examples from transports.conf illustrate the syntax of transport definitions.

[SS01]
type = tibss
server_names = rtHost1
username = emsServer6
password = myPasswd
project = sales_order_entry

[SS02]
type = tibss
server_names = tcp:rtHost2A:5555, ssl:rtHost2B:5571
username = emsServer6
password = myPasswd
project = mfg_process_control
override_lb_mode = enable
delivery_mode = gmd_some

Topic&Queueconfiguration

Topics can both export and import messages.
Queues can import messages, but cannot export them.
addprop topic myTopics.news import="SS01,SS02 "
addprop topic myTopics.news export="SS02

SmartSockets messages with subject myTopics.news arrive at tibemsd
over the transports SS01 and SS02. EMS clients can receive those messages
by subscribing to myTopics.news.

EMS messages sent to myTopics.news are exported to SmartSockets over
transport SS02. SmartSockets clients of the corresponding daemons can
receive those messages by subscribing to myTopics.news.

TIBCO
MessageTranslation

EMS supports the ten predefined JMS header fields
These header fields are special cases:
JMS header JMSDestination corresponds to SmartSockets dest .
JMS header JMSReplyTo corresponds to SmartSockets reply_to.

When importing a SmartSockets message to an EMS message, tibemsd does not
set any JMS header fields, except for the special cases.

When exporting an EMS message to a SmartSockets message, tibemsd groups all
the JMS header fields (except for the special cases) into a single submessage
within the SmartSockets message. The field JMSHeaders contains that
submessage. Fields of the submessage map the names of JMS header fields to
their values.

tibemsd ignores any JMS header fields that are null or absentit omits them
from the exported message.

TIBCO
FaultTolerance

You can arrange TIBCO Enterprise Message Service servers for fault-tolerant
operation by configuring a pair of serversone primary and one backup.

The primary server accepts client connections, and interacts with clients to
deliver messages. If the primary server fails, the backup server resumes operation
in its place.

fault-tolerant servers must have access to shared state, which consists of
information about client connections and persistent messages. This information
enables the backup server to properly assume responsibility for those
connections and messages.

To prevent the backup server from assuming the role of the primary server, the
primary server locks the shared state during normal operation. If the primary
server fails, the lock is released, and the backup server can obtain the lock.

When a primary server fails, its backup server assumes the status of the primary
server and resumes operation. Before becoming the new primary server, the
backup server re-reads all of its configuration files.

A backup server detects a failure of the primary in either of two ways:

Heartbeat Failure The primary server sends heartbeat messages to the
backup server to indicate that it is still operating. When a network failure
stops the servers from communicating with each other, the backup server
detects the interruption in the steady stream of heartbeats.

Connection Failure The backup server can detect the failure of its TCP
connection with the primary server. When the primary process terminates
unexpectedly, the backup server detects the broken connection.

TIBCO
When a backup server (B) detects the failure of the primary server (A), then B
attempts to assume the role of primary server. First, B obtains the lock on the
current shared state. When B can access this information, it becomes the new
primary server.

When B becomes the new primary server, A can restart as a backup server, so
that the two servers exchange roles.

Clients of A that are configured to failover to backup server B automatically
transfer to B when it becomes the new primary server. B reads the clients current
state from the shared storage to deliver any persistent messages to the client.
To receive notification, Java client programs set the system property
tibco.tibjms.ft.switch.exception to any value, and define an ExceptionListener to
handle failover notification.

When the primary server heartbeat stops, the backup server waits for its
activation interval (elapsed time since it detected the most recent heartbeat); then
the backup server retrieves information from shared storage and assumes the
role of primary server.

The default heartbeat interval is 3 seconds, and the default activation interval is
10 seconds. The activation interval must be at least twice the heartbeat interval.
Both intervals are specified in seconds. You can set these intervals in the server
configuration files.

Sharestate

The primary server and backup server must share the same state. Server state
includes three categories of information:

persistent message data (for queues and topics)
client connections of the primary server
metadata about message delivery

During a failover, the backup server re-reads all shared state information

The tibemsd server creates three files to store shared state.
meta.db This file records durable subscribers, fault-tolerant connections,
and other metadata.

sync-msgs.db When a queue or topic definition (in a configuration file)
specifies that the destination is failsafe, then the server stores its messages
in this file (using synchronous I/O calls).

async-msgs.db When a queue or topic definition (in a configuration file)
does not specify that the destination is failsafe, then the server stores its
messages in this file (using asynchronous I/O calls). .
TIBCO
Configuringservers
To configure an EMS server as a fault-tolerant backup, set these parameters in its
main configuration file (or on the server command line):

server Set this parameter to the same server name in the configuration
files of both the primary server and the backup server.

ft_active In the configuration file of the primary server, set this
parameter to the URL of the backup server. In the configuration file of the
backup server, set this parameter to the URL of the primary server.

For example, you have two EMS Servers (Server 1 and Server 2) that are named
"EMS-SERVER" and are to use a password of "mySecret." To set the user names
and passwords, start the EMS Administration Tool on each server, and do the
following.

From the active (Server 1), enter:
set server password=mySecret
create user EMS-SERVER password=mySecret

From the backup (Server 2), enter:
set server password=mySecret
create user EMS-SERVER password=mySecret

From the active (Server 1), enter:

From the backup (Server 2), enter:

Configuringclients

To enable a client to reconnect, you must specify the URLs of both servers when
creating a connection. Specify multiple servers as a comma-separated list of
URLs. Both URLs must use the same protocol (either tcp or ssl).

serverUrl = tcp://server0:7222, tcp://server1:7344

Use the TibjmsConnectionFactory objects
setReconnAttemptCount(), setReconnAttemptDelay(), and
setReconnAttemptTimeout() methods to establish new reconnection failure
parameters:

factory.setReconnAttemptCount(10);
factory.setReconnAttemptDelay(1000);
factory.setReconnAttemptTimeout(1000);

TIBCO
Routes
TIBCO Enterprise Message Service servers can route messages to other servers.

Topic messages can travel one hop or multiple hops (from the first server).
Queue messages can travel only one hop to the home queue, and one hop
from the home queue.

Each route connects two TIBCO Enterprise Message Service servers.

Each route forwards messages between corresponding destinations (that is,
global topics with the same name, or explicitly routed queues) on its two servers.

Routes are bidirectional; that is, each server in the pair forwards messages along
the route to the other server.

Zone
A zone is a named set of routes. Every route belongs to a zone. A zone affects the
forwarding behavior of its routes:

In a multi-hop (mhop) zone, topic messages travel along all applicable
routes to all servers connected by routes within the zone.
In a one-hop (1hop) zone, topic messages travel only one hop (from the
first server).
Queue messages travel only one hop, even within multi-hop zones.

Zones restrict the behavior of routes, so you can configure complex routing
paths. Zones affect topic messages, but not queue messages.

TIBCO
EMSRoutingandJNDI

Route

TIBCO Enterprise Message Service servers can route messages to other servers.

Topic messages can travel one hop or multiple hops (from the first
server).
Queue messages can travel only one hop to the home queue, and one hop
from the home queue.

Each route connects two TIBCO Enterprise Message Service servers.

Each route forwards messages between corresponding destinations (that
is, global topics with the same name, or explicitly routed queues) on its
two servers.
Routes are bidirectional; that is, each server in the pair forwards messages
along the route to the other server.

Routes forward messages only between global destinationsthat is, for topics
the global property must be set on both servers

Zone

A zone is a named set of routes. Every route belongs to a zone. A zone affects the
forwarding behavior of its routes:

In a multi-hop (mhop) zone, topic messages travel along all applicable
routes to all servers connected by routes within the zone.
In a one-hop (1hop) zone, topic messages travel only one hop (from the
first server).
Queue messages travel only one hop, even within multi-hop zones.

TIBCO
A server can have routes that belong to several zones. When zones overlap at a
server, the routing behavior within each zone does not limit routing in other
zones. That is, when a forwarded message reaches a server with routes in several
zones, the message crosses zone boundaries, and its hop count is reset to zero.

ConfiguringRoutesandZones

To create a route using the administration tool, first connect to one of the servers,
then use the create route command with the following syntax:
create route name url=URL zone_name=zone_name zone_type=1hop|mhop
properties

name is the name of the passive server (at the other end of the route); it
also becomes the name of the route.

URL specifies the passive server by its URLincluding protocol and port.
If your environment is configured for fault tolerance, the URL can be a
comma-separated list of URLs denoting fault-tolerant servers.

zone_name specifies that the route belongs to the routing zone with this
name. When absent, the default value is default_mhop_zone (this default
yields backward compatibility with configurations from releases earlier
than 4.0).

The zone type is either 1hop or mhop. When omitted, the default value is
mhop.
properties is a space-separated list of properties for the route. Each property
has the syntax:
prop_name=value

TIBCO
Examples :
create route B url=tcp://B:7454 zone_name=Z1 zone_type=1hop
create route C url=tcp://C:7455 zone_name=ZM zone_type=mhop

You can display these routes using the show routes command in the
administration tool:
show routes
Route T ConnID URL Zone T

The Route column lists the name of the passive server.
The T column indicates whether the route is active (A) or passive (P), from
the perspective of server A.
The ConnID column contains either an integer connection ID (if the route
is currently connected, or a dash (-) if the route is not connected.

For fault tolerance, a route specification can specify primary and secondary
passive servers, so that if the route to the primary server fails, the active server
can connect to the backup server and resume routing.

Example :
create route B url=tcp://B:7454,tcp://BBackup:7454 zone_name=Z1
zone_type=1hop

EMS&JNDI

TIBCO EMS allows you to work with third-party naming/directory service
products.

TIBCO EMS supports the storage (binding) and retrieval (look-up) of
ConnectionFactories and Destinations in third-party naming or directory
services. Examples of such services : LDAP server, the RMI registry, or the file
system.

To use a third-party directory service, you must have a JNDI provider for that
specific type of service.

The EMS server provides a implementation of JNDI that enables to lookup
connection factories, topics and queues, which are collectively referred to as
administered objects. Java clients can look up administered objects stored in EMS
using standard JNDI calls.

TIBCO
StoringAdministeredObjectsinaNaming/DirectoryService
As All TIBCO EMS administered objects implement the JNDI Referenceable

interface, when they are bound in a foreign naming/directory service, what is
physically stored there is not the serialized object itself, but rather a Reference
object that knows how to re-create the original object when the object is looked
up.

There are two forms of Reference objects that are stored, and which form is used
depends on the origin of the original object.

If the original object was looked up in the TIBCO Enterprise Message
Service server, then the Reference object that gets stored for the object
contains a URL pointer to the originating server.
When this object is looked up in the foreign naming/directory service, the
JNDI provider follows the associated URL and retrieves the object from
the TIBCO Enterprise Message Service server

1. Client 1 requests a lookup of an object in TIBCO EMS server by way of the JNDI
provider supplied in TIBCO EMS.

2. The TIBCO EMS server returns the object to Client 1.

3. Client 1 binds the object into a third-party service using a third-party JNDI
provider. The object is stored as a URL reference to the actual object in the TIBCO
EMS server.

4. Client 2 requests a lookup of an object in the third-party service using the third-
party JNDI provider.

TIBCO
5. The URL reference is returned by the third-party JNDI provider.

6. JNDI realizes that this is a reference, and further that it is a URL reference to the
TIBCO Enterprise Message Service server. Therefore, it invokes the URL context
factory of the TIBCO Enterprise Message Service JNDI provider which requests a
lookup of the object in the TIBCO Enterprise Message Service server.

7. The TIBCO Enterprise Message Service server returns the object to Client 2.

If however, the object was created locally by the client using the public constructor
of the class, then the Reference object that is stored for the object contains whatever
information is required to re-create the object locally. When this object is
subsequently looked up in the foreign naming/directory service, the JNDI
provider uses the information stored in the Reference object to instantiate the
original object locally. All of this behavior happens automatically without any
special interaction required of the client.

1. Client 1 creates a new administered object using the constructor of the class.

2. Client 1 binds the object into the third-party service using the third-party JNDI
provider. The object is stored as a local reference.

3. Client 2 requests a lookup of the object in the third-party service using the third-
party JNDI provider

4. The local reference is returned to the third-party JNDI provider.
TIBCO
5. JNDI realizes that this is a local reference, and invokes the TIBCO EMS JNDI
object factory associated with the reference, which creates a new instance of the
object locally and returns it to Client 2.

Administered objects can be configured for storage in EMS using either the
administration tool or the administration APIs, or directly in the configuration
files.

to create a generic connection factory, named myFactory, that establishes a
TCP connection to port 7344 on server1, start the EMS Administration Tool
and enter:

create factory myFactory generic URL=tcp://server1:7344

The connection factory data stored on the EMS server is located in the
factories.conf file.

to create a generic connection factory, named myFtFactory, that establishes
TCP connections to port 7545 on the primary server, server0, and port 7344
on the backup server, server1, start the EMS Administration Tool and enter
(on one line):

create factory myFtFactory generic url=tcp://server0:7545, tcp://server1:7344

Should server0 become unavailable, the client will connect to server1.

LookingupAdministeredObjectsStoredinEMS

All clients can lookup objects in the EMS naming service. Alternatively, Java
applications can lookup objects in a third-party JNDI server, and C and C# clients
can lookup objects in a third-party LDAP server.

To lookup administered objects stored in EMS, you need to create the initial
context that identifies the URL of the naming service provider and any other
properties, such as the username and password to authenticate the client to the
service. The naming service provider URL has form:
tibjmsnaming://host:port

Create an InitialContext object for the initial context, which consists of the
provider context factory and JNDI provider URL, as well as the username and
password to authenticate the client to the EMS server:

Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,
"com.tibco.tibjms.naming.TibjmsInitialContextFactory");
env.put(Context.PROVIDER_URL,"tibjmsnaming://localhost:7222");
env.put(Context.SECURITY_PRINCIPAL, "userName");
env.put(Context.SECURITY_CREDENTIALS, "password");
InitialContext jndiContext = new InitialContext(env);
TIBCO

Look up a connection factory, named ConFac, and destinations, named
topic.sample and queue.sample, from the initial context:

ConnectionFactory factory = (javax.jms.ConnectionFactory)
jndiContext.lookup("ConFac");
javax.jms.Topic sampleTopic =
(javax.jms.Topic)jndiContext.lookup("topic.sample");
javax.jms.Queue sampleQueue =
(javax.jms.Queue)jndiContext.lookup("queue.sample");

LookingUpObjectsUsingFullURLNames
Java clients can look up administered objects using full URL names. In this case,
the Context.URL_PKG_PREFIXES property is used in place of the
Context.PROVIDER_URL property. For example:

Hashtable env = new Hashtable();
env.put(Context.URL_PKG_PREFIXES,"com.tibco.tibjms.naming");
env.put(Context.PROVIDER_URL,"tibjmsnaming://localhost:7222");
env.put(Context.SECURITY_PRINCIPAL,"userName");
env.put(Context.SECURITY_CREDENTIALS,"password");
jndiContext = new InitialContext(env);

When using full URL names, you can look up objects like the following example:

Topic sampleTopic =
(javax.jms.Topic)jndiContext.lookup("tibjmsnaming://jmshost:7222/topic.sample"
);
Queue sampleQueue =
(javax.jms.Queue)jndiContext.lookup("tibjmsnaming://jmshost:7222/queue.sampl
e");

TIBCO

TIBCO
Rendezvous

TIBCO
TIBCO Rendezvous

It is a messaging component.
Basically messaging components are two types

1. Rendezvous
2. JMS

RV is a TIBCO own messaging component. Easy to create distributed applications
exchange data across a network

In JMS it contains of JMS Server

It is similar to protocol also like TCP/IP and UDP

Intension of this application is to develop distributed applications over the networks
also

Loosely coupled and Tritely coupled (decoupled)

Rv is a bus architecture here there is no centralized server

TIB/RVcomponents

TIB/Rendezvous programming language interface (API)
- Efficient, easy to use and compatible with most other libraries

TIB/Rendezvous Daemon.
- runs on each computer in the network

TIB/Rendezvous Programs
- use TIB/Rv s/w to communicate in a network
- depend on the rvd, background process for reliable and efficient
communication

TIB/RV Distributed Application System
- A set of programs to fulfill mission

TIB/RVLanguageInterfaces

C
C++
JAVA
COM
Perl 5

TIBCO
OrganizationofTIB/Rendezvous

TIB/RV uses unified data representation to exchange messages among all
supported platforms

MESSAGES
Common currency TIB/RV programs use to exchange data.
Contain Fields of self-describing data.
Every message has a subject name

Fields
Message is a set of fields
Fields contain data item of specific datatype
Program identifies and access fields by name or Numeric Identifiers (NID)
Program can do the fallowing with the fields

- Addition
- Removal
- Getting a field
- Updation
- Destroy

WireFormat

Each Message exists as a byte sequence in TIB/RV wire format
A universal format, independent of hardware, operating system and
programming language architecture.

TIBCO
TypesofMessageInteraction

Request/Reply interactions Queries and transactions.

Communication is bi-directional.

Multicastrequest/replyinteractionsrepliesfrommultipleservers.

Communication is bi-directional.

Publish/Subscribeinteractionsforgeneraldistributionofinformation

Communication is in one direction.

TIBCO
DATA
RV programs exchange self-describing data.
Contain 6 parts
- Data
- Type
- Size
- Name
- Identifier
- Count

TIB/RVMessage
- Its a composite containing zero or more fields

Field ID Type Size Count Data
Name 1 TIBRVMSG_STRING 10 1 SURESH
Address 2 TIBRVMSG_STRING 30 1 TCS,
GG1
Scores 3 TIBRVMSG_U8ARRAY 1 3 43,33,86

SUBJECTNAMES

Contains one or more elements separated by dot.

It reflects the structure of information in an application system

WildCardSubjectNames

A program can receive a group of related subjects by listening for a wild
card subject.

Wild Card
Subjects
Matching Subjects Non-matching
Subjects
Reason
RUN.* RUN.away
RUN.AWAY
RUN.Home
RUN.Run.Run
Run.away
RUN
Extra Element
Case Sensitive
Missing Element
RUN.> RUN.Away
RUN.Run.Run
RUN.swim.bike
Home.RUN
Run.away
RUN
Position
Mismatch
Case Sensitive
Missing Element

TIBCO
InboxNames

Specify a destination that is unique to a particular process

TIB/RV software uses point to point techniques to deliver messages with
these Inbox names

Used as reply subject names in Request/reply interaction which depend
on TIB/RV routing daemon

TRANSPORT

Programs use transport objects to send messages and listen for messages.
A transport determines 3 aspects of message delivery

- Delivery scope potential range of messages
- Delivery Mechanism - the path that its message travels
- Delivery protocol the ways in which programs cooperate and share
information concerning delivery

VarioustypesofTransportObjects

Intra-process Delivery
Network Transport
Reliable Delivery
Certified Delivery
Distributed Queue Delivery

IntraprocessDelivery

Between program threads within a single process
Doesnt pass through TIB/RV Daemon, remains in local within the
program process
Faster than Network transport

NetworkTransport

Delivers messages across network to processes on one or more hosts.
To one or more processes within a single host

ReliableDelivery

Subscribers have to pick up the message, published by the publisher
within specified time.
Usually time will be of 60 sec.

TIBCO
CertifiedDelivery

Keeps on sending the message till the subscriber receives the message.
Subscriber will send the acknowledgement once it receives the message

DistributedQueueDelivery

Load Balancing Technique
Scheduler and worker concept, work will be allocated based on the
priority

Transport creation calls accept three parameters that govern behaviour of the
transport
Service
Network
Daemon

Serviceparameters:

- RVD processes communicate using UDP.
- This instructs TIB/RV Daemon to use this service whenever it conveys message
on this transport
- Service group is a group of TIB/RV transport objects which communicate
using same UDP service

HowdoesuspecifytheService?

Service name
- transport creation function calls getservbyname(), which searches in
network database or a file
Port Number
- string representing a decimal integer

If NULL then it will take default value.

NetworkParameters:

Every network transport object communicates with the other transport
object over a network
Program must create a separate transport object to communicate on more
than one network

TIBCO
Consistsof3parts

- Network
- Multicast groups
- Send address

Ex: lan0;224.1.1.1,224.1.1.5;224.1.1.6

Network:

Host name: it will call gethostbyname();
Host IP address: 227.157.11.105;
Network name : getnetbyname();
Network or host IP address: same as above;
Interface name: transport function searches for the interface table for
the specified name
Default: if dont mention anything uses gethostname();

Multicastgroups:

Part II specifies zero or more multicast groups
Joining multicast group enables listeners on the resulting transport to
receive data that sent to that multicast group

Sendaddress:

When a program sends the multicast data on the resulting transport it
sends to this address
Need not be in the multicast group
Dont mention, it takes first one of the multicast group

DaemonParameters:

Instructs the transport function call about how and where to find out the
tibrv daemon and establish communication

For local daemon mention socket: xxxx
Dont mention anything :7500 (default)

RemoteDaemon:

It requires when the program runs on the laptop that not directly
connected to the network

It connects to the workstation in the network and daemon runs on that
workstation

TIBCO
For remote daemon use
1) remote host and
2) socket number

Ex: host:7777;

SuppressDaemonAutoStart:

If the transport cannot automatically start a remote daemon results in a
way to suppress the auto-start feature of a local daemon

How to specify this?

Host name:port number
125.564.45.784:7500;
---------------------------------------------------------------

VersionofRendezvous7.0onwords

PGM and TRDP
Security features
Security client connections
Virtual circuits
Direct communications
Routing daemon subject weights and path costs

PGMandTRDP

7.0 onwards PGM and TRDP are implemented PGM stands for programming generic
multicasting. Before 7.0 TRDP is there it stands for transformation reliable diagram
protocol

The main purpose of PGM and TRDP is at the time connection of internet we will call
PGM and TRDP

These protocols can be configure by N/W administrator

PGM and TRDP having a same API

The bridge between your PGM and TRDP N/W use the RVD

Program dependent

No need to required, compile, re-link and changed the program also

Its background is UDP implementation

TIBCO
Differenceb/wPGMandTRDP

Aspects TRDP PGM
Multicast
communication
Broad casting or
multicasting over UDP
channel
Can be multicasting
over a PGM channel
Point-to-point
communication
Unicast protocol over UDP
Channel
PGM, RPTP Over UDP
channel
Direct communication RPTP over UDP channel
6.0
RPTP over UDP channel
7.0

Direct communication we have Inbox is there

Securityfeatures

From 7.0 onwards the new security features implement based on these SSL (Security
Socket Layer)

The steps of SSL is

Client to daemon i.e. connection with client

Browser to daemon i.e. HTTPS Protocol will be there

Between routings i.e. RVD & RVRD b/w the routing connection

Encryption

Decryption
X.509 Are also implemented from this version also
|
(X.509 it is a security certification from ISO Standard)

Securityclientconnections

All based on that Rvsd , Rvsrd. This Rvsd used for with in the LANs. Rvsd stands for
Rendezvous security daemon.

Rvsrd Rendezvous security routing daemon. It is used for out side the LANs

Virtualcircuits

These virtual circuits provides new quality of service

TIBCO
Directcommunications

Also without Rvd you are establish a communication between two applications through
inboxes at a time

Routingdaemonsubjectweightsandpathcosts

This total control over system administrator for the purpose of routing path costs

Subjectbasedaddressing

These subject based addressing is anemones to sender

Subject based addressing anemones to the senders or receivers (computers program,
N/Ws, and operating systems)

The syntax of subject based addressing is

<Scope> . <Object> . <Name>

<Scope> this is the format of domain name. It is the universal format

. Dot , - Underscore, > Greater than * Astric These all are
used in this above syntax

<Object>
Ex: news.yahoo.com

Subject object name

The total length of the subject name should not exceed 255 characters

Subject based addressing can be used in multicast communication only

R
S
TIBCO
Validationsofsubjectname
news.yahoo.com
news.group.yahoo.com
It should be stored with an alphabet

MESSAGE COMUNICATIONS

Eventdriven(or)publishsubscriber

In this publish subscriber there is no acknowledgement
Multi casting

Demanddriven(or)request/reply

unicasting
In this request /reply acknowledgement is there

Multicastrequest/reply

Acknowledgement is there
Point-to-point communication

Directcommunication

It is established with out Rvd
Based on inbox in the receiver

TYPESOFMESSAGES

1.ReliableMessage(RVRM)

In this reliable delivery of data

RV pallet

RV configuration out put

reliable
C.M
DeQueue
In reliable some times data may lost

2. CertifiedMessage(RVCM)

This will be storing assurance delivery of data when compared to reliable data and
greater certainty (greater delivery of data)

TIBCO
FeaturesofRVCM

Certainty

This assumes every receiver can receive message when it is not possible .they can
communicate explicit via rendezvous

Control

Programs are develop explicitly with in the short span of time for each message

Convenience

Once a program sends a certified message to rendezvous s/w. Continuous delay after
until delay success or time limit expires

Detail

If you are using the RV certified s/w present advisory messages to informs programs of
every significant external delay

Ledgers

Ledgers are storage the status of information of sender & receiver

DifferenceBetweenReliableandCertifiedMessages

Reliable Certified
It is implements the Rvd

If data lost ,not easy to find out

Ledgers are not used

Maximum Rvd time limit is 60 sec

Both are implement this rvrd for
external system communication

File storage is not used
It supports or
implements the
tib RVCM
Guarantee delivery of
data

Ledgers are used for
storage

Time limit is not effective

It is implement this rvrd
for external system
communication

File storage is neccessary

TIBCO
Ledgers

Certified messages transformation of data is stored in the ledger ,ledger is a group of
records ,and it is on the based of stack

Ledgers are basically two types

File based ledger
Process based ledger

Filebasedledger

In this data can be stored or retrieved synchronous or asynchronous
Occupy the hard disc space, no limitation for store data
File will be persistence storage
The rate of data storage should be based on file size

Processbasedledger

It is a small data storage current business process; status storage is the process based
ledger
In this we have size limitation is there
Persistence via buffers
This is only synchronous purpose (request/reply based)

Relayagent

Its purpose is if we want to communications b/w via laptops (or) external to laptops

TIBCO
DISTRIBUTED QUEUE

It is responsible for group of rendezvous certified message transport object and each can
have separate process

In this DQ we have members are there
Members can be share DQ reusable components
Members are 2 types

Worker
Scheduler

Worker
This worker is responsible for process the what ever the work given by the scheduler

1 to n deliveries

Time slot will be allocated to the worker based on the worker size

Sender sends the request to scheduler

Scheduler can allocate the request to the worker based on the worker size

If all the workers are busy state then one more request comes from sender then the
scheduler will act as owner

If any worker fails then that worker work will taken care by scheduler

There is no ledger in D.Q

For back up records may be we can use log records

Scheduler
member
Work member
Work member
Work member
Work member
Sender
TIBCO
Filetofilescenario

First we go to start and then goto programs after then TIBCO designer 5.x and then
designer 5.x after then it will display TIBCO window . in that window we have 3 panels
are there

Pallets panel
Design panel
Configuration panel

First it will as project directory D:\Tibcopractice\sriveninfotech\ file to file then it
will display project name i.e. file to file.

After then we go to pallets and click on the process pallet.

We can select process definition in that process palette.

Simply we can drag and drop in to design panel.

After then click on that process definition then it will display start and end process.

In between these two we can insert read file and write file from the file palette.

These all are mapped from start to end by create transition.

Then we will create one input file link flat file.

Then go to read file and click on that

Then we can give configuration for read file like configuration, input, output, error
o/p.

After then goto input .then we can give file name means input file name
i.e. d:\filetofile\output.txt

And then click on apply. Then go to output option .in that output it will display file
info and file content

After then go to write file and click on that file. It will configure that file

And then go to input and give file name e:\output.txt

TIBCO
after then go to process data in that read file is there click on that it will display file
info and file content

Then click on that file content it will display text content .

Mapping from that text content to the write file text content.

And then click on apply. After then save this process

And go to text option click on that start selected

Then the process is going on and then complete the business process success fully

TIBCO

RENDOZVOUS FAULT TOLERANCE

It is an s/w; and it is there in every enterprise

Purpose is to solve the machine critical problems

Automatic recoverable failure

N/w failure
Process failure
Hand ware failure

This F.T s/w will monitor in the groups

Groups:

It contains a instance of objects. Those are under active state or inactive state
It will reduce the redundant process also
This RVFT s/w contains no. of cooperative programs are under running state

AdvantagesofF.T

Main advantage of this F.T is strength and our communication

Locationtransparency
It does not bounder object the o/s and which n/w we are sending

Scalability
In our group contains any no. of active states it will support n no. of active states

Convenience
In this convenience RV API program are available for writing programs and its a
decision making process .it is a back and behavior process also

Written custom RVFT programs by using RVFT API. When ever our occurrence is
need.

TIBCO
Group
It contains set of programs those cooperated (or) couperated with for F.T service
.in this. In this group contains members .members we have 2 types

Active members and Inactive members

There is no limitation of groups and members.

Another name of these two are

Primary members Active members
Secondary members Inactive members

In inactive state contains we have backup

Any new members join this group this will become an inactive state

This RVFT s/w means will monitor how many no. of active & inactive & try to
become active those who are inactive

F.Tcallback:

In this function as a parameter. Any new member joined in this group this is F.T
call back function will be called

RankandWeight:

Rank
In this RVFT group contains members are there. Each member has rank and weight

Rank Rank

n highest active n+1 inactive
1-n nos n+1 to n-1
Weights
In this weight we have highest members

Weight is 1 for active
Weight is 0 for inactive members
Members
TIBCO
WhenF.Twillbeoccurring:

Heartbeats messages
1) Process termination
2) s/w errors independent conformation using this two methods
3) h/w failures will give messages while one is failed
4) n/w disconnected

Heartbeattracking:

Process failure

Independentconformation:

In this active members withdraw the conformation

TIBCO

Adapters

TIBCO
Adapters
WhatisanAdapter?
To deploy the best solution for each aspect of your business, you usually have to
purchase applications from several different application vendors. Unfortunately,
vendors typically have their own way to format and expose data. Therefore integrating
the various applications across your enterprise poses significant challenges.
An adapter provides a bridge between an application and your TIBCO integration
environment. Using a no-coding approach to integration, TIBCO Adapters enable
packaged applications, databases and other technologies to become active participants
in the enterprise information flow, regardless of their data formats or communication
protocols. Integration of new applications does not require programming skills and
does not interfere with existing infrastructure.
Adapters isolate the application from more complex actions. Message transformation
and business process automation can be handled once the data is published to the
TIBCO infrastructure.
As shown in the next diagram, adapters allow data to be exchanged among different
technologies.
Adapters are available for off-the-shelf applications from leading vendors. Each
adapter integrates with at least one, and usually several, of the interfaces exposed
by the vendor application.
Database adapters enable an enterprises database to initiate important business
processes based on exception data they identify. Database adapters also make
data available to the enterprise.
Mainframe adapters enable real-time two way communication between them and
the rest of a companies business applications and databases.
Adapters can also enable integration with component or object development
models and other messaging technologies.
Figure 1 Adapters provide a bridge for data

TIBCO
AdapterKeyTerms
At the most basic level, an adapter exposes transactions carried out by the vendor
application to the rest of the infrastructure and allows information resulting from
transactions in other applications to be entered into the vendor application.
The following key terms are used when describing adapter interactions in this manual.
A run-time adapter is the adapter component that is used in a production system
to handle communication between a vendor application and TIBCO
infrastructure.
A design-time adapter is an adapter component that is used at configuration time
to introspect the vendor application data schemas and configure the adapter. Not
all adapters use design-time adapters. Many adapters have the same
functionality built into their palettes.
A palette is an adapter component that contains the screens used to gather input
at design-time when configuring an adapter with a service.
A project is a collection of all configured adapter resources. A project contains
configuration information for one or more adapter instances. A local project is
typically used at design-time for testing adapter instances. For production, a
project is typically managed by an administration server, which is provided by
the TIBCO Admininstrator product.

Adapter Lifecycle
The following is an overview of the adapter lifecycle.
The vendor application to which the adapter connects should be installed prior to
installing the adapter. For many adapters, the adapter and vendor application need not
be installed on the same machine.
2. Adapters depend on other software from TIBCO. Before installing an adapter, the
TIBCO Runtime Agent software must be installed on each computer on which
the adapter runs.
3. Create an adapter instance and save it in a project using TIBCO Designer. A
project contains configuration information required for a run-time adapter to
interact with the vendor application and other applications.
4. Deploy the adapter. There are two ways to deploy an adapter instance, using
TIBCO Administrator Enterprise Edition or using TIBCO Administrator
Repository Edition.
If you are using the adapter in a TIBCO BusinessWorks project, you must use
TIBCO Administrator Enterprise Edition.
TIBCO
a. Using TIBCO Designer, create an Enterprise Archive (EAR) file, which
contains information about the adapter instances and processes you wish
to deploy.
b. Using TIBCO Administrator Enterprise Edition, upload the EAR, then
deploy the adapter on the machine(s) of your choice. You can set runtime
options before deployment.
c. Using TIBCO Administrator, start and stop the adapter.
d. Monitor the adapter using the built-in monitoring tools provided by
TIBCO Administrator.
If you are using the adapter standalone, use TIBCO Administrator
Repository Edition to manage adapter projects.
e. Using TIBCO Designer, export the project to a repository server.
f. Create an adapter properties file and in it provide the location of the
project repository and adapter instance. You can also set runtime options
in the properties file.
g. Invoke the runtime adapter against the property file on the command line.
h. Monitor the adapter using the TIBCO Hawk microagents, which allow
you to get information about the adapter and manage it by setting certain
parameters during run-time.
AdapterServicesExamples
Adapters are responsible for making information from different applications available
to other applications across an enterprise. To do so, an adapter is configured to provide
one or more of the following services:
Publication Service
Subscription Service
Request-Response Service
Request-Response Invocation Service
The diagrams in this section use shaded icons to indicate TIBCO components and non
shaded icons to indicate other components.
PublicationService
An adapter publication service recognizes when business events happen in a vendor
application, and asynchronously sends out the event data in realtime to interested
systems in the TIBCO environment.
For example, an adapter can publish an event each time a new customer account is
added to an application. Other applications that receive the event can then update their
records just as the original application did.
As shown in the next diagram, when an application receives a request to create a new
customer record, the application notifies the adapter about the request and the adapter
publishes the event.
TIBCO
Figure 2 Adapter publication service

The following steps correspond to steps listed in the diagram:
1. Using a graphical user interface, a new customer record is created in the
application.
2. The application sends the new customer record to the adapter.
3. The adapter publishes the event using TIBCO messaging.

SubscriptionService
An adapter subscription service asynchronously performs an actionsuch as updating
business objects or invoking native APIson a vendor application. The adapter service
listens to external business events, which trigger the appropriate action.
Going back to the previous example, an adapter subscription service can listen for
customer record creation events (happening in an application and published to the
TIBCO infrastructure) and update another application.

TIBCO

Figure 3 Adapter subscription service

The following steps correspond to the new steps listed in the diagram:
4. The adapter is configured to listen to customer record creation events as they are
published.
5. Upon reception of a customer creation event, the adapter updates the application
to which it is connected.
RequestResponseService
In addition to asynchronously publishing and subscribing to events, an adapter can be
used to synchronously retrieve data from or execute transactions within a vendor
application. After the action is performed in the vendor application, the adapter service
sends a response back to the requester with either the results of the action or a
confirmation that the action occurred. This entire process is called request-response, and it
is useful for actions such as adding or deleting business objects.
In the next example, an adapter receives a request message from the TIBCO
infrastructure and sends it to an application. The adapter gets a response from the
application and returns it.

TIBCO

Figure 4 Adapters retrieve data

The following steps correspond to steps listed in the diagram:
1. An application sends a message request to the TIBCO environment.
2. The adapter, acting as a request-response server receives the request and
forwards the request to the application.
3. The application parses the request and returns a response message to the adapter.
4. The adapter sends the response message back to the TIBCO infrastructure where
the response is available to the requesting application.
RequestResponseInvocationService
An adapter request-response invocation service is similar to the request-response service,
except that the roles are reversed. The vendor application is now the requester or
initiator of the service, instead of the provider of the service. The adapter service acts as
a proxy, giving the vendor application the ability to synchronously invoke functionality
on an external system.
The next diagram shows the adapter sending a request message from application Y to
application X. After it processes the message, it is returned to the adapter, which sends
the response back to application Y.

TIBCO
Figure 5 Adapters act as proxies

AdapterServicesSummary
The next table summarizes the services introduced in this section.
Service Initiator Target Event Mode
Publishing service
(sends to target)
Vendor
application
TIBCO
infrastructure
Asynchronous
Subscribing service
(gets from initiator)
TIBCO
infrastructure
Vendor
application
Asynchronous
Request-response service
(gets from initiator, waits for
response then sends response to
target)
TIBCO
infrastructure
Vendor
application
Synchronous
Request-response invocation service
(sends to target, waits for response,
then sends response to initiator)
Vendor
application
TIBCO
infrastructure
Synchronous

TIBCO
ChoosinganAdapterService
A business integration scenario drives the choice of one adapter service or another. This
section provides a simple flow chart that helps you to choose the service to use. Note
that not all adapters provide all services and some adapters may provide additional
services not listed here. See your adapter users guide for details.
Consider the following environment that involves application X, an adapter and another
application:

In this scenario, data must be exchanged between the application X and another
application. The other application could be a customer management system, such as
PeopleSoft, or another TIBCO application, such as TIBCO BusinessWorks.
To decide the adapter service to configure in the adapter, start by finding out where the
scenario beginswhat triggers it. Is the scenario triggered by an event inside the
application X, or inside the other application?
For example, when a new customer account is created in application X, must the
account information also be propagated via the adapter to the other application? Or
does a batch business process in TIBCO BusinessWorks need information from
application X to generate some report?

TIBCO
This question is the starting point of the decision chart provided below:

Working through the decision chart, if the business process is the creation of a customer
record in application X and if many other applications need to be updated when the
event occurs, but no acknowledgements are required, the adapters publication service
should be used.

TIBCO
AdapterKeyFeatures
The following features are available to most adapters.
Easy-to-use GUI. All adapters use TIBCO Designer for configuring and
maintaining each adapter. .
Built-in monitoring and control using TIBCO Hawk. All adapters provide vital
business statistics (such as number of messages processed) to the Hawk console
and also include Hawk microagents that provide methods to remotely query, set
run-time parameters and stop a run-time adapter.
Support for multiple message transports. TIBCO Rendezvous or TIBCO
Enterprise for JMS can be used to transport messages to and from an adapter.
Multiple Platform Support. Adapters are usually supported on multiple
platforms such as Microsoft Windows, Solaris, and HP-UX. See each adapters
readme file for details.
Connection Management. An adapter can detect and replace lost connections to
its vendor application. Connection loss is detected upon receipt of a message
intended for a particular application. Adapters support both synchronous and
asynchronous attempts to replace a lost connection.
Multi threading. Most adapters maintain a dynamic pool of threads for
performing tasks, which allows the adapter to respond to and process multiple
events simultaneously. The adapter can track and communicate event status
without affecting other processing. See your adapter users guide for more
information.
Error Handling. All adapters use the same error handling mechanism to report
run-time adapter errors. Resolutions for run-time errors are documented in the
adapters users guide.
Multi-lingual Support. Most adapters support multi-byte character sets.

TIBCO
AdapterComponents
Overview
Each adapter has two main components, an adapter palette and a run-time adapter. In
addition, some adapters include a design-time adapter. The adapter palette and design-
time adapter are used during configuration, and the run-time adapter is used at
production time.
AdapterPalette
Each adapter includes a palette that is used for configuration. The palette is
automatically loaded into TIBCO Designer during adapter installation and available the
next time Designer is started. The palette enables you to configure adapter specific
options, such as its connection to the vendor application, logging options, and adapter
services.
During the design phase, the palette connects to the vendor application and fetches
information about connection options and data schemas. You can then graphically select
the appropriate items.
For example, during configuration of a TIBCO Adapter for ActiveDatabase adapter
instance, the palette fetches all pertinent tables in the database. You then choose the
tables that the particular service being configured is to send or receive.
The following diagram shows the TIBCO Adapter for ActiveDatabase palette and the
configuration options for a publication service.
Figure 6 Example adapter palette

TIBCO
RuntimeAdapter
Once the adapter has been configured using TIBCO Designer, it can be deployed. A
deployed adapter instance is referred to as a run-time adapter. A run-time adapter
operates in a production environment, handling communication between a vendor
application and other applications that are configured for the TIBCO environment.
DesigntimeAdapter
Some adapters use a design-time adapter (DTA) to access a vendor application and
return design-time configuration information. The palette is a client of the DTA process.
The DTA connects to the vendor application, fetches data schemas and sends them to
the palette.
ComponentDetails
The next diagram shows components used at design-time for adapters that provide a
design-time adapter. The DTA uses the applications native client libraries to access
schema from the application. The palette (in TIBCO Designer) communicates with the
DTA.
Figure 7 Design-time adapter connection to application

Not all adapters require a design-time adapter. Where possible, the adapter palette
communicates directly with the applications native client libraries as shown in the next
diagram.

TIBCO
Figure 8 Adapter palette connection to application

At run-time, the adapter uses the native client libraries to communicate with the vendor
application. This shown in the next diagram.

Figure 9 Run-time adapter connection to application

TIBCO
AdapterLifecycle
This chapter explains the lifecycle or sequence of tasks performed when integrating an
adapter into a business process.
Overview
Adapters use TIBCO Designer to configure projects and TIBCO Administrator to
deploy, run, and monitor projects.
As shown in the next diagram, after a project is created and configured, it is placed into
an EAR file and imported into TIBCO Administrator.
Figure 10 TIBCO Application Flow of Information

Installation
TIBCO Runtime Agent software must be installed before installing an adapter. If the
TRA software is not already installed, the adapter installation program warns you, then
exits.
You can run the TIBCO Installer in different modes. Each is supported on all platforms.
GUI mode presents panels that allow you to make choices about product
selection, product location, and so on.
Console mode allows you to invoke the installer and make installation choices
from a command prompt or terminal window.
Silent mode either installs using the default settings or uses a response file that
was saved during an earlier installation. You must invoke the installer from the
command-line to use silent mode.

TIBCO
TaskAInstallVendorApplication
The vendor application should be installed before installing the adapter. The vendor
application can be on any machine on your subnet. The machine on which the adapter is
installed must have network access to the vendor application.

TaskBInstallTIBCORuntimeAgent
The TIBCO Runtime Agent must be installed on each machine that hosts an adapter
design-time or run-time component before installing the adapter.
TaskCInstallAdapter(s)
You can install adapter design-time components, run-time components or both on the
same machine. A typical environment has the design-time components installed only on
machines where adapters are configured. Production machines require only run-time
components. TIBCO Runtime Agent must be installed on the machine prior to installing
an adapter design-time or run-time component.
TaskDInstallTIBCOAdministrator
TIBCO Administrator components can be installed on any machine on your subnet as
long as it can communicate with the machine that hosts the adapter.
TaskEInstallotherTIBCOSoftware
Other TIBCO software may be required in your environment. The software can be
installed before or after the adapter is installed.
TIBCO Hawk. Used to monitor and control the run-time adapter.
TIBCO BusinessWorks. An adapter can be included in a BusinessWorks process.
TIBCO IntegrationManager. An adapter can interoperate with
IntegrationManager if complex data mapping is required.
TIBCO Enterprise for JMS. Must be installed on a machine in your subnet if the
JMS transport is used by an adapter.
TIBCO Rendezvous. TIBCO Rendezvous is installed as part of the TIBCO
Runtime Agent installation. You need not install the software separately

TIBCO
Development
Adapters are configured using TIBCO Designer. This section lists the high-level steps
required to configure an adapter. Each of these steps is explained in detail in your
adapter users guide.
TaskAConfiguretheVendorApplicationtoworkwiththeAdapter
This task is completed after installing the adapter and before configuring an adapter
instance for the first time. Each adapter interoperates with its vendor application in
different way. See your adapter users guide for details.
TaskBDefineanAdapterProject
When starting TIBCO Designer, you create or select a project. A project contains adapter
configuration information, such as the service and messaging transport to use, logging
options, and other specific settings. A project is opened and saved in muti-file format,
which allows a version control system to manage the files associated with the project.
TaskCSetGlobalVariables
By default each project you create in TIBCO Designer includes a number of global
variables. Global variables provide an easy way to set defaults for use throughout your
integration project. Default values are predefined for some of the variables. You can
define additional variables and, optionally, set their values when configuring your
adapter.
When the project is deployed and the configured adapters are run, all occurrences of the
global variable name are replaced with the global variable value.
A global variable value set in TIBCO Designer can be overridden at run-time by
redefining the value in TIBCO Administrator.
TaskDCreateanAdapterInstance
An adapter instance is saved in a project and contains all information needed by the
run-time adapter. The following tabs are common in most adapter instances. An adapter
may have more tabs available along with more options under each tab.
Configuration tabEach adapter instance has a unique name in the project. The
name is set under this tab. Vendor application-specific options are also set here.
Logging tabAn adapter can log messages to standard output or to a log file.
You can define an adapter instance to use both methods, or one. In addition you
can specify that the adapter log messages of type Information, Warning, Error or
all three. Advanced logging is also available, which allows you to add specialized
log sinks.

TIBCO
Connection tabAn adapter typically connects to a vendor application or
database. Parameters used both at design-time and run-time to access the
application or database are set under this tab.
Monitoring tabIf TIBCO Hawk is used to monitor and control the run-time
adapter, and you have written custom microagents, you configure the adapter to
use them here.
TaskEConfigureanAdapterService
An adapter supports various services: publication, subscription, request-response and
request-response invocation. The services were introduced and explained on Adapter
Services Examples. Each service contains the following tabs. Additional tabs may be
available and are specific to each adapter service.
Configuration tabThe adapter service name, transport type, transport quality
of service and wire format to use are specified here.
Schema tabThe choices available vary by adapter, based on how the adapter
interoperates with the vendor application to download schema.
Encoding tabAllows you to set encoding options.
Advanced tabAllows you to change the transport subject or destination used
by the service to send messages. Other advanced fields maybe available and vary
by adapter.
After you have configured an adapter instance with at least one service, the project is
included in an Enterprise Archive File (EAR). An EAR is imported into TIBCO
Administrator when you are ready to deploy.
A project can also be imported or exported in the following formats:
Local RepositoryThe project is exported using single-file .dat format. This
format is convenient if you want to share a single file with other users. It is also
included for backward compatibility.
Server RepositoryThe project is exported using single-file format and is
managed by the administration server. This format also allows you to use the
authorization and authentication features of TIBCO Administrator.
TaskFSetSecurityOptions
If you have installed TIBCO Administrator with the security module and the TIBCO
administration domain, you can use Administrator to set security access to the projects
managed by the server. At design-time, only a user who has been authorized with write
privileges is allowed to save adapter instances in the project. At run-time, the adapter
must use a user account set in Administrator to access the project.
If a local project is used by a run-time adapter, TIBCO Administrator security is not
available.
TaskGTesttheAdapterConfiguration

TIBCO
Deployment
After an integration project has been developed and tested, it is necessary to deploy the
run-time components to the machines on which they will ultimately run in a production
environment. An adapter instance can be deployed, started and managed using one of
the following methods:
Deploy using TIBCO Administrator Enterprise Edition
Enterprise Edition must be used if your adapter is part of a TIBCO
BusinessWorks process. Enterprise Edition allows you to deploy, monitor, start
and stop adapters from the Administrator web browser.
Deploy using TIBCO Administrator Repository Edition
Repository Edition provides the repository server and the ability to set access
control to your projects. This method requires you to manually create the adapter
properties file and start and stop the adapter on the command line.
DeployUsingTIBCOAdministratorEnterpriseEdition
During development, you save your design to a project. When you are ready to deploy
your project to a machine, you generate an Enterprise archive file (EAR file) from
TIBCO Designer. The EAR file contains information on what you wish to deploy.
Building the archive creates the EAR file, which you can then deploy from TIBCO
Administrator. If you make changes to the adapters in the archive, you need to rebuild
the archive. Saving the project does not affect the archive.

TaskAGenerateandImportanEnterpriseArchiveFile
An Enterprise Archive file contains adapter instance configuration information, which is
used by a run-time adapter. An Enterprise Archive file is generated using TIBCO
Designer and imported into TIBCO Administrator.

TaskBSpecifyDeploymentInformation
After importing an Enterprise Archive file, the adapter can be deployed. This involves:
Assigning adapter services to the machines in the administration domain.
Specifying startup options for each process engine and adapter service.
TIBCO
TaskCSpecifyMonitoringOptions
Before starting the adapter you can optionally specify monitoring options, including:
Specifying alerts or TIBCO Hawk rulebases for each machine.
Specifying alerts and TIBCO Hawk rulebases for an adapter service.
Setting log file properties for an adapter service instance.
TaskDStarttheAdapter
The adapter is started and stopped using the TIBCO Administrator GUI.
DeployUsingTIBCOAdministratorRepositoryEdition
If you are using Repository Edition, you must export your project to a repository server,
then create an adapter properties file where the location of the project repository,
adapter instance and other runtime options are defined.
TaskAExportProjecttoaServerRepository
In TIBCO Designer, after the project has been configured, verified and tested, you
export the project to be managed by an administration server. The server provides
TaskBCreateorModifythePropertiesFile
Before starting the run-time adapter you must create a properties file or edit the default
properties file that is provided in the adapter package. Each adapter must have a unique
properties file. The easiest way to deploy an adapter is to copy the default properties file
to a unique name and edit the properties defined in the file. Values for the following
parameters are typically changed:
tibco.repourlpathname of the TIBCO Designer project that contains the
configuration information used by the run-time adapter.
tibco.configurlname of the adapter instance to run. The name is defined at
design-time. If you nest an adapter instance under one or more folders in TIBCO
Designer, the folder structure must also be specified as part of the tibco.configurl
parameter.
application.argsname of the properties file to pass to the run-time adapter.
tibco.clientVar.<varname> value for a global variable in a properties file. This
overrides the global varible setting defined in the project.
tibco.usernameaccount name defined in TIBCO Administrator to access a
server-based project.
tibco.passwordpassword to the account.

TIBCO
TaskCStarttheAdapter
An adapter is started from the command line. When starting an adapter against a local
project, any user with file system read privileges set on the project can start the adapter.
When starting the adapter against a server-based project, and if the project has been
configured (using TIBCO Administrator) with access control restrictions, the user name
and password must be supplied.
ManagementandMonitoring
There are several ways to monitor a run-time adapter:
TIBCO Administrator Enterprise Edition provides the Application Management
module, which is used to manage and monitor the machines in your TIBCO
You can use TIBCO Hawk to manage a run-time adapter. Each adapter has built-
in microagents that can be accessed using Hawk. The microagents are
documented in the adapter users guide.
Each adapter maintains a log file where error, warning and information messages
are written.
Each message sent by an adapter contains a trace message. The message
identifies which process has handled the message.
If a run-time adapter throws an exception, an error is displayed in the console
window where the adapter was started. You can use the displayed error code to
find the corresponding description and resolution in the adapters User Guide.
TIBCOAdministratorEnterpriseEdition
At run-time, TIBCO Administrator Enterprise Edition allows you to remotely access all
deployments in your administration domain. Depending on your security privileges,
you may be able to perform one or more of the following tasks.
User ManagementAdd users and passwords to the administration domain for
authentication, then give each user view or execute privileges for TIBCO
Administrator GUI elements or project repositories (data stores).
Domain Monitoring and ManagementView the status of machines and
components running on machines in the domain. Start and stop components as
needed.
Deployment monitoringMonitor the status of each deployment component
(process engine and adapter) and process instance and the status of the machines
executing them. View trace files and throughput.
Deployment managementView all running components and stop and restart
them as needed.
These aspects of monitoring and management are supported by TIBCO Administrator
Enterprise Edition, which includes the TIBCO Administration Server and the TIBCO
Administrator GUI.
TIBCO
TIBCOHawk
TIBCO Hawk allows monitoring, management, and fault detection. It can be customized
according to the users requirements and be used to monitor any TIBCO product on the
network. TIBCO Hawk is especially suited for very large distributed systems where
customization is required.
If TIBCO Hawk is installed at a site, Hawk microagents can be used to supplement the
monitoring information provided by the standard logging capability. Examples of
supplemental information that you can obtain with microagents are:
Current configuration settings for this adapter instance
URL of the project used for adapter instance
Command line arguments used to start the adapter
In a TIBCO Hawk environment, agents on each local computer can perform the
monitoring work. A TIBCO Hawk Agent is an autonomous process that uses
microagents to monitor local applications and systems activity. Microagents represent
managed objects such as operating system subsystems, agent components, log files,
event logs, and applications. Each microagent exposes a set of methods to the agent for
collecting information and taking actions. This design allows for separation between
management data and management rules or policies.
See your adapter users guide for a list of supported microagents.
LogFiles
By default all error, warning and information messages are printed in the console
window in which the adapter instance starts and to a default log file. The log file can be
located anywhere on the file system.
When a log file name is specified in the Logging tab, the adapter:
Creates a file with no extension, using the file name specified at design-time.
Redirects all trace messages generated by this configuration to that file until it
reaches the file size specified at design-time.
When this file size is reached (that is, as soon as the file is greater than or equal to
the limit specified at design-time), renames the current file to file.1 and creates a
new file with no extension.
Repeats this process of rolling log files and renaming files each time a new file is
generated, until three log files exist.
Information can also be written to the log file in the overwrite mode, rather than the
default append mode. In overwrite mode, the adapter instance overwrites the existing
log file when it is next started. In append mode, trace information is appended to
existing entries in the log file.
TIBCO
TraceMessages
Trace messages provide information about adapter activities. The messages are logged
to the console where the runtime adapter was started and to a log file. Trace messages
can also be redirected to the TIBCO Hawk Display application, or sent to other
applications using the TIBCO Rendezvous transport.
Each trace message can include the following fields:

<Timestamp> <Adapter Identifier> <Role> <Category> <Status Code>
<Tracking Identifier>
The above fields are explained your adapter users guide. The following diagram shows
an example trace message and calls out the fields.

StatusCodes
An adapter includes a status code in a tracing message. A status code provides
information such as connection errors, startup errors and certain adapter service errors.
These messages provide details about the error, are contextual and are applied
uniformly across adapters.
Low-level exception messages like System and TIBCO Rendezvous messages have
appropriate adapter-level information. Status code descriptions and resolutions are
available in the respective adapter users guide.
TrackingIdentifier
A tracking identifier is "stamped" on each significant trace message by the originating
adapter. This allows you to track the progress of a message as it travels among TIBCO
applications.

TIBCO
Adapter Types
TIBCO Adapters are available for a wide range of off-the-shelf applications, databases
and files, network technologies, and mainframe applications. Custom adapters can be
developed using the TIBCO Adapter SDK. Adapter SDK is a development platform for
building adapters that automatically interoperate with TIBCO ActiveEnterprise
applications.
TIBCO Adapters provide shared XML metadata definitions, standard error handling
and reporting, and the same GUIs for configuration, deployment, and monitoring.
Topics
Application Adapters
Adapters for Database and File Systems
Adapters for Other Technologies
Custom Adapters
ApplicationAdapters
Application adapters for a wide range of applications from leading vendors are
supported. Each adapter integrates with at least one, and usually several, of the
interfaces exposed by the applications.
TIBCO Adapters are available for many applications and platforms. Note that more
adapters are available then listed here, including adapters for Broadvision, Infranet,
Metasolv, JDE, Remedy and Tuxedo.
Note that this appendix provides a short summary of each adapter. See your adapter
users guide for more information.
TIBCOAdapterforR/3
The adapter enables bi-directional, real-time and asynchronous communication with
SAP R/3. The adapter supports the following SAP R/3 integration interfaces:
BAPI (Business Application Programming Interface) This interface provides
an object-oriented view of SAP's business objects and enables easy integration of
non-SAP applications in the TIBCO environment with SAP's Business Integration
Framework. This interface is best used in concert with the adapter for performing
realtime queries and updates to and from the SAP R/3 system. For example,
creation of a sales order in SAP R/3 from a legacy order management system in
the TIBCO environment. The BAPI is SAP's recommended integration interface
over RFC (Remote Function Call).
RFC interface This interface is the most popular SAP R/3 access technology. It
allows non-SAP R/3 and SAP R/3 applications to execute SAP Advanced
Business Application Programming (ABAP) functions that have been RFC-
enabled and forms the basis of ALE/IDoc and BAPI interfaces. The RFC interface
is functionally handled similar to the BAPI by the adapter and is typically used
TIBCO
when a BAPI is not provided by SAP to perform the same task. RFCs are also the
quickest way to integrate highly customized scenarios.
ALE/IDoc Interface ALE/IDocs or Intermediate Documents are SAP defined
document containers for business transactional data, such as purchase or sales
orders and order invoices. SAP's middleware to integrate different SAP R/3
systems together to begin with, ALE helps achieve cross-business functionality
and facilitates the event driven, asynchronous exchange of information directly
out of business transactions. This interface is typically used with the adapter for
non-realtime and asynchronous transfer of business data to and from the SAP
R/3 system, for example, a batch transfer of sales orders from SAP R/3 to a data
warehouse.
TIBCOAdapterforSiebel
The adapter exports or imports data into a Siebel system and other external systems in
real time. A Business Event Specification is defined to describe how data is imported
into and exported from the Siebel system. The Business Event Specification is
configured according to the Siebel Business Object model.
Siebel eBusiness applications are customized primarily through creating and modifying
object definitions. Programming is supported through the following facilities in Siebel
applications:
Siebel VB and Siebel eScript enables developers to write event procedures,
known as scripts, that are associated with certain object types and events. These
scripts can be used to attach additional validation logic to a business component
or interface with external applications by invoking methods of a Microsoft COM
object. Siebel VB is available only on Windows.
Java Data Bean Interface provides an open interface to Siebel applications,
supporting integration between Siebel applications and external applications. For
example, an application can use the Siebel Object Interfaces for importing data
into Siebel from external data source and exporting data from Siebel to external
applications in an event-driven manner. Using the Siebel Object Interface, the
adapter can access Siebel data using the Siebel Java Bean that is independent of
the underlying database platform, while at the same time preserving the Siebel
business rules built into the Business Component Objects.
Siebel Business Service simplifies the task of moving data and converting
data formats between Siebel and external applications.
Siebel business services can be written in Siebel VB or Siebel eScript. They can
then be accessed by Siebel VB or Siebel eScript code and called from the Siebel
workflow process.
Through the use of Siebel VB and Siebel eScript, the adapter can be invoked to
send or request data to or from external applications in the outbound scenarios.

TIBCO
Using the custom Business Service 'EAI TIBCO HTTP Agent' provided with the
adapter installation, publication requests can be forwarded to the Siebel Adapter
Publication Services and work seamlessly with Siebel Workflow process and
other Siebel Business Services.
TIBCOAdapterforPeopleSoft8
The adapter is a bidirectional gateway between a PeopleSoft 8 application and the
TIBCO environment. The adapter can integrate with any PeopleSoft 8 component
including PeopleSofts CRM module and the PeopleTools 8.4 application.
TIBCOAdapterforClarifyCRM
The adapter exports data from and imports data into a ClarifyCRM system in an event-
driven fashion. For example, data is exported by the adapter when a user saves data to
the ClarifyCRM database. When the adapter receives a message containing data to
import, the adapter inserts the data into the ClarifyCRM database.
TIBCOAdapterforTeradata
The adapter uses CLI (Call Level Interface) to integrate with Teradata applications. CLI
is a collection of callable service routines that provide an interface to the Teradata
RDBMS. The Teradata RDBMS communicates with the external world using CLI APIs;
this allows the adapter and Teradata RDBMS to be deployed on remote machines.
The adapter also uses JDBC to integrate with Teradata applications. JDBC is a
specification for an application programming interface (API). This API allows platform
independent Java applications to access database management systems using Structured
Query Language (SQL).
TIBCOAdapterforRemedy
The Remedy Action Request System (AR System) provides an application foundation
for IT Service Management solutions, such as the Remedy Help Desk, Remedy Asset
Management and custom-built applications.
The AR System consists of an Action Request server, which interacts with the Remedy
database and provides information to client applications, independent of the database
that the client applications use.
The adapter is a bi-directional gateway between an AR System and applications
configured for the TIBCO environment. All communication between the Remedy
database and the adapter passes through the Action Request server except for the
Publication service, which interacts directly with the Remedy database to get data from
the publishing table. The adapter uses the AR Systems APIs to interface with the Action
Request server.
TIBCO
TIBCOAdapterforTuxedo
TIBCO Adapter for Tuxedo acts as a gateway to Tuxedo services, allowing you to
invoke Tuxedo services. The adapter facilitates real-time integration between Tuxedo
applications and other applications that are configured for the TIBCO environment. The
adapter uses Tuxedo's ATMI interface and the communication paradigms provided by
Tuxedo to interface with Tuxedo applications.
For the Subscription, Request-Response and Request-Response Invocation services, the
adapter uses the appropriate method (communication paradigms) to invoke a Tuxedo
Service, which reads, writes from, or writes into buffers.
For the Publication service, all communication between Tuxedo and the adapter is either
through the EventBroker or the Adapter Agent.
TIBCOAdapterforLotusNotes
TIBCO Adapter for Lotus Notes processes schemas between Lotus Notes applications
through TIBCO Rendezvous in real-time. It maintains data integrity in both directions,
and integrates other software in the TIBCO environment seamlessly into an enterprise.
The adapter receives messages from external applications that are integrated with
TIBCO Rendezvous. Messages are passed to Lotus Notes and documents are published
from the Lotus Notes database using TIBCO Rendezvous. Publishing is carried out by
agents in the Lotus Notes databases. The Lotus Notes agents can be initiated manually,
or scheduled to run automatically.
TIBCOAdapterforJ.D.EdwardsOneWorldXe
TIBCO Adapter for J. D. Edwards OneWorld Xe allows one-way (publish or subscribe)
or two-way (request-response) message exchange between TIBCO ActiveEnterprise
applications and the J. D. Edwards OneWorld Xe enterprise resource planning (ERP)
system.
The adapter interoperates with the J. D. Edwards OneWorld Xe system by making
business function calls, extracting data using query lists, and publishing real-time
events.

TIBCO
AdaptersforDatabaseandFileSystems
Adapters can connect directly to databases or files systems to query or place data. In
addition to the following, adapters are available to transfers files from IBM AS/400 and
OS/390 external applications to applications that reside on operating systems other than
IBM AS/400 or OS/390.
TIBCOAdapterforActiveDatabase
The adapter monitors a database for changes and sends them as they occur to other
databases and applications. It extends publish-subscribe and request-response services
to databases, making multiple levels of delivery services available to applications that
access data from a database. ODBC and JDBC compliant databases such as Oracle,
Sybase, and Microsoft SQL Server are supported. While the adapter does not run on
OS/390 and AS/400 systems, it can remotely connect to a DB2 database running on
these systems.
TIBCOAdapterforOracleApplications
TIBCO Adapter for Oracle Applications allows TIBCO ActiveEnterprise applications to
communicate with Oracle Applications using publish and subscribe with reliable,
certified, and transacted message delivery.
The adapter allows third-party applications to send updates, inserts, and deletes to
Oracle Applications. It also allows Oracle Applications to publish to other applications.
The adapter includes pre-configured publication and subscription transactions.
TIBCOAdapterforFiles
The adapter provides a publication and subscription service. The publication service
reads text files and publishes their contents. The subscription service subscribes to
messages and writes their contents to a text file.

TIBCO
AdaptersforOtherTechnologies
TIBCO Adapters enable integration with component or object development models as
well as with other messaging technologies. In fact, integrating applications based on
these network technologies into a TIBCO-enabled e-business infrastructure can expand
their functionality to include features such as publication and subscription service level
messaging, and load-balancing.
TIBCO Adapters for Network Technologies are available for the following technologies.
Note that the list is not complete. Adapters are available for CORBA, CICS and other
technologies.
TIBCOAdapterforLDAP
The adapter allows applications configured for the TIBCO environment to communicate
with LDAP servers without any knowledge of LDAP protocol, LDAP APIs, and LDAP
server implementation. Applications can retrieve information from or update LDAP
servers, or receive changes occurring on the LDAP servers.
TIBCOAdapterforCOM
The adapter allows you to use ordinary COM interfaces to send messages to or receive
messages from applications configured for the TIBCO environment. You do not need to
write complex code to manage a messaging session or to marshal your data into
messages. Instead, you develop a COM interface and then use a graphical
administration tool to set certain configuration parameters.
TIBCOAdapterforCORBA
TIBCO Adapter for CORBA enables the integration of CORBA and TIBCO
ActiveEnterprise applications. The adapter provides a standalone process which
interoperates between your CORBA applications and TIBCO ActiveEnterprise. There is
no need to re-compile your existing CORBA or TIBCO ActiveEnterprise applications.
Information about your CORBA and TIBCO ActiveEnterprise applications is entered
into a repository that contains configuration information for the adapter.
TIBCO Adapter for CORBA supports the CORBA Internet Inter-ORB Protocol (IIOP)
which allows it to interoperate with CORBA applications built using third-party ORBs.
TIBCOAdapterforEJB
The adapter enables the integration of EJB and applications that operate in the TIBCO
environment. This adapter currently supports version 1.3 of the Java 2 Platform
Enterprise Environment (J2EE) specification. It also supports the J2EE Connector API,
which is part of the J2EE version 1.3 specification.
TIBCO
TIBCOAdapterforMQSeries
The adapter facilitates message flow between MQSeries applications, applications
configured for the TIBCO environment, and compatible third-party applications. The
adapter takes messages received from applications configured for the TIBCO
environment, transforms the message if necessary, and then places this data on an
MQSeries queue where it can be accessed by MQSeries applications. Conversely, the
adapter extracts data from an MQSeries queue and converts it into a TIBCO wire format
for consumption by external applications that subscribe to this data. Request-Response
interactions are also supported between TIBCO Rendezvous and MQSeries.
TIBCOAdapterforSWIFT
The adapter enables exchange of data between the SWIFT network and applications
configured for the TIBCO environment. It sends and receives SWIFT messages to and
from the SWIFT network. It also parses, validates, and unparses SWIFT messages for
publishing and subscribing in the TIBCO environment. This can be done in two ways:
automatically by running the adapter, or programmatically using the Java API. The API
enables SWIFT messages to be used for private messaging without using the SWIFT
network.

TIBCO
CustomAdapters
To write a custom adapter program, developers use the TIBCO Adapter Software
Development Kit (SDK). The Adapter SDK is a class library available in C++ and Java
on multiple platforms. The Adapter SDK also includes a number of example programs
for commonly found behavior.
TIBCO Adapter SDK provides the foundation for common adapter functionality, such
as sending and receiving information, metadata management, configuration, and
tracing. The SDK includes classes that allow access to the data saved during
configuration in the project file. The program then uses these publishers, subscribers,
sinks, etc.
Using the Adapter SDK allows custom adapters interoperability with other TIBCO
ActiveEnterprise products such as other packaged adapter products and TIBCO
IntegrationManager.
Custom adapters are configured using TIBCO Designer (the same tool used to configure
other adapters). The Generic Adapter Configuration palette allows configuration of the
sessions and endpoints, that is, publishers, subscribers, clients, or servers in TIBCO
Designer. Configuration includes specify the messaging protocol to be used, and
specifying which session type should handle with endpoint. Both standard and custom
logging behavior can also be configured. Adapter metadata determines which data the
adapter sends or receives. For this configuration, TIBCO Designer supports schema
resources.

TIBCO

TIBCO Adapter
for
ActiveDatabase

TIBCO
ADB ADAPTER
Overview
TIBCO Adapter for ActiveDatabase software (the adapter) allows data changes in a
database to be sent as they occur to other databases and applications. It extends publish-
subscribe and request-response technology to databases, making multiple levels of
delivery services available to applications that need access to these databases. ODBC
and JDBC compliant databases such as Oracle, Sybase, and Microsoft SQL Server are
supported. While the adapter does not run on OS/390 and AS/400 systems, it can
remotely connect to a DB2 database running on these systems.
TIBCO Adapter for ActiveDatabase is written using the TIBCO Adapter SDK software,
which allows the adapter to interoperate with other TIBCO products. The adapter can
communicate with any application that is configured for the TIBCO environment.
Capabilities
The following capabilities are described in detail in this manual.
Automatically publish data when rows in pre-specified database tables are
inserted, updated or deleted:
o Publish data by creating a copy (by value).
o Publish by reference (publish data directly from the source database table
without first copying the data from the source table to a publishing table).
o Publish on parameterized subjects, which allows a subject to be created
from the contents of one or more table columns.
o Preregister certified subscribers with a certified publisher..
o Update both parent and child tables within a publication. Both the parent
row and all related child rows will be published if the user has set up to
publish child data..
o Specify that a group of rows fetched from the publishing table is sent in a
single message..
Automatically subscribe to data and insert, update or delete the data in pre-
specified tables in a database:
o Subscribe using wildcard subject names..
o Perform batch commits based on message count or time out value..
Use request-response semantics to publish SQL statements, stored procedures, or
both on a specified subject:
o Execute stored procedures with IN parameters, OUT parameters, or both.
(Binary OUT parameters are not supported. This is a limitation of the
Oracle ODBC driver.).
Support RPC (Remote Procedure Calls). The adapter can act as an operation
server providing a simple means for a client to execute a single or batch of SQL
statements..
Change published messages for a publication or subscription service by
customizing the supplied callout library..
Customize adapter behavior to suit your needs:
TIBCO
o Specify relationships between tables, then publish related tables together.
o Monitor for database changes using periodic polling or notification by an
alerting mechanism..
Rely on standards:
o Connect to multiple database vendors using ODBC or JDBC drivers.
o Interoperate with other TIBCO products through the use of TIBCO
Adapter SDK software..
o Monitor your adapter service using TIBCO Hawk software..
o Choose message transports: TIBCO Rendezvous or Java Messaging Service
(JMS)..
Configure the adapter easily using TIBCO Designer..
AdapterServices
The adapter offers publication, subscription, and request-response services.
Communication parameters, database connectivity parameters, and many other
parameters can be configured for these adapter services using TIBCO Designer.
The following sections describe how these adapter services interact with the database
environment to provide message connectivity with it.
PublicationandSubscriptionServices
The following diagram illustrates publication and subscription. Database Application 1
updates a table in a database monitored by a TIBCO Adapter for ActiveDatabase
publication service. The adapter extracts data from the changed rows of the database
tables and publishes it on the specified transport (TIBCO Rendezvous or TIBCO
Enterprise Message Service). This data is then available to other applications listening
on these transports.
One particular type of listening application could be another instance of a TIBCO
Adapter for ActiveDatabase adapter, running a subscription service. Upon receiving a
message, it updates the relevant tables in its associated database.
Figure 1 Typical Publication-Subscription Services Flow

TIBCO
RequestResponseService
The request-response feature in TIBCO Adapter for ActiveDatabase allows an
application to submit one or more SQL statements, stored procedures, or both for the
adapter to execute. After execution, the adapter returns one or more result sets and a
result code. The request and responses are formulated using nested self-describing
messages. This data flow is illustrated in the figure below.

Figure 2 Typical Request-Response Service Flow

The adapter can also be configured to manage requests using load balancing among a
set of adapters that participate in the same named queue. Additionally, the adapter has
been designed to allow multiple threads to process application requests.

TIBCO
ADBAdapterVSBWJDBCPalette

The Objective of this document is to provide guidance on the use and feature
comparison of TIBCO Adapter for Active Database and Business Works JDBC Palette. Listed
features are driven primarily on type of connectivity, Ease of use, Monitoring, and
Database support.

Feature Adapter BW Palette
Ease of
Integration
Adapter consists design time
and run time environments,
which are to be managed
separately.
JDBC palette for both run-time and
design-time operates in the same way.
Completeness Adapter is a very scalable
component to handle both
inbound and outbound
messages.
BW JDBC does not have a mechanism to
detect database changes in a push
environment.
* Custom code required

Consistent error
viewing and
handling
Adapter are written using SDK
and strictly adhere to standard
error viewing and handling.
Thereby making monitoring
easy.
JDBC provides error objects and rules
have to be written for error viewing and
handling.
Transactions
Volume
Adapters are useful in high-to-
medium load situations for both
real-time and batch-updates.
Adapter can be run on the
application machine using native
lib.
BW palette are useful in medium-to-low
level load real-time situation
Connectivity
Design Time
JDBC JDBC
Connectivity
Run-Time
ODBC JDBC
Transaction
Support
When asynchronous operations
are acceptable.
Useful when dealing with synchronous
model and you need to take explicit
action on transaction failure
SQL Statements Useful when you are using
straight forward and simple SQL
statements
Useful when the database operations
are not straight forward i.e. the
operations depend on a lot of
"if..then..else" data dependent clauses.
Ease of Data
Transformation,
parsing and
mapping
Data is transformed to desired
protocol format (JMS etc) at the
source. Parsing and mapping
takes place in process flow.
Data transformation, Parsing and
mapping takes place in process flow.

TIBCO
ADBADAPTEREXECUTION

PostInstallationProcedure:
Open a command window and change directory to your database directory. For
example, for Oracle: cmd : cd <install-
path>\tibco\adapter\adadb\5.2\config\oracle
open create_user.sql file

Change the userID and Password:
--
-- create_user.sql --
-- Sample script used to create a user in ORACLE
-- Script must be run under the system account
-- For more details, see the ORACLE Administrator's Guide
-- SQL*Plus formatting commands
SET VERIFY OFF;
-- Actual SQL commands to create the user
CREATE USER suneel IDENTIFIED BY adbuser;
GRANT CONNECT, RESOURCE TO suneel IDENTIFIED BY adbuser;

-- For Alerter use only
-- GRANT EXECUTE on DBMS_AQ to suneel ;
-- GRANT EXECUTE on DBMS_AQADM to suneel ;

-- Reset SQL*Plus variables
UNDEFINE user;
UNDEFINE passwd;

ConfiguretheODBCSystemDataSource
A. Navigate to the Control Panel, then locate and double-click the Data Sources
(ODBC) icon.

B. Click the System DSN tab, then click Add... .
TIBCO

C. Select an ODBC driver and click Finish.

D. In the ODBC Driver Setup dialog, type appropriate values in the fields. Click the
Help button for an explanation of each field.

TIBCO

E. In the Advanced tab, select the Procedure Returns Results checkbox. This is
necessary for the ODBC driver to return retrieved data from stored procedures
for Request-Reply operations. Fill in the other fields as required for your
configuration, or accept the defaults.
F. Click Apply, and then click Test Connect to test the connection.

TIBCO
G. In the ODBC Driver Setup dialog, click OK to save the object, then click OK to
exit

Create the tables:
D:\tibco\adapter\adadb\5.2\demo\demo2>sqlplus scott/tiger
@demo2_ora.sql
ConfigurethePropertiesFiles
Open a command window and change directory to the demo2 subdirectory. For
example:
> cd D:\tibco\adapter\adadb\5.2\demo\demo2
Open the publisher adapter file, demo2pub.tra, and set the following values as
appropriate for your environment.

C:\TIBCO\adapter\adadb\5.2\demo\demo2>write demo2pub.tra
#
# Sample ADB properties file
# Optional properties file you can use in place of command line
parameters
# Usage: adbagent --propFile propFilename
.
.
.
# Change these settings for your login and dsn for Demo2
adb.user suneel
adb.password suneel
adb.dsn oracle1
.
.
.

TIBCO
Save and close the demo2pub.tra file.
Open the subscriber adapter file, demo2sub.tra, and set the same values as
appropriate for your environment.
Save and close the demo2sub.tra file.
CreateaProjectintheDesigner.
CreateanAdapterInstance

Fill in the Configuration tab fields as follows:
o In the Instance Name field, type demo2pub.
o In the Vendor field, select the type of database you are using, such as
Oracle, from the drop-down list.
o Make sure the Write to Database on Save checkbox is selected. This default
option writes configuration information to the database when you save the
project in TIBCO Designer.
Click Apply.
Click the Design-Time Connection tab and specify database connection
parameters for your environment.

TIBCO

Click the Test Connection button to verify the parameters you entered are
correct for your setup.
Click Apply. Click OK to any confirmation messages that appear.
Click the Run-Time Connection tab and in the ODBC DSN field, specify
ODBC system data source for the adapter.

TIBCO
Click the Configuration tab and select Show All Tabs.
Click the General tab and in the Termination Subject or Topic field, type
demo2pub.stop.

Click Apply
Click Project>Save
In the project panel, expand the demo2pub icon and click the Adapter
Services folder
In the Palettes panel, drag the Publication Service icon to the design panel.
The icon name changes to ADBPublisher. New fields appear in the
Configuration tab. Other new tabs also appear.
TIBCO

Click the Table tab, then click the Add Table icon in the tool bar

TIBCO
Then this screen appears

Enter Customer then

Click the Publisher Options tab and verify that P_CUSTOMER is set in the
Publishing Table field. If the value is not set, type the value in the field and click
Apply.

TIBCO
Select ORDER_DETAILS from the Add Table drop-down list, then click OK.
TIBCO Designer loads schema information for the ORDER_DETAILS child table.
In the Table tab, expand the ORDER_DETAILS table.
Add the join between CUSTOMER and ORDER_DETAILS:
a. In the ORDER_DETAILS CUSTID entry, click the User Key checkbox.
This entry is now marked with a key icon, like primary key columns.

b. b. In the ORDER_DETAILS CUSTID entry, click in the Join To field and
select CUSTOMER.CUSTID from the drop-down list and click Apply.
TIBCO

Add Two Child Tables to the ORDER_DETAILS Table
1. To add the first secondary table relationship, select the ORDER_DETAILS table,
then click the Add Child Table icon in the tool bar.

TIBCO
The Add Table dialog displays.
2. Select INTERNAL_ORDER_ITEMS from the drop-down list, then click OK.
TIBCO Designer loads schema information for this secondary detail table.
3. Add the join between ORDER_DETAILS and INTERNAL_ORDER_ITEMS:
a. Expand INTERNAL_ORDER_ITEMS. (You can enlarge the configuration
panel by dragging the borders.)
b. In the INTERNAL_ORDER_ITEMS ORDERID entry, click the User Key
checkbox. This marks the entry with a key icon.

4. To add the second secondary table relationship, select the ORDER_DETAILS
table, then click the Add Child Table icon in the tool bar.
The Add Tables dialog displays.
5. Select EXTERNAL_ORDER_ITEMS from the drop-down list, then click OK.
6. Add the join between ORDER_DETAILS and EXTERNAL_ORDER_ITEMS:
a. Expand EXTERNAL_ORDER_ITEMS.
b. In the EXTERNAL_ORDER_ITEMS ORDERID entry, click the User Key
checkbox. This entry is now marked with a key icon.
c. In the EXTERNAL_ORDER_ITEMS ORDERID entry, click in the Join To
field and select ORDER_DETAILS.ORDERID from the drop-down list.
TIBCO
The Configuration panel, fully expanded, should look as follows:

1. ADBSubscriber:

TIBCO
2.AddtheSubscriptionService
1. In the project panel, expand the demo2sub icon and click the Adapter Services
folder.
2. In the Palettes panel, drag the Subscription Service icon to the design panel. The
icon name changes to ADBSubscriber.

3.AddaTableandaChildTabletotheSubscriptionService
1. Click the Table tab, then click the Add Table icon in the tool bar.
The Question dialog displays.
2. Click OK to retrieve the tables from the database. A status bar displays, and the
Add Table dialog shows the available tables.
3. In the Add Table dialog, select SUB_CUSTOMER from the drop-down list, then
click OK. TIBCO Designer loads schema information for this destination table.
4. Expand the SUB_CUSTOMER table.
5. Click the Add Child Table icon in the tool bar.
TIBCO
6. Select SUB_ORDER_DETAILS from the drop-down list, then click OK. TIBCO
Designer loads schema information for this child table.
7. Expand the SUB_ORDER_DETAILS table.
8. Add the join between SUB_CUSTOMER and SUB_ORDER_DETAILS:
Note: When setting a relationship on the subscription side, the columns to index
must match the columns indexed in the corresponding child table on the publication
side.
a. In the SUB_ORDER_DETAILS CUSTID entry, click the User Key checkbox. This
entry is now marked with a key icon.
b. In the SUB_ORDER_DETAILS CUSTID entry, click in the Join To field and
select SUB_CUSTOMER.CUSTID from the drop-down list.

4.AddTwoChildTablestotheSUB_ORDER_DETAILSTable
1. To add the first secondary table relationship, select the SUB_ORDER_DETAILS
table, then click Add Child Table in the tool bar. The Add Tables dialog displays.
2. Select SUB_INTERNAL_ORDER_ITEMS from the drop-down list, then click OK.
3. Expand the SUB_INTERNAL_ORDER_ITEMS table.
TIBCO
4. Add the join between SUB_ORDER_DETAILS and
SUB_INTERNAL_ORDER_ITEMS:
a. In the SUB_INTERNAL_ORDER_ITEMS ORDERID entry, click the User
Key checkbox. This entry is now marked with a key icon.
b. In the SUB_INTERNAL_ORDER_ITEMS ORDERID entry, click in the Join
To field and select SUB_ORDER_DETAILS.ORDERID from the drop-
down list.

5. To add the second secondary table relationship, click the SUB_ORDER_DETAILS
table to select it, then click Add Child Table in the tool bar. The Add Tables
dialog displays.
6. Select SUB_EXTERNAL_ORDER_ITEMS from the drop-down list, then click OK.
a. In the SUB_EXTERNAL_ORDER_ITEMS ORDERID entry, click the User
Key checkbox. This entry is now marked with a key icon.
b. In the SUB_EXTERNAL_ORDER_ITEMS ORDERID entry, click in the Join
To field and select SUB_ORDER_DETAILS.ORDERID from the drop-
down list.
TIBCO

5.AddChildTableMappings
This task adds a child table mapping for the relationship between the publishing and
subscribing side. Child tables between a publisher and subscriber must be mapped
unless the tables have the same name. If the subscriber child tables have the same names
as the publisher child tables, you do not need to perform this task.
1. Click the Child Table Mappings tab.
2. Click in the Publisher Child Table Name column and enter the following data:
a. For the SUB_ORDER_DETAILS table, type ORDER_DETAILS.
b. For the SUB_INTERNAL ORDER_ITEMS table, type
INTERNAL_ORDER_ITEMS.
c. For the SUB_EXTERNAL_ORDER_ITEMS table, type
EXTERNAL_ORDER_ITEMS.
TIBCO

3. Click Apply.
4. Click the Subscriber Options tab. In the Exception Table field, type
EXCP_CUSTOMER.
This defines an exception table for use with this subscription. if an error occurs
when inserting data, the data will be inserted into this exception table.
5. Click Apply.
6.ChangetheSubjectName
The subject name must be the same for both the publication and the subscription
service.
1. Click the Advanced tab. Do not change the default subject name. Copy the
%%Domain%%.%%Deployment%%.adb.demo2sub.ADBSubscriber subject
name.
2. In the project tab, select the ADBPublisher service icon, then click the Advanced
tab and paste the subject name copied in the previous step.
3. Click Apply.
4. Save the project using Project>Save.
TIBCO
RequestResponseServiceTabs
This service is often called a Request Reply Server or RPC (Remote Procedural Call)
Server. When running as a Request-Response Service, the adapter receives requests
from other applications, parses them, calls the appropriate component interface API to
set the input fields, then calls another set of component interface APIs to get the output
fields. The output fields are wrapped in a schema and sent back to the caller.
A Request-Response Service is renamed ADBServer when you drag its icon into the
design panel. Configuration involves specifying its name, quality of service and wire
format. A server operation allows the adapter to process requests from client
applications and return results in a response to the client.
When using the RPC server, you can configure custom operations. These are configured
under the Call Operation Tab.
You can configure parameters under the following tabs:
Configuration Tab
Call Operation Tab
Advanced Tab
When JMS is selected as Transport Type:

TIBCO
When RV is selected as Transport Type:

ConfigurationTab
TransportType
Select the transport type (JMS or TIBCO Rendezvous) to be used by the run-time
adapter.
The transport can be configured to use a trusted store and identity resource for use in
SSL (Secure Sockets Layer) configurations. TIBCO Rendezvous sessions and JMS topics
have an SSL configuration field which uses a dialog to perform SSL configuration.
ToenableandconfigureSSL:
In the Project panel, expand the Advanced folder, then expand the Sessions folder.
Select the TIBCO Rendezvous session or JMS topic and click Use SSL?.
The SSL configuration options are explained in the online help associated with the
session dialog.
Click the question mark to display the online help.

TIBCO
ConnectionFactoryType
Connection Factory objects creates JMS connections for sending and receiving messages.
Topic
Publish and subscribe messaging. A message published to a topic is broadcast to
one or more subscribers. All messages published to the topic are received by all
services that have subscribed to the topic.
Queue
Point-to-point messaging. A message sent to a queue is consumed by one and
only one receiver. Each message has only one receiver though multiple receivers
may connect to the queue. The first receiver to access the queue gets the message.
The other receivers do not.
DeliveryMode
(Only available when JMS is selected as the transport type) The delivery mode for each
message sending operation.
Durable (see Persistent)
Non-Durable (see Non-Persistent)
Mode
The server mode.
Request Reply is the basic request-reply mode. The server subscribes to the
request and publishes the reply.
RPC allows you to configure an adapter to act as an RPC (remote procedure call)
server on behalf of a client.
WireFormat
The wire format in which data will be sent. Note that the wire format for both the
publisher and subscriber must be the same, otherwise an error will occur. See Wire
Formats for a description of these formats.
Rendezvous Message (TIBCO Rendezvous only)
XML Message (TIBCO Rendezvous or JMS)
ActiveEnterprise Message (TIBCO Rendezvous only)
UseCustomOperations
This checkbox appears when the Mode field is set to RPC. Selecting this checkbox and
clicking Apply creates the Call Operation Tab.
TIBCO
CallOperationTab
This tab appears when the mode is set to RPC and the Use Custom Operations box is
checked in the Request-Response Service Configuration tab.
Click New to enter data into the fields. After making changes, click Apply.
TIBCO Designer retrieves the signature of each stored procedure from the database.

If you change the stored procedure or database connection while editing your project,
you must return to this dialog and click Refresh to retrieve the changes from the
database.

Name
Enter a unique name for the call operation.
Catalog/Package
(Optional, only applicable to databases that have more than one catalog or package.)
The catalog or package in which the procedure resides. This name is used to resolve
naming conflicts if more than one catalog or package in the database has the selected
procedure with the same name. See your database documentation for more information
about catalogs and packages.
Schema
(Optional) The schema in which the procedure resides. This name is used to resolve
naming conflicts if more than one schema in the database has the selected procedure
with the same name.
ProcedureName
Name of the database procedure to call.
SelectProcedure
Queries the database for available procedures for the Procedure Name field. Clicking
this button displays a dialog showing the available procedures.
TIBCO

To select a procedure:
a. Select a call operation from the list on the left. Its input and output
parameters, if any, are displayed in the fields on the right side of the
dialog.
b. Click Select Procedure.
MaximumRows
(Optional) The maximum number of rows to retrieve.
Oneway
(Optional) Check this box if you want to execute this procedure using a one-way
operation. If left unchecked, the procedure will execute using a two-way operation.
Advanced Tab
Message Subject
Destination
(JMS transport type only)
The subscriber destination. A service uses a default destination generated using the
Domain and Deployment global variables, the adapter acronym, the adapter instance
name and the service name. If you use this default destination, make sure the values for
Domain and Deployment are not empty.
Alternatively, you can manually enter a destination in this field. The destination does
not have to be predefined in the TIBCO Enterprise Message Service server. The
destination can be static or dynamic.
See the TIBCO Enterprise Message Service Users Guide for information about destinations.

TIBCO
ReplySubject
Type a TIBCO Rendezvous subject name that the adapter uses to respond, if no
response subject is specified in the request message.
EndpointReference
Displays the endpoint reference. Click the Browse icon to change the endpoint reference
or the Go To icon to reconfigure the existing reference. You can also click the Delete
icon to remove the reference. Endpoint reference objects are explained in TIBCO
Designer Palette Reference.
ClassReference
Click the Go To icon to reconfigure the existing reference. Class reference objects are
explained in TIBCO Designer Palette Reference.
ExampleDescription
This example shows how the adapters publication, subscription and request-response
services can be used in TIBCO BusinessWorks to process a sales order. While processing
the order, the delivery priority assigned to sales items is changed and sales items are
verified to ensure the items are valid.
The BusinessWorks process calls a stored procedure that adjusts the priority of the items
on the sales order. The BusinessWorks process also calls a stored procedure that
validates each item on the sales order. If an item is invalid, it is rejected and the
adapters publication service deletes the invalid sales item. The following Business
Works activities are used in the example:
Subscribe to New Sales Order
The activity receives a message containing a new sales order from the adapter's
publication service.
Insert New Sales Order
The activity uses the adapter's subscription service to insert the new sales order
into the database.
Adjust Sales Order Priority
The activity invokes the ADJUSTPRIORITY operation of the adapter's request-
response service to adjust the priority of the sales order.
Update Sales Order Priority
TIBCO
The activity uses the adapter's subscription service to update the priority and
shipping notes of the sales order in the database.
For each Order Item (Group)
This grouping has two activities. The first activity invokes the
VALIDATESALESORDER operation of the adapter's request-response service to
validate each sale order item. The second activity use the adapter's subscription
service to delete the invalid sales order items from the database.
SetuptheExample
To setup the example you must run an SQL script that creates the schema and database
objects used in the example. You must also create a project in TIBCO Designer and
import the example project. After importing the project, edit it with account and service
information about your database connection.
The example setup uses the Oracle database. SQL scripts are also available for Sybase
(syb used in file names) and Microsoft SQL Server (ms used in file names).
1. Setup the database by running an SQL script using the database account used by
the adapter. In a command window:
a. > cd C:\tibco\adapter\adadb\5.3\demo\salesOrderDemo
b. > sqlplus userid/pswd@dbService @salesOrder_ora.sql
2. Configure the design-time and run-time connections in the project.
a. Start TIBCO Designer with a new empty project.
Import the demo project by clicking File>Import Full Project. In the Input
project window, select the Zip Archive tab. In the File field, click the
Browse button to select the demo project:
<install-
path>\tibco\adapter\adadb\5.3\demo\salesOrderDemo\salesOrderDe
mo.zip
b. Click Apply in the pop-up window.
c. In the project panel, expand Adapter Configuration then select
rvSalesOrderDemo. If you are using the JMS transport, select
jmsSalesOrderDemo.
d. Click the Design-time Connection tab and configure your design-time
connection parameters. Click Test Connection to verify the connection.
e. Click the Run-time Connection tab and provide your ODBC DSN
connection. Click Apply
f. Click Project>Save.

TIBCO
Start the JMS Server
If you are using the JMS transport, you must start the JMS server before testing the
example. Ensure that the JMS server is running and accessible to the machine on which
the adapter is installed before running any of the processes.
1. Open a command window and change directory to the JMS bin directory.
> cd C:\tibco\ems\bin
2. Start the JMS server. For example: tibemsd

TesttheExample
To run the example you first start the adapter using the TIBCO Designer Adapter
Tester, then step through the example using the TIBCO BusinessWorks Tester.
1. In TIBCO Designer, start the adapter:
a. Click Tools>Show Adapter Tester.
b. Select rvSalesOrderDemo. Or, if you are using the JMS transport, select
jmsSalesOrderDemo.
c. Click Start.
d. Click the Console tab to view adapter messages.
2. In the palettes panel, expand the Process Definition folder and select the Rv Sales
Order Demo, or the Jms Sales Order Demo.
3. In the buttons bar at top, click the Set Breakpoints icon.
4. In the window that appears, choose Select All, then click OK.
5. Click the Tester tab to the left of the project panel. The test panel replaces the
project tree.
6. Click the Start testing viewed process button.
7. In the process selection window that appears, the rv Sales Order Demo is selected
by default. Click Start Selected. The process is now in Test mode.
8. In a command window, insert a row into the source database table:
> sqlplus userid/pswd@dbService @insertSalesOrder_ora.sql
9. After the process starter is highlighted (indicating a process has started), click the
Step to next activity icon to step through the process.
10. Click the Stop Testing icon to return to design mode.
11. In the Adapter Tester, click Stop.
12. Close the Adapter Tester window and click Project>Exit to exit TIBCO Designer.

TIBCO
ExpectedResults
After running the example, the sales order is changed to contain only the valid sales
items. The priority assigned to each valid sales item is also changed.
A query of the original sales order shows the following entries:
select HEADER_NUMBER, PRIORITY, SHIP_NOTE from SO_HEADER;
1-1ABXYZ 2 Regular Shipping
select HEADER_NUMBER, LINE_NUMBER, SHIPPING_NOTE from SO_LINE;
1-1ABXYZ L-1ABXYZ Regular
After running the example, a query of the changed sales order shows the following
results:
select HEADER_NUMBER, PRIORITY, SHIP_NOTE from NEW_SO_HEADER;
1-1ABXYZ 1 Express Shipping
select HEADER_NUMBER, SHIPPING_NOTE from NEW_SO_LINE;
1-1ABXYZ L-1ABXYZ Urgent
1-1ABXYZ L-2ABXYZ Urgent

RuntheDatabaseCleanupScript
The cleanup script removes the example tables that were created when the
SalesOrder_databasevendor.sql script was run.
1. Change directory to the salesOrderDemo directory.
cd C:\tibco\adapter\adadb\5.3\demo\salesOrderDemo\
2. Execute the demo cleanup script to remove the example tables.
sqlplus userid/pswd@dbService @deleteSalesOrder_ora.sql
3. Clean up the database objects.
sqlplus userid/pswd@dbService @salesOrder_cleanup_ora.sql

TIBCO

TIBCO
Adapter
for Files

TIBCO
FILE ADAPTER
Overview
TIBCO Adapter for Files software processes data from text files and publishes the
contents in real-time to the TIBCO environment. The adapter also listens for messages in
the TIBCO environment and writes the contents to a file.
The adapter is compliant with the TIBCO ActiveEnterprise environment, and can be
used in conjunction with adapters and products that are compliant with this
environment, such as TIBCO Adapter for ActiveDatabase, TIBCO Adapter for Siebel,
and TIBCO IntegrationManager.
Figure 1 TIBCO Adapter for Files in operation

The adapter has two main components: design time and run time.
The design-time component allows you to configure the adapter and will store the
configuration in persistent storage. The run-time component uses this configuration to
perform appropriate tasks.
Various aspects of configuration and their semantics are discussed in detail later in the
manual
The adapter supports only text files when it is integrating a file system into the TIBCO
ActiveEnterprise environment. It supports both text and binary files when it is
transferring files between two or more TIBCO Adapter for Files installations.

TIBCO
AdapterFeatures
This section provides a brief overview of the adapters features. These are discussed in
detail later in the manual.
The adapter provides the following features:
AneasytouseGUIforconfiguringtheadapter The adapter provides its own design-
time component, namely the adapter palette, which seamlessly integrates with TIBCO
Designer. This easy-to-use interface allows you to quickly configure adapter-specific
features; it also validates some configurations.
Support for defining schema An important palette operation is defining schema.
Schemas capture the rules and relations that are used by the run-time component to
process the contents of a file during publication or write data into a file during
subscription.
Supportforglobalization The adapter supports data containing date and time as type
date and time. It also provides support for various locales.
Support for dual message transport The adapter supports two popular message
transports, TIBCO Rendezvous and JMS.
Filerecognition The adapter provides options to selectively recognize files that need to
be processed for publication.
Support for invoking external scripts The adapter allows you to run external scripts
on the files that are being processed.
External process call out capability The adapter allows you to process the message
before being published or subscribed.
Restartcapability The adapter provides restart capabilities when publishing files.
Performance tuning The adapter provides configuration options for performance
tuning.
Flow control The adapter supports flow control so that the publication service can
cater to slower consumers.
Adapterspecificmicroagent In addition to the standard microagents that are available
with any ActiveEnterprise-compliant adapter, the adapter provides its own microagent.
This microagent provides methods for getting basic processing-related statistics as well
as methods for getting and setting some configuration parameters at run time.

TIBCO
AdapterServices
The adapter provides a publication service and a subscription service. The publication
service processes data from text files and publishes the contents in real-time to the
TIBCO environment. The subscription service listens for messages in the TIBCO
environment, processes the received messages, and writes the contents to text files.
Typically, an adapter configuration contains one or more publication services, one or
more subscription services, or both.
FileAdapterVSBWFilePalette
The Objective of this document is to provide guidance on the use and feature
comparison of TIBCO Adapter for Files and Business Works File Palette. Listed features are
driven primarily on type of connectivity, ease of use, ease of integration, monitoring,
and management.
Feature Adapter BW Palette
Ease of
Integration
Adapter consists design time
and run time environments,
which are to be managed
separately.
File palette does not require
separate run-time and design-time.
Completeness Not optimal for XML files
Support pre and post event
script processing
File palette can handle XML file
effectively, can handle
script/custom code execution
File Mode The adapter supports text files
*supports both text and binary files
in file transferring mode
Palette has a lot more flexibility and
support both Text and Binary
mode.
Operating Mode Not optimized for directory
polling and dynamic binding.
Adapter supports asynchronous
mode
Support directory polling and all
other basic file operations
Consistent error
viewing and
handling
Adapter are written using SDK
and strictly adhere to standard
error viewing and handling.
Thereby making monitoring
easy.
Palette provides error objects and
rules have to be written for error
viewing and handling.
Transactions
Volume
Adapters are useful in high-to-
medium load situations. File
adapter can operated to send
data in a batched mode
More geared towards reading the
whole file and scales well.
Connectivity
Design Time
Adapter Design Time Agent BW environment
Connectivity
Run-Time
Adapter Run Time Agent BW environment
Ease of Data
Transformation,
parsing and
mapping
Data is transformed to desired
protocol format (JMS etc) at the
source. Parsing and mapping
takes place in process flow.
Data transformation, Parsing and
mapping takes place in process
flow.
TIBCO
Ease of
Monitoring
Adapter enabled with Hawk
framework (admin) deployed as
a service has much fine grain
monitoring, configuration &
management than File activity.
Palette monitoring can be handled
as embedded component in the
process.
Component
Management
Adapter is deployed as separate
component from the process
and requires management.
Palette is embedded in the process
along with data parsing, mapping
etc. and does not require separate
deployment
Protocol support TIBCO EMS TIBCO EMS
Smart
Publishing
On a slower consumer, Flow
controls may be configured to
control publishing rate.
In such a case palettes rely on
design of the process
Check Point The adapter publication service
offers the facility to restart
processing and publication from
where the publication service
left off, just before exiting
normally or abnormally.
File palettes may use checkpoints
tasks/activity of BW.
Duplication of
Messages
When the publication format is
set to MInstance there is a
possibility of getting a duplicate
message depending on when
the adapter had exit.
File palette provides better options
to avoid message duplication.
Outbound Scenario BW File Palette
The figure shows the outbound communication from the file system to EMS. This is a
scenario, which requires polling of the directory to see new files. Using an BW File-
Poller is preferred over TIBCO Adapter for Files using due to following capabilities:
Polling capability of File palette
Support provided for binary and text files

TIBCO
Getting Started With File Adapter

This chapter discusses the steps involved in configuring the adapter using the adapter
palette, which seamlessly integrates with TIBCO Designer, and the steps involved in
deploying and running the adapter.
Repository
The TIBCO ActiveEnterprise infrastructure provides a repository for compliant
applications to create, store, and retrieve all the necessary configuration.
The adapter design-time component uses this facility to store all the configuration
information for the adapter. The run-time component, namely the run-time adapter uses
the repository to retrieve all the configuration information needed and perform the
desired task.
TypesofRepository
There are three types of repository that can be created. They are:
Local Repository
Remote Repository
Multi-File Repository
All the three types of repository fundamentally allow storage and retrieval of
configuration information.
Typically, in an application integration scenario a single repository will be used and all
TIBCO compliant applications will use that repository to store and retrieve the
configuration information. Therefore, the first step in configuring a TIBCO compliant
application is to identify if a repository already exists or a new repository should be
created.
TIBCO
ConfiguringtheAdapter
Configuring the adapter involves deciding whether to use an existing repository or to
create a new repository.
UsinganExistingRepository
1. Start TIBCO Designer and click the Administration tab. Click Convert Dat to
Files.

The Convert DAT To File-Based Project dialog box is displayed.
2. Enter the required information and click OK. TIBCO Designer converts the dat
file to a project.

3. Click the Project tab and click Open Existing Project. The Open Project dialog
box is displayed.
4. Browse to the location you specified in step 2 and select the project. Click OK.
TIBCO
You have now successfully opened the repository.

CreatingaNewRepository
1. Start TIBCO Designer and click New empty project. This opens a new repository.

TIBCO
2. Click Project > Save. The Save Project dialog is displayed.

3. Enter the appropriate information and click OK.
You have now successfully created a repository.
CreatinganAdapterConfiguration
An adapter configuration can be created by selecting the project name in the project
panel and then dragging and dropping the File Adapter Configuration icon from the
palette panel into the design panel.

Configuration options are available for the adapter at the instance level. The
configuration parameters at the instance level apply to all the services that are part of
the configuration.
TIBCO
CreatingServices
An adapter configuration can consist of the publication service and subscription service.
Desired services can be created by highlighting the Adapter Services folder, and then
dragging and dropping either the Publication Service or the Subscription Service from
the palette panel into the design panel.
ConfiguringtheServices
Configuring the services is an important part of the adapter configuration. The steps for
configuring the publication or the subscription service is dependent on the operation
mode.
In the record mode of operation, creating the ReadSchema and the WriteSchema for the
publication and subscription service and associating them with the service is important.
In the simple file transfer mode of operation, setting the parameters for the file transfer
options is important.
For the record mode and the simple file transfer mode, the publication and subscription
services offer a wide variety of configuration options. Some of them are specific to the
mode of operation and others are common to both the modes of operation.
After configuring the services and saving the repository, the adapter configuration is
ready for use by the run-time adapter.
ConfigurationSequenceintheRecordMode
PublicationService
1. Create and design the ReadSchema.
2. Associate the ReadSchema(s) to the publication service using the services's
Schema tab.
3. Enter appropriate information for the publication services Configuration,
Processing, Encoding, Transport, and Advanced tab.
SubscriptionService
1. From an existing wire schema, generate the WriteSchema.
2. Edit the WriteSchema.
3. Associate the WriteSchema(s) to the subscription service using the services
Schema tab.
4. Enter appropriate information for the subscription services Configuration,
Processing, Encoding, Transport and Advanced tab.
TIBCO
ConfigurationSequenceintheSimpleFileTransferMode
PublicationService
1. Begin with the SFT tab and set the desired file transfer configuration.
2. Enter appropriate information for the publication services Configuration,
Processing, Encoding, and Transport tab.
SubscriptionService
1. Begin with the SFT tab and set the desired file transfer configuration.
2. Enter appropriate information for the subscription services Configuration,
Processing, Encoding, and Transport tab.
DeployingandExecutingtheRuntimeAdapter
The run-time adapter uses the repository and the adapter configuration information to
create the necessary publication and subscription services.
For successfully running the run-time adapter, the environment needs to be set
correctly, and the repository information and adapter configuration information needs
to be provided.
The recommended way to execute the run-time adapter is to specify a run-time
configuration file known as the TIBCO Runtime Agent file (because the suffix of the file
is tra).
The installation program generates the TIBCO Runtime Agent file for the TIBCO
Adapter for Files, and is called the adfilesagent.tra. On Windows, if the TIBCO Runtime
Agent file generated by the installation program is copied and used by the run-time
adapter (with the appropriate modifications) it will take care of setting the required
environment for the adapter to run. On Unix, while it takes care of most of the required
environment settings, some environment variables need to be set before running the
adapter.
The TIBCO Runtime Agent file consists of name-value pairs that the run-time adapter
will interpret during run-time. The most important name - value pairs in the TIBCO
Runtime Agent file are:
tibco.repourl -- Specifies the repository (local or remote)
tibco.configurl -- Specifies the adapter instance or configuration.

TIBCO
The run-time adapter can work with a local or remote repository. However, if
you chose the Multi-File repository during design-time, it should be converted
into either local or remote.
.

On Windows, if the TIBCO Runtime Agent file that is created by the installation
program is used as the template it will set the environment required for the adapter to
run.
On Unix, while most of the environment is set by the generated TIBCO Runtime Agent,
some of the environment variables need to be set before running the adapter.
The installation program generates the adfilesagent_env.csh (or adfilesagent_env.sh)
under the File Adapter home/bin to set the environment variables that cannot be set by
the TIBCO Runtime Agent, and to facilitate TIBCO Administrator to deploy the adapter
on UNIX platforms. When running the adapter from the command line, the appropriate
script file needs to be sourced.

TIBCO

TIBCO
Adapter
for
MQSeries

TIBCO
MQSeries Adapter
Overview
TIBCO Adapter for MQSeries facilitates message flow between MQSeries applications,
TIBCO applications such as TIBCO IntegrationManager or other adapters, and
compatible third-party applications such as a JMS-enabled application. The adapter
takes messages received from applications, transforms the message if necessary, and
then places this data on an MQSeries queue where it can be accessed by MQSeries
applications. Conversely, the adapter extracts data from an MQSeries queue and
converts it into a TIBCO wire format for consumption by external applications that
subscribe to this data. Request-Response interactions are also supported between
TIBCO-enabled applications, such as TIBCO Rendezvous and TIBCO Enterprise for
JMS, and MQSeries.
AdapterFeatures
The following features are described in detail throughout this manual.
EasytoUseGUI
The adapter is configured using TIBCO Designer, which provides an easy-to-use
graphical user interface that allows you to quickly specify operational parameters or
change them as needed.
AdapterServices
The following services are supported:
Publication Service Gets MQSeries messages and sends them to applications
configured for the TIBCO environment.
Subscription Service Gets TIBCO messages and puts them on the MQSeries
queue.
Request-Response Service Gets requests from applications configured for the
TIBCO environment, sends them to MQSeries and then routes the response back
to the applications.
Request-Response Invocation Service Gets requests from MQSeries
applications, sends them to applications configured for the TIBCO environment,
waits for responses and forwards the responses to the MQSeries application.
DataFormatConversions
A key operation of the adapter is converting MQSeries data formats to TIBCO wire
formats and vice versa. The adapter supports:
Standard data format conversions between the most widely-used TIBCO wire
formats and MQSeries formats.
TIBCO
Custom data format conversions. These custom conversions accommodate
messages that originate or are destined for consumption by applications outside
the TIBCO and MQSeries environments..
MultithreadedCapability

The adapter is multi-threaded by default. However, you can run the adapter in single-
threaded mode by modifying the property defined in the adapter properties file that
specifies that the adapter should run in single-threaded mode.
In the multi-threaded mode, the adapter can process concurrent requests. When the
adapter is operating as a request-response server or as a subscriber, it handles
concurrent requests differently from the way it handles them when it is operating as a
request-response client or as a publisher.
When Operating as a Request-Response Service or Subscriber
The adapter gets requests concurrently from multiple applications configured for
the TIBCO environment and uses multiple threads to efficiently process these
requests. Each thread has its own connection. The adapter maintains a pool of
connections to the MQSeries queue manager. Using the TIBCO-enabled
application dispatcher, the adapter routes these concurrent requests to the
MQSeries application.
When Operating as a Request-Response Invocation Service or Publisher
The adapter has a multi-threaded polling component and can listen for multiple
concurrent message queuing events from MQSeries applications. You can
configure the polling interval for each MQSeries queue when you configure the
adapter service. The adapter retrieves messages from the MQSeries queue at the
specified polling interval.
SchemaSupport
TIBCO environment messages are defined using schema. The adapter uses these to
describe data received from or sent to a TIBCO-enabled application. You can define a
schema, and then point to that schema from the adapter. The adapter will apply the
schema to messages received from MQSeries queues.
Schemas are not specifically linked with one adapter instance. Instead, they reside in the
public area of the repository and are available to any adapter instance that needs them.
As a result, multiple adapter instances can be updated when a change is made to a
single schema. For example, if you have specified schema for a Purchase Order, the
adapter can validate an incoming message against the schema before passing the
message to MQSeries, and then send the message as an instance of the schema. The
adapter will also pre-validate data on a queue and build a message using the schema
information. Changes made to the Purchase Order schema are localized and do not
affect services and other internal objects stored in the repository.
TIBCO
With the ActiveEnterprise and XML wire formats, you can configure a schema to
describe the structure of messages processed by the adapter. The schema is stored in a
repository managed by TIBCO Administrator Repository Edition. This feature is
especially useful in a variety of situations, for example:
Where several programmers collaborate on an adapter application, a
specification document normally defines the data model for several related
adapter applications. Inside the TIBCO framework, you can define a schema to
serve as the data model and update it as needed.
When the data model of the adapter application changes, you do not have to
reconfigure the adapter service. Instead, you change the schema class.
When the adapter is installed, pre-created schema is available to you. You can use this
schema when you configure the adapter service.
DistributedQueueSupport
A distributed queue is a group of cooperating transport objects, each in a separate
process. Each transport object is called a member. To balance the transmission load
among servers, the adapter can use distributed queues for one-of-n delivery of messages
to a group of servers. Each member of a distributed queue must listen for the same
subject using the TIBCO Rendezvous Distributed Queue listener objects. Even though
many members listen for each inbound message (or task), only one member processes
the message. For details on distributed queues, see TIBCO Rendezvous Concepts.
In the queue mode within TIBCO Enterprise for JMS, each listener is a single receiver of
a point-to-point message. However, the listeners can be configured as a set of receivers,
each of which receives a fraction of the messages. Fault tolerance is also available
because when one listener fails, other listeners take over.
Load balancing for the processing of TIBCO Rendezvous or JMS certified messages to
MQSeries is supported by using distributed queuing. The messages from TIBCO
Rendezvous or TIBCO Enterprise for JMS are distributed equally among all instances
that belong to the same group. This distributes the message load over several adapter
instances. However, the order in which messages are sent to the MQSeries application is
not guaranteed.
UserspecifiedMQSeriesMessageQueueOptions
You can specify the type of MQSeries queue access (for example, shared or exclusive),
priority, message lifetime, persistence, message ID, Correlation ID, Coded Character Set
(CCS) ID, and so on.
Queue options can be specified while putting messages on queues or while getting
messages out of queues. For example, you can specify whether messages retrieved from
an MQSeries queue should be marked as read or removed from the queue when you
configure the adapter instance.

TIBCO
BatchProcessing
For publication and request-response invocation services, you can configure the adapter
to group messages into a single batch for processing.
SupportedMessageTypes
The adapter supports the following MQSeries message types while placing messages on
a queue:
MQMT_DATAGRAM indicates that no reply is expected from the receiving
application.
MQMT_REQUEST indicates that messages will be requests and that the receiving
application will send a reply.
MQMT_REPLY indicates that messages to be processed will be replies.
MQMT_REPORT indicates that messages will be used for reporting errors.
Custom Message Types indicates that you can enter a custom message type in the
range of 65536 to 999999999.
SupportedandNonSupportedMessageFormats
The message format specifies the format that will be applied to messages processed by
the adapter. The adapter supports all MQSeries message formats while receiving
messages from a queue.
The adapter supports the following message formats while placing messages on an
MQSeries queue:
MQFMT_NONE
MQFMT_ADMIN
MQFMT_CHANNEL_COMPLETED
MQFMT_COMMAND_1
MQFMT_COMMAND_2
MQFMT_PCF
MQFMT_STRING
MQFMT_IMS_VAR_STRING
MQFMT_EVENT
MQFMT_IMS
The adapter does not support the following message formats while placing messages on
an MQSeries queue:
MQFMT_CICS "MQCICS"
MQFMT_DEAD_LETTER_HEADER "MQDEAD"
MQFMT_DIST_HEADER "MQHDIST"
MQFMT_MD_EXTENSION "MQHMDE"
MQFMT_REF_MSG_HEADER "MQHREF"
MQFMT_RF_HEADER "MQHRF"
MQFMT_RF_HEADER_2 "MQHRF2"
TIBCO
MQFMT_TRIGGER "MQTRIG"
MQFMT_WORK_INFO_HEADER "MQHWIH"
MQFMT_XMIT_Q_HEADER "MQXMIT"
If you need to use a format that is not supported, you must write a custom conversion
function to set the required format..
SupportforIMS
The adapter provides support for the Information Management System (IMS) Message
format. The MQSeries-IMS Bridge provided by IBM allows MQSeries applications to
interact with IMS applications and vice versa.
The adapter supports the message formats MQSeries applications use while exchanging
data with IMS applications.
SupportforCorrelationofRequestandResponseMessages
You can configure client and server processes to correlate requests and responses.
Support for correlating request messages with response messages provides you with the
flexibility of specifying correlation options for reply messages. The adapter uses this
correlation to map the response message from MQSeries applications within the
specified time limit.
SupportforDynamicReplyQueues
The adapter dynamically retrieves the reply queue name from the request queue
header. The adapter also retrieves static queue names that are specified when the
adapter is configured.
SupportforDualMessageTransports
The adapter supports the following message transports:
TIBCO Rendezvous Transport This transport uses subject-based addressing to
provide support for both multicast or broadcast and point-to-point
communications. You can configure the wire format and the delivery modes of
the messages when you configure the adapter service.
JMS Transport TIBCO Enterprise for JMS must be installed to use the JMS
transport. The JMS administration interfaces allow you to create and manage
administered objects such as Connection Factories, Topics, and Queues. JMS
clients can retrieve references to these objects by using Java Naming and
Directory Interface (JNDI). Creating static administered objects allows clients to
use these objects without having to implement the object within the client. When
a JMS client starts, it performs a JNDI lookup for the connection factories that it
needs. For details on JNDI, see the TIBCO Enterprise for JMS Users Guide. You can
configure the connection factory type and the delivery mode used when you
configure the adapter service.
TIBCO
MQSeriesFeatures
This section describes terms that will help you understand the MQSeries environment.
Message
A message is a string of bytes that is used to transfer data between two applications.
Messages may or may not require a response from the application receiving it. A
message consists of two parts:
Message descriptor This identifies the message and contains other control
information, such as the type of message and the priority assigned to the message
by the application sending it.
Application data The content and structure of this part of the message is
defined by the application programs that use the data. MQSeries 5.2 supports
messages that are up to 4 MB in size and WebSphere MQ 5.3 supports messages
that are up to 100 MB in size.
The adapter can send messages to an MQSeries queue and receive messages from an
MQSeries queue.
QueueManager
The run-time component in MQSeries is the queue manager. A queue manager owns
and manages queues and is responsible for putting the messages it receives onto the
appropriate queue. The queue manager provides the MQI to enable applications to
access the queues and the messages contained in them. Application programs invoke
functions of the queue manager by using API calls.
Queue
A queue is a data structure in which messages are stored. Queues exist independently of
the applications that use them. Message queuing is the process of placing messages on a
queue. The messages are held in the queue until they are processed. Queues are objects
that belong to a queue manager. You can configure queues using MQSeries Explorer.
When you are configuring the adapter, you can specify the queues that you have
configured.
You can define different queues to send and receive messages. Some of the MQSeries
queues are:
Local queue Is a queue that is owned by the queue manager to which the
application program is connected. This queue is used to store messages for
programs that use the same queue manager.
Remote queue Is a structure that contains the characteristics of a queue that is
hosted by a different queue manager.

TIBCO
Alias queue Is a queue that can be used to access other queues. Multiple
applications can work with the same alias queue because the applications will
access the queue using different names and attributes.
Dynamic queue Is a queue that is created when the application needs it.
Dynamic queues can be retained by the queue manager or automatically deleted
when the application program ends.
You can specify queue and error queue names when you are configuring the adapter.
Channel
A channel provides a communication path to a queue manager. A queue manager
exchanges messages with other queue managers via channels. A channel is called the
sender on the source platform and the receiver on the destination platform. The sender
channel definition contains connectivity information such as the destination platform
name or IP address.
There are two kinds of channels:
Message channels One-way channels that are used to connect two queue
managers on the same, or different platforms. If two-way communication is
required between the queue managers, two message channels must be used.
MQI channels Two-way channels, also known as client channels, that connect
the MQSeries client to a single queue manager running on a server machine.
You can specify channels in MQSeries Explorer when you are creating a queue
manager. For details on creating channels, see the MQSeries Systems Administration
documentation.
Cluster
A cluster is a named collection of queue managers that requires at least one of the queue
managers in the cluster to be defined as the repository. The cluster information is stored
in the repository. You can define a cluster using MQSeries Explorer.
MQSeriesClient
An MQSeries client accepts MQSeries calls from applications and passes them to an
MQSeries server. An MQSeries client does not have a queue manager of its own and
shares a queue manager that is on a server with other MQSeries clients.
TIBCO
MQSeriesServer
An MQSeries server is a queue manager. All MQSeries objects exist only on the
MQSeries server machine. The difference between an MQSeries server and an ordinary
queue manager is that the MQSeries server can support MQSeries clients. Typically, the
MQSeries client and server reside on different machines, However, they can also exist
on the same machine. The adapter interacts with the MQSeries queue manager. You
must provide the queue manager name when you are configuring the adapter. You can
specify the queue manager name in the Queue Manager field under the Configuration
tab of the adapter instance.
AdapterServices
TIBCO Adapter for MQSeries consists of the adapter services shown in the following
figure.
Figure Adapter Services

TIBCO

StartedWithMQSeriesAdapter
CreateaProject
The TIBCO Designer GUI is used to configure adapter instances. When starting
Designer, you must create or select a project. A project contains the configuration files
that define options used by a run-time adapter. After a project is configured, it is
converted to a repository file and available for use by the run-time adapter.
To create a project:
1. Start TIBCO Designer by executing the following command, depending on your
operating system.
On Microsoft Windows, select: Start > Programs > TIBCO > TIBCO Designer
5.1 > Designer 5.1.
On Unix, from a command window change directory to the <install-
path>/TIBCO/designer/5.1/bin directory and type ./designer
2. In the TIBCO Designer dialog, click New empty project.

TIBCO
3. In the Save Project dialog, select Multi-File Project (if it is not selected) and click
the Browse button. As shown in the next diagram, navigate to the
<Adapter_install_path>\examples folder and click the Create New Folder icon.
Name the new directory MQSeriesConfig and click OK. The project for the
example will be saved in the MQSeriesConfig directory. In the Save Project
dialog, click OK.
4. The following figure shows the TIBCO Designer GUI with the MQSeriesConfig
project defined.

TIBCO
ConfiguretheAdapter
An adapter instance can contain publication services, subscription services, request-
response invocation services, or request-response services, or all services. Options for
logging, startup, and monitoring are set on the adapter instance. In this exercise, default
values are used for these options.
To configure the adapter instance:
1. Drag the MQSeries Adapter Configuration icon from the palettes panel to the
design panel. This creates an adapter named by default,
MQSeriesAdapterConfiguration. In the Configuration tab, the name can be
changed, but in this exercise, names assigned by TIBCO Designer will be used.

2. Click the Logging tab to identify the file log options.
In the next diagram, Information, Warning, and Error messages are specified to
be logged to the log file and standard input. The Log File field lists the global
variables that are used to define the log file path and name. The DirTrace and
Deployment variables are set using global variables. You can click the Global
Variable tab to display the variables in the project panel. The default settings will
be used in this example. The InstanceId variable need not be set. The variable
automatically substitutes the adapter name at run-time.
TIBCO

ConfigureaService
The next step in the configuration process requires you to configure an adapter service
that will perform the publication, subscription or request-response data passing
operations for the adapter. For example, here you will learn how to configure a
publication service using the COBOL Copybook format to TIBCO wire format message
conversion for the adapter.
To add a publication service:
1. Double-click the Adapter Services folder in the file tree.
2. Drag the Publication Service icon from the MQSeries resource area to the main
window.

TIBCO
The following screen example shows a publication service with all the tabs that
are available for configuration:

3. Click the Configuration tab and enter the name of the queue in the MQ Queue
Name field, which will be used to communicate with MQSeries applications.
4. Click the Conversion tab and select the CobolCopybook MQ to TIB Message in
the Conversion Type box.
5. To specify the class associated with the Copybook data that has already been
imported into a schema, use the Class Reference Browse button. You could also
import the contents of a Copybook into a schema if required.
6. Click Apply.
7. Click Project > Save to save the project information.
A sample TIBCO Repository instance (admqsDemo.dat) file is provided in
$TIBCO_ADMQS_HOME/demo/. You can use this to see how a publication
service will operate when using the CobolCopybook MQ to TIB Message
conversion.

TIBCO
You can add a subscription service, request-response invocation service, and request-
response service in the same way as you added the publication service.
Before running the adapter, you must convert the multi-file project to a repository file
and edit the run-time adapter property file with the project name and adapter
configuration name. This is explained in the next sections.

ConverttheProjecttoaRepositoryFile
The project will be run as a local repository and must be saved in DAT (repository)
format for use by the adapter.
To export the project to a local repository:
1. Start TIBCO Designer and click the Project > Export Full Project.
2. Click OK in the Export Project dialog box.
3. Click Yes in the Create Project? dialog box. The project will be converted to a
repository file.

RuntheAdapter
After you have completed the configuration, you can modify the properties file with the
project name and adapter instance, then start the run-time adapter.
If you are using TIBCO Designer, you can also use the Adapter Tester to run the
adapter. However, you must make sure that the adapter and TIBCO Designer are
installed on the same machine.
While running the adapter, if the JMS server stops, you must restart the adapter after
the JMS server starts again.

TIBCO

SAP R/3
adapter

TIBCO
SAP R/3

The purpose of SAP R/3 adapter is to esatablish a connection or communication
between SAP R/3 systems to TIBCO system. SAP is a built in ERP package. It is the top
most ERP package in the world. The data migration between to your SAP system to out
side system like People soft Oracle Apps. In between we are using this TIBCO

We want to data migration transfer between to SAP to SAP is we have to two methods
BDC,LSMW .SAP to non SAP we have ALE,BAPI, RFC
ALE means application linking enabling
BDC means batch data communication
LSMW means legassy system migration work bench
In ALE we have 2 methods are avaible
1. SAP to SAP This is not consider in ALE
2. SAP to non SAP

SAPtononSAP:
By using this ALE we can create the IDOC means (INTERMEDIATE
DOCUMENTATION)
This IDOC is a container which is understandable by sap system only.

ALE

XML Sibel adapter

SAP R/3 is called three- tier architecture
SAP R/2 is called client/server architecture
These 2 are versions in SAP adapter
ALE, BAPI, RFC These 3 is SAP R/3 methods

BAPI(Business Application Programming Interface)
Heading this BAPI we can create an object. The object is transfer to your
destination system directly

RFC (Remote Function Calls )
By using this RFCs we can create the function calls . that function module create
the table and then send to the destination

SAP R/3 SIBEL IDOC TIBCO
SAP means system application & products for data processing
ABAP Advanced Business Application Program
TIBCO

TIBCO
Administrator

TIBCO
TIBCO Administrator

Overview

TIBCO Administrator allows administrators and end users to manage authentication
and security, configure and deploy applications, manage and monitor deployments, and
view information about running processes and machines in an administration domain.
The following modules are provided in the TIBCO Administrator GUI to manage users,
resources and applications:

User Management
Resource Management
Application Management

UserManagement

This module allows you to create users and roles and assign them access rights to
resources available in the administration domain.
An administration domain can be integrated with an LDAP directory server where
users and groups are defined in an LDAP directory and imported into TIBCO
Administrator.

UsersYou can create users and assign them into roles, which allow easier
administration. You can also set read, write or administer permissions so a user can
directly access TIBCO Administrator modules and consoles, and domain and
application repositories.
RolesAccess control is easier when roles are used. You can assign multiple users
into roles and then assign permissions for the role.
SecurityEach resource in an administration domain can have users or roles assigned
to it. The security level setting determines who can access the resource and at what
access level.

TIBCO
ResourceManagement

This module allows you to create application domains, get information about installed
TIBCO software on each domain machine, view the status of each domain machine, and
configure monitoring rules and events that can trigger other actions such as sending
email or running a command.

Application DomainsIf your TIBCO application supports this feature, you can
create multiple application domains and assign applications to them. An application
domain allows you to specify that application data be written to a repository that is
separate from the repository used by the administration domain. This is useful, for
example, if an application needs to use a local database rather than that used by the
Installed SoftwareYou can view TIBCO applications that are running on each
machine in the domain and enable or disable applications.
MachinesEach administration domain contains one or more machines. You add a
machine to an administration domain using the TIBCO Domain Utility.

ApplicationManagement

This module allows you to upload an applications Enterprise Archive (EAR) file and
optionally change runtime options and global variables that were set for the application
when it was configured. You can also define monitoring rules for each application. You
then deploy the application and start (or stop) it.
The next diagram shows the TIBCO Administrator GUI with the application
management module displaying its contained consoles. An application is selected and
the configuration builder in the right panel displays the application, its service and
service instance.

Clicking an application name allows you to change global variable values set for the
application when it was configured in TIBCO Designer. You can also specify the
transport the client application will use when communicating with the administration
server. Alternatively, you can specify that the applications repository be sent to the
target machine, which allows the application to run independently of the administration
server.
TIBCO
Clicking the service name allows you to set monitoring options and other runtime
properties.
Clicking the service instance name allows you to set logging options, whether to run
as the instance as a service on Microsoft Windows, and shutdown options.

TIBCO Administration Domain

After you install TIBCO Administrator, the installer starts TIBCO Domain Utility to
create the initial administration domain. An administration domain is a collection of users,
machines, and services. It is managed by a administration server, which is assisted by a
TIBCO Hawk Agent running on each machine in the administration domain. You can
create multiple administration domains on the same machine. In that case, each domain
must have a primary administration server associated with it.

For example, the next diagram shows an administration domain with three machines.
Each machine has TIBCO Runtime Agent installed and a TIBCO Hawk Agent running.
One machine has an adapter installed, another TIBCO BusinessWorks and the other
machine has the administration server installed. The browser-based TIBCO
Administrator GUI can be run from any machine, including machines not in the
domain.
TIBCO

AdministrationServer

An administration server manages resources in an administration domain. Each domain
has its own administration domain. The administration servers main responsibilities
are to:

Manage data storage for the domain and applications.
Storage can be in a file-based repository, or in a database repository. Domain storage
options are specified when creating the domain. Application storage options can be set
when creating the domain and modified per application when deploying the
application.

Enforce security for the domain.
Only authorized users are allowed access to applications during development. TIBCO
Administrator supports both authentication and authorization of users that want read
access or write access to applications.

Provide load balancing.
Each domain can be configured with one primary server and multiple secondary
servers. The primary server allows read and write operations, while secondary servers
only support read operations. Only one primary server can be running for each
administration domain. Multiple secondary servers are allowed, but each must be on a
different machine than the primary server. Secondary servers are defined using TIBCO
Domain Utility.

Provide failure recovery.
You can use a load-balanced server for failure recovery, where secondary servers
continue serving requests even with the primary server down.

TIBCO
TomcatWebServer

The Tomcat web server manages basic communications and makes the TIBCO
Administrator GUI available. The ports used by the Tomcat web server can be
configured when using TIBCO Domain Utility to create the domain, or later changed if
required.

TIBCOHawkAgent

TIBCO Hawk Agent is an autonomous process that monitors applications and systems
activity. Each administration server has a corresponding TIBCO Hawk Agent. The
Hawk Agent monitors activity by processing rulebases, which hold the logic that
determines how monitoring and management will take place. The Hawk Agent also
builds local properties files and executable files for deployed applications, and creates
NT services for applications.

A Hawk Agent runs on the machine that hosts the administration server and on each
machine that is part of the administration domain.

TIBCORuntimeAgent

TIBCO Runtime Agent provides the runtime environment required for TIBCO
applications. It includes many software tools including TIBCO Domain Utility, TIBCO
Designer, TIBCO Rendezvous as well as libraries used by many TIBCO applications.
Command line utilities used by TIBCO Administrator are included in the TIBCO
Runtime Agent installation.

Utilities,PluginsandModules

TIBCO Administrator includes several utilities, plug-ins and modules that are
introduced in this section.

TIBCODomainUtility

The TIBCO Domain Utility is part of the TIBCO Runtime Agent installation. The utility
is launched directly after installing the administration server and is used to create the
initial administrator domain. You can start the utility at any time to manage domain
machines, domain configurations, administration server settings, upgrade
administration domains and register a TIBCO Enterprise Message Service server.

TIBCO
ScriptingDeploymentUtility

Two scripting utilities are available, builder and AppManage. The utilities allow you to
perform the functions available in TIBCO Administrator, but from the command line.
This allows you to execute script you have written to perform repetitive tasks.

The builder utility builds an enterprise archive file based on an archive defined in a
TIBCO Designer project. You provide the location of an archive resource in Designer,
location of the Designer project and location of the output enterprise archive file to the
builder utility. You can optionally save an archive version to the project when building
the enterprise archive file.

The AppManage utility creates an XML based deployment configuration file where
deployment options can be defined. The utility also uploads the deployment file and
enterprise archive file into an administration domain. It can be used to:

Create a deployment configuration file based on information in an enterprise archive
file, or from an application already configured in TIBCO Administrator.

Upload an enterprise archive file to an administration domain without specifying
deployment configuration options. After the file is imported, it is ready to be configured
with deployment options and deployed using TIBCO Administrator.

Upload an enterprise archive file and a deployment configuration file into an
administration domain in one operation. The application is uploaded with its
deployment options set, but is not deployed.

Upload an enterprise archive file and a deployment configuration file and deploy the
application in one operation. Using this method, you can quickly deploy your
applications in multiple domains.

Export all application archives and deployment configuration files within a domain,
so they can be batch deployed, undeployed or deleted in another domain.

Undeploy a deployed application.

Delete an application from an administration domain. If the application is deployed,
you can undeploy it and delete it in one operation.

Start an applications process engines or service instances

Stop a successfully deployed process engine or service instance.

TIBCO
CommandLineUtilities

The following commands are used from the command line

Command Description
CorpRoleSynchronizer

Syncs an administration domain with
its associated LDAP directory.
CorpUserSynchronizer

Pre loads user objects into an
application.
ExportDomainSecurity

Exports security data from a domain.
This includes users and roles.
ImportDomainSecurity

Imports security data into a domain.
MigrateDomainStorage

Migrates domain data stored in a file-
based repository to a database.
MoveMachine

Moves a domain from one machine to
another.
RedeployAllAppsForUser

Updates password changes to all
deployed applications in a given
domain.
RepoConvert

Converts back and forth between
single-file (.dat) and multi-file projects.
RepoManager

Launches the Repository Manager
utility.
RepoPing

Checks whether an administration
server is running and communicating.

TIBCOEnterpriseMessageServicePlugin

The TIBCO Enterprise Message Service plug-in (EMS plug-in) allows you to use TIBCO
Administrator to configure a TIBCO Enterprise Message Service server. The EMS plug-
in is included in your TIBCO Administrator installation.

The EMS plug-in includes online help files that describe each parameter that can be set
from within TIBCO Administrator. You should be familiar with the TIBCO Enterprise
Message Service documentation, which explains full use of the server.

You must first install the TIBCO Enterprise Message Service server, and then run TIBCO
Domain Utility to add the EMS plug-in to your administration domain. After the EMS
plug-in is installed, you access it from TIBCO Administrator by clicking Application
Management > All Services Instances >
<machine-name>-E4JMS<port>.

The next diagram shows the location of the EMS server in the TIBCO Administrator
GUI.

TIBCO

The users and roles defined in your domain can be synchronized with the users and
groups defined for the TIBCO Enterprise Message Service server. Both users and their
passwords become known to the EMS server after synchronization. If a user or group in
the EMS server has the same name as a user or group in your domain, the user or group
name in the EMS server is overwritten. The EMS $admin group and admin user are not
changed.

If your domain is integrated with an LDAP Directory server, synchronization is not
supported. An LDAP directory server does not allow passwords to be exported, and as
a result passwords would not be exported on synchronization.

ToAccesstheEMSPlugin

1. Click Application Management > All Service Instances
2. Expand the TIBCO Enterprise Message Service.
3. Click the server instance name.
You can set options for the following:
Server Parameters
Queues Parameters
Topics Parameters
Durables Parameters
Connection Factories Parameters
Connections Parameters
Producers and Consumers Parameters
Routes Parameters
Bridges Parameters
Transports Parameters
Transactions Parameters
Users and Groups Parameters
JNDI Bindings Parameters

TIBCO

TIBCOBusinessWorksManualWorkModule

TIBCO BusinessWorks provides a simple web interface for viewing manual work tasks
assigned to users. This interface is named BW Manual Work in the TIBCO
Administrator GUI.

The BW Manual Work module is documented in TIBCO BusinessWorks Palette Reference,
which is part of the TIBCO BusinessWorks documentation set. To access the module in
the TIBCO Administrator GUI, in the left panel, click BW Manual Work.

When you log into the web interface, you can see any task that you have acquired. To
log in, you must specify a valid username, password, and TIBCO InConcert server
name.

If you are authorized to use the module, you can perform the following:

Exporting Users or Roles to TIBCO InConcert
Using a TIBCO InConcert Proxy Server
Logging In and Viewing the Task Lists
Acquiring Tasks
Working with Tasks in the Acquired List
Working with the Completed List
Administering Tasks

TIBCO

ManagingUsersandRoles
UserManagementOverview
The User Management module allows you to manage users, roles and security for an
administration domain. You specify users and roles using the Users and Roles consoles
and give users and roles access to individual components in the TIBCO administration
domain using the Security console.
The Users console allows privileged users to create users. It also allows users
who have the Administer permission to grant other users permission to read,
write, or administer any of the consoles or other resources in TIBCO applications
and repositories.
The Roles console allows privileged users to create roles. The purpose of roles is
to allow an administrator to group users, and then simultaneously give (or
withdraw) permission for that group of users to use consoles, applications, or
application repositories.

UsingtheGuestRole
The TIBCO Administrator GUI role console displays a Guest role as a sibling to
authenticated users. Privileged users use this role to designate certain consoles or
resources in TIBCO applications that do not require log-on.
TIBCO
SearchingforUsers
Most TIBCO Administrator GUI consoles include a search function. The search function
works the same for each console. For example, for the Users console:
Typing a users name and clicking Search displays only that user.
Using the wildcard character (*) allows you to indicate zero or more characters.
For example, if users Ravi, Rachel, and Tara are defined, *ra* returns Ravi,
Rachel, and Tara, ra* returns Ravi and Rachel, and ra does not return anything.
Search is case sensitive with the exception of searching users.
Typically, search can be based on data that appears in any of the columns.
SelectingItems
There are multiple ways to select items in the TIBCO Administrator GUI. For example,
for the Users console:
Clicking Name displays users in ascending or descending alphabetical order.
Clicking the check box next to Name selects or clears all users.
Shift-clicking selects check boxes for multiple sequential users.
Clicking selects check boxes for multiple non sequential users.
Clicking a users name (not a check box) displays a dialog where that users
properties can be viewed or edited.
Sorting a column clears the selection.
A selection can span pages (in cases where the table or list is paged).
Following are creating and configure users and roles in standard administration
domains.
Managing Access Rights
Adding Users
Assigning Role Membership to Users
Removing Role Membership for a User
Assigning Permissions to Users
Changing or Resetting Passwords
Deleting Users
Renaming Users
Changing Domain Administrator User Credentials
Managing the Password Policy for an Administration Domain
Creating a Role
Adding or Removing a User from a Role
Removing a Child Role from a Parent Role
Assigning Permissions to Roles
Users Dialog
New User Dialog
Roles Dialog
New Role Dialog
Profile Dialog
TIBCO

TIBCO
HAWK

TIBCO
TIBCO HAWK

Overview

TIBCO Hawk is a tool for monitoring and managing distributed applications and
operating systems. Unlike other monitoring solutions, TIBCO Hawk software uses
TIBCO Rendezvous software for all communication and inherits many of its benefits.
These benefits include a flexible architecture, enterprise-wide scalability, and location-
transparent product components that are simple to configure.

TIBCO Hawk is an event-based system built around the concept of a distributed,
autonomous smart agent that operates on each managed machine in the network. The
software is designed specifically for monitoring distributed systems, so there is no
centralized console or frequent polling across the network. With this structure, TIBCO
Hawk is able to scale to multi-thousand node global networks without the use of
hierarchical managers and has the flexibility to allow individual managed entities to be
added or modified without the need to re-configure or re-start any other parts of the
system.

The work required to monitor applications and systems is performed by TIBCO Hawk
agents. An agent can be a rulebase, rulebase map, or schedules object.

An agent runs on each node on the network and monitors local conditions. Each agent
uses collections of locally loaded rules organized into rulebases to apply monitoring
logic. A rulebase tells an agent how to monitor particular application or system
resources and what actions to take when specific conditions are detected. TIBCO Hawk
includes pre-built rulebases that monitor basic system level parameters, and
administrators can build additional rulebases using editors in TIBCO Hawk Display.
Rulebases can be selectively loaded to an agent or group of agents on a temporary or
permanent basis.

The TIBCO Hawk Display application subscribes to alert messages generated by TIBCO
Hawk rulebases and presents them in an organized view. Alerts are color-coded to
indicate the severity of a reported problem. Clicking on a node displays the error
message along with a recent history of problems on the node. TIBCO Hawk Display
does not store centralized monitoring intelligence; it simply offers a view of events on
your distributed systems. Adding more instances of the Display application requires no
additional network overhead or configuration.

TIBCO

Architecture

The following diagram gives an overview of TIBCO Hawk system architecture.

Figure TIBCO Hawk System Architecture

The TIBCO Hawk system is made up of two main components: agents and Console
Applications. Agents perform the bulk of the monitoring duties, and Console
Applications act as user interfaces for status and configuration (TIBCO Hawk Display),
historical event loggers (TIBCO Hawk Event Service), or bridges to other management
systems.

The right side of the diagram shows TIBCO Hawk agents installed on machines to
monitor local resources and conditions. Default microagents are used to monitor objects
such as operating system performance, processes, log files, application metrics or the
status of TIBCO Rendezvous sessions.

The left side of the diagram shows how user applications can be instrumented and
monitored using TIBCO Hawk agents. In both scenarios, the TIBCO Hawk Application
Management Interface (AMI) protocol acts as a gateway between the applications
management capabilities and the local TIBCO Hawk agents. An application can be
directly instrumented with the AMI protocol to expose its management operations and
data. If an application already employs a management interface other than AMI, an
AMI adapter can be built to allow the agent to discover and exercise it.

TIBCO

Features

As the complexity and size of a distributed network increases, most tools that manage
these networks also increase in size and complexity. Many of these tools use a
centralized approach for gathering information and performing tasks, making heavy
use of polling and point-to-point messaging. The result can be excessive network
bandwidth, bottlenecks, and compromised reliability and efficiency of the network.
TIBCO Hawk addresses these problems by providing a monitoring solution that is
scalable, location transparent, and reliable.

Scalability

A scalable network management tool seeks to minimize network traffic so the least
amount of bandwidth is used. Also, to be truly scalable, the bandwidth consumed
should not grow proportionately as a distributed network grows.

One way TIBCO Hawk achieves scalability is by using TIBCO Rendezvous as the
underlying communication layer. This communication is extremely efficient and
reliable. A message sent to 100 nodes in the network uses the same network bandwidth
as a message sent to 10 nodes. Applications that use TIBCO Rendezvous are inherently
scalable. For more information, refer to TIBCO Rendezvous Concepts.

TIBCO Hawk agents monitor conditions on their local machines and send alerts over
the network only when problems are detected, an approach that has major scalability
advantages over a central, dedicated console server. With centralized server-based
architectures, monitoring data is collected from remote nodes via network polling or
point to point messages to the console generated by simple agents on the devices. After
gathering or receiving this information, the console server then makes centralized
monitoring decisions. The network bandwidth consumed by polling-based systems
grows proportionately with the number of monitored nodes, as does resource
utilization on the console machine. Eventually, additional console servers must be
employed to scale the system. Using the distributed event-driven monitoring
architecture employed by the TIBCO Hawk system, network bandwidth and system
resources are conserved by decentralizing and distributing the monitoring load.
Another advantage of this method is that alerts are generated only when a problem
exists, so under normal conditions minimal network bandwidth is used.

LocationTransparencyandFaultTolerance
A TIBCO Hawk agent runs on each node, where it collects information, applies
monitoring logic, and carries out event notification and corrective actions. TIBCO Hawk
agents are autonomous because they monitor and perform management tasks
independently of TIBCO Hawk Display. TIBCO Rendezvous messages between agents
and TIBCO Hawk Display use subject-based addressing, so the physical location of each
component is unimportant. Fault-tolerance is built in because agents perform tasks
independently of other agents. If one or more agents on the network cease to function,
other agents continue to monitor local data and perform tasks. In the console server
TIBCO
model, if the server becomes disabled, all monitoring stops until another console server
can be brought on line. Additionally, as all connections are point-to-point, all remote
agents must be manually reconfigured to connect to the new server and all polled
connections need to be rediscovered.

Multiple instances of TIBCO Hawk Display can run without configuration
modifications or incurring additional network overhead. The centralized approach to
distributed application management usually requires that all configuration and
management tasks be performed from a single console. Additional consoles in such
systems incur a proportional increase in the network traffic required for monitoring,
and often require considerable configuration changes.

SystemManagementOverNetworksofAnySize

Using TIBCO Hawk Display, administrators can easily monitor and manage nodes in a
large, distributed network using a collective or "follow the sun" approach.
Administrators can be in Tokyo, New York and London, each viewing and managing
the same group of TIBCO Hawk agents. Each administrator can construct a customized
view with his or her own unique Display arrangements. Alerts viewed by the
administrators are consistent across all instances of TIBCO Hawk Display and other
applications (built with the TIBCO Hawk Console API) in the network.

AdvancedMonitoringLogic

TIBCO Hawk provides flexibility in performing monitoring tasks. The rules or policies
you create can be very simple or complex. Using advanced features, you can implement
solutions like the following:

Automatically restart a failed process.
Create a series of escalating actions to respond to a continuing or deteriorating
problem.

Clear an alert when certain criteria are met.
Selectively ignore an intermittent condition and respond only after it persists.
Take an action when an alert clears, such as sending a stand-down notice to a backup
systems administrator who is on call.
Switch rules automatically to support different monitoring setups.
Create thermostat-like controls to respond to fluctuating conditions.
Automatically alter monitoring behavior based on user defined schedules.

Flexibility
A distributed network typically must support multiple platforms and enterprise

applications. In such a heterogeneous environment, many different combinations of
objects require monitoring and many variations of routine tasks require automation.
The TIBCO Hawk environment is flexible enough to support these variations, both
internally and through components designed to communicate with external application
environments.
TIBCO

Administrators can tailor the TIBCO Hawk environment by building custom rules and
by automatically executing commands and custom scripts. Programmers can extend
TIBCO Hawk by instrumenting applications using the AMI protocol, or by using AMI
to build gateways between agents and non-instrumented applications. The Console API
also provides a comprehensive interface for communicating with TIBCO Hawk agents,
allowing programmers to build customized display applications or sophisticated, multi-
level decision-making programs that can draw data across multiple agents. The
Configuration Object API allows you to build custom rulebases. Using the
Configuration Object API you can also build a custom rulebase editor.

FunctionalComponents

This section gives a general overview of the functional components of the TIBCO Hawk
enterprise monitor.

TheTIBCORendezvousSystem
TIBCO Hawk uses TIBCO Rendezvous for all network and intra-machine
communications between the various TIBCO Hawk components. It supports both
broadcast or multicast network environments. WAN connectivity is provided through
the use of the TIBCO Rendezvous routing daemon, which routes messages efficiently
and reliably between networks.

TIBCOHawkAgentsandMicroagents
In a TIBCO Hawk environment, agents on each local computer perform the monitoring
work. Agents use objects called microagents to represent and interact with managed
objects. Microagents support methods which are invoked to extract monitoring
information and carry out specified tasks. This allows a total de coupling of the
management data from the management rules or policies. Microagent methods can be
accessed and invoked from TIBCO Hawk Display or Console API applications. They are
also used with the agent's powerful rules engine in autonomous monitoring.

Microagents are available for managed entities such as log files, custom executables,
operating system performance metrics, processes, file systems, event logs, and services.
Applications instrumented with AMI are dynamically discovered and represented by
microagents, allowing them to be monitored and managed. Each microagent runs
within an agent but the managed application it represents can be a separate process. The
agent itself is represented by microagents, allowing it to be configured and managed in
the same manner as any other managed entity.

TIBCO
RulebasesandRules
A rulebase is a collection of one or more rules. A rule is a user defined monitoring

policy. It specifies a data source in the form of a microagent method, one or more
untests that check for conditions, and one or actions to perform if a test is true.

With TIBCO Hawk rulebases, you can perform general monitoring tasks and test for
very specific conditions. Escalations can be applied to actions to allow for a staged
response to a condition. An agent can be configured to initially take corrective actions
itself, but if the condition still persists, then call for outside help from administrators.
The rulebase editor in TIBCO Hawk Display allows easy construction of simple and
complex rules. No scripting is required and an administrator does not need to learn
special rule syntax.

The rules of a rulebase are typically constructed so that each rulebase focuses on
monitoring a particular application or system resource. The rulebases are then assigned
to multiple agents with similar monitoring requirements. Configuration options provide
flexible mechanisms for distributing rules. Adding a new rulebase to one agent or 1000
agents takes the same amount of time. All rulebase changes are performed dynamically
in the agent with no required restart.

Schedules can be imposed on the rulebase hierarchy to control when monitoring activity
and corrective tasks are performed. In a schedule you can define both inclusion and
exclusion periods during which an object can be active. Like rules, schedules can be
distributed to multiple agents with similar requirements.

TIBCOHawkDisplay

The TIBCO Hawk Display application is the primary means of interacting with
managed objects on your network. The main window of the TIBCO Hawk Display
graphically represents system behavior with each monitored computer represented by a
container icon. You use application menus and dialogs to create, modify and distribute
rulebases, which control the monitoring behavior of TIBCO Hawk agents. TIBCO Hawk
Display can be run over a regular dial-up line with the same functionality as well as on
the network.

The TIBCO Hawk Display is not a centralized console server with management logic,
but a local window into activity on your network. All TIBCO Hawk Display users view
the same managed objects without complicated configuration schemes. Each user can
also customize their instance of the TIBCO Hawk Display interface without affecting
others.

The agent processes themselves are monitored using TIBCO Hawk Display and other
Console API-based applications. If an agent stops communicating with the application,
it will be detected and appropriate notifications

TIBCO
AMIProtocol
The TIBCO Hawk Application Management Interface (AMI) is an open, TIBCO

Rendezvous-based protocol for instrumenting an application with an extremely
powerful management interface. Applications can be monitored and controlled from
the inside using the tools of the TIBCO Hawk system in the same way as any other
system component. The protocol allows for complete independence between the TIBCO
Hawk agents and the managed application with two-way dynamic discovery.
Information and action methods within an application are exposed to the agent in the
same format as any other microagent. They are available for use within rulebases and
for invocation or subscription and Network Query/Action calls from TIBCO Hawk
Display and Console API applications.

AMI features are as follows:

AMI API libraries that implement the protocol are provided in C, C++ and Java.
Direct AMI using the TIBCO Rendezvous APIs is also supported in ActiveX, and Perl.

AMI can be easily back-fitted into existing applications, even those that do not
currently use TIBCO Rendezvous, and expose existing internal application methods to a
TIBCO Hawk agent.

Third-party applications can be managed by writing an AMI wrapper that interfaces
with an API or other mechanism provided by the application for the purpose of
managing it.

ConsoleAPI
The Console API is a comprehensive set of Java interfaces that a programmer can use to
interact with TIBCO Hawk agents. TIBCO Hawk Display uses the Console API to
monitor and manage agent behavior on your network. Using the Console API,
programmers can write custom applications that monitor agent behavior, subscribe to
alert messages and invoke microagent methods. For example, a sophisticated load-
balancing program could draw information from TIBCO Hawk agents.

ConfigurationObjectAPI
The TIBCO Hawk Configuration Object API is a Java language interface for writing
custom rulebases. Rulebases are used by TIBCO Hawk agents to monitor and manage
systems and applications. The Configuration Object API provides classes to define rules,
tests and actions. Instances of these classes are put together to define a new rulebase.

EventService
The TIBCO Hawk Event Service is a Console API-based application that records the
activity of TIBCO Hawk agents. The Event Service logs all TIBCO Hawk system events
such as agent activation and expiration, alerts, clears, and microagent and rulebase
changes. It writes entries on these activities to data files, which can be accessed by
external applications. It can also execute a user-supplied
TIBCO

TIBCO
SmartMapper

TIBCO
SmartMapper

Overview

BusinessWorks SmartMapper is focused on addressing three problems common to
solutions that are part of enterprise application integration (EAI):

Lookups
Cross-Referencing
Configurable Business Rules

Lookups

Any two applications are likely to have different code sets for things like currency,
countries, status codes and so forth. This generally represents pick lists in the
applications. As the number of applications increase or more packaged applications are
thrown in the mix, it becomes prohibitively difficult to make them all the same. As the
list expands, it also becomes unwieldy to hardcode these lists into maps. Because of this,
the majority of these lookups are done in databases.

This introduces a number of problems:
Lookups are difficult to write, as they require advanced programming skills
To save time, the data models become oversimplified, which makes their growth
difficult over time
Database access can be very slow

CrossReferencing

The most common integration need in EAI is data synchronization. Data
synchronization typically requires the development of three things for each object:

A mapping, to transform data from one schema to another. Three mapping models are
needed if there is a common object model. See Using a Common Data Model: Three
Mapping Models on page 7 for more information on this case.
A process, to define the business rules that control how data is processed.

Cross-referencing, which allows users to
Match an entity in one application with its semantic equivalent in another
application. For example, an account id in Siebel might be labeled "acme-123" and the
same account in SAP might be labeled "00001890".
Follow a previously created link to perform updates or to preserve references.
Match static data such as codes or a pick-list of data among applications. For
example, a pick list in one system may use "USD" and another system pick list may use
"Dollars".

TIBCO
ConfigurableBusinessRules

Through the Data Models and Cross-Referencing Functions, users can
Set thresholds in a process, and make these thresholds configurable from the
administrative GUI rather than by redoing the entire process. For example, a business
may choose that all purchase orders over $10,000 must be manually approved. If the
business now chooses to change that threshold to $5,000, they only need to change the
value in the database through the SmartMapper GUI.

Set closed loop integration. TIBCO BusinessWorks processes can set the values
required by SmartMapper. For example, you can set stocking levels in BusinessWorks,
and have SmartMapper incorporate these levels into its processes.

HowTIBCOBusinessWorksSmartMapperAddressestheBusinessProblem

BusinessWorks SmartMapper offers a unique set of features that both simplify and
enhance the process of setting up, deploying, using, and managing cross-referencing
services for data synchronization. These features can dramatically reduce the time and
cost of integration projects.

The following is an overview of what BusinessWorks SmartMapper offers:

Speed. High-performance cache, parallel execution, and distributed server options
ensure that lookups are not the bottleneck.

Simplicity. A graphical user interface models relationships, applies them to maps,
and even generates the tables without the need for coding. This dramatically reduces
both development time and the total cost of ownership.

Power. Modeling the right relationships the first time rather than forcing them into a
one-size-fits-all model saves endless extra steps and workarounds.

Flexibility. Neither the model nor the processes is tied to the deployment data store
options, which allows the system to grow as a companys needs grow.

This additional set of features is built on the power of TIBCO BusinessWorks and offers
the same ease-of-use, standards, and lifecycle management capabilities that are available
in BusinessWorks.

TIBCO
Features

TIBCO BusinessWorks SmartMapper includes the following major features:

Cross-reference activities, which are used within a TIBCO BusinessWorks process.
Cross-reference activities allow you to look up, create, update, and delete mappings,
and to generate keys.
SmartMapper Wizard, which allows data translation in the context of a hierarchical
object.
Zero-coding approach with SmartMapper Wizard-driven graphical entity relationship
modeling and mapping. This approach enables lookups, new key generation, and
maintenance of the mapping model. Zero-coding is available through the TIBCO
Designer GUI.
Batched approach, which allows lookups to be processed efficiently and writes to be
all-or-nothing.
Entity relationship modeling. This allows you to model objects and keys, and to link
modeled objects through relationships. This is available through the TIBCO Designer
GUI.
Bulk extract of data. The Bulk Extract activity enables the bulk extraction of cross-
referencing data for reporting purposes. You can query entity or relationship data by
providing an entity name or relationship name.
Dynamic loading and dynamic query. The Bulk Load activity allows you to load
SmartMapper data and the Dynamic Lookup activity allows you to query SmartMapper
data.
Non-key attributes.
Creation and modification timestamps for records can be included in the
Dynamic Lookup and Bulk Extract activities
The association relationship type has been added for relationships where there are
only two participants. The relationship type is set on the Relationship resource.
Composite key lookups: To allow for many-to-many relationships, BusinessWorks
SmartMapper provides the ability to take multiple attributes in and produce multiple
attributes.
Uses XML standards such as XSD for definition and XPath for attributes.
Server, server-less, or cache only.
Simplified correlation of data from multiple sources
Use of TIBCO Administrator to maintain data related to rules and cross-reference
services.
Leverages and features all of the deployment, administration, security and
management capabilities of BusinessWorks.

PerformanceandScalability

High-performance caching mechanisms for optimal throughput and scalability
Queries are performed in parallel
Shared cross-referencing engine among multiple instances of TIBCO BusinessWorks
(TIBCO BusinessWorks SmartMapper Enterprise Server only). Shared cross-referencing
takes place in the Maximize Throughput scenario.
TIBCO
Shared multiple adapter instances among one instance of TIBCO BusinessWorks. This
is the Minimize Latency scenario.

ComplexityofRelationships

Multiple keys
The same object may participate in many relationships
Ability to handle complex object relationships: one-to-many, many-to-one, many-to-
many, non key data.

Compatibility

For information on which platforms this product is compatible with

UsingaCommonDataModel:ThreeMappingModels

A common data model is used when data is mapped into a canonical data format such
as OAG.

When using a publish and subscribe /event-driven architecture, a source does not
necessarily know what its destinations are. Further, if multiple applications are
connected to the network as peers, it is helpful if each application does not have to
know about the internal data formats of all of the others. In this case, you can set up one
standard common data model and have all the sources map to and from that model.

Generally, when performing cross-referencing between two applications with a
common data model, the following three mapping models are necessary:

Publish mapping. This goes from a source application to a common data model. This
can be used to generate keys for primary keys if the objects have not yet been created in
the cross-reference mapping tables.
The sample projects address the publish mapping only, but the software can be used to
build any one of these mappings.

Request mapping. This maps data from a common data model to a target application.
In request mapping, if a primary key lookup fails, it usually does not matter because the
adapter creates a key in the application. The target adapter generates these entities. For
example, when you create a customer in
SAP, request mapping will generate a customer id which is returned in the response
from the SAP BAPI.

Response mapping. After a key is successfully created into the target application, the
newly-generated keys must be matched to the common keys.

TIBCO

The following image shows all three mapping models in action:

Publisher Mapping maps an entity (say Customer_Number) from the Siebel adapter to
the common model in SmartMapper. A common id can be generated in the common
model. From there, the mapper takes the entity as defined in the common model and
performs the synchronization logic.

Request Mapping uses the synchronization logic results, and generates a request to the
SAP adapter. If SAP uses external numbering, then, if necessary, during Request
Mapping, a key can be generated that will correspond to a SAP identifier.

Response Mapping established the link between the common id and the one generated
by the SAP application.

Architecture

There are as many ways to set up BusinessWorks SmartMapper as there are ways to set
up TIBCO BusinessWorks. However, the following are some of the more likely
scenarios:

Development. In this case, all the BusinessWorks SmartMapper components run on
one machine. The project is undeployed. The data store is a local database or a file
system.

Small project. In this case, BusinessWorks SmartMapper is installed on the remote
TIBCO BusinessWorks machine. The database is installed on the remote TIBCO
BusinessWorks machine.

Large project or enterprise. In this case, there are multiple TIBCO BusinessWorks
engines with BusinessWorks SmartMapper, and a TIBCO Administrator server. The file
system is used for static data on TIBCO BusinessWorks engines. The SmartMapper
Enterprise Server runs on the database machine.

TIBCO
ScalingBusinessWorksSmartMapper

The following diagrams show how to scale BusinessWorks SmartMapper. Your scaling
depends on whether you are getting many messages or a smaller number of large
messages.

In the simplest case, you might need only one BusinessWorks engine, as shown in the
next diagram. This is a typical small project where some data source is sending
messages to TIBCO BusinessWorks. SmartMapping is done in process and
BusinessWorks SmartMapper accesses a JDBC data source as needed.

In more complex situations, you need to take account of loads.

For example, imagine 10,000 orders, each with many lines and at least one lookup per
line.

In one case, each order would be a separate inbound message. Refer to the Maximize
Throughput Scenario (Many Small Objects) on page 10.

In the second case, the whole batch of orders is a single message

MaximizeThroughputScenario(ManySmallObjects)

If you are receiving many messages, tune your system for high message throughput. To
do this tuning, use multiple TIBCO BusinessWorks engines. As throughput increases,
more TIBCO BusinessWorks engines are used to handle the load. The SmartMapper
Enterprise Server brokers the transactions to the data store. If you have many messages,
you need to scale the number of TIBCO BusinessWorks engines that you use, but the
SmartMapper Enterprise Server can be shared among all the TIBCO BusinessWorks
engines.

TIBCO

MinimizeLatencyScenario(OneLargeBatch)

If you are receiving large messages, tune to minimize latency. To do this use multiple
SmartMapper Enterprise Servers (instead of multiple TIBCO BusinessWorks engines).
In some cases like legacy, payroll, or supply chain planning systems, huge messages are
generated. For example, one message might contain a months worth of orders. If there
is only one message, adding TIBCO BusinessWorks engines does not help, but the
SmartMapper Wizard can still perform lookups in parallel.

Also, by using distributed queues, multiple SmartMapper Enterprise Servers can work
against the load. You change the batch size on the SmartMapper Enterprise Server to a
reasonable chunk size (100) and set the subscriber to use RVDQ. The RVDQ
(Rendezvous Distributed Queue service) facilitates load balancing.

Tibco Sriven

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tibco Sriven

Uploaded by

Copyright:

Available Formats

TIBCO

SRIVEN INFOTECH svit4info.com 1

In this architecture, each application connects to a message bus. Each

The centralized architecture lacks standardized integration nodes 9adapter). Although

The Checkpoint activity performs a checkpoint in a running process

Static destinations let administrators configure EMS behavior at the enterprise

Dynamic destinations give client programs the flexibility to define destinations as

As All TIBCO EMS administered objects implement the JNDI Referenceable

- Its a composite containing zero or more fields

In this weight we have highest members

A distributed network typically must support multiple platforms and enterprise

A rulebase is a collection of one or more rules. A rule is a user defined monitoring

The TIBCO Hawk Application Management Interface (AMI) is an open, TIBCO

You might also like