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.

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.

Related topics

Centralized Configuration

AR-System-architecture

Enabling-Progressive-Web-Application

Developing-a-Progressive-Web-Application

While using Mid Tier to access the applications, you can open multiple browser windows by using workflows. All the forms opened with the workflows are closed after you log out. However, if you make any of the following changes to the open forms, Mid Tier does not close such windows, but a session timeout error is displayed if you perform any operations on them:

Change the URL in web address bar
Refresh the page
Access any other forms by typing a form name
Open a new browser window or tab and access other forms

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

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 servers 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 by 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.
Mid Tier caches AR System definitions which require fewer trips to the AR System server to retrieve them. In addition, use browser caching to reduce 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 means you can link a central Mid Tier to one or more remote Mid Tiers (also known as federated Mid Tiers) 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 of launching a browser on another Mid Tier, is used by the Hub and Spoke implementation of BMC Helix ITSM or independently. 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, that is the spoke AR System server, is configured to a central AR System server which is 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 servers 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 Apex Global, 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 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.

PWA screens available from Smart IT

End users can open the following PWA screens from Smart IT:

Incident
Work Order
Problem Investigation
Task
Known Error
Asset
People
Broadcast
Change

The following video shows some of the PWA screens in Smart IT

https://youtu.be/QwtOubSXdZ8

You can enable opening of these PWA screens from Smart IT by using the cross-launch settings configured in the Centralized Configuration. The following diagram illustrates how PWA screens are viewed from Smart IT:

When a screen is available in PWA, Mid Tier screens are displayed from Smart IT as described in the following steps, which illustrate the example of when a Smart IT user views an incident ticket.

The Incident screen is available as PWA, so Mid Tier is cross-launched from Smart IT so that the incident ticket can be viewed as PWA.
The Incident screen is available as PWA, so the user is redirected to Mid Tier. The user views the incident and gets the incident details such as tasks and notes.
Mid Tier sends the final response to the Smart IT user.

The following list shows the information flow when a Smart IT user accesses a screen that is available only in Smart IT:

A. The request to view a screen is sent to the Smart IT server because the interface is not available as PWA.

B. An authentication REST API call is sent to the Smart IT server.

C. A user logs in to BMC Helix ITSM.

D. BMC Helix ITSM displays the information to the user.

Important

Smart IT with PWA enabled is not supported on Internet Explorer (IE).

Browser navigation buttons and browser history might not work as expected when you open Mid Tier screens from Smart IT.
You should not simultaneously view Mid Tier and Smart IT screens enabled by progressive views through the same browser as it might cause issues with permissions.

To learn more about enabling Progressive Views, see Enabling Progressive Web Application screens in the BMC Helix ITSM documentation.