AR System architecture

AR System is based on a multitiered client-server architecture that includes the client tier, the Mid Tier, the server tier, and the data tier. AR System clients provide the user interface. The Mid Tier  makes the user interface available in browsers. The AR System server  implements the workflow functions, access control, and flow of data into and out of the database. The database server acts as a data storage and retrieval engine. The following table provides details about the different tiers:

The following figure depicts the relationship among the system components that reside within each of the functional environments of the AR System architecture. These system components work together to provide power, flexibility, and scalability. Notice that no definitive starting and ending point separates the environments because their functions sometimes overlap. 

 AR System  functional components

AR System includes the following functional environments:

AR System groups for scalability and high availability

To provide scalability and increase reliability, you can connect a group of Approval Server to the same database and manage them as a unit by configuring a server group. Server groups act as a single server to support the applications that they run. Servers in the server group can be configured to spread the load of shared services, and they can provide backup to each other to ensure that those services are always available.

The following figure depicts the high-level architecture of the AR System:

Heterogeneous environment provides flexibility

Because the multiple layers of AR System are independent of one another, you can combine operating system platforms to fulfill different functions. The heterogeneous environment enables you to mix and match client and server platforms. For example:

• Developer Studio on a computer running Windows can manage forms on a UNIX or Linux server.
• Browsers can use a Mid Tier based on Microsoft Windows to access forms on a UNIX server.
• An AR System server on Windows can interact with a database on UNIX.

AR System client-server communication

AR System components communicate with each other by using the communication protocols. The following figure represents the communication structure:

Communications between clients and the AR System server

All clients of the AR System communicate with the server by using remote procedure calls (RPCs) on top of a TCP/IP transport stack. The type of RPC is the Oracle ONC RPC. TCP/IP networks are generally the standard for corporate and internet communications. The RPC mechanism is used because it is a "lightweight" transport that uses minimal network bandwidth, yet provides robust communications services. It can function over slower dial-up network links and high-speed internet and intranets, and is supported over most of the wireless networking technologies. The AR System web server communicates with the browsers by using Hypertext Transfer Protocol (HTTP) or Secure HTTP (HTTPS).

Communications between AR System server and database servers

From the perspective of the database server, the AR System server is a database client. AR System server uses the JDBC to connect to the database. When a AR System server is installed, the installer specifies the type and location of the database server that informs the AR System server which JDBC driver to use. The AR System server supports SQL Server, Oracle, and PostgreSQL databases and communicates with the database servers by using type 4 JDBC drivers. The AR System server uses the JDBC connection pooling to allow multiple database connections in parallel. The AR System server process comprises many threads to support user requests and share the connection pool. This provides tremendous data throughput and system scalability.

Many-to-many connections

In an AR System environment, one AR System server can theoretically support any number of AR System client connections that are limited by network bandwidth and server host and database performance. The clients can be on any mix of platforms. Similarly, a AR System client can be connected to any number of servers at the same time. These servers can be any mix of server hosts and underlying database engines.

AR System clients

AR System clients provide user interface facilities available from various platforms, including the Web. AR System clients are available for many operating system environments, as shown in the AR System client-server architecture. For each operating system, the client is composed of a set of native applications or tools that use the standard user interface conventions for that environment. Individual users can run these tools as necessary.

AR System clients can be broadly divided into user clients and developer clients.

User clients

Through the Mid Tier, users can access AR System in a browser.

From the browser, administrators can:

• Create groups and roles
• Create users and assign licenses
• Manage AR System server settings and licenses

Users can:

• Access AR System forms and applications to create, submit, search, and modify requests
• Receive and respond to AR System notifications
• Chart data
• Generate reports
• Display alerts in the Alert List form, which can be refreshed automatically at specified intervals or manually at any time
• Search records, run or generate reports, and view Flashboards

Developer clients

The developer clients are used to create, modify, and extend AR System applications. The following table briefly describes the tasks that you can carry out with the developer clients.

 AR System database server

AR System uses standard relational database engines for the actual storage and retrieval of data. Architecturally, the database server is an independent set of processes that are completely separate from the AR System server processes. Physically, the database server processes can be running on the same server host as the AR System server or on a different host. The database server can be any platform that the database engine supports. 

For information about supported platforms, see Compatibility matrix in the BMC Helix Innovation Suite Deployment online documentation.

Support for an external database

AR System can also work with data stored in external databases and other data sources that AR System does not manage. AR System accesses these data sources through view forms. In addition, AR System can use AR System database connectivity (ARDBC) to work with data not stored in databases as if the data were locally owned. In other words, ARDBC plug-ins can be created and configured to enable access to data stored outside the database as if it were in tables owned by AR System.

Support for multiple database types

Because the AR System server manages all workflow, applications are independent of the database. Therefore, applications created on a AR System server running one type of database can easily be moved to a server running a different type of database. BMC provides a simple export/import utility for this purpose.

AR System is not a database application in the typical sense. AR System server manages all of the workflow, so proprietary database features such as triggers and stored procedures are not used. An application created on an AR System server running one type of database engine can easily be moved to a server running a different database engine through a simple export-import process.

Support for database searches

AR System workflow components can search for records or requests in the AR System database and act on the results of the search. Clients can use the following types of searches:

• Query-by-example (QBE)
• Advanced search
• Predefined
• Recent

An administrator can create and store searches that users commonly perform. A user can define personal searches for forms to which the user has access.

Support for high availability and failover

AR System leverages common database architecture for high availability, including failover.

For tested configurations, see the Compatibility matrix.