Mid Tier architecture

Mid Tier  serves as a client of the  AR System server  and as a server to a browser. The  Mid Tier  enables you to view  AR System  applications on the web and access the  AR System server  from a web server. It also provides instructions to the browser in the form of document markup and downloadable scripts. These instructions describe how to present application data and how to interact with the user.

Mid Tier  translates client requests, interprets responses from the server, handles web service requests, and runs server-side processes that bring  AR System  functionality to web and wireless clients. A browser is a generic client that has no inherent knowledge of any application that might run within it. By acting as an interpreter, the mid tier allows a browser to become a fully functional  AR System  client.

While accessing the applications using Mid Tier , you can open multiple browser windows using workflows. All the forms opened with the workflows are closed after you log out. But if you make any changes to the open forms (for example, change the URL in web address bar or refresh the page or access any other forms by typing form name) or if a new browser window or tab is opened and other forms are accessed. Mid Tier  does not close such windows, but a session timeout error is displayed if you perform any operations on them.

The Mid Tier  requires an Oracle Java Server Pages (JSP) engine that AR System  supports.

Apache Tomcat is bundled with the Mid Tier  and is installed by default.

The Mid Tier  leverages a Java servlet engine and includes a collection of servlets plugged in to the web server to serve forms, images, and other resources. The servlet engine facilitates communication between the browser and the web server. It provides components and add-in services that run on the web server. 

The web server manages the transfer of all HTML content to the browser. Infrastructure components, such as servlets and other services (special Java classes), translate client requests and interpret responses from the AR System server .

The main components of the Mid Tier  infrastructure are:

• Web server—A server that receives requests for a web page and maps the uniform resource locator (URL) to a local file or servlet on the host server. The server then loads the content and serves it across the network to the user's browser.
• Oracle JSP engine—An engine that handles the .jsp files and the basic request and response interface in the browser environment.
• Oracle JSP servlets—A small piece of Java code (often translated from a .jsp file) that runs on a web server.
• JAVA API—An API used to communicate with the AR System server . The object model provides a set of classes representing the data structures and functions of the API.
• Centralized Configuration Tool for Mid Tier —A tool that enables you to configure Mid Tier  property settings. The settings are written to the file config.properties on the Mid Tier  server. Settings include the list of AR System server s to access, session time-out interval, directory locations, reporting tool options, logging options, cache policy options, connections for load balancing, flashboard options, home page server options, and user authentication for web services. The Centralized Configuration Tool is accessible through a .jsp file in a browser. For more information, see Accessing the Mid Tier Configuration Tool.
• Report Console—An ARDBC plug-in application that is installed with AR System . It works with the components that support Web reports, which are installed with the Mid Tier , and with the installed JSP engine. By default, the Tomcat JSP engine is installed with AR System , but you can use other compatible JSP engines. To use the Report Console, the plug-in server, the  Mid Tier  and web server, and a JSP engine must be running. 

Mid Tier  scalability

The strategy for processing and serving browser-client requests is based on several components. These components work together to take input from the client and compute a response that the user sees in the browser as dynamic HTML (DHTML). These Mid Tier  components do not run in a separate proprietary process, but in the JSP engine using standard web protocols.

The use of JSP servlets makes the mid tier scalable in the following ways:

• Multiple threads connecting to a servlet can handle many concurrent users.
• Common web-server mechanisms and practices can be used for scaling and load balancing. See Mid Tier architecture
• Mid Tier  caches AR System  definitions require fewer trips to the AR System server  to retrieve them. In addition, using browser caching reduces data size, which in turn reduces bandwidth requirements. See Best practices for configuring mid tier cache.

Additionally, the architecture supports server clusters, or web farms that are hardware setups in which several physical web servers share the load directed to one logical server (one IP address). In a web farm, a load balancer receives requests and sends them to whichever physical server has the most resources available to handle them.

Multiple browser sessions in a distributed  Mid Tier  environment

Administrators can configure a  Mid Tier  to launch a browser on another mid tier in a Hub and Spoke implementation or independently. For information about configuring this feature with AR System , see Configuring a mid tier to launch a browser in a different mid tier.

A Mid Tier  allows you to launch a browser on another  Mid Tier  so that users can work on records in a distributed Mid Tier  environment. This feature allows you to link a central Mid Tier to one or more remote  Mid Tier s (also known as federated  Mid Tier s) to display forms residing on the remote  AR System server . You configure only the servers that are running the AR System server as the central server.

Hub and Spoke overview

This feature is used by the Hub and Spoke implementation of BMC Helix ITSM . It can also be used independently without the Hub and Spoke implementation. For more information about Hub and Spoke capabilities in BMC Helix ITSM , see Hub and Spoke capability overview .

The Hub and Spoke implementation displays a consolidated list of tickets from a central console for a support staffer. This architecture efficiently maintains data integrity and country boundary rules.

When a remote AR System server  (the spoke AR System server ) is configured to a central AR System server  (the hub AR System server ) for this feature, a support staffer can work with records from any of the remote AR System server  to which his central AR System server  is connected. The central AR System server  receives and stores only a subset of the transactional data from the original record located on the remote AR System server . This feature allows a support staffer to seamlessly work with remote AR System server s in the Hub and Spoke scenario.

Without requiring authentication, the central system displays the remote transactional data in a new Mid Tier  window on a workstation connected to the central AR System server . The support staffer can open the record from the remote server, view the record's details, and work the record through its lifecycle.

If the user name and password for the user on the central AR System server  and remote AR System server  do not match, a browser launches on another Mid Tier  as follows:

• If guest users are enabled on the remote AR System server , the user is logged in as a guest user and has guest user privileges. The user receives a guest user warning message.

• If guest users are not enabled on the remote AR System server , the user receives an authentication failure message from the Mid Tier . When reloading the page, the user is directed to the remote Mid Tier  login page.

Scenario for launching a browser on another Mid Tier

Francie Stafford is a support staffer of Calbro Services, which supports several customers. Francie opens her Incident Management console (on the central AR System server ) and sees several newly assigned incident requests, one each from Company A, Company B, and Company C. When Francie opens the new incident request from Company A, she is automatically connected to the appropriate remote server. She can then view the incident request details and work the incident request through its lifecycle.

If a user has multiple records open in multiple remote windows when working with central and remote (hub and spoke) servers, logging off of one remote window invalidates the session that is established for all open remote windows. The remaining sessions become invalid even if they appear active. Before logging off from any remote window, be sure that you complete and save your work.

For information about configuring this feature with an AR System , see Configuring a mid tier to launch a browser in a different mid tier.

For information about configuring this feature within a BMC Helix ITSM: Asset Management  hub and spoke system, see Registering hub and spoke servers .

Mid Tier  architecture for Progressive Web Application

Mid Tier is capable of rendering a progressive web application (PWA) for a custom application. The following image represents the architecture of Mid Tier that involves a cross-launch from Smart IT .

As part of the new architecture, the Mid Tier backend is used to leverage its generic and AR System metadata-driven implementation, and the client-side rendering logic is changed to produce a user interface and experience that is similar to that of Smart IT .

The core business logic and functional logic including Role Based Access Control (RBAC) exists in the BMC Helix ITSM application workflows. The ITSM data model also exists in the AR System with the business logic in filters. Smart IT and Mid Tier continue to work until the Progressive Web Application (PWA) technology completely replaces their functionality.

Enabling the Progressive Web Application screens