TIBCO ADR3 SAGA Chapter Three -Adapter and their Interraction Modes

At the most basic level, a TIBCO Adapter receives data available from a source application or sends data to a target application.

This is based on a service architecture. Services are abstractions that describe how adapters work together with other applications.

An adapter generally supports publish/subscribe and request/response interaction modes. The following table summarizes the adapter interaction modes and adapter services introduced in this section.


Publish/Subscribe Interactions

Publish/subscribe interactions are driven by events, such as the arrival of data or a timer signaling that a specified interval has expired.

The following services are available for publish/subscribe interactions.

Publication Service:-

Publication Service recognizes when business events happen in a vendor application, and asynchronously publishes the event data in real time to interested systems in the TIBCO environment.

For example, a “Publication Service” service can publish an event each time a new customer account is added to application X, as shown in the following figure.

Other applications that receive the event can then update their records just as the original application did.


 Subscription Service:-

Subscription Service gets information about business events from the TIBCO environment, and asynchronously writes the information into a target application.

Referring to the previous example, a “Subscription Service” service can subscribe to events that indicate the creation of a new customer and then enter the customer information into target application Y, as shown in the following figure.


Request/Response Interactions :-
In addition to asynchronously publishing and subscribing to events, an adapter
can synchronously retrieve data from or execute transactions within a vendor
Demand-driven computing suits distributed applications that require
point-to-point messages, that is, a request and a response. In request/response
interactions, a data provider coordinates closely with a data consumer. A provider
does not send data until a consumer requests it. The consumer listens until it
receives the reply, and then stops listening (unless it expects further installments
of information). This is useful for actions such as adding or deleting business
The following services are available for request/response interactions:

• Request-Response Invocation Service
• Request-Response Service

Request/response is the default invocation protocol for both Request-Response
Invocation Service and Request-Response Service, but you can also use both
services asynchronously when the invocation protocol is one way. Not all
adapters support the one way protocol, but for those that do, the implementation
of the protocol is consistent.

Request-Response Invocation Service :- 
Request-Response Invocation Service acts as a proxy, giving the vendor application
the ability to invoke services on TIBCO infrastructure. TIBCO infrastructure may
perform a series of steps to complete the request, including invoking services on
other applications through TIBCO infrastructure and other adapters.
For example, a Request-Response Invocation Service service sends a request
message from the vendor application X to another application Y through TIBCO
infrastructure. After application Y processes the message, it returns the result to
TIBCO infrastructure. Then the adapter receives the response and sends it back to
application X, as shown in the following figure.



Request/reply is the default invocation protocol for Request-Response Invocation
Service, but it can also be used asynchronously where the invocation protocol is
one way. Not all adapters support this, but the implementation is consistent
across all adapters that support the one way protocol.


Request-Response Service :-
Request-Response Service is similar to Request-Response Invocation Service, except
that the roles are reversed. The vendor application is now the provider of the
service, instead of the requester or initiator of the service.
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.
Referring to the previous example, a Request-Response Service service sends a
request message from TIBCO infrastructure to application Y. The adapter gets a
response from application Y and returns it to TIBCO infrastructure, which then
sends the response to application X, as shown in the following figure.




TIBCO ADR3 SAGA Chapter two – Overview of TIBCO Adapters

Many businesses rely on a complex mix of custom applications, databases, and technologies to implement their business processes and manage information.

Optimizing the reuse and coordination of these assets and information sources helps organizations simultaneously reduce time-to-market and costs, but this data is not always easy to access or to integrate.

Vendors typically have their own ways to format and expose data. Therefore, integrating the various applications across an enterprise poses significant challenges.

TIBCO Adapters bridge custom applications, databases, and other technologies in the enterprise information flow, regardless of their data formats or communication protocols. An adapter isolates an application from complex interaction and makes it part of TIBCO infrastructure without requiring any changes to the application.

Integration of new applications does not require programming and does not interfere with existing infrastructure.

TIBCO Adapters encapsulate complex interaction patterns into a set of standard services.

This makes it easy to administer the adapters.

TIBCO Adapters exchange information through TIBCO messaging platform, which provides flexible and scalable information bus infrastructure.

When the information is published to TIBCO infrastructure, it is transformed and delivered with extremely low latency and you can implement business process automation across applications.

TIBCO Adapters provide integration for a variety of technologies:

  • Packaged Applications SAP, Siebel, PeopleSoft, Lotus Notes, SWIFT, Oracle BRM, J.D. Edwards Enterprise One, BMC Remedy, and others.
  • Databases Oracle, SQL Server, Sybase, MySQL, and PostGres, DB2 UDB for UNIX, DB2 for z/OS, and DB2 for i5/OS.
  • Mainframe and i5/OS Technologies CICS, IMS, DB2, VSAM, dataset files for z/OS and RPG program objects, Data Queues, and SPOOL files for i5/OS.
  • Other Standards and Technologies EJB, Files, LDAP, MQSeries, Tuxedo, and OSISoft PI.
  • Custom Integration Java and C++.

TIBCO ADR3 SAGA Chapter One SAP R/3 – An Introduction

SAP AG brought out a client–server version of the software called SAP R/3

Real-Time Data Processing (3 stands for 3-tier)

  • Database
  • Application Server
  • Client (SAPgui)



  • SAP R/1 System RF: 1972
  • SAP R/2 Mainframe System: 1979
  • SAP R/3 Enterprise Edition 1.0 A: July 1992
  • SAP R/3 Enterprise Edition 2.0: 1993
  • SAP R/3 Enterprise Edition 3.0: 1995
  • SAP R/3 Enterprise Edition 4.0B: June 1998
  • SAP R/3 Enterprise Edition 4.3
  • SAP R/3 Enterprise Edition 4.5B: March 1999
  • SAP R/3 Enterprise Edition 4.6C: April 2001
  • SAP R/3 Enterprise Edition 4.6F
  • SAP R/3 Enterprise Edition 4.7: 2003
  • SAP ERP Central Component (ECC) 5.0: 2004
  • SAP ERP Central Component (ECC) 6.0: October 2005
  • SAP enhancement package 1 for SAP ERP 6.0: December 2006
  • SAP enhancement package 2 for SAP ERP 6.0: July 2007
  • SAP enhancement package 3 for SAP ERP 6.0
  • SAP enhancement package 4 for SAP ERP 6.0
  • SAP enhancement package 5 for SAP ERP 6.0: June 2010
  • SAP enhancement package 6 for SAP ERP 6.0: June 2012
  • SAP enhancement package 7 for SAP ERP 6.0: 2013
  • SAP S/4 Simple Suite for HANA: February 2015


  • SAP R/3 was arranged into distinct functional modules, covering the typical functions in a business organization. The most widely used modules were Financials and Controlling (FICO), Human Resources (HR), Materials Management (MM), Sales & Distribution (SD), and Production Planning (PP).
  • Each module handled specific business tasks on its own, but was linked to the other modules where applicable. For instance, an invoice from the billing transaction of Sales & Distribution would pass through to accounting, where it will appear in accounts receivable and cost of goods sold.
  • SAP typically focused on best practice methodologies for driving its software processes, but more recently expanded into vertical markets. In these situations, SAP produced specialized modules (referred to as IS or Industry Specific) geared toward a particular market segment, such as utilities or retail.
  • SAP based the architecture of R/3 on a three-tier client/server structure:
  • Presentation Layer (GUI)
  • Application Layer
  • Database Layer



  • Presentation Layer
  • SAP allows the IT supported processing of a multitude of tasks which occur in a typical company. The newer SAP ERP software differs from R/3 mainly because it is based on SAP Net Weaver: core components can be implemented in ABAP and in Java and new functional areas are mostly no longer created as part of the previous ERP system, with closely interconnected constituents, but as self-contained components or even systems.


  • Application Server
  • This server contains the SAP applications. In systems with two layers, this server forms part of the database server. Application server can be set up for online users, for background processing, or for both.
  • An application server is a collection of executables that collectively interpret the ABAP/4 (Advanced Business Application Programming / 4th Generation) programs and manage the input and output for them. When an application server is started, these executables all start at the same time. When an application server is stopped, they all shut down together. The number of processes that start up when you bring up the application server is defined in a single configuration file called the application server profile. Each application server has a profile that specifies its characteristics when it starts up and while it is running. For example, an application server profile specifies:
  1. Number of processes and their types
  2. Amount of memory each process may use
  3. Length of time a user is inactive before being automatically logged off.


  • The Application layer consists of one or more application servers and a message server.
  • Each application server contains a set of services used to run the R/3 system.
  • Not practical, only one application server is needed to run an R/3 system.
  • But in practice, the services are distributed across more than one application server.
  • This means that not all application servers will provide the full range of services.
  • The message server is responsible for communication between the application servers.
  • It passes requests from one application server to another within the system.
  • It also contains information about application server groups and the current load balancing within them.
  • It uses this information to choose an appropriate server when a user logs onto the system.
  • The application server exists to interpret ABAP/4 programs, and they only run there.
  • If an ABAP/4 program requests information from the database, the application server will send the request to the database server.


  • Security
  • Server-to-server communications can be encrypted with the SAP cryptographic library. With the recent acquisition of relevant parts of SECUDE, SAP can now provide cryptography libraries with SAP R/3 for Secure Network Communications and Secure Socket.
%d bloggers like this: