Roles and Features
Each tier in the architecture has a specific role in the operation of Oracle Utilities Operational Device Management. The sections below outline the roles and features of each tier.
Browser Client
The Browser User Interface (BUI) is a combination of HTML, JavaScript and Oracle JET for creating interactive web applications. This makes web pages more responsive by exchanging small amounts of data with the server, so that the entire page does not have to be reloaded each time the user makes a change. This increases the web page's interactivity, speed, and usability.
Note: Refer to the installation guide for the supported browsers and versions.
Note: In past releases, Adobe/Apache Flash Player was required for displaying and interacting with graphs. This is no longer required.
There are no ActiveX or Java components in the base product installation. This means that the deployment of the browser client is relatively simple as the only required component to use the product is a supported version of a web browser on the client machine. If the implementation requires ActiveX controls for extensions, then they can be added and used for the implementation.
The browser tier for this product is provided for the end users to access the product on a desktop. The client provides the following roles in the architecture:
• Screen Rendering and Caching – All the screens are rendered using standard HTML and JavaScript (not Java). The rendering is performed as the screen is served from the web application server and stored in the local browser cache.
• User Interaction – The client provides the user with the screen interaction. Once the page is rendered, the user can interact (manipulate data and screen elements) in accordance with their business transaction. The browser client is responsible for ensuring navigation and interaction with the user interface elements.
• User Context – The product is stateless and therefore the client stores the transactional context locally and passes this to the transaction as required. The client records the context of the transaction in the browser memory.
No business logic is stored on the client component.
Web Application Server
Oracle Utilities Operational Device Management is a set of Oracle WebLogic web applications that are housed in an Oracle WebLogic domain. The product and the web application server provide the following roles in the architecture:
• Authentication – The web application server software that houses the product provides adapters to common security repositories. This means that security products interfaced to the web application server software can be used in conjunction (with configuration) with the product.
• Managing Client connections – The web application server software manages any client connections (during and after they are authenticated) for processing and availability.
• Page Server – The major responsibility of the web application server is to serve pages to the client on demand. At start-up time (or at the first request for a particular page) the product generates the screens dynamically using metadata and rendering style sheets. These are cached for reuse locally.
• Cache Management – For performance reasons, the static data (usually metadata and configuration data) is cached in memory on the web application server.
No business logic is stored on the web application server component. The web application server component of the product is written in Java and JavaScript.
Business Application Server
Oracle Utilities Operational Device Management is a set of business applications that are housed in Oracle WebLogic (this can be the same instance of the web application server or a separate one). The product and the business application server provide the following roles in the architecture:
• Authorization – After authentication has been performed by the Web application server, the business application server is responsible for determining which functions and which data can be accessed.
• Data Integrity – The business application server contains the business logic to maintain referential integrity for the product data.
• Validation – The business application server contains the business logic that contains all the validation rules for the product data.
• Business Rules – The business application server contains the business logic that implements business rules and performs calculations.
• SQL – The business application server contains all the SQL statements and formats and processes results from those SQL statements.
The business application server Component of the product is written in Java.
Database Server
Oracle Utilities Operational Device Management contains a database schema within a database management system. The database server has the following roles in the architecture:
• Data Storage – The database is responsible for efficiently storing all data.
• Data Retrieval – The database is responsible for efficiently retrieving data using SQL provided by the business application server .
• Data Management – The database is responsible for efficiently managing all data.
No business logic is stored on the Database Server.
Note: Refer to the DBA Guide for your product for specific facilities supported by the Database Server.
Batch Server
Oracle Utilities Operational Device Management is known for its online (or foreground) processing (also known as online processing) but one of the major features of the product is its set of background processes. Background processing is a major part of the product with numerous background processes supplied as standard.
The easiest way to understand the concept behind background processing is to think that background processing is like a super efficient user that operates on a batch of objects. That is why background processing is commonly called Batch.
Note: For publishing purpose the term batch may also be used to denote background processing in this document.
Online typically operates on one object at a time, initiated by an online user or a web service call, where batch can operate on one or more objects (also known as a set of objects) at a time, initiated using several technologies.
Batch Processing Architecture
The main reasoning behind the super efficient user is that each background process consists of a driver object that identifies the set of valid objects to process and then processes each object through the same business objects that the online uses. For example, the BILLING driver determines which accounts are eligible to be billed according to business calendar and then passes each account to the rate object to produce a bill. Contrast this with online bill generation, where the user identifies the account manually, and then that single account is passed to the same rate object to be billed. The background process can call more than one object during the duration of the background process.
For the batch process, all of the database access and object access (including access to business objects, algorithms, user exits (server side only) etc is done through the Oracle Utilities Application Framework.
Background Processing and Architecture
The background processing component is run within the Oracle Utilities Application Framework and is associated typically with the business application server. It is not associated with the web application server nor requires for it to be active to operate. The only component other than product that the background processing component requires is the database server (or tier).
Depending on the initiation method employed the background processing component uses a standalone copy of the product to perform access to the database and business objects and its own copy of the same business objects used by the business application server.
Essentially the background processing has its own resources (Java Virtual Machines, connection pools) independent of the rest of the architecture and can therefore be run on the same hardware as the rest of the architecture or on dedicated hardware.
Batch Architecture Overview
The background processing component of the architecture is a scalable clustered batch approach that allows implementation, using configuration to spread the batch load across a clustered based architecture.
Batch Architecture Overview
The architecture has the following features:
• A background process cluster is defined using the inbuilt Oracle Coherence configuration. This cluster defines the group of hosts, either communicating through unicast or multicast, which will execute background processing threads.
Note: The Oracle Coherence implementation within the product uses a subset of the Oracle Coherence feature set, specifically Named (or Job) Caches.
• Within the cluster, the configuration defines threadpoolworkers (also known as workers). These are running Java Virtual machines where the batch processes are executed. Threadpoolworkers are named to segregate batch threads and can be clustered across hosts defined in the Coherence cluster. Threadpoolworkers are defined with a maximum limit on the number of threads supported per instance of the threadpool.
• Background processes are submitted (known as submitters) to the named threadpools either at a particular threadpool/host instance or automatically distributed across a threadpool across the cluster.
• A background process is defined within the metadata as a batch control (see Batch Controls) which defines the physical characteristics of the job as well as any configurable parameters of the background process.
• When a background process is executed, several threads (1 to many) are specified in the execution. Each thread will create Batch Instance records to track the progress of the job internally (exposed through the Batch Run Tree transaction within the product).
• Oracle Coherence is used, internally, to manage the communication between the cluster and all the members (such as workers and submitters) within that cluster. If a submitter or workers completes the thread or aborts, then the cluster is informed and synchronized to take this into account. For instance, in the case of a status change (completion or abort) the Batch Instance record is updated to reflect the state of the job.