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.
While accessing the applications using Remedy Mid Tier, you can open multiple browser windows using workflows. All the forms opened using the workflows are closed after you log out. But if you make any changes to open the 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. Such windows are not closed by the mid tier after you log out, but a session timeout error is displayed if you perform any operations on them.
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 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:
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.
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 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).
You configure only the servers that are running the Remedy AR System Server as the central server.
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.
If the user name and password for the user on the central Remedy AR System server and remote Remedy AR System server do not match, then a browser launches on another mid tier as follows:
- If guest users are enabled on the remote Remedy AR System server, then 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 Remedy AR System server, then 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.
If the remote mid tier is from a release earlier than 8.1, the user is directed to the remote mid tier login page for authentication.
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.
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 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.
Smart IT with PWA enabled is not supported on Internet Explorer (IE).
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.
Cross-launch of PWA from Smart IT
You can access work orders and incident screens from Smart IT browser. A cross-launch of PWA from Smart IT is required because not all Smart IT screens are converted to PWA currently. Therefore, the system handles the transition between PWA and regular Smart IT views automatically.
The following diagram illustrates cross-launch of PWA from Smart IT:
When a Smart IT user accesses an incident ticket:
- The Incident screen in available as PWA. Therefore, Mid tier is cross-launched from Smart IT so that the incident ticket can be viewed as PWA.
- The incident screen is available as a PWA. Therefore, the user is redirected to Mid Tier. The user views the incident and gets the incident details such as, tasks, notes.
- Mid Tier sends the final response to the Smart IT user.
When a Smart IT user accesses a problem ticket:
- The request to view a problem ticket is sent to the Smart IT server because the Problem screen is not available as PWA.
- An authentication REST API call is sent to Smart IT server.
- A user is logged into Remedy ITSM.
- A user receives problem related information such as, problem and relations.
To learn more about enabling Progressive Views for work orders and incidents, see in Smart IT online documentation.