Remedy Mid Tier architecture

Remedy Mid Tier serves as a client of the Remedy AR System server and as a server to a browser. The mid tier enables you to view Remedy AR System applications on the web and access the Remedy 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.

Remedy Mid Tier translates client requests, interprets responses from the server, handles web service requests, and runs server-side processes that bring Remedy 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 Remedy AR System client.

The Remedy Mid Tier requires a Oracle Java Server Pages (JSP) engine, that is supported by Remedy AR System. For a list of supported engines, see  Compatibility matrix  in the Remedy ITSM Deployment online documentation. Apache Tomcat is bundled with the mid tier and is installed with the mid tier 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 Remedy 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 Remedy AR System server. The object model provides a set of classes representing the data structures and functions of the API.

Centralized Configuration Tool for Remedy Mid Tier

The Centralized Configuration Tool for Remedy Mid Tier 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 Remedy 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.

Remedy Mid Tier Configuration Tool is accessible through a .jsp file in a browser. For more information, see Accessing the Mid Tier Configuration Tool.

Report Console overview

To use the Report Console, the plug-in server, the mid tier and web server, and a JSP engine must be running. The Report Console is an ARDBC plug-in application that is installed with Remedy AR System. It works with the components that support Web reports, which are installed with the Remedy Mid Tier, and with the installed JSP engine. By default, the Tomcat JSP engine is installed with Remedy AR System, but you can use other compatible JSP engines.

For the most current information about supported web servers and JSP engines, see  Compatibility matrix  in the Remedy ITSM Deployment online documentation.

Remedy 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 Remedy 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, Parameters to support load balancers between Remedy Mid Tier and server group without a sticky bit.
• Remedy Mid Tier caches Remedy AR System definitions require fewer trips to the Remedy AR System server to retrieve them. In addition, use of browser caching leads to data size reductions, which in turn reduces bandwidth requirements. See, About Mid Tier caching.

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 form, 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 Remedy 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 tiers (also known as federated mid tiers) to display forms residing on the remote Remedy AR System server(s).

This feature is used by the Hub and Spoke implementation of Remedy IT Service Management (Remedy ITSM). It can also be used independently without the Hub and Spoke implementation. For more information about Hub and Spoke capabilities in Remedy ITSM, see Hub and Spoke capability overview.

Hub and Spoke 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 Remedy AR System server (the spoke Remedy AR System server) is configured to a central Remedy AR System server (the hub Remedy AR System server) for this feature, a support staffer can work with records from any of the remote Remedy AR System servers to which his central Remedy AR System server is connected. The central Remedy AR System server receives and stores only a subset of the transactional data from the original record located on the remote Remedy AR System server. This feature allows a support staffer to seamlessly work with remote Remedy 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 Remedy 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.

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

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

For information about configuring this feature within a Remedy IT Service Management Suite hub and spoke system, see Registering hub and spoke servers.

Remedy Mid Tier architecture for Progressive Web Application

Remedy Mid Tier is capable of rendering a progressive web application (PWA) for a custom Remedy application.

The following image represents the interim architecture of Remedy Mid Tier that involves a cross-launch from Smart IT. This interim architecture contains only the Smart IT forms that have been converted to PWA. Conversion of the rest of the forms is still in progress as of the Remedy 20.08 release.

As part of the new architecture, the mid tier back end is used to leverage its generic and AR metadata driven implementation and the client-side rendering logic is changed to produce a UI and UX similar to that of Smart IT.

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

To learn more about enabling Progressive Views for work orders and incidents, see  Enabling the Progressive Web Application screens  in Smart IT online documentation.

Related topics

Centralized Configuration

Remedy AR System architecture

Enabling Progressive Web Application

Developing a Progressive Web Application