Mid Tier architecture
While accessing the applications using , 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. does not close such windows, but a session timeout error is displayed if you perform any operations on them.
The requires an Oracle Java Server Pages (JSP) engine that supports.
Apache Tomcat is bundled with the and is installed by default.
The 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 .
The main components of the 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 . The object model provides a set of classes representing the data structures and functions of the API.
Centralized Configuration Tool for
—A tool that enables you to configure property settings. The settings are written to the file config.properties on the server. Settings include the list of 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 . It works with the components that support Web reports, which are installed with the , and with the installed JSP engine. By default, the Tomcat JSP engine is installed with , but you can use other compatible JSP engines. To use the Report Console, the plug-in server, the and web server, and a JSP engine must be running.
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 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
- caches definitions require fewer trips to the 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 environment
Administrators can configure a to launch a browser on another mid tier in a Hub and Spoke implementation or independently. For information about configuring this feature with , see Configuring-a-mid-tier-to-launch-a-browser-in-a-different-mid-tier.
A allows you to launch a browser on another so that users can work on records in a distributed environment. This feature allows you to link a central to one or more remote s (also known as federated s) to display forms residing on the remote . You configure only the servers that are running the as the central server.
Hub and Spoke overview
This feature is used by the Hub and Spoke implementation of . It can also be used independently without the Hub and Spoke implementation. For more information about Hub and Spoke capabilities in , 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 (the spoke ) is configured to a central (the hub ) for this feature, a support staffer can work with records from any of the remote to which his central is connected. The central receives and stores only a subset of the transactional data from the original record located on the remote . This feature allows a support staffer to seamlessly work with remote s in the Hub and Spoke scenario.
Without requiring authentication, the central system displays the remote transactional data in a new window on a workstation connected to the central . 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 and remote do not match, a browser launches on another as follows:
- If guest users are enabled on the remote , 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 , the user receives an authentication failure message from the . When reloading the page, the user is directed to the remote login page.
Scenario for launching a browser on another
Francie Stafford is a support staffer of Calbro Services, which supports several customers. Francie opens her Incident Management console (on the central ) 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 , see Configuring-a-mid-tier-to-launch-a-browser-in-a-different-mid-tier.
For information about configuring this feature within a hub and spoke system, see Registering hub and spoke servers.
architecture for Progressive Web Application
is capable of rendering a progressive web application (PWA) for a custom application. The following image represents the architecture of that involves a cross-launch from .
As part of the new architecture, the backend is used to leverage its generic and metadata-driven implementation, and the client-side rendering logic is changed to produce a user interface and experience that is similar to that of .
The core business logic and functional logic including Role Based Access Control (RBAC) exists in the application workflows. The ITSM data model also exists in the with the business logic in filters. and continue to work until the Progressive Web Application (PWA) technology completely replaces their functionality.
How PWA screens are viewed from
The following video shows some of the PWA screens in
You can enable opening of these PWA screens from by using the cross-launch settings configured in the Centralized Configuration. The following diagram illustrates how PWA screens are viewed from :
When a screen is available in PWA, screens are displayed from as described in the following steps, which illustrate the example of when a user views an incident ticket.
- The Incident screen is available as PWA, so 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 . The user views the incident and gets the incident details such as tasks and notes.
- sends the final response to the user.
The following list shows the information flow when a user accesses a screen that is available only in :
A. The request to view a screen is sent to the server because the interface is not available as PWA.
B. An authentication REST API call is sent to the server.
C. A user is logged in to .
D. displays the information to the user.
To learn more about enabling Progressive Views, see Enabling the Progressive Web Application screens in the documentation.