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 today’s 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 middleware’s, 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. Today’s 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. The Business Advantages of EAI 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 enterprise’s 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 application’s functionality by mimicking normal users through the application’s 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. EAI for Critical New Solutions 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 enterprise’s 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. EAI of Legacy and Packaged Applications An enterprise’s legacy applications have become the repositories of the enterprise’s 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. The World Wide Web and EAI 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 today’s 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 enterprise’s crown jewels. They are highly efficient and robust and above all there represent an enterprise’s 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, you’ll 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

Data – level integration 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 application’s database tables. Push – based data – level integration pushes data into another application’s 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 application’s interface tables and retrieve the pertinent data. You’d use pull-based data-level integration when an application requires passive notification of changes within another application’s 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 application’s 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 application’s 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


UI – level integration 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 application’s database and a JMS (Java Message Service) topic. Proxy – based UI - level integration uses the integrated application’s 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 code’s maintenance. Application – level integration 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 Siebel’s JAVA Data Beans and SAP’s JCA (J2EE Connector Architecture). Prefer application – level integration because it is transparent to the integrated application and preserves the application’s data integrity. Method – level integration 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, you’d 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 component’s addCustomer () method. The component would then add the customer to the ERP and CRM (customer relationship management) systems. Method – level integration’s 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. How to choose an integration method 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. Core Integration Components Now that we have looked at the different integration methods, let’s 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. Common XML Schema 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


Data transformation 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 application’s 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. Define Processes 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 you’ll route messages through intermediate systems before ending at the target systems. You will eventually implement this information in the physical integration architecture. Physical integration architectures 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


Message bus architecture 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

45

6

2

2 2

13

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.

Centralized architecture 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. You’ll 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. J2EE connector architecture The JCA takes a radically different approach to integration by placing the integration components within the J2EE application serer, giving you the centralized architecture’s 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 doesn’t support event – based processing. BEA Web Logic has extended JCA 1.0 by adding support for events, but that solution is proprietary.

Figure: The J2EE 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.0’s disadvantages relate to the specification’s 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

AdministrationAnd

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) TIBCO II) Web Methods III) SEEBEYOND IV) NETVIEWER V) MQ-Series VI) MERKATOR VII) BizTalk VIII) WLPL IX) WBP-PL X) VITRIA

We know before EAI we have TP’s are there TP Stands for translated programs .these are written in c or c++

TIBCO


INTRODUCTION TO

TIBCO

TIBCO


TIBCO - INTRODUCTION

What is Tibco?

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.

Tibco Definition 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. TIBCO’s 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 TIBCO’s 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. TIBCO’s 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

TIBCO’s 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 API’s 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 subsystem’s 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 TIB’s 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 TIBCO’s 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


Which areas Tibco Products used? 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 TIBCO Products Overview

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. The Challenge of Application Integration Application integration is one of the most pressing challenges of today’s 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. Integration Benefits 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


Integration Platform Requirements 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 use—Integration 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. Business Integration Scenario 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. Problem Definition 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 company’s web site via the Internet. Customer service representatives can then have easy access to all ordering information. Addressing the Challenge 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 telephone—with direct access to PeopleSoft as before—or 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 shipper’s 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

Example Scenario Runtime Implementation 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


TIBCOBusinessWorks KeyComponents 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


TIBCO Administration Domain 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 Server—Each administration domain has one and only one TIBCO Administration Server. 2. Components—Component software includes the TIBCO BusinessWorks engine and adapters. 3. Machines—Each 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 Information—User and authorization information is specified with the TIBCO Administrator GUI and stored in the domain data store. See Security below. 5. Projects—A 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. • Authentication—The verification of the identity of a person or process. • Authorization—Permission 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 company’s needs.

TIBCO


Monitoring and Managing the Domain 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 Support for Standards 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 company’s 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 Compliant—JMS, EJB, JNDI • Protocols—Web services (SOAP, WSDL), HTTP, HTTPS • Messaging—JMS, TIBCO Rendezvous • Data Description—Native support for DTD, XSD, and TIBCO AE Schema • Data Representation and Expressions—Native support for XML, XPath • Data Transformation—XSLT TIBCO BusinessWorks also supports a plug-in for B2B interactions.

TIBCO


Integrated Development Environment 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. Extensibility and Scalability 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. Design‐Time Architecture 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


TIBCO Designer Layout 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 project’s 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. Enterprise Archive 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. Run‐Time Architecture 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 tolerance—Message 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 architecture—A 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 throughput—High 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. • Scalability—As 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 Adapter—All 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 Processes—The 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 Monitoring—When 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. TIBCO BusinessWorks Adapters 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 adapters—Includes adapters that access files or databases. • Application adapters—Includes 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


Business Process Modelling 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


Schemas and Data Mapping 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." Understanding Schemas 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


Schemas in TIBCO BusinessWorks 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 Manual Activities 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 you’ve 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.

Step 1: Define and Delimit the Problem

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 vendor’s 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.

Step 2: Identify Processes

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 company’s 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.

Step 3: Identify Components

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

Shared Resources

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


Services and Corresponding Activities

The business process uses services to retrieve or send data. There are two kinds of services:

• Adapter services—The 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 services—Web 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.

ManualWork Activities

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


Transitions and Conditions

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.

Step 4: Describe Business Events and Objects

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


Step 5: Design Business Processes

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.

Step 6: Consider Domain Setup

After you’ve 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.

TIBCO Administration Domain

A TIBCO administration domain is a set of hardware and software resources. TIBCO Administration Domain gives an overview of a domain’s 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.

TIBCO Administration Server

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 Server’s 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 machine’s 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.

TIBCO Runtime Agent

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: TIBCO BusinessWorks Services

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


Service Characteristics

The following characteristics are associated with a service:

Service interface, for example WSDL/SOAP or AE Services

Transport, for example, HTTP, JMS, TIBCO Rendezvous

Data syntax, for example, XML or ActiveEnterprise message format

Data schema, for example DTD or XSD schema

Invocation Modes

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 messages—a 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 adapters—Allow you to interact with enterprise applications such as Siebel, SAP R/3, and PeopleSoft.

Adapter Service Configuration Steps

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

Step 1: Installing the Adapter

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


Step 2: Setting up the Design‐Time Adapter

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.

Step 3: Configuring the Run‐Time Adapter

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


Step 4: Accessing the Adapter Service From the Process

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 Adapter—Publishes 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 Subscriber—Subscribes to incoming data published by the adapter.

Invoke an Adapter Request-Response Service—Communicates (as a client) with an adapter request-response service.

Adapter Request-Response Server—Starts a process based on the receipt of a request from an adapter.

Respond to Adapter Request—Sends a response to an adapter for a previously received request.

Wait for Adapter Message—Waits for the receipt of a message from the publication service of the specified adapter.

Wait for Adapter Request—Waits 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.

Step 1: Define Shared Resources

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


Step 2: Create Process Definitions

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


Step 3: Add a Process Starter

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

Step 4: Add Activities

Activities are the individual units of work within a process definition. Activities are generally operations that interface to external systems, but activities can also perform internal processing.

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

Step 5: Optionally, Add Manual Work Activities

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:

Shared Configuration Resources

• Workflow Schema—The 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


Manual Work Activities

• Assign Work—Creates 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 Document—Manual 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 Status—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.

• Modify Work—This 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 Completion—Waits 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.

Step 6: Create Transitions Between Activities

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


Adding Transitions

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.

Step 7: Perform Mapping and Transformation for Each Activity

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 activity’s 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 activity’s input fields.

TIBCO


Step 8: Optionally, Group Activities As Needed

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.

Step 9: Test the Process

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 activity’s 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.

TIBCO BusinessWorks Project Phases

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

Monitoring and Management Options

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 Management—Add 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 Management—View the status of machines and components running on machines in the domain. Start and stop components as needed.

• Deployment monitoring—Monitor 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 management—View 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.

Global Variables: 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


Process Variables: 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

Activity Output: Activities have access to any data that is output from previously executed activities in the process definition. An activity’s 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).

Predefined Process Variables 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.

Error Process Variables 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 activity’s error variable is populated with the

appropriate error schema.

User‐Defined Process Variables 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


Creating a process variable

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. Assigning a value to a user‐defined process variable

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

TIBCO


Shared Variables

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

XPath Basics

TIBCO BusinessWorks uses XPath (XML Path Language) to specify and process elements of data schema. These data schema are either process variables or input schema for an activity. You can also use XPath to perform basic manipulation and comparison of strings, numbers, and booleans. To use XPath in TIBCO BusinessWorks, you need only be familiar with the basic XPath concepts, but you may wish to learn more about XPath when building complex expressions. For a complete description of XPath, refer to the XPath specification

The XPath Formula Builder

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


Describe the different areas of the XPath formula builder.

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 function’s parameters. You can drag and drop schema elements from the Data tab into the function’s placeholders. The result of evaluating the function is displayed in the "Expression Evaluates To" panel. If there are any errors in the expression, they are listed there as well. For more information about XPath functions, see the description of the function that is displayed when it is selected in the XPath formula builder.

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

Addressing Schema Elements

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 activity’s 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.

Evaluation Context

XPath also has a method for referencing relative paths from a particular node. If you have an evaluation context, or a particular starting node in a schema tree, you can specify the relative path to other elements in the tree.

For example, if your evaluation context is $GetOrderInformation/ShipName, then you can reference the sub-items of ShipName without specifying the entire path. If you wish to reference $GetOrderInformation/RequiredDate, the relative path would be ../RequiredDate. The path is relative to the evaluation context — RequiredDate is one level higher in the schema tree than the elements of ShipName.

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.

Search Predicates

An XPath expression can have a search predicate. The search predicate is used to locate a specific element of a repeating schema item. For example, the $GetOrderInformation/OrderDetails/OrderItem item is a repeating element. If you wish to select only the first item 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.

Testing For Nil

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

String Representations of Datatypes

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.

Numeric Datatypes

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


Date Datatypes

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.

Date and Time Functions

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 ’o’’clock’ a, zzzz" 9 o’clock 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.

The Error Process Variables

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.

$_error Process Variable :

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_<activity Name> Process Variables

Each activity has one or more predefined error schemas. The error schemas are displayed on the activity’s 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 activity’s 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.

Error Propagation

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.

Group Error Propagation

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


Called Process Error Propagation

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.

Process Error Schemas

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 definition’s 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.

Using the Catch and Rethrow Activities

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.

Web Services Methodology with BusinessWorks 5.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


Schemas for the SOAP Server

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 TIBCO’s 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


Using the Schema in the WSDL Editor

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 – I’ve 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 I’ve 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


Process Definition for the SOAP Server

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


Java Code Activity as the Engine of the Service

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!

And…we are finished with the Web Service! Now, on to the Client…

SOAP Client

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. I’ve 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


Retrieve Resources – Optional

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 – don’t 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…

Building a SOAP Client

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 aren’t 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


Multiple Operation PortType

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, I’ve 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. Process Variables: 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. Common Features across Active Enterprise Activities: 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. Adapter Request‐Response Server:

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 adapter’s service using the Respond to Adapter Request activity. Adapter Subscriber:

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


Invoke an Adapter Request‐Response Service:

The Invoke an Adapter Request-Response Service activity is used to communicate with an adapter’s 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 Publish to Adapter:

The Publish to Adapter activity publishes a message that can be received by an adapter’s 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. Respond to Adapter Request:

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. Send Exception to Adapter Request:

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


Wait for Adapter Message:

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. Wait for Adapter Request:

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 adapter’s 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. Create File:

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. File Poller:

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. List Files:

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

The Read File activity is used to read a file and place its contents into the activity’s output. Remove File:

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


Rename File:

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. Wait for File Change:

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. Write File:

The Write File activity writes content to the specified file.

TIBCO


FTP Palette:

The FTP palette is used to issue FTP commands. FTP Change Default Directory:

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

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) FTP Delete File:

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

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

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 activity’s output or written directly to local storage. If you choose to place the contents of a remote file into the activity’s output, you can only retrieve one remote file (FTP get command) and the file’s content will be stored in memory as part of the activity’s 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). FTP Get Default Directory:

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. FTP Make Remote Directory:

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

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). FTP Quote:

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


FTP Remove Remote Directory:

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

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

The FTP Sys Type activity retrieves the FTP server’s 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. Call Process:

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


Checkpoints and Transactions 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.

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

Recovering After a Crash 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.

Checkpoints and the Confirm Activity: 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. Confirm Event 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


Engine Command:

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 External Command:

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 activity’s output schema, written to a file, or both. Generate Error:

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. Get Shared Variable:

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.

JNDI Configuration:

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


Job Shared Variable:

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. Lock Object:

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 Notify’s 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. Notify Configuration:

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


On Event Timeout:

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 ... activity’s 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. On Shutdown:

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. On Startup:

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. Receive Notification:

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. Set Shared Variable:

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. 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 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. Write To Log:

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


Custom Properties for the Write To Log Activity: 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. HTTP Connection:

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. Custom Properties for the HTTP Palette: 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


HTTP Receiver:

Starts a process based on the receipt of a HTTP request. Proxy Configuration:

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

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. Sending Data in the HTTP Request: 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). Send HTTP Response:

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". Wait for HTTP Request:

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. Java Code:

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. Java Custom Function :( Most imp activity)

The Java Custom Function resource allows you to create custom functions to use when mapping data in an activity’s 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. Example Java Function 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)"}, Java Global Instance:

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


Java Method:

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. Java Schema:

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


Java To XML:

The Java To XML activity allows you to convert a Java object’s 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 activity’s output schema, but that element will not have a value because there is no public mechanism for getting the data. XML To Java:

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 activity’s 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. JDBC Call Procedure:

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. JDBC Connection:

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

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


JDBC Update:

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. SQL Direct:

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 activity’s 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. Get JMS Queue Message:

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. Acknowledge Mode: 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.

TIBCO


JMS Application Properties:

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. JMS Connection:

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

Starts a process based on the receipt of a message for the specified JMS queue. Load‐Balancing of Incoming Messages 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 engine’s 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. JMS Queue Requestor:

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. JMS Queue Sender

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

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

The JMS Topic Requestor activity is used to communicate with a JMS application’s 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


JMS Topic Subscriber:

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. Reply To JMS Message:

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


Wait for JMS Queue Message:

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

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. Receive Mail:

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. Send Mail:

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. Workflow Schema: 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. Workflow Server Connection: The connection to the TIBCO InConcert workflow server. This server is used to track and manage manual tasks. Assign Work:

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. Download Document:

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


Get Work Status:

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. Workflow Schema:

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. Workflow Server Connection:

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

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. Wait for Completion:

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 Data Format:

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


Parse Data:

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. Render Data:

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. RawRVMsg2 Schema: 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.

Publish Rendezvous Message:

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

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

TIBCO


Rendezvous Transport:

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

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

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. Wait for Rendezvous Message:

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. RMI Lookup:

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. RMI Server:

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 Retrieve Resources:

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. SOAP Event Source:

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. WSDL File and SOAP Event Source: 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


SOAP Request Reply :

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. SOAP Send Fault:

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) SOAP Send Reply:

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. Using the TCP/IP Palette Activities: 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. Read TCP Data:

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 activity’s input.

TIBCO


TCP Close Connection:

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 activity’s input. TCP Connection:

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. TCP Open Connection:

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. TCP Receiver:

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


Wait for TCP Request:

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. Write TCP Data:

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 activity’s input. Transaction Palette: 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. JTA UserTransaction Configuration:

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


Transaction State:

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. XA TransactionManager Configuration:

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 palette’s 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. Parse XML:

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. Render XML:

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. Transform XML:

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 activity’s 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. XSLT File:

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.

TIBCOʹs Messaging Products • TIBCO Ajax Message Service • TIBCO Enterprise Message Service • TIBCO Rendezvous • TIBCO SmartSockets

TIBCO


TIBCO Enterprise Message Service

(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++, TIBCO’s 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.

EMS Architecture

TIBCO


EMS Concepts • 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)

Point‐to‐Point

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

Publish and Subscribe

• 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,

Durable Subscribers for Topics

• 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


JMS Message Header Fields

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

Message Body (JMS Message Types) 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


Message Delivery Modes

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

Persistent Messages in EMS

• 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


Message Acknowledgement

• 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 ’lazily“acknowledges only the individual message, rather than all messages received so far on the session.

• Synchronous and Asynchronous Message Consumption – 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.

Static destinations

• Static destinations let administrators configure EMS behavior at the enterprise level. Administrators define these administered objects, and client programs use them—relieving 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


Dynamic destinations

• 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

Temporary destinations

• 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


Destination properties

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

sender’s 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 sender’s 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-robin—one 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

server—initiating 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 receive—either 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 & Modifying destinations

• 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. Config files

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 Parameters—Deprecated

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. – The format of the file is:

[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


Developing an EMS Client Application • 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.

Creating EMS app using JAVA APIs

• 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.*; Step 1: Connection Factories • 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 object’s setConnAttemptCount(),

setConnAttemptDelay(), and setConnAttemptTimeout() methods to establish new connection failure parameters:

factory.setConnAttemptCount(10); factory.setConnAttemptDelay(1000); factory.setConnAttemptTimeout(1000);

Step 2 : Connecting to the EMS Server

– A connection with the EMS server is defined by the Connection object

obtained from a Connection Factory.

– Use the TibjmsConnectionFactory object’s createConnection() method to create a Connection object:

Connection connection = factory.createConnection(userName,password); Step 3: Creating a Session

– A Session is a single-threaded context for producing or consuming messages.

– Connection object’s 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); Step 4 : Setting an Exception Listener

– Implement an ExceptionListener.onException method, use the Connection object’s 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); Step 5 :Dynamically Creating Topics and Queues

– Use the Session object’s createTopic() method to create a topic as a Destination object:

Destination topic = session.createTopic(topicName);

– Use the Session object’s createQueue() method to create a queue as a Destination object:

Destination queue = session.createQueue(queueName); Step 6 : Creating a Message Producer

– Use the Session object’s createProducer() method to create a MessageProducer object:

MessageProducer QueueSender = session.createProducer(queue);

TIBCO


Step 7 : Configuring a Message Producer

– Use the MessageProducer object’s 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); Step 8 : Working with Messages 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 object’s createTextMessage() method to create a TextMessage: TextMessage message = session.createTextMessage("Hello");

Step 9: Setting and Getting Message Properties

– Use the Message object’s 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"); Step 10: Sending Messages

– Use the MessageProducer object’s 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


Step 11: Receiving Messages

– Use the Connection object’s start() method to start the connection: connection.start();

– Use the MessageConsumer object’s 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();

EMS and TIBCO Rendezvous. • 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.

Transport configuration

• 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 & Queue configuration

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

Message Translation

• 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 absent—it omits them

from the exported message.

TIBCO


EMS and TIBCO SmartSockets.

• 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


Transport configuration

• 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 & Queue configuration

• 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


Message Translation

• 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 absent—it omits them

from the exported message.

TIBCO


Fault Tolerance

• You can arrange TIBCO Enterprise Message Service servers for fault-tolerant operation by configuring a pair of servers—one 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 client’s 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.

Share state

• 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


Configuring servers • 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: set server authorization=enabled

– From the backup (Server 2), enter: set server authorization=enabled

Configuring clients

• 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 object’s • 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


EMS Routing and JNDI 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 destinations—that 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.

Configuring Routes and Zones

• 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 URL—including 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


Storing Administered Objects in a Naming/Directory Service

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

Looking up Administered Objects Stored in EMS

• 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"); Looking Up Objects Using Full URL Names

• 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.sample");

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/RV components

• 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/RV Language Interfaces

• C • C++ • JAVA • COM • Perl 5

TIBCO


Organization of TIB/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 Wire Format

• 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


Types of Message Interaction

• Request/Reply interactions – Queries and transactions.

Communication is bi-directional. Multicast request/reply interactions – replies from multiple servers.

Communication is bi-directional. Publish/Subscribe interactions – for general distribution of information

Communication is in one direction.

TIBCO


DATA • RV programs exchange self-describing data. • Contain 6 parts

- Data - Type - Size - Name - Identifier - Count TIB/RV Message

- It’s 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

SUBJECT NAMES

• Contains one or more elements separated by dot.

• It reflects the structure of information in an application system Wild Card Subject Names

• 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


Inbox Names

• 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

Various types of Transport Objects

• Intra-process Delivery • Network Transport • Reliable Delivery • Certified Delivery • Distributed Queue Delivery

Intra‐process Delivery

• Between program threads within a single process • Doesn’t pass through TIB/RV Daemon, remains in local within the

program process • Faster than Network transport

Network Transport

• Delivers messages across network to processes on one or more hosts. • To one or more processes within a single host

Reliable Delivery

• Subscribers have to pick up the message, published by the publisher within specified time.

• Usually time will be of 60 sec.

TIBCO


Certified Delivery

• Keeps on sending the message till the subscriber receives the message. • Subscriber will send the acknowledgement once it receives the message

Distributed Queue Delivery

• 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

Service parameters: - 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

How does u specify the Service?

• 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. Network Parameters:

• 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


Consists of 3 parts

- 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 don’t mention anything uses gethostname();

Multicast groups :

• 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

Send address :

• When a program sends the multicast data on the resulting transport it sends to this address

• Need not be in the multicast group • Don’t mention, it takes first one of the multicast group

Daemon Parameters:

• Instructs the transport function call about how and where to find out the tibrv daemon and establish communication

For local daemon mention socket: “xxxx” Don’t mention anything :”7500” (default) Remote Daemon :

• 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”; Suppress Daemon Auto‐Start:

• 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”; ---------------------------------------------------------------

Version of Rendezvous 7.0 on words PGM and TRDP Security features Security client connections Virtual circuits Direct communications Routing daemon subject weights and path costs PGM and TRDP 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


Difference b/w PGM and TRDP

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 Security features 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) Security client connections 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 Virtual circuits These virtual circuits provides new quality of service

TIBCO


Direct communications Also without Rvd you are establish a communication between two applications through inboxes at a time Routing daemon subject weights and path costs This total control over system administrator for the purpose of routing path costs

Subject – based addressing 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


Validations of subject name news.yahoo.com news.group.yahoo.com

It should be stored with an alphabet

MESSAGE COMUNICATIONS

Event driven (or) publish subscriber

In this publish subscriber there is no acknowledgement Multi casting

Demand driven (or) request /reply

unicasting In this request /reply acknowledgement is there

Multicast request/reply

Acknowledgement is there Point-to-point communication

Direct communication

It is established with out Rvd Based on inbox in the receiver

TYPES OF MESSAGES 1. Reliable Message (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. Certified Message (RVCM) This will be storing assurance delivery of data when compared to reliable data and greater certainty (greater delivery of data)

TIBCO


Features of RVCM 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 Difference Between Reliable and Certified Messages

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 File based ledger

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

Process based ledger

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)

Relay agent 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


File to file scenario

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 Advantages of F.T

Main advantage of this F.T is strength and our communication Location transparency 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 it’s 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 member’s and Inactive members

There is no limitation of groups and members. Another name of these two are Primary member’s Active member’s 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.T call back:‐ In this function as a parameter. Any new member joined in this group this is F.T call back function will be called Rank and Weight:‐ 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


When F.T will be occurring:‐ 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 Heart beat tracking:‐ Process failure Independent conformation:‐ In this active members withdraw the conformation

TIBCO


Adapters

TIBCO


Adapters

What is an Adapter?

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 enterprise’s 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


Adapter Key Terms

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.

Adapter Services Examples

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.

Publication Service

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.

Subscription Service

An adapter subscription service asynchronously performs an action—such as updating business objects or invoking native APIs—on 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.

Request‐Response Service

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.

Request‐Response Invocation Service

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

Adapter Services Summary

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)


Vendor application

Asynchronous

Request-response service (gets from initiator, waits for response then sends response to target)


Vendor application

Synchronous

Request-response invocation service (sends to target, waits for response, then sends response to initiator)

Vendor application


Synchronous

TIBCO


Choosing an Adapter Service

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 user’s 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 begins—what 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 adapter’s publication service should be used.

TIBCO


Adapter Key Features

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 adapter’s 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 user’s 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 adapter’s user’s guide.

• Multi-lingual Support. Most adapters support multi-byte character sets.

TIBCO


Adapter Components

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.

Adapter Palette

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


Run‐time Adapter

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.

Design‐time Adapter

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.

Component Details

The next diagram shows components used at design-time for adapters that provide a design-time adapter. The DTA uses the application’s 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 application’s 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


Adapter Lifecycle

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


Task A Install Vendor Application

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.

Task B Install TIBCO Runtime Agent

The TIBCO Runtime Agent must be installed on each machine that hosts an adapter design-time or run-time component before installing the adapter.

Task C Install Adapter(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.

Task D Install TIBCO Administrator

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.

Task E Install other TIBCO Software

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 user’s guide.

Task A Configure the Vendor Application to work with the Adapter

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 user’s guide for details.

Task B Define an Adapter Project

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.

Task C Set Global Variables

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.

Task D Create an Adapter Instance

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 tab—Each 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 tab—An 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 tab—An 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 tab—If 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.

Task E Configure an Adapter Service

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 tab—The adapter service name, transport type, transport quality of service and wire format to use are specified here.

• Schema tab—The choices available vary by adapter, based on how the adapter interoperates with the vendor application to download schema.

• Encoding tab—Allows you to set encoding options. • Advanced tab—Allows 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 Repository—The 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 Repository—The 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.

Task F Set Security Options

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.

Task G Test the Adapter Configuration

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.

Deploy Using TIBCO Administrator Enterprise Edition

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. Task A Generate and Import an Enterprise Archive File

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.

Task B Specify Deployment Information

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


Task C Specify Monitoring Options

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.

Task D Start the Adapter

The adapter is started and stopped using the TIBCO Administrator GUI.

Deploy Using TIBCO Administrator Repository Edition

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.

Task A Export Project to a Server Repository

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

Task B Create or Modify the Properties File

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.repourl—pathname of the TIBCO Designer project that contains the configuration information used by the run-time adapter.

• tibco.configurl—name 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.args—name 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.username—account name defined in TIBCO Administrator to access a

server-based project. • tibco.password—password to the account.

TIBCO


Task C Start the Adapter

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.

Management and Monitoring

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

• 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 user’s 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 adapter’s User Guide.

TIBCO Administrator Enterprise Edition

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 Management—Add 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 Management—View the status of machines and components running on machines in the domain. Start and stop components as needed.

• Deployment monitoring—Monitor 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 management—View 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


TIBCO Hawk

TIBCO Hawk allows monitoring, management, and fault detection. It can be customized according to the user’s 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 user’s guide for a list of supported microagents.

Log Files

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


Trace Messages

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 user’s guide. The following diagram shows an example trace message and calls out the fields.

Status Codes

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 user’s guide.

Tracking Identifier

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

Application Adapters

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 user’s guide for more information.

TIBCO Adapter for R/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.

TIBCO Adapter for Siebel

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.

TIBCO Adapter for PeopleSoft 8

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 PeopleSoft’s CRM module and the PeopleTools 8.4 application.

TIBCO Adapter for ClarifyCRM

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.

TIBCO Adapter for Teradata

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

TIBCO Adapter for Remedy

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 System’s APIs to interface with the Action Request server.

TIBCO


TIBCO Adapter for Tuxedo

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.

TIBCO Adapter for Lotus Notes

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.

TIBCO Adapter for J.D. Edwards OneWorld Xe

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


Adapters for Database and File Systems

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.

TIBCO Adapter for ActiveDatabase

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.

TIBCO Adapter for Oracle Applications

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.

TIBCO Adapter for Files

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


Adapters for Other Technologies

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.

TIBCO Adapter for LDAP

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.

TIBCO Adapter for COM

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.

TIBCO Adapter for CORBA

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.

TIBCO Adapter for EJB

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


TIBCO Adapter for MQSeries

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.

TIBCO Adapter for SWIFT

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


Custom Adapters

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

Adapter Services

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.

Publication and Subscription Services

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


Request‐Response Service

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


ADB Adapter VS BW‐JDBC Palette 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


ADB ADAPTER EXECUTION Post Installation Procedure:

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; Configure the ODBC System Data Source

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

Configure the Properties Files

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.

Create a Project in the Designer.

Create an Adapter Instance

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. TIBCO Designer loads schema information for this secondary detail table.

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. ADB Subscriber:

TIBCO


2. Add the Subscription Service

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. Add a Table and a Child Table to the Subscription Service

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. Add Two Child Tables to the SUB_ORDER_DETAILS Table

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. TIBCO Designer loads schema information for this secondary detail table.

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. Add Child Table Mappings

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. Change the Subject Name

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


Request‐Response Service Tabs

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:

Configuration Tab Transport Type

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.

To enable and configure SSL:

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


Connection Factory Type

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.

Delivery Mode

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

Wire Format

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)

Use Custom Operations

This checkbox appears when the Mode field is set to RPC. Selecting this checkbox and clicking Apply creates the Call Operation Tab.

TIBCO


Call Operation Tab

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.

Procedure Name

Name of the database procedure to call.

Select Procedure

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.

Maximum Rows

(Optional) The maximum number of rows to retrieve.

One way

(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 User’s Guide for information about destinations.

TIBCO


Reply Subject

Type a TIBCO Rendezvous subject name that the adapter uses to respond, if no response subject is specified in the request message.

Endpoint Reference

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.

Class Reference

Click the Go To icon to reconfigure the existing reference. Class reference objects are explained in TIBCO Designer Palette Reference.

Example Description

This example shows how the adapter’s 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 adapter’s 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.

Setup the Example

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

Test the Example

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


Expected Results

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 1-1ABXYZ L-2ABXYZ Regular 1-1ABXYZ L-3ABXYZ 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

Run the Database Clean up Script

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


Adapter Features

This section provides a brief overview of the adapter’s features. These are discussed in detail later in the manual.

The adapter provides the following features:

An easy‐to‐use GUI for configuring the adapter 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.

Support for globalization 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.

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

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

Adapter‐specific microagent 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


Adapter Services

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.

File Adapter VS BW‐File Palette 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.

Types of Repository

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


Configuring the Adapter

Configuring the adapter involves deciding whether to use an existing repository or to create a new repository.

Using an Existing Repository

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.

Creating a New Repository

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.

Creating an Adapter Configuration

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


Creating Services

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.

Configuring the Services

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.

Configuration Sequence in the Record Mode Publication Service

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 service’s Configuration, Processing, Encoding, Transport, and Advanced tab.


1. From an existing wire schema, generate the WriteSchema.

2. Edit the WriteSchema.

3. Associate the WriteSchema(s) to the subscription service using the service’s Schema tab.

4. Enter appropriate information for the subscription service’s Configuration, Processing, Encoding, Transport and Advanced tab.

TIBCO


Configuration Sequence in the Simple File Transfer Mode Publication Service

1. Begin with the SFT tab and set the desired file transfer configuration.

2. Enter appropriate information for the publication service’s Configuration, Processing, Encoding, and Transport tab.


1. Begin with the SFT tab and set the desired file transfer configuration.

2. Enter appropriate information for the subscription service’s Configuration, Processing, Encoding, and Transport tab.

Deploying and Executing the Run‐time Adapter

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.

Adapter Features

The following features are described in detail throughout this manual.

Easy‐to‐Use GUI

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.

Adapter Services

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.

Data Format Conversions

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

Multi‐threaded Capability 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.

Schema Support

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.

Distributed Queue Support

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.

User‐specified MQSeries Message Queue Options

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


Batch Processing

For publication and request-response invocation services, you can configure the adapter to group messages into a single batch for processing.

Supported Message Types

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.

Supported and Non Supported Message Formats

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

Support for IMS

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.

Support for Correlation of Request and Response Messages

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.

Support for Dynamic Reply Queues

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.

Support for Dual Message Transports

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 User’s Guide. You can configure the connection factory type and the delivery mode used when you configure the adapter service.

TIBCO


MQSeries Features

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.

Queue Manager

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.

MQSeries Client

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


MQSeries Server

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.

Adapter Services

TIBCO Adapter for MQSeries consists of the adapter services shown in the following figure.

Figure Adapter Services

TIBCO


Started With MQSeries Adapter

Create a Project

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


Configure the Adapter

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


Configure a Service

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.

Convert the Project to a Repository File

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.

Run the Adapter

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

SAP to non SAP:‐ 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 RFC’s 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 User Management 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. • Users—You 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. • Roles—Access control is easier when roles are used. You can assign multiple users into roles and then assign permissions for the role. • Security—Each 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


Resource Management 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 Domains—If 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 administration domain. • Installed Software—You can view TIBCO applications that are running on each machine in the domain and enable or disable applications. • Machines—Each administration domain contains one or more machines. You add a machine to an administration domain using the TIBCO Domain Utility.

Application Management This module allows you to upload an application’s 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 application’s 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


Administration Server An administration server manages resources in an administration domain. Each domain has its own administration domain. The administration server’s 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


Tomcat Web Server 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. TIBCO Hawk Agent 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. TIBCO Runtime Agent 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, Plug‐ins and Modules TIBCO Administrator includes several utilities, plug-ins and modules that are introduced in this section. TIBCO Domain Utility 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


Scripting Deployment Utility 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 application’s process engines or service instances • Stop a successfully deployed process engine or service instance.

TIBCO


Command Line Utilities 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.

TIBCO Enterprise Message Service Plug‐in 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. To Access the EMS Plug‐in 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


TIBCO BusinessWorks Manual Work Module 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


Managing Users and Roles

User Management Overview

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.

Using the Guest Role

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


Searching for Users

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 user’s 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.

Selecting Items

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 user’s name (not a check box) displays a dialog where that user’s

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 application’s 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. Location Transparency and Fault Tolerance 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. System Management Over Networks of Any Size 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. Advanced Monitoring Logic 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. Functional Components This section gives a general overview of the functional components of the TIBCO Hawk enterprise monitor. The TIBCO Rendezvous System 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. TIBCO Hawk Agents and Microagents 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


Rulebases and Rules 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. TIBCO Hawk Display 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


AMI Protocol 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. Console API 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. Configuration Object API 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. Event Service 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 Cross‐Referencing 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


Configurable Business Rules 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. How TIBCO BusinessWorks SmartMapper Addresses the Business Problem 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 company’s 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. Performance and Scalability • 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. Complexity of Relationships • 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 Using a Common Data Model: Three Mapping Models 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


Scaling BusinessWorks SmartMapper 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 Maximize Throughput Scenario (Many Small Objects) 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


Minimize Latency Scenario (One Large Batch) 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 month’s 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

Documents

Transcript of Tibco Sriven