Ariba Buyer: System Architecture and Topology
By Ariba Product Marketing (Issue 1 2001)
Ariba Buyer helps streamline and automate companies' buying cycles and integrates with a variety of other back-end systems and databases. This article describes the design, features, and architecture of Ariba Buyer, including its scalability, high availability, and integration capabilities.
Ariba BuyerTM can be deployed on company intranets or hosted by application service providers (ASPs). It integrates with the Ariba® Commerce Services Network (CSN) on the Internet to provide services such as order routing to suppliers, catalog delivery from suppliers, purchase order tracking, and logistics support. With Ariba Buyer, users can access a broad set of suppliers, Ariba-based industry marketplaces, and other marketplaces. Figure 1 illustrates the overall architecture of Ariba Buyer and CSN.
Figure 1. Ariba Buyer and Ariba Commerce Services Network architecture
Ariba Buyer architecture
Several independent tiers comprise Ariba Buyer. Each tier scales independently and provides firewall opportunities between tiers. Figure 2 illustrates the tiers and components of an Ariba Buyer system; the following sections describe each of these tiers.
Figure 2. Ariba Buyer tiers
The Ariba Buyer client is browser-based and is presented with HTML. The client communicates with the Web server tier using HTTP or HTTP Secure (HTTPS). Ariba requires a minimum configuration for Windows® clients of 32 MB of RAM and a 90 MHz Pentium® CPU. However, at least 64 MB of RAM and a 166 MHz Pentium CPU are recommended.
Web server tier
The Web server uses a JavaTM servlet for Netscape® with iPlanetTM Web servers and a Java class within the Active Server Pages (ASP) framework for Microsoft® Internet Information Server (IIS). Although the current version of Ariba Buyer 7.0 uses a single Web server communicating with the Ariba Buyer application server, the upcoming release will support multiple Web servers communicating with multiple Ariba Buyer application servers. The Web server for the main HTML user interface (UI) may reside on the same server as the Ariba application server or run on a separate server.
Application server tier
The Ariba Buyer application server is a multithreaded Java application written using Java Developer's Kit (JDK). The application server is responsible for handling client requests and generating responses, as well as managing and supplying object data, including database interactions.
The Ariba application server uses servlets to receive and respond to client requests. The servlets invoke object methods to retrieve and manage object data within the application server. Threads provide a pool of shared services for handling client requests; a pool of persistent database connections uses native Java Database Connectivity (JDBC) drivers for all database interactions. The JDBC drivers use the database's native networking layer, such as Net8 for Oracle8iTM databases.
Ariba Buyer supports multiple application servers. Benchmark testing on a single application server with 8 to 12 CPUs and 4 GB RAM with a comparable database server demonstrated the ability to scale to more than 100,000 deployed users (at a concurrency of 1.3 percent), and system throughput of several thousand requisitions per hour.
Standard relational database technology provides automatic object persistence-all business object data is stored in the database. Ariba Buyer communicates with the database through native JDBC drivers and the underlying relational database manages transactions. Approval documents, such as requisitions or time-off requests, can have attachments that are stored in a file system on the application server. Ariba Buyer supports IBM® DB2® , Oracle® , and Microsoft SQL Server 7.0 databases on Windows NT® and Windows® 2000.
Networks, tiers, and servers
Ariba Buyer uses HTTP, HTTPS, and TCP/IP and can be accessed from a browser over LAN, wide area network (WAN), virtual private network (VPN), and dial-up connections with at least a 28.8 KB/sec connection. Ariba recommends a 100BaseT Ethernet LAN connection between the Web, application, and database servers.
The Web server, application server, and database tiers are logically separated; therefore, they can also be physically separated. The tiers can be combined or separated on servers based on corporate standards or preferences for tier isolation, allowing a variety of platform configurations to meet specific needs. The hardware requirements for each tier depend on the scope of the deployment and the configuration selected.
Concurrency and availability
The nature of the Ariba Buyer workflow, generally characterized by the creation of requisitions followed by approval or refusal of these requisitions, significantly reduces the likelihood of concurrent updates to any object. However, the Ariba Buyer application server maintains state information for all clients and automatically transfers this information to the underlying relational database. This provides transparent persistence of the user's work without having to save or submit changes to avoid losing work in the event of failure. The application server relies on the database for managing transactions-Ariba Buyer does not consider a change persistent until the database confirms the change.
Ariba Buyer uses optimistic locking, which is managed by the application server. To support concurrency, the database layer controls record versions for locking. When an object state is persisted in the database, Ariba Buyer verifies the version number of the object in the database. If another client has already modified the object data, Ariba Buyer refuses to overwrite the data created by the earlier session. Instead, the second session receives an out-of-date exception, and Ariba Buyer sends the user the new version of the object for review and resubmission of changes.
Although object state information can be cached in the middle tier to improve performance, the official data is stored in the database to avoid potential loss or corruption—making recovery implicit and automatic. Whenever the mid-tier server starts, it retrieves the state of the various objects from the underlying database.
The Web server, Ariba Buyer server, and the underlying relational database can be deployed on clustered servers for automated failover and redundancy. Figure 3 depicts a possible high-availability configuration for Ariba Buyer 7.0 with clustered servers and automated failover. Figure 4 illustrates another high-availability option with multiple Web servers and Ariba Buyer application servers.
Figure 3. High-availability configuration for Ariba Buyer 7.0
Figure 4. High-availability configuration with multiple Web and application servers
Enterprise integration architecture
Enterprise Application Integration (EAI) remains one of the most challenging aspects of corporate system implementation. As the number of systems grows, the workload of constructing and maintaining custom-built interfaces between system pairs increases exponentially. This has led to the growth of EAI frameworks and products. These solutions typically offer a "hub-and-spoke" architecture, which allows new systems to plug into the EAI infrastructure through adapters. The hub provides core services for message routing, transformation, and management of the metadata associated with the EAI participants.
Ariba Buyer uses an EAI approach to integrate with existing enterprise applications, allowing any data from other back-office systems such as accounting data, lists of users, addresses, and supplier data to be read from existing databases. Ariba Buyer provides both synchronous, real-time integration and asynchronous integration with other systems.
Ariba Buyer provides prebuilt and pretested integration with Enterprise Resource Planning (ERP) vendors including SAPTM , Oracle® , and PeopleSoft® , as well as interaction with any other database or legacy system through the Generic Integration Pack. This integration may be customized using graphical tools to alter the metadata for Ariba-to-ERP mapping, rather than through core logic modifications.
Ariba Buyer supports real-time integration, which may be field-based, event-based, or use generic listeners. Field-based integration allows synchronous communication with external systems based on changes to values within an Ariba Buyer field. A field value can be defaulted from or validated against an external system via a real-time lookup in that external system. For example, the value of a "budget" field can be retrieved or validated at runtime via a lookup within an ERP system table.
Event-based integration enables real-time communication with an external system based on significant events in a document's life cycle. For example, when a document is submitted, this event may trigger communication with an external system, such as data validation against data in an external ERP system or data retrieval from an external system.
Generic listeners enable data sources to update Ariba Buyer in real time. Generic listeners subscribe to messages from worksheets that publish data from a data source. When data is changed, the data source publishes a message with the new data, which Ariba Buyer accepts and uses. These listeners allow Ariba Buyer to update data automatically.
These real-time interfaces to external systems are configured using a combination of XML, Java, and parameter files that are stored and managed separately from the core Ariba Buyer logic.
Ariba Buyer provides an integration layer to pull data from and push data to other systems. This layer allows Ariba Buyer to integrate with a wide variety of sources within the enterprise infrastructure. Ariba Buyer can pull data such as user details, suppliers, account structures, and currencies from ERP systems, and then push data such as requisitions, purchase orders, receipts, and accounting details back to these systems. Ariba Buyer also integrates with other resources on corporate networks such as databases, flat files, and Lightweight Directory Access Protocol (LDAP) directories.
In a simple configuration with only one ERP system, integration tends to be fairly straightforward: Ariba Buyer is set up to exchange data with the ERP system. However, many corporations have several internal organizations with different data. These branches may have different data or business requirements that must be preserved in the Ariba Buyer configuration. In a multi-ERP configuration, a company has several internal organizations with different Ariba Buyer configuration requirements.
Most Ariba Buyer configurations integrate with one or more underlying ERP systems to exchange data. Integration is typically bidirectional—Ariba Buyer pulls data from and pushes data to external ERP systems. A single Ariba Buyer instance can exchange data with multiple ERP systems simultaneously, resulting in one global application across all systems and organizational units.
Flexible system topology
The core Ariba Buyer architecture combined with the enterprise integration options creates a variety of potential system configurations. Figure 5 illustrates one potential system topology with reporting features and enterprise integration off-loaded from the core Ariba servers. Ariba Buyer offers a proven business solution that offers scalability, high availability, and integration capabilities. Future releases of Ariba Buyer will support multiple Web servers and application servers, adding load-balancing features.
Figure 5. System topology example with enterprise integration
For more information
For more information about Ariba products and services, visit www.ariba.com