Adapters · TIBCO

TIBCO Adapters FAQs

What are Adapters?
Adapters are connectors to data sources to catch event changes. Once an Adapter catches a event change, it publishes the message to a message box using either EMS or RVD
Adapter is a gateway between different applications using messaging channels.

What are the different types of adapters?
Technical Adapters (File Adapter, DB Adapter)
Functional Adapters (PeopleSoft Adapter, SAP R3 Adapter)
Custom Adapters

Adapter Components
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 is to send or receive.

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.

Adapter Lifecycle:
The following is an overview of the adapter lifecycle:
1. Install the vendor application to which the adapter connects before 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. An adapter instance is deployed using TIBCO Administrator.
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, 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.

Adapter Services :
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

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. When an application receives a request to create a customer record, the application notifies the adapter about the request and the adapter publishes the event.
User Interface—————–Application X————–Adapter ————– TIBCO Messaging
Create record Send to adapter Publishing

Polls on the source data table (base table).
Reads data from the source table.
Sends the data to the message bus.

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. Referring 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 Messaging————Adapter———–Application Y Subscribing Update record

Reads data from the message bus.
Gives the data to the destination table.

Request-Response Service:
In addition to asynchronously publishing and subscribing to events, an adapter can be used for synchronously retrieving data from or executing 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.

Receives requests from other applications.
Parses the requests.
Returns response (Sends only the requested data to the message bus).

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 invoke synchronously functionality on an external system.

How can u fine-tune an ADBAdapter? What are the different parameters that can be used?
a) we can use publish by value or publish by reference for high speed and data type support like oracle long respectively.
b) Can use polar or alerter for frequent and infrequent data changes respectively.
c) Adb.PollingInterval, _ADB.DUPDECT.adapter_instance_name parameters can be used to do flow control and avoid duplication respectively.

What are the quality of services we can have in adapter publishing services?
RV: reliable, certified, transactional

What are the wire formats we can have in adapter publishing services?
wire formats:
a) RV: active enterprise message, RV message, XML message.
b)JMS: XML message

What are the objects, which will be created if you configure and save ADB adapter?
Publishing table for source table, Trigger acts as a bridge between source and publishing table

Explain the internal functioning of ADB publication service?
When we configure ADB publishing service it creates Publishing table for source table, Trigger acts as a bridge between source and publishing table. Whenever data is being inserted/updated/deleted from source table, it will be inserted into publishing table by means of trigger. ADB has another component called polling agent. Polling agent will be keep looking for new inserts into publishing table and if it finds any then converts the record in p table into the specified wire format and publishes on specified quality of service

Can we filter the records from publishing when they get updated in source table? (Data from all regions are coming into table but I want to publish only New York data)
Yes – By modifying the trigger we can only insert the New York data into publishing table

Can we limit the number of columns to be published from the source table?
Yes, using the use? field in adapter publishing table tab. just uncheck the columns u dont want to use.

Can we publish parent and child table information by using single adapter configuration and how?
Yes, in the adapter publisher table tab create a parent table first by look up and then add the child table using the add child tab then click on the child table column to specify the foreign key than to establish a relationship between the primary key of the parent and the foreign key of the child go to the column in the child table and specify the primary key of the parent table.
In the subscription service the destination table is created and the child table mapping tab will have the child table on the left mapped with the parent table on the right.

What is publish by value and publish by reference. Explain the pros and cons.

publish by value: in this type the changes in the source table are reflected in the p_ table and the data is taken from there. its used when high speed is required. it dose not support data types like oracle long.

publish by reference: in this type the data is directly taken from the source table where only the primary key will come from p_ table. it allows data types like oracle long.
loss of changes in the source table can be lost bcos of the waiting time.(this can be avoided using alerter).

What are the types of message transfers in file adapters?
record transfer: to integrate file systems to TIBCO AE environment.
simple file transfer: to transfer files to other TIBCO adapters.

What is read schema and write schema in file adapter.
Read schema in the file adapter publisher config is used to define typr of expected input. Here we can use the delimited file tupe or the positional file type.

What is the difference between an ADBAdapter and JDBC palette activities?
• Using ADB we can only pick up the data from one database and put it in onother one.
• But using JDBC we can Query using JDBCQuery and manupulate data using JDBCUpdate. like we can use select statements and insert and update statements to selective query and update.
• ADB adapters might be useful in scenarios where we have large amount of data.

What is the difference between a FileAdapter and File palette activities?
In file activities the file polar cannot handle multi format data and record by record transfer .it takes care of particular format specified and does file transfer.
where as file adapter can handle multiple formats and does record by record transfer.

If the reference to Schema changes in “Activity Input” does it through error, how do you correct it?
Yes, and we have to correct the schema in the way the input expect it.

Where do we specify HTTP Port number?
In HTTP connection in the HTTP activities.

What is the difference between JDBC activities and ADB Adapter?
• ADB uses ODBC to connect, JDBC uses JDBC
• ADB is more suitable for instances where you have a lot of processing
• ADB is more suitable for instances where you want that a particular action on a DB Table triggers a BW process.
• ADB adapter is best for publishing from database.
• For simple inserts and updates then ADB subscriber is best.
• ADB is an adapter which is used to capture the events and take action, this has pub and sub mechanisms, pub is used to capture the events and publish the messages and sub will be used to upsert the operations.
• Jdbc is a collection of activities that can be used for custom operations
• In case of insert or update to database then check if you have complex JDBC inserts, transaction management and other dynamic queries then JDBC activities are best.
• JDBC is more suitable for running dynamic code where in runtime you can execute statements with different values depending on process execution.

What are modes of operation for File Adapter in Record Mode?
Synchronous mode upon receiving an event, the publication service will allow other services in the instance only after it completes the processing and publishing of all the files that match the specified criteria.
In Asynchronous mode the publication service allows other services of the instance to receive events while it is processing and publishing a file. By default Subscription service always operates in Asynchronous mode.

What is the diff between tibco adapter and BW component?
Adapters are connectors that use a messaging channel that can be configured over source/target systems which can be used in Pub, Sub or Replyrequest mode. BW components are designer, administrator, bw engine.

What is a synchronous service that an adapter supports?
Of the 4 Adapter services, Request/Response is the only adapter service that is synchronous.

What is Event Driven and Demand Driven?
Event Driven – Push
Demand Driven – Poll.

TIBCO Adapter for ActiveDatabase:
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 z/OS and iSeries 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.

What is File Adapter?
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 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.

File Adapter Operations Mode?
Selecting an operation mode is the first step in configuring a service. The operation mode determines whether the service will integrate the file system with the TIBCO ActiveEnterprise environment or transfer files between instances of TIBCO Adapter for Files.
In the Record Mode of operation, where the adapter integrates the file system with TIBCO ActiveEnterprise, you will have to define and use schemas.
In the Simple File Transfer Mode of operation, where the adapter transfers files among instances of TIBCO Adapter for Files, you will have to define various options for file transfer. However, there is no need to define a schema.

Can two adapters communicate with each other?
No two adapters can communicate with each other directly. They can communicate only through a messaging layer.
Considering Tibco to be the messaging layer,
Publishing Adapter always publishes to Tibco messaging bus.
Subscribing Adapter always subscribes from a Tibco messaging bus.

What are users and user-key columns in Adapter Publisher’s Table tab?
While configuring an ADB Publisher:
“Users” column specifies what columns have to be published to the publishing table.
“User-key” is selected means it acts as a primary key. Child tables can be joined to the Parent tables only using the primary keys. Publish by reference storage mode copies only the primary key from the source table. If a source table does not have a primary key column, we can use the user-key to do the same.

What are the columns available in a Adapter Publishing table?
An adapter Publishing table contains the actual data columns plus Internal Adapter columns.
Actual data colums:
Depending on the storage mode selected, the actual data colums in the publishing table varies:
For Publish by value, the actual data columns will be the exact copy of the base table data colums.(all the columns).
For Publish by reference, the actual data columns will be the exact copy of the base table’s primary key data colums (only Primary key column).

Internal Adapter columns:
ADB_SUBJECT
ADB_SEQUENCE
ADB_SET_SEQUENCE
ADB_TIMESTAMP
ADB_OPCODE
ADB_UPDATE_ALL
ADB_REF_OBJECT
ADB_L_DELIVERY_STATUS
ADB_L_CMSEQUENCE

Publication and Subscription formats ( file adapter)
Two types of formats are supported by adapters while exchanging data between applications
1. MInstances
2. MBusinessDocuments
MInstances is the entity that is exchanged among TIBCO applications. It is the schema instantiations. The runtime adapter parses the input file, identifies the schema associated with the publication service, creates the MInstances and publishes it.

MBusinessDocuments is a facility provided by TIBCO ActiveEnterprise for grouping MInstances. MBusinessDocument always contain MInstances created from the same file. If high throughput is desired from publication service MBusinessDocument attributes can be used.

Modes of operation(file adapter)
There are two modes of operation
Synchronous mode
Asynchronous mode

An adapter instance/configuration can have multiple publication and subscription services. Services are activated by events. The publication service can be activated by a timer event or message event. The event that activates the publication service is called polling agent.

In Synchronous mode upon receiving an event, the publication service will allow other services in the instance only after it completes the processing and publishing of all the files that match the specified criteria.

In Asynchronous mode the publication service allows other services of the instance to receive events while it is processing and publishing a file. By default Subscription service always operates in Asynchronous mode.

If the configuration has more than one service or if the publication service is expected to process large file sizes or large set of files, setting the publication service in asynchronous mode is recommended.

Types of file records (file adapter)
File records can be classified into two categories:
1. delimited file record
2. positional file record
Delimited file records are used to interpret lines that have a well-defined delimiter between the fields. Delimiters can be of single or multiple characters. These can be identified by the number of fields or by using a
constant field value.

Positional file records are used to interpret lines that have well defined field lengths. These can be identified using line or record length or by using a constant field value ie; constant line length.

what is opaque table
The subscription service uses two logical layers when processing a message. The first layer decodes data from the message and the second layer provides the database transaction. If an exception occurs in the first layer, the adapter logs the message to the opaque exception table. In the second layer, if any DML command fails at any level, the adapter rolls back this transaction and starts another transaction, inserting into exception tables. If the insert into exception table transaction fails, the adapter then logs the message to the opaque exception table.
what is the difference between exception table and opaque exception table?
The subscription service uses two logical layers when processing a message.
The first layer decodes data from the message and the second layer provides the database transaction. If an exception occurs in the first layer, the adapter logs the message to the opaque exception table.

In the second layer, if any DML command fails at any level, the adapter rolls back this transaction and starts another transaction, inserting into exception tables. If the insert into exception table transaction fails, the adapter then logs the message to the opaque exception table.

What are the transport types supported by ADB adapters?
The transport types supported by ADB adapters are:
1) Rendezvous
2) JMS

Rendezvous
Quality of service supported by Rendezvous:
1) Reliable
2) Certified
3) Transactional

Wire Formats Supported by Rendexvous:
1) Active Enterprise Message
2) Rendezvous Message
3) XML Message

JMS
Wire Formats Supported by JMS:
1) XML Message

Connection Factory Type Supported by JMS:
1)Topic
2)Queue

Delivery Mode Supported by JMS:
1) Persistent
2) Non-Persistent

— Hari Iyer

Advertisements
Adapters · TIBCO

TIBCO ADR3 SAGA – CHAPTER FIVE – ADAPTER COMPONENTS

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 ActiveMatrix Adapter for Database adapter instance, the palette fetches all pertinent tables in the database.

You then choose the tables that the particular service is to send or receive.

The following diagram shows the TIBCO ActiveMatrix Adapter for Database palette and the configuration options for a publication service.

Capture

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 native client libraries of the application to access schema from the application.

The palette (in TIBCO Designer) communicates with the DTA.

Capture

Not all adapters require a design-time adapter.

Where possible, the adapter palette communicates directly with the native client libraries of the application as shown in the next diagram.

Capture

As shown in the following diagram, the adapter at run-time uses the native client libraries to communicate with the vendor application.

 

Capture

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.

Adapters

TIBCO ADR3 SAGA – CHAPTER FOUR – How to Choose 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 choose the service to use.

Consider the following environment that involves application X, an adapter, and another application

BusinessIntegration

In this scenario, data is exchanged between application X and another application.

The other application can be a customer management system, such as PeopleSoft, or another TIBCO application, such as TIBCO ActiveMatrix BusinessWorks.

Advanced Scenario :-

To choose the adapter service to use, start by finding out where the scenario begins or what triggers it.

For example, when a new customer account is created in application X, must the account information be propagated through the adapter to the other application?

Or does a batch business process in TIBCO ActiveMatrix BusinessWorks need information from application X to generate a report?

This question is the starting point of the decision chart provided in the following figure.

ChooseService

 

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, use Publication Service.

Adapters

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.

AdapterInterractionModes

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.

AdapterPublicationService 

 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.

AdapterSubscriptionService

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

AdapterReqestResponseInvocation

 

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.

 

AdapterRequestResponseService

Adapters

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

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)

 

Releases:-

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