![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
||
Previous | Next | Contents | Index | Library |
Figure 1 - 1. Product Architecture
See the detailed sections below:
The following definitions will help you to understand the big picture of Oracle Self-Service Web Applications.
Flow A series of web pages, each of which can display data. The pages that make up a flow are bound together by complex definitions. Specifically, flows are comprised of pages, page regions, and region items.
HTML (HyperText Markup Language) A format for encoding hypertext documents that may contain text, graphics, and references to programs, and references to other hypertext documents. HTML is a subset of Standard Generalized Markup Language (SGML).
HTTP (HyperText Transfer Protocol) A protocol used to request documents from the web server.
Javascript Javascript is a scripting language that adds significant power to HTML files without the need for server-based CGI programs.
Web Applications Dictionary An Oracle Forms-based tool used to create web inquiries.
Web Request Broker (WRB) Cartridges WRB applications, implemented as a shared library, uses the WRB API to handle HTTP requests from web clients. Cartridges can be developed in any language and then integrated with the WRB through the WRB API.
Web Browser The client user interface component. The browser you use must support tables and frames and be Javascript enabled. The embedded Javascript code in Oracle Web Customers, Oracle Web Employees, and Oracle Web Suppliers provides a mechanism for client side caching of user-entered data during a transaction, and simple client side validation of user-entered data. Execution of simple Javascript code logic at the client side results in reduced network traffic between the web browser client and the web server.
Oracle WebServer Oracle Web Customers, Oracle Web Employees, and Oracle Web Suppliers, Release 11 requires Oracle WebServer 3.0 or above. WebServer 3.0 is Oracle's standard HTTP server that offers an open, extensible application development platform for the Web. This enables secure, high speed transactions with the Oracle8 RDBMS.
Oracle WebServer is designed to be a scalable, high-performance network daemon. It is implemented as a multi-threaded, single-process asynchronous engine, allowing multiple concurrent requests to be processed at the same time using standard HTTP or HTTP over SSL.
Web Listener A component of Oracle WebServer responsible for delivering incoming requests to the Web Request Broker, where they are processed or dispatched to services built with the WebServer Software Development Kit (SDK). The HTTP server is the network layer component of Oracle WebServer. It listens for incoming HTTP requests, delivers static files, and runs simple CGI programs. The HTTP server transfers everything else to the Web Request Broker (WRB), where a request is handled by a server extension.
The first generation of web sites on the Internet only offered static HTML files to their visitors. To enable dynamic content, web designers usually use CGI to extend the capabilities of their web server. Although easy to use, CGI has limitations, primarily the high overhead of spawning a new process for each incoming request, which causes degradation in scalability and throughput.
Currently, several web servers have defined an API for implementing extensions to the basic HTTP engine. The typical HTTP API enables a custom extension to be linked into the HTTP server process and allows it to intercept and fulfill a client request. Examples of such APIs are Netscape NSAPI, Spyglass ADI, and Microsoft IS-API. These APIs are becoming increasingly popular because they address the shortcomings of the original CGI protocol.
To compensate, Oracle WebServer 3.0 is layered into two fundamental components: an HTTP engine (Oracle Web Listener) and a high-speed dispatch mechanism (the Web Request Broker) that routes requests to server extensions running in separate processes.
Web Request Broker (WRB) An asynchronous request handler with an API (Application Program Interface) that enables it to interface dynamically and seamlessly to various back-end technologies called "WRB Cartridges." It provides an architecture that allows server-side web applications to run under any HTTP server to which the WRB has been ported.
WRB applications, called cartridges, take advantage of the WRB's multi-process architecture to get higher performance than ordinary CGI scripts. The WRB architecture also makes WRB cartridges extremely scaleable--they can handle small request loads economically and large request loads efficiently.
The cartridge used by Oracle Web Customers, Oracle Web Employees, and Oracle Web Suppliers is the PL/SQL Agent. This cartridge executes PL/SQL commands stored in the database.
Other cartridges that are not used by Oracle Web Customers, Oracle Web Employees, and Oracle Web Suppliers, but are available through Oracle WebServer 3.0 are mentioned here for informational purposes:
Java Cartridge | Enables you to execute Java on the server to generate dynamic web pages. |
LiveHTML | Enables the inclusion of output from programs supported by your operating system in your web pages. |
Custom Cartridges | Since the WRB uses an open API, you can write your own cartridges to use it. Currently, only the C language is used to write WRB cartridges. In the future, however, the WRB API will also be available in other languages. |
Third-Party Cartridges | Various independent vendors write cartridges for the WRB's open API. |
When the Dispatcher receives a request, it determines the WRB cartridge to which the request is directed, and directs the WRB to allocate an execution instance (WRBX) of that cartridge. The Dispatcher then dispatches the request to that WRBX. An execution instance of a WRB cartridge is a process running a program composed of two parts: a copy of the WRB application engine, and the WRB cartridge shared library.
The WRB application engine is the executable program that implements the WRB API and runs within each WRBX. It provides the interface between WRB cartridges and the Dispatcher, directs WRB cartridge flow of control, and provides services for WRB cartridges to use.
Figure 1 - 2. WRB cartridge instance creation in response to a request
The Dispatcher may then forward future requests directly to the cartridge instance and receive responses from the cartridge directly. The WRB configuration data specifies the maximum number of WRBXs that may run at once for each cartridge, and the minimum number of WRBXs that must always be running. You can tune the WRB performance by adjusting these values using the Web Request Broker administration pages.
When the Web Listener receives a request for WRB, it forwards the request to the WRB dispatcher. The dispatcher works like a traffic director, redirecting requests to the appropriate cartridges. If the dispatcher determines that the URL is a request for the PL/SQL agent, the dispatcher forwards the URL to the PL/SQL agent.
Not only does the Dispatcher redirect requests, but it controls the number of WRBX processes running at any one time. If a request comes in for the PL/SQL agent and there is no WRBX running, the Dispatcher starts a WRBX. If many requests come in for the PL/SQL agent, the Dispatcher can distribute the load by starting multiple WRBX processes. If there are no requests coming in for a WRBX, the Dispatcher can shut down WRBX processes.
Figure 1 - 3. The web browser serving a dynamic page based on a PL/SQL request
illustrates the sequence of events:
http://<machine>:<port>/<dcd_name>/<owa>/<stored procedure>
In the following example
http://19sun.us.oracle.com:9333/ic/owa/Oracle/OracleApps.VL
19sun.us.oracle.com:9333 is the pointer to the web server which is listening on port 9333, owa is the directory path which has an entry in the WRB configuration file and indicates the request should route to the PL/SQL agent, and OracleApps.VL is the stored procedure, which is executed.
The DCD name specifies which database to connect to, what user to connect as, and how to connect to the database. Different DCDs allow access to different databases or schema using the same Web Listener. Each DCD specifies a username, password, database to connect to, and specifies how to connect to the database.
When it is called, the PL/SQL agent executes a stored procedure. This procedure is responsible for retrieving data and returning results in HTML format. By writing to an extension to the database standard output, an HTML document is generated via a PL/SQL stored procedure containing the appropriate data retrieved from the database. Within this generated page, there may be embedded Javascript code. Once the page is generated, it is returned to the client for display on a standard browser.
Workflows are defined using the Workflow Builder, a Windows GUI interface that enables users to design the business process, the activities, items, messages and lookup lists, and roles (the approval chain). This workflow is then integrated into the business transaction process. For Web Employees, it is integrated with the requisition approval process.
Notifications generated in the workflow chain can be viewed with the Oracle Self-Service Web Applications or a Workflow-supported email system.
Oracle Web Employees includes a predefined workflow process to generate offer letters.
All workflow processes are customizable. See: Oracle Workflow.
The Web Applications Dictionary provides a means of defining business flows which can then be web-enabled using the existing functionality provided by Oracle Web Customers, Oracle Web Employees, and Oracle Web Suppliers. All inquiry flows shipped with Oracle Web Customers, Oracle Web Employees, and Oracle Web Suppliers were built using Web Applications Dictionary. These can be customized as needed.
The Web Applications Dictionary is part of Oracle Applications, Release 11, and is part of the named "AK Common Modules". Once installed, it is accessed in the same manner as all of the core Oracle Applications.
See: Web Applications Dictionary.
Web Transactions enable users to perform two simple transactions: place an order and enter a requisition. These transactions insert data into open interface tables. Data is then validated and then loaded into the core Oracle Applications production tables.
Figure 1 - 4. Web Inquiries
A web inquiry, or "flow", is a series of hyperlinked web pages. Standard flows are predefined to allow users to easily navigate through web pages to access relevant information. These navigation flows are designed based on common business inquiry processes, and are built using Web Applications Dictionary. For example, a user can log in and request the View Purchase Orders inquiry. Once the data displays, the user can hyperlink to invoices and receipts related to the retrieved purchase orders.
Oracle Self-Service Web Applications (product code "ICX") packages contain PL/SQL functions and procedures that access Web Applications Dictionary (product code "AK") objects to retrieve information for the display elements and actual applications data. The Web Applications Dictionary has a run time execution engine that generates dynamic PL/SQL based on the ICX views. These views are based on those provided by the standard Oracle Applications.
Figure 1 - 5. The process of performing a web transaction
The diagram above depicts the process of performing a web transaction (e.g., order entry) and the key components involved. A user who wants to enter a sales order uses a web browser to access the Web Store component of Oracle Customers. When the user enters lines on the order, the line data is stored at the client using Javascript technology. When the user submits the order, data is passed to the PL/SQL agent, which executes PL/SQL procedures to store the sales order data in the ICX shopping cart temporary tables. Finally, the data is loaded into the standard Order Entry Open Interface tables.
The batch interface OrderImport program in Oracle Order Entry then reads the open interface tables, performs necessary validations, and finally loads the data into Order Entry production tables. A source parameter can be set for the OrderImport program so that only imports those records entered via the web.
Oracle Web Customers, Oracle Web Employees, and Oracle Web Suppliers only provide the logic to insert data into the open interface tables, leaving all validation logic to existing open interface programs.
The coding logic provided by Oracle Web Customers, Oracle Web Employees, and Oracle Web Suppliers is mainly for building the user interface elements of the web. There is little transaction code; only limited Javascript logic for data caching at the client. Oracle Web Customers, Oracle Web Employees, and Oracle Web Suppliers leverage the applications business logic provided by standard Oracle Applications by using its open interfaces.
Previous | Next | Contents | Index | Library |