WO1999015976A1 - Interface mandataire integree pour ensemble d'outils demandeurs de rapports basee sur le web - Google Patents

Interface mandataire integree pour ensemble d'outils demandeurs de rapports basee sur le web Download PDF

Info

Publication number
WO1999015976A1
WO1999015976A1 PCT/US1998/020144 US9820144W WO9915976A1 WO 1999015976 A1 WO1999015976 A1 WO 1999015976A1 US 9820144 W US9820144 W US 9820144W WO 9915976 A1 WO9915976 A1 WO 9915976A1
Authority
WO
WIPO (PCT)
Prior art keywords
report
server
user
customer
data
Prior art date
Application number
PCT/US1998/020144
Other languages
English (en)
Inventor
Carol Y. Devine
Tammy E. Dollar
Wayne J. Munguia
Edward Schwarz
Original Assignee
Devine Carol Y
Dollar Tammy E
Munguia Wayne J
Edward Schwarz
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Devine Carol Y, Dollar Tammy E, Munguia Wayne J, Edward Schwarz filed Critical Devine Carol Y
Priority to AU96674/98A priority Critical patent/AU9667498A/en
Publication of WO1999015976A1 publication Critical patent/WO1999015976A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising

Definitions

  • the present invention relates generally to information delivery systems and, particularly, to a novel, WWW/Internet -based, reporting service for customers requesting information located at remote back-end intranet servers of telecommunications service entities .
  • Major telecommunications service entities e.g., MCI, AT&T, and Sprint, presently provide for the presentation and dissemination of customer account and network management information to their customers predominantly through a Windows -based graphical user interface resident on their computer workstation.
  • service entity customers are enabled to directly dial-up, e.g., via a modem, or, alternately, via dedicated communication lines, e.g., ISDN, T-l, etc., to the entity's application and database servers, and initiate the generation of reports of their requested account information through the reporting GUI.
  • the report requests initiated by the customer are processed by the entity's application server, which retrieves the requested customer information from one or more databases, processes and formats the information for downloading to the client's reporting GUI.
  • MCI's Service View platform provides for the generation of Toll-free Network Management data, priced call detail or “Perspective” data for usage analysis and trending, and unpriced call detail or real-time “TrafficView” data each of which requires a different reporting mechanism due to the nature of the data being presented. For example, much of the customers "Perspective" data is provided in a CD-ROM media and shipped to the customer, usually on a monthly basis, and requires extensive client -side processing to utilize the data.
  • reporting systems typically do not provide any report customization or presentation options for the customer, and any reporting customization is provided by an application specific program running on the client workstation. Furthermore, such systems do not readily provide for the scheduling of periodic or ad hoc "one -shot" reports.
  • Intranet/Internet/Web-based reporting system that provides a common GUI enabling both report requesting, customizing and viewing of various types of data from different server applications.
  • Intranet/Internet/Web-based reporting system including a report manager and requesting tool that manages the generation and presentation of specific reports that are available to customers, and enables specific report customization and scheduling options.
  • Intranet/Internet/Web-based reporting system infrastructure capable of providing for the secure initiation, acquisition and presentation of customer reports to customers from any computer workstation running a browser located anywhere in the world.
  • the present invention is directed to a novel
  • Intranet/Internet/Web-based reporting system that provides a common GUI enabling the requesting, customizing, scheduling and viewing of various types of reports generated by different server applications and/or application platforms. More specifically, the present invention includes an Intranet/Internet/Web- based reporting system infrastructure employing report manager and report scheduler server components, and report requestor and viewer client components enabling customers to define various reports relating to their telecommunications network usage, in addition to managing the generation and presentation of specific reports.
  • This infrastructure employs novel authentication and security features providing for the secure acquisition and compilation of customer reporting data, configuration and generation of reports, and presentation of reports on the customers workstation via a standard web browser.
  • FIG. 2 is a diagrammatic overview of the software architecture of the networkMCI Interact system
  • Figure 3 is an illustrative example of a backplane architecture schematic- Figure 4 illustrates an example client GUI presented to the client/customer as a browser web page;
  • Figure 5 is a diagram depicting the physical networkMCI Interact system architecture;
  • Figure 6 is a block diagram depicting the physical architecture of the StarWRS component of networkMCI Interact system
  • Figures 7 (a) - 7 (d) illustrate flow diagrams depicting the report request/scheduling process 600 implemented by StarWRS Report Manager and Report
  • Figure 8 illustrates an example Web/Internet - based home page screen providing general menu of customer options
  • Figures 9 (a) -9(h) illustrate various examples of report requestor screen dialogs enabling user customization of report requests.
  • Figure 10 (a) illustrates an example browser based message center screen dialog;
  • Figure 10 (b) illustrates an example report viewer dialog box used for requesting view of available generated reports;
  • Figures 11(a) -11(b) illustrate flow diagrams depicting the perpetually running, report request running/scheduling process 600;
  • Figure 12 illustrates a logical message format sent from the client browser to the desired middle tier server for a particular application
  • Figures 13 (a) and 13 (b) are schematic illustrations showing the message format passed between the Dispatcher server and the application specific proxy ( Figure 13 (a) ) , and the message format passed between the application specific proxy back to the Dispatcher server ( Figure 13 (b) ) .
  • Figures 14 (a) -14(c) illustrate a low level logic diagram depicting the multi - threaded proxy process .
  • the present invention is one component of an integrated suite of customer network management and report applications using a Web browser paradigm.
  • a networkMCI Interact system such an integrated suite of Web -based applications provides an invaluable tool for enabling customers to manage their telecommunication assets, quickly and securely, from anywhere in the world.
  • the nMCI Interact system architecture is basically organized as a set of common components comprising the following: 1) an object-oriented software architecture detailing the client and server based aspect of nMCI Interact; 2) a network architecture defining the physical network needed to satisfy the security and data volume requirements of the networkMCI System;
  • FIG. 1 is a diagrammatic illustration of the software architecture component in which the present invention functions.
  • a first or client tier 10 of software services are resident on a customer work station 10 and provides customer access to the enterprise system, having one or more downloadable application objects directed to front end business logic, one or more backplane service objects for managing sessions, one or more presentation services objects for the presentation of customer options and customer requested data in a browser recognizable format and a customer supplied browser for presentation of customer options and data to the customer and for internet communications over the public Internet.
  • a second or middle tier 12 is provided having secure web servers and back end services to provide applications that establish user sessions, govern user authentication and their entitlements, and communicate with adaptor programs to simplify the interchange of data across the network.
  • a third or back end tier 15 having applications directed to legacy back end services including database storage and retrieval systems and one or more database servers for accessing system resources from one or more legacy hosts.
  • the customer workstation includes client software capable of providing a platform- independent, browser-based, consistent user interface implementing objects programmed to provide a reusable and common GUI abstraction and problem- domain abstractions.
  • client- tier software is created and distributed as a set of Java classes including the applet classes to provide an industrial strength, object-oriented environment over the Internet.
  • Application- specific classes are designed to support the functionality and server interfaces for each application with the functionality delivered through the system being of two -types: 1) cross-product, for example, inbox and reporting functions, and 2) product specific, for example, toll free network management or Call Manager functions.
  • the system is capable of delivering to customers the functionality appropriate to their product mix.
  • FIG. 2 is a diagrammatic overview of the software architecture of the networkMCI Interact system including: the Customer Browser (a.k.a. the Client) 20; the Demilitarized Zone (DMZ) 17 comprising a Web
  • the Customer Browser 20 is browser enabled and includes client applications responsible for presentation and front -end services. Its functions include providing a user interface to various MCI services and supporting communications with MCI's Intranet web server cluster 24.
  • the client tier software is responsible for presentation services to the customer and generally includes a web browser 14 and additional object - oriented programs residing in the client workstation platform 20.
  • the client software is generally organized into a component architecture with each component generally comprising a specific application, providing an area of functionality.
  • the applications generally are integrated using a "backplane" services layer 12 which provides a set of services to the application objects which provide the front end business logic and manages their launch.
  • the networkMCI Interact common set of objects provide a set of services to each of the applications such as: 1) session management; 2) application launch; 3) inter- application communications; 4) window navigation among applications; 5) log management; and 6) version management .
  • the primary common object services include: graphical user interface (GUI); communications; printing; user identity, authentication, and entitlements; data import and export; logging and statistics; error handling; and messaging services.
  • GUI graphical user interface
  • Figure 3 is a diagrammatic example of a backplane architecture scheme illustrating the relationship among the common objects.
  • the backplane services layer 12 is programmed as a Java applet which can be loaded and launched by the web browser 14.
  • a typical user session starts with a web browser 14 creating a backplane 12, after a successful logon.
  • the backplane 12 presents a user with an interface for networkMCI Interact application management.
  • a typical user display provided by the backplane 12 may show a number of applications the user is entitled to run, each application represented by buttons depicted in Figure 3 as buttons 58a, b,c selectable by the user.
  • the backplane 12 launches that specific application, for example, Service Inquiry 54a or Alarm Monitor 54b, by creating the application object.
  • Service Inquiry 54a or Alarm Monitor 54b may utilize common object services provided by the backplane 12.
  • Figure 3 shows graphical user interface objects 56a, b created and used by a respective application 54a, b for its own presentation purposes.
  • Figure 4 illustrates an example client GUI presented to the client/customer as a browser web page 80 providing, for example, a suite 70 of network management reporting applications including: MCI Traffic Monitor 72; an alarm monitor 73; a Network Manager 74 and Intelligent Routing 75. Access to network functionality is also provided through Report Requester 76, which provides a variety of detailed reports for the client/customer and a Message Center 77 for providing enhancements and functionality to traditional e-mail communications.
  • Report Requester 76 provides a variety of detailed reports for the client/customer and a Message Center 77 for providing enhancements and functionality to traditional e-mail communications.
  • the browser resident GUI of the present invention implements a single object, COBackPlane which keeps track of all the client applications, and which has capabilities to start, stop, and provide references to any one of the client applications.
  • the backplane 12 and the client applications use a browser 14 such as the Microsoft Explorer versions 4.0.1 or higher for an access and distribution mechanism.
  • the client applications are generally isolated from the browser in that they typically present their user interfaces in a separate frame, rather than sitting inside a Web page.
  • COBackPlane 12 is an application backplane which launches the applications 54a, 54b, typically implemented as COApp.
  • COBackPlane 12 is generally implemented as a Java applet and is launched by the Web browser 14. This backplane applet is responsible for launching and closing the COAp s .
  • the backplane When the backplane is implemented as an applet, it overrides standard Applet methods init(), start () , stopO and run ( ) .
  • the backplane applet obtains a COUser user context object.
  • the COUser object holds information such as user profile, applications and their entitlements.
  • the user's configuration and application entitlements provided in the COUser context are used to construct the application toolbar and Inbox applications.
  • launchAppO method When an application toolbar icon is clicked, a particular COApp is launched by launchAppO method.
  • the launched application then may use the backplane for inter - application communications, including retrieving Inbox data.
  • the COBackPlane 12 includes methods for providing a reference to a particular COApp, for interoperation.
  • the COBackPlane class provides a getApp ( ) method which returns references to application objects by name. Once retrieved in this manner, the application object's public interface may be used directly.
  • the aforesaid objects will communicate the data by establishing a secure TCP messaging session with one of the DMZ networkMCI Interact Web servers 24 via an Internet secure communications path 22 established, preferably, with a secure sockets SSL version of HTTPS .
  • the DMZ networkMCI Interact Web servers 24 function to decrypt the client message, preferably via the SSL implementation, and unwrap the session key and verify the users session.
  • a networkMCI Interact session is designated by a logon, successful authentication, followed by use of server resources, and logoff.
  • HTTP HyperText Transfer Protocol
  • each HTTP request and reply is a separate TCP/IP connection, completely independent of all previous or future connections between the same server and client.
  • the nMCI Interact system is implemented with a secure version of HTTP such as S-HTTP or HTTPS, and preferably utilizes the SSL implementation of HTTPS.
  • the preferred embodiment uses SSL which provides a cipher spec message which provides server authentication during a session.
  • the preferred embodiment further associates a given HTTPS request with a logical session which is initiated and tracked by a "cookie jar server” 28 to generate a "cookie” which is a unique server-generated key that is sent to the client along with each reply to a HTTPS request.
  • the client holds the cookie and returns it to the server as part of each subsequent HTTPS request.
  • either the Web servers 24, the cookie jar server 28 or the Dispatch Server 26 may maintain the "cookie jar” to map these keys to the associated session.
  • a separate cookie jar server 28, as illustrated in Figure 2 has been found desirable to minimize the load on the dispatch server 26.
  • This form of session management also functions as an authentication of each HTTPS request, adding an additional level of security to the overall process.
  • the dispatch server 26 will unwrap an outer protocol layer of the message from the DMZ services cluster 24, and will reencrypt the message with symmetric encryption and forward the message to an appropriate application proxy via a third TCP/IP socket 27. While waiting for the proxy response all three of the sockets 22, 23, 27 will be blocking on a receive.
  • the wrappers are examined to reveal the user and the target middle- tier (Intranet application) service for the request. A first- level validation is performed, making sure that the user is entitled to communicate with the desired service.
  • the user's entitlements in this regard are fetched by the dispatch server 26 from StarOE server 49 at logon time and cached.
  • Each application proxy is an application specific daemon which resides on a specific Intranet server, shown in Figure 2 as a suite of mid- range servers 30.
  • Each Intranet application server of suite 30 is generally responsible for providing a specific back-end service requested by the client, and, is additionally capable of requesting services from other Intranet application servers by communicating to the specific proxy associated with that other application server.
  • an application server not only can offer its browser a client to server interface through the proxy, but also may offer all its services from its proxy to other application servers.
  • the application servers requesting service are acting as clients to the application servers providing the service. Such mechanism increases the security of the overall system as well as reducing the number of interfaces.
  • the network architecture of Figure 2 may also include a variety of application specific proxies having associated Intranet application servers including: a StarOE proxy for the StarOE application server 39 for handling authentication order entry/billing; an Inbox proxy for the Inbox application server 31, which functions as a container for completed reports, call detail data and marketing news messages, a Report Manager Proxy capable of communicating with a system- specific Report Manager server 32 for generating, managing and receiving notification of customized reports including, for example: call usage analysis information provided from the StarODS server 33; network traffic analysis/monitor information provided from the Traffic view server 34; virtual data network alarms and performance reports provided by Broadband server 35; trouble tickets for switching, transmission and traffic faults provided by Service Inquiry server 36; and toll free routing information provided by Toll Free Network Manager server 37.
  • a StarOE proxy for the StarOE application server 39 for handling authentication order entry/billing
  • an Inbox proxy for the Inbox application server 31 which functions as a container for completed reports, call detail data and marketing news messages
  • a Report Manager Proxy capable of communicating
  • each Intranet server of suite 30 communicates with one or several consolidated network databases which include each customer's network management information and data.
  • the Services Inquiry server 36 includes communication with MCI's Customer Service Management legacy platform 40 (a) .
  • Such network management and customer network data is additionally accessible by authorized MCI management personnel .
  • legacy platforms 40(b), 40(c) and 40(d) may also communicate individually with the Intranet servers for servicing specific transactions initiated at the client browser.
  • the illustrated legacy platforms 40 (a) - (d) are illustrative only and it is understood other legacy platforms may be interpreted into the network architecture illustrated in Figure 2 through an intermediate midrange server 30.
  • Each of the individual proxies may be maintained on the dispatch server 26, the related application server, or a separate proxy server situated between the dispatch server 26 and the midrange server 30.
  • the relevant proxy waits for requests from an application client running on the customer's workstation 10 and then services the request, either by handling them internally or forwarding them to its associated Intranet application server 30.
  • the proxies additionally receive appropriate responses back from an Intranet application server 30.
  • Any data returned from the Intranet application server 30 is translated back to client format, and returned over the internet to the client workstation 10 via the Dispatch Server 26 and at one of the web servers in the DMZ Services cluster 24 and a secure sockets connection.
  • the resultant response header and trailing application specific data are sent back to the client browser from the proxy, the messages will cascade all the way back to the browser 14 in real time, limited only by the transmission latency speed of the network.
  • the networkMCI Interact middle tier software includes a communications component offering three (3) types of data transport mechanisms: 1) Synchronous; 2) Asynchronous; and 3) Bulk transfer. Synchronous transaction is used for situations in which data will be returned by the application server 40 quickly. Thus, a single TCP connection will be made and kept open until the full response has been retrieved. Asynchronous transaction is supported generally for situations in which there may be a long delay in application server 40 response. Specifically, a proxy will accept a request from a customer or client 10 via an SSL connection and then respond to the client 10 with a unique identifier and close the socket connection. The client 10 may then poll repeatedly on a periodic basis until the response is ready.
  • Each poll will occur on a new socket connection to the proxy, and the proxy will either respond with the resultant data or, respond that the request is still in progress. This will reduce the number of resource consuming TCP connections open at any time and permit a user to close their browser or disconnect a modem and return later to check for results.
  • Bulk transfer is generally intended for large data transfers and are unlimited in size. Bulk transfer permits cancellation during a transfer and allows the programmer to code resumption of a transfer at a later point in time.
  • FIG. 5 is a diagram depicting the physical networkMCI Interact system architecture 10. As shown in Figure 5, the system is divided into three major architectural divisions including: 1) the customer workstation 20 which include those mechanisms enabling customer connection to the Secure web servers 24; 2) a secure network area 17, known as the DeMilitarized Zone "DMZ" set aside on MCI premises double firewalled between the both the public Internet 25 and the MCI Intranet to prevent potentially hostile customer attacks; and, 3) the MCI Intranet Midrange Servers 30 and Legacy Mainframe Systems 40 which comprise the back end business logic applications. As illustrated in Figure 5, the present invention includes a double or complex firewall system that creates a "demilitarized zone" (DMZ) between two firewalls 25a, 25b.
  • DMZ demilitarized zone
  • one of the firewalls 29 includes port specific filtering routers, which may only connect with a designated port on a dispatch server within the DMZ.
  • the dispatch server connects with an authentication server, and through a proxy firewall to the application servers. This ensures that even if a remote user ID and password are hijacked, the only access granted is to one of the web servers 24 or to intermediate data and privileges authorized for that user. Further, the hijacker may not directly connect to any enterprise server in the enterprise intranet, thus ensuring internal company system security and integrity. Even with a stolen password, the hijacker may not connect to other ports, root directories or applications within the enterprise system.
  • the DMZ acts as a double firewall for the enterprise intranet because the web servers located in the DMZ never store or compute actual customer sensitive data.
  • the web servers only put the data into a form suitable for display by the customer's web browser. Since the DMZ web servers do not store customer data, there is a much smaller chance of any customer information being jeopardized in case of a security breach.
  • the customer access mechanism is a client workstation 20 employing a Web browser 14 for providing the access to the networkMCI Interact system via the public Internet 15.
  • a secure TCP/IP communications link 22 is established to one of several Web servers 24 located inside a first firewall 29a in the DMZ 17.
  • the system employs SSL encryption so that communications in both directions between the subscriber and the networkMCI Interact system are secure.
  • all DMZ Secure Web servers 24 are preferably DEC 4100 systems having Unix or NT -based operating systems for running services such as HTTPS, FTP, and Telnet over TCP/IP.
  • the web servers may be interconnected by a fast Ethernet LAN running at 100 Mbit/sec or greater, preferably with the deployment of switches within the Ethernet LANs for improved bandwidth utilization.
  • One such switching unit included as part of the network architecture is a HydraWEBTM unit 45, manufactured by HydraWEB Technologies, Inc., which provides the DMZ with a virtual IP address so that subscriber HTTPS requests received over the Internet will always be received.
  • the HydrawebTM unit 45 implements a load balancing algorithm enabling intelligent packet routing and providing optimal reliability and performance by guaranteeing accessibility to the "most available” server. It particularly monitors all aspects of web server health from CPU usage, to memory utilization, to available swap space so that Internet/Intranet networks can increase their hit rate and reduce Web server management costs. In this manner, resource utilization is maximized and bandwidth (throughput) is improved.
  • a redundant HydrawebTM unit may be implemented in a Hot/Standby configuration with heartbeat messaging between the two units (not shown) .
  • the networkMCI Interact system architecture affords web server scaling, both in vertical and horizontal directions. Additionally, the architecture is such that new secure web servers 24 may be easily added as customer requirements and usage increases. The use of the HydraWEBTM enables better load distribution when needed to match performance requirements.
  • the most available Web server 24 receives subscriber HTTPS requests, for example, from the HydraWEBTM 45 over a connection 44a and generates the appropriate encrypted messages for routing the request to the appropriate MCI Intranet midrange web server over connection 44b, router 55 and connection 23.
  • a TCP/IP connection 38 links the Secure Web server 24 with the MCI Intranet Dispatcher server 26.
  • DMZ 17 is a second
  • RTM server 52 having its own connection to the public Internet via a TCP/IP connection 48.
  • This RTM server provides real-time session management for subscribers of the networkMCI Interact Real Time Monitoring system.
  • An additional TCP/IP connection 48 links the RTM Web server 52 with the MCI Intranet Dispatcher server 26.
  • the networkMCI Interact physical architecture includes three routers: a first router 49 for routing encrypted messages from the Public Internet 15 to the HydraWebTM 45 over a socket connection 44; a second router 55 for routing encrypted subscriber messages from a Secure Web server 24 to the Dispatcher server 26 located inside the second firewall 25b; and, a third router 65 for routing encrypted subscriber messages from the RTM Web server 52 to the Dispatcher server 26 inside the second firewall.
  • each of the routers 55, 65 may additionally route signals through a series of other routers before eventually being routed to the nMCI Interact Dispatcher server 26.
  • each of the Secure servers 24 function to decrypt the client message, preferably via the SSL implementation, and unwrap the session key and verify the users session from the COUser object authenticated at logon. After establishing that the request has come from a valid user and mapping the request to its associated session, the Secure Web servers 24 will re- encrypt the request using symmetric RSA encryption and forward it over a second secure socket connection 23 to the dispatch server 26 inside the enterprise Intranet.
  • the data architecture component of networkMCI Interact reporting system is focused on the presentation of real time (un-priced) call detail data, such as provided by MCI's TrafficView Server 34, and priced call detail data and reports, such as provided by MCI's StarODS Server 33 in a variety of user selected formats.
  • Report viewer GUI application interface which support spreadsheet, a varity of graph and chart type, or both simultaneously.
  • the spreadsheet presentation allows for sorting by any arbitrary set of columns.
  • the report viewer may also be launched from the inbox when a report is selected.
  • Report management related data is also generated which includes 1) report profiles defining the types of reports that are available, fields for the reports, default sort options and customizations allowed; and 2) report requests defining customer specific report requests including report type, report name, scheduling criteria, and subtotal fields. This type of data will be resident in a Report Manager server database and managed by the Report Manager server.
  • the Infrastructure component of the nMCI Reporting system includes means for providing secure communications regardless of the data content being communicated.
  • the nMCI Interact system security infrastructure includes: 1) authentication, including the use of passwords and digital certificates; 2) public key encryption, such as employed by a secure sockets layer (SSL) encryption protocol; 3) firewalls, such as described above with reference to the network architecture component; and 4) non- repudiation techniques to guarantee that a message originating from a source is the actual identified sender.
  • One technique employed to combat repudiation includes use of an audit trail with electronically signed one-way message digests included with each transaction.
  • Another component of the nMCI Interact infrastructure includes order entry, which is supported by the Order Entry ("StarOE”) server.
  • the general categories of features to be ordered include: 1) Priced Reporting; 2) Real-time reporting; 3) Priced Call Detail; 4) Real Time Call Detail; 5) Broadband SNMP Alarming; 6) Broadband Reports; 7) Inbound RTM; 8) Outbound RTM; 9) Toll Free Network Manager; and 10) Call Manager.
  • the order entry functionality is extended to additionally support 11) Event Monitor; 12) Service Inquiry; 13) Outbound Network Manager; 14) Portfolio; and, 15) Client View.
  • the Self -monitoring infrastructure component for nMCI Interact is the employment of mid- range servers that support SNMP alerts at the hardware level. In addition, all software processes must generate alerts based on process health, connectivity, and availability of resources (e.g., disk usage, CPU utilization, database availability) .
  • the Metrics infrastructure component for nMCI is the employment of mid- range servers that support SNMP alerts at the hardware level. In addition, all software processes must generate alerts based on process health, connectivity, and availability of resources (e.g., disk usage, CPU utilization, database availability) .
  • Interact is the employment of means to monitor throughput and volumes at the Web servers, dispatcher server, application proxies and mid- range servers. Metrics monitoring helps in the determination of hardware and network growth.
  • the client tier 10 is organized into a component architecture, with each component providing one of the areas of functionality.
  • the client- tier software is organized into a "component" architecture supporting such applications as inbox fetch and inbox management, report viewer and report requestor, TFNM, Event Monitor, Broadband, Real -Time Monitor, and system administration applications. Further functionality integrated into the software architecture includes applications such as Outbound Network Manager, Call Manager, Service Inquiry and Client View.
  • the present invention focuses on the client and middle- tier service and application proxy components that enable customers to request, specify, customize, schedule and receive their data and account information in the form of reports that are generated by the various back-end application servers.
  • StarWRS this WWW/Internet Reporting System 200, as shown in Figure 6, comprises the following components and messaging interfaces: 1) those components associated with the
  • Client GUI front end including a report requestor client application 212, a report viewer client application 215 and, an Inbox client application 210 which implement the logical processes associated with a "Java Client", i.e., employs Java applets launched from the backplane ( Figure 3) that enable the display and creation of reports and graphs based on the fields of the displayed reports, and, allows selection of different reporting criteria and options for a given report; and,
  • those middle- tier server components enabling the above-mentioned reporting f nctionality including: a Report Manager server 250, a Report scheduler server 260, and an Inbox Server 270. Also shown in Figure 6 are the system Order Entry client application 280 and a corresponding Order Entry Server 285 supporting the StarWRS reporting functionality as will be described.
  • the Report Manager (“RM”) server 250 is an application responsible for the synchronization of report inventory with the back-end "Fulfilling" servers 400, 500; retrieval of entitlements, i.e., a user's security profiles, and report pick list information, i.e., data for user report customization options, from the system Order Entry server 280; the transmission of report responses or messages to the Dispatcher server 26 ( Figure 6); the maintenance of the reporting databases; and, the management of metadata used for displaying reports.
  • the RM server 250 employs a Unix daemon that passively listens for connect requests from the GUI client applications and other back-end servers and deploys the TCP/IP protocol to receive and route requests and their responses.
  • Unix stream sockets using the TCP/IP protocol suite are deployed to listen for client connections on a well-known port number on the designated host machine.
  • Client processes e.g., report requestor 212, desiring to submit requests connect to RM 250 via the dispatcher 26 by providing the port number and host name associated with RM 250.
  • a Talarian smart socket connection 254 is provided for particular back-end server 400 providing priced reporting data.
  • Request messages received by the RM server are translated into a "metadata" format and validated by a parser object built into a report manager proxy 250' that services requests that arrive from the GUI front -end. If the errors are found in the metadata input, the RM 250 will return an error message to the requesting client.
  • server 400 provides a customer's priced billing data through a Talarian smart socket messaging interface 254 to the Report Manager.
  • a back-end billing mainframe application known as the StarODS server provides such priced call detail data.
  • call detail data is FTP'd directly to the Inbox Server and a message is sent to the report manager server 250 from the Traffic View server (“TVS”) 500.
  • TVS Traffic View server
  • the RM 250 server can manage reporting data for customer presentation from other back-end and legacy servers including, e.g., Broadband, Toll Free Network Management, and Event Monitor servers, etc. in order to present to a customer these types of network management and reporting data.
  • the report manager server additionally utilizes a database 258, such as provided by Informix, to provide accounting of metadata and user report inventory.
  • a database 258, such as provided by Informix to provide accounting of metadata and user report inventory.
  • an SQL interface is utilized to access stored procedures used in processing requests and tracking customer reports.
  • C++ tools and other tools such as Rogue Wave's tools.
  • h++ are additionally implemented to perform metadata message parsing validation and translation functions.
  • the Report Manager server 250 additionally includes the scheduling information, however, a report scheduler server component passes report requests to the back-end fulfilling servers 400, 500 at the scheduled times.
  • the Report Scheduler (“RS") server component 260 is, in the preferred embodiment, a perpetually running Unix daemon that deploys the TCP/IP protocol to send report requests to the back-end fulfilling servers such as the StarODS server 400, TVS server 500, and receive their responses. More particularly, the RS server 260 is a Unix server program that is designed to handle and process report requests to the fulfilling servers by deploying Unix stream sockets using the TCP/IP protocol suite, sending the request for customized reports to client connections on a well-known port number on the designated host machine.
  • interface socket connections 264, 266 are shown interfacing with respective back end servers 400 and 500.
  • report requests are published by the RS server 260 to a pre-defined subject on the Talarian Server.
  • Talarian SmartSockets 4.0 another daemon process is necessary that uses Talarian C++ objects to connect their message queue and extract all messages for a given subject for storage in a database table contained in database 263.
  • Each message includes the track number of the report that was requested from the fulfilling server.
  • the user may specify the type of reporting, including an indication of the scheduling for the report, e.g., hourly, daily, weekly or monthly. For priced data the user has the option of daily, weekly, or monthly. For real-time, or unpriced data, the user has the option of hourly, daily, weekly or monthly.
  • the report scheduler interface additionally enables a user to specify a pager or E-mail account so that an e-mail or pager message may be sent to indicate when a requested report is in the Inbox server 270.
  • the report scheduler server 260 interfaces directly with the Report Manager server 250 to coordinate report request scheduling and processing. It should be understood that the respective report management and scheduling functions could be performed in a single server.
  • the Inbox Server component 270 serves as the repository where the completed user report data is stored, maintained, and eventually deleted and is the source of data that is uploaded to the client user via the dispatcher over a secure socket connection 272 between the Web server and the browser. It is also a Unix program that is designed to handle and process user requests submitted in meta data format using an Informix database.
  • the Report Manager server 250 communicates the corresponding report metadata to the Inbox server 270 over socket connection 274 as shown in Figure 6.
  • the metadata will be stored in the Inbox server database 273 along with the report results. Thus, if the meta data is required to be changed, it will not interfere with the information needed to display the reports contained in the Inbox. Additionally, as shown in Figure 6, the Inbox server interfaces with the report scheduler to coordinate execution and presentation of reports.
  • the StarOE server 280 is the repository of user pick lists and user reporting entitlements as shown in database 283. Particularly, it is shown interfacing with the Inbox server 270 and report scheduler servers 260.
  • the Report Manager does not interface with or contain metadata for StarOE. It will, however, include information in the report metadata that will tell the Report Requestor it needs to get information (i.e., Pick Lists) from StarOE server 285.
  • a common database may be maintained to hold the common configuration data which can be used by the GUI applications and by the mid- range servers.
  • Such common data will include but not be limited to: customer security profiles, billing hierarchies for each customer, general reference data (states, NPA's, Country codes) , and customer specific pick lists: e.g., ANI's, calling cards, etc..
  • An MCI Internet StarOE server will manage the data base for the common configuration of data.
  • the above-mentioned Inbox client application 210 functions as an interface between the client software and the Inbox server 270 for presenting to the customer the various type of reports and messages received at the Inbox including all completed reports, call detail, and marketing news messages.
  • the messages for the user in the inbox are sorted by type (report, call detail, alarms) and then by report type, report name, date, and time.
  • the Inbox client application uses the services of the backplane ( Figure 3) to launch other applications as needed to process report messages.
  • the inbox will also use the services of the data export objects to provide a save/load feature for inbox messages, and, is used to provide a user- interface for software upgrade/download control.
  • Inbox messages are generated by the versioning services of the backplane; actual downloads will be accomplished by a request through the inbox.
  • the inbox client is able to receive information on multiple threads to allow a high priority message to get through even if a large download is in progress.
  • the browser is configured to allow more than one network connection simultaneously, i.e., the polling thread on the client uses a separate connection to check for new messages, and starts a new thread on a new connection when a new message is detected. In this way, multiple messages may be downloaded simultaneously.
  • the Report Requestor application 212 is a GUI Applet enabling user interaction for managing reports and particularly includes processes supporting: the creation, deletion, and editing of the user's reports; the retrieval and display of reports based on selected criteria; the display of selected option data; and the determination of entitlements which is the logical process defining what functionality a user can perform on StarWRS.
  • the Report requestor additionally enables a user to specify the frequency of report generation, e.g., periodically, or as "one -shots" to be performed at a later time.
  • the report scheduler service maintains a list of requested reports for a given user, and forwards actual report requests to the appropriate middle- tier servers at the appropriate time. Additional functionality is provided to enable customers to manage their inventory, e.g., reschedule, change, or cancel (delete) report requests.
  • the report requestor utilizes the platform client JAVA code to communicate with the report manager server.
  • the Report Requestor uses StarOE client Java code.
  • Report Requestor JAVA applets implementing the above - described report requestor f nctionality, are downloaded to the the customer's workstation in the form of a cab file after initial login.
  • the Report Viewer application 215 is a GUI Applet enabling a user to analyze and display the data and reports supplied from the fulfilling servers such as StarODS 400, Traffic View ("TVS") 500, and other systems such as Broadband and toll free network manager.
  • the Report Manager 250 includes and provides access to the metadata which is used to tell the Report Requestor what a standard report should look like and the "pick- list" options the user has in order for them to customize the standard report. It is additionally used to tell the Report Viewer client how to display the report, what calculations or translations need to be performed at the time of display, and what further customization options the user has while viewing the report.
  • It additionally includes a common report view by executing a GUI applet that is used for the display and graphing of report data and particularly, is provided with spreadsheet management f nctionality that defines what operations can be performed on the spreadsheet including the moving of columns, column suppression, column and row single and multiple selection, import and export of spreadsheet data, printing of spreadsheet, etc. It is also provided with report data management functionality by defining what operations can be performed on the data displayed in a spreadsheet including such dynamic operations as sorting of report data, sub- totaling of report data, etc.. Furthermore, the report viewer 215 is provided with functionality enabling the interpretation of Meta Data; and, functionality enabling communication with the Backplane ( Figure 3) . The Report Viewer application 215 additionally accepts messages telling it to display an image or text that may be passed by one of the applications in lieu of report data (e.g., Invoice, Broadband report, etc.) All reporting is provided through the Report
  • Viewer interface which supports text displays, a spreadsheet, a variety of graphic and chart types, or both spreadsheet/graph simultaneously.
  • the spreadsheet presentation allows for sorting by any arbitrary set of columns.
  • the report viewer 215 is launched from the inbox client 210 when a report is selected.
  • reports can be presented without report- specific presentation code.
  • these metadata descriptions function like the catalog in a relational database, describing each row of a result set returned from the middle tier as an ordered collection of columns.
  • Each column has a data type, a name, and a desired display format, etc.
  • the metadata data type may include geographic or telecommunications - specific information, e.g., states or NPAs .
  • the report viewer may detect these data types and provide a geographic view as one of the graph/chart types.
  • a user first establishes communication with the DMZ Web server at step 602 and logs on to the nMCI Interact system by entering the user's name and password onto a logon dialog box, as indicated at step 604. Then, at steps 606-608, an application running on the backplane directs a "Validate User Message" to the StarOE server 280 via the web server and dispatcher servers ( Figure 6) to direct the StarOE server 280 to perform security validation and authenticate the user ID and password.
  • StarOE server acts as a proxy when messages are sent from the Dispatcher server 26 and supports synchronous transactions. All data and security information is accessed by direct queries to a StarOE server database 283, such as provided by Informix.
  • a StarOE server database 283, such as provided by Informix Once a user is logged on, the Web Server ( Figure 2 (b) ) requests a current list of authorized applications from the StarOE server 285 as indicated at steps 608 and 610.
  • a "Get User Application Request” message is communicated to the StarOE server via the backplane which queries the Informix database to obtain a list of authorized applications, i.e., services, for the user and which determines which buttons on the home page are active, thus controlling their access to products.
  • This information is downloaded by a GUI applet that is executed via the Backplane (not shown) and incorporated into the home page that is presented to the user as indicated at steps 612 -614.
  • An exemplary home page screen display 290 is shown in Figure 8 which provides a list of icons representing the possible options available to the user.
  • the steps 615 and 616 indicate the selection and presentation of the Report Requestor display which presents the reporting options to a user in accordance with that user's entitlements as determined at previous step 610.
  • Appendix H provides the format and content of the nMCI Interact common objects downloaded to the Report Requestor client application to enable web -based reporting. As shown in Appendix H, the Report Requestor first asks for common objects for a user's default timezone, language and currency. The Report Requestor objects are invoked to retrieve from StarOE the various customer entitlements relating to security, geographical hierarchy, billing hierarchy, and paging and e-mail notification, as further shown in Appendix H.
  • Figure 9 (a) illustrates an exemplar dialog box 295 provided on the report requestor web page that is presented to the user after the logon and authentication process. From this dialog, the user is enabled to edit an existing report maintained in the report manager inventory, by selecting "edit” button 350, generate a new report by selecting "new” button 353, copy an existing report by selecting button 354, or delete an existing report by selecting button 355.
  • the user may enter the desired reporting options including: 1) the report product, as indicated by menu 358, and which includes toll-free, MCI Vision, and MCI Vnet options; 2) the report category, as indicated by menu 359, and which includes options for: analyzing traffic, call center, call detail, checking calling frequencies, financial, marketing, monitoring usage, and telecommunications categories for toll-free, Vnet and Vision customers; 3) the report type, as indicated by menu 360, and which includes priced call detail data or traffic data options; and 4) a report direction, as indicated by selection areas 363, and which includes inbound, outbound, or both directions.
  • the user may select the report format associated with a reporting category.
  • the report format options indicated in selection field 365 include the following: area code summary, country code summary, state summary, range summary, city summary, frequent numbers, payphone report, usage summary, calling card summary, IDAC/Supp Code Summary, Day of Week Distributions, Hourly Distribution, Call Access Summary and review calls options.
  • report formats include: longest calls, most expensive calls, Off Peak Calls, payphone report, usage summary, calling card summary, and area code summary; for marketing report category, report formats include: country code summary, state summary, frequent numbers, frequent area code summary, frequent state, and frequent cities.
  • report formats include: call duration summary, IDAC/Supp Code Summary and Call Access Summary; for the call center report category, report formats include: most active toll free numbers, Hourly Distribution, Day of Week Distributions, state summary, and country code summary.
  • report formats include: longest calls, most expensive calls, most active calling card and most active toll free numbers.
  • report formats include: frequent numbers, frequent area code, frequent country codes, frequent state and frequent cities. It should be understood that enablement of any of these reporting options is based according to predefined user entitlements. That is, "Get User Security" message with a reporting application set, and a “Get User Report Security” message are sent to the StarOE server 285 via the Dispatcher server to retrieve that user's detailed security profile (entitlements) for a user that has the reporting application option.
  • These entitlements include a list of all the report products, i.e., Vnet, Vision, Toll free, report types (priced or unpriced) and the report categories that are available for that user.
  • a report had already been created and maintained in the report manager database, it will be displayed in the report inventory field 368 of Figure 9(a) .
  • a determination is made as to whether an existing report from inventory is selected. If an existing report is not selected then the user is prompted to generate a new report according to customization options that the user is entitled for the selected report product, category, type, etc., as indicated at step 630.
  • step 626 If an existing report is selected at step 626 based on the report product, category, type, etc., then the user is prompted at step 628 to select from among the following options: a report edit option, as shown at step 635; a report delete option, in which case the selected report will be deleted at steps 638 and 639; and, a report copy option, in which case an existing report will be copied, e.g., for subsequent editing, as shown at steps 640 and 641.
  • a report edit option as shown at step 635
  • a report delete option in which case the selected report will be deleted at steps 638 and 639
  • a report copy option in which case an existing report will be copied, e.g., for subsequent editing, as shown at steps 640 and 641.
  • Figure 9 (b) illustrates the dialog screen 296 presented to the user showing all the report customization categories for building a new report and editing an existing report. From this screen and related report building dialog boxes, all of the initial values for retrieving the MetaData, customization options and GUI builder options from the report manager server 250 necessary to build (edit) a report are provided in accordance with the user's entitlements.
  • a user may provide the following customization and report builder options as indicated in the field 370: general customization options, by selecting field 371; layout customization options, by selecting field 373; access customization options, by selecting field 375; hierarchy customization options, by selecting field 377; geographic customization options, by selecting field 378; and, notification customization options, by selecting field 379.
  • general customization options by selecting field 371
  • layout customization options by selecting field 373
  • access customization options by selecting field 375
  • hierarchy customization options by selecting field 377
  • geographic customization options by selecting field 378
  • notification customization options by selecting field 379.
  • the user is enabled to specify or change the report title, by selecting field 371a, report description, by selecting field 371b, and the report schedule, by selecting field 371c.
  • the right hand field 380 will present the user with a field 381 for entering the title of the report. If an existing inventory report had been selected, then the field 380 will be display the existing title.
  • Report Manager will autopopulate the right hand field 380 with the existing report values .
  • the report schedule 371c the user is presented with a screen 297, as shown in Figure 9 (c) .
  • the entry options for selection in the right hand field 380 includes: selection of time zone, by menu choice 382; selection of the report schedule radio buttons 383 to specify the report as recurring, daily, weekly, monthly, or hourly entry field the nature of screen; a time range for the report as specified by entry fields 384; and, a date range for the report as specified by entry fields 385.
  • the user may also specify the report as a "one -shot" by selecting radio button 386.
  • the user is enabled to specify or change the number of report rows, by selecting field 373a, and specify or change the report columns, by selecting field 373b.
  • selection of report columns customization will present the user with a columns customization screen such as example screen display 298 presented as shown in Figure 9 (d) .
  • the right hand field 380 indicates a column tab 387, and a sorts tab, 388.
  • the column tab enables the user to specify add or remove columns, with the selection of individual columns names provided in field 389.
  • An example description of the column headers for an example selection of columns is shown in field 390.
  • selection of report sorts customization tab 388 will present the user with a sorts customization screen such as example screen display 299 presented as shown in Figure 9 (e) .
  • the sorts tab enables the user to specify columns to be sorted in an available sorts selection field 391, whether totals are to be made, whether the column data to be provided is in ascending or descending order, for example, as provided by selection of buttons 392, shown in Figure 9(e) .
  • the Report Manager provides the customer with the ability to specify select columns as primary and secondary sorts. The user may specify additional secondary sorts in addition to the default sorts. For example, the user may provide the following sorts: for a Longest Call Report, a primary sort is Number of Minutes in descending order.
  • the primary sort is dollars in descending order.
  • a primary default sort is the Number of Calls but may be changed to Number of Minutes, or dollars, all in descending order;
  • a Secondary sort is Toll Free Number in ascending order.
  • a primary default is Number of Calls but may be changed to Number of Minutes, or dollars, all in descending order;
  • a Secondary sort is Card Number in ascending order.
  • the primary default sort is Area Code in descending order but may be changed to Number of Calls, Number of Minutes or dollars.
  • the primary sort is Duration Range in ascending order.
  • the primary default sort is Country code in ascending order but may be changed to one of the following: Number of Calls, Number of Minutes, or dollars (in descending order) .
  • a primary default sort is State code in ascending order but may be changed to one of the following: Number of Calls, Number of Minutes, or dollars (in descending order) .
  • a primary default sort is Number of Calls but may be changed to Number of Minutes, or dollars, all in descending order; a secondary sort is Number Called in ascending order.
  • a primary default sort is Number of Calls but may be changed to one of the following:
  • a primary default sort is Number of Calls but may be changed to Number of Minutes, or Dollars, all in descending order, or State Code in ascending order; a secondary sort is State in ascending order.
  • a primary default sort is Number of Calls but may be changed to Number of Minutes, or dollars, all in descending order, or City Code in ascending order; a secondary sort is City in ascending order.
  • sort is by 800 Number.
  • a primary default is date, but may be changed to Time or Billing Hierarchy.
  • a primary default is Date, but may be changed to time or billing hierarchy.
  • the user is enabled to specify or change an accounting "IDAC" code or supplemental code, by selecting field 375a, and specify or change the inbound access type, by selecting field 375b.
  • IDAC accounting "IDAC" code or supplemental code
  • selection of inbound access customization presents the user with a web page having an inbound access customization screen such as example screen display 301 presented as shown in Figure 9(f).
  • the right hand entry field 304 presents the user with the following selectable access types: dial 1, card, dedicated, 800 Remote Access, Direct Dial fax, store/forward fax, 800 Business line (highlighted in the Figure 9(f)), 800 wide area telecommunications service, 800 dedicated, 800 Network Call Redirect, local, cellular.
  • the user is enabled to specify or change the billing location by selecting field 377a.
  • the billing location customization option Upon selection of the billing location customization option, the user is presented with a web page having a customization screen such as example screen display 303 presented as shown in Figure 9 (g) .
  • the right hand screen presents the user with three tabs: a corporations tab 307, a search tab, 308, and, a selected items tab 309.
  • the corporations tab 307 enables the user to add or remove a corporate ID to/from a billing location hierarchy in the entry field 310.
  • a search of corporate IDs may be performed by selecting the search tab 308, and items that have been selected may be displayed in a field (not shown) presented by selection of the selected items tab.
  • the user is enabled to specify or change the billing location by selecting field 377a.
  • the billing location customization option the user is presented with a web page having a customization screen such as example screen display 311 presented as shown in Figure 9 (h) .
  • the right hand screen presents the user with three tabs: a countries tab 312, a search tab, 313, and, a selected items tab 314.
  • the countries tab 307 enables the user to select, add or remove a country that may be a subject for reporting as provided in the entry field 320.
  • a search of countries may be performed by selecting the search tab 313, and items that have been selected may be displayed in a field (not shown) presented by selection of the selected items tab 314.
  • the user is enabled to specify report notification by paging, by selecting field 379a, and, report notification by e-mail, by selecting field 379b.
  • the user Upon selection of the paging notification option, the user is presented with a web page having a customization screen (not shown) presenting the user to select or enter that user's page number, PIN number and a paging message description.
  • the user Upon selection of the e- mail notification option, the user is presented with a web page having a customization screen (not shown) presenting the user to select or enter that user's e- mail address.
  • the Report Requestor client application 212 gains access to the Metadata stored at the Report Manager server 250 through messaging. Particularly, as hereinafter described, a message generated by the Report Requestor in accordance with the user request is first received by the report manager proxy 250' .
  • the report manager proxy comprises a set of tools in the form of reusable objects, preferably written in C++ code, or the like. For example, a parser object tool is employed to decompose the Metadata messages sent by the report requestor 212 to validate the message. If errors are found in the Metadata input, the RM will return an error message to the requesting client. If the Metadata passes the validation tests, the request type is then determined and the appropriate service will be invoked after which a standard response is sent back to the requesting client.
  • the Report Manager 250 implements stored procedures to translate the message, perform the request, and send the information back to the Report Requestor 212 which uses the metadata to determine what a standard report should look like, the customization options the user has, and the types of screens that should be used for the various options (i.e., single selection, multiple selections, etc.) . It is understood that the selection of available standard template reports is based on the user's entitlements .
  • the following list provides the types of requests that may be initiated by the Report Requestor 212 and the responses performed by the Report Manager 250: 1) Get/Send report template list (GRTL/SRTL) - which request retrieves the list of all standard report templates for all products and is used only to obtain general report information, e.g., report title, description, etc.; 2) Get/Send report template detail (GRTD/SRTD) - which request retrieves the details of a specific standard report template; 3) Get/Send user report list (GURL/SURL) - which request retrieves the list of all user reports for the report format selected from a user report table and is used only as a request for general report information, e.g., report title, status, etc.; 4) Get/Send user report detail (GURD/SURD) - which request retrieves the details of a specific user's report; 5) Add report definition/Acknowledgment (ARD/ARDA) - which requests addition of a user- created report to a user report table.
  • the report is a scheduled report, this request is also communicated to the fulfilling server at the time the report is due; 6) Delete report definition/Acknowledgment (DRD/DRDA) - which request deletes a user-created report from the user table; 7) Copy report definition/Acknowledgment (CRD/CRDA) - which request creates a duplication of the report the user is editing (other than the report title) and creates a new report ID for it; 8) Update Reporting Schedule/Acknowledgment (URS/URSA) - which request updates the scheduling information on a report without having to send a Delete and Add request; and, 9) Get Pick List/Acknowledgment (GPL/GPLA) - which request enables the Report Requestor 212 to get a pick list provided by StarOE server.
  • DDRD/DRDA Delete report definition/Acknowledgment
  • CCD/CRDA Copy report definition/Acknowledgment
  • URS/URSA Update Reporting Schedule/
  • the interface message sent to the RM server 250 from the report requestor via the Dispatcher server 24 comprises a three to four character message acronym followed by request specific parameters.
  • Table 2 illustrates the interface message format returned by the RM server 250.
  • the response message to be returned in Metadata format preferably includes a four character message acronym followed by an error code.
  • a successful request (or a request acknowledgment) generates a response with an error code of "0". Additional data specific to the response follows this error code. If any server receives a message which is not known, the response message will echo the message acronym back along with an appropriate error code.
  • Appendix A provides a series of tables containing the content for each metadata message request that can be sent by the report requestor 212 for each of the enumerated user requests, in addition to the content of the corresponding metadata message responses by the RM server 250.
  • an example metadata format is as follows:
  • the GRTL message is received by the StarWRS proxy server application 250' to enable the RM server 250 to perform the query into the RM Informix database having the data associated with the request.
  • a WRSApp object is launched.
  • the WRSApp object creates a DataManager object to guide the data and which initiates a CommunicationManager object to manage all communication between the client and the server.
  • the CommunicationManager utilizes a RptManagerMsg object to create: 1) a GRTL; 2) a WRSCommWrapper for direct communication with the backend; and, 3) a WRSReportManagerUtilParser to format the data returned.
  • the Report Manager creates a Dispatcher object, which contains the business logic for handling metadata messages at the back-end and utilizes the services of a RMParser class.
  • the appropriate member function is invoked to service the request.
  • the Report Manager Upon receiving the message, the Report Manager creates the Parser object (RMParser) which takes the message apart and invokes a validation object which validates the message.
  • RMParser Parser object
  • the data returned by the Report Manager server 250 for this particular request may include the following data in metadata format as follows:
  • ⁇ RptCategoryDescription#n ⁇ RptTitle#n.n,
  • RptID# indicates a standard report template ID
  • RptTitle# indicates the standard report template title
  • RptCategory# indicates the report category, e.g. Monitor Usage, Analysis Traffic, Historical, Executive Summary, Call Detail, etc.
  • RptDescript indicates the standard report template description displayed to the user.
  • the SRTL message is sent from the StarWRS RM proxy server to the report requestor for presentation to the customer.
  • the SRTL response is built inside the esql wrapper function after obtaining the necessary information through the stored procedure from the Report Manager Informix database.
  • the Report Manager creates the RMServerSocket object and sends the SRTL message back to the client.
  • the GRTD request message request is sent having content shown in the table in Appendix A.
  • the Report ID field indicates an existing report that a user may wish to edit.
  • N0DEl ⁇ node levell, label valuel, assigned unique screen identificationl, >,
  • NODE2 ⁇ node level2, label value2 , assigned unique screen identification2 , ⁇ control ID2.1, field value2.1, data location2.1>, ⁇ control ID2.2, field value2.2, data location2.2>, ⁇ ..,..,..>>,
  • the MetaTreeData Label fields include such values as General, Report Name, Report Description, Scheduled Execution, etc.
  • the MetaCtrllnfo MetaField Value fields may be blank or may contain the selection options available to the user. This information is taken from the report template database.
  • the example metadata format is as follows:
  • this process entails invoking the Communication Manager object to communicate with the RM server in order to obtain a SURL metadata message.
  • the CommunicationManager utilizes the RptManagerMsg object to create: 1) a GURL, 2) a WRSCommWrapper for direct communication with the backend, and, 3) a WRSReportManagerUtilParser to format the data returned.
  • the parser returns a hash table containing the User Report List.
  • the Report Manager creates an Dispatcher object that contains the business logic for handling metadata messages at the back-end and utilizes the services of the RMParser class.
  • the Report Manager upon receiving a message, creates a Parser object (RMParser) which takes the message apart and invokes a validation object which validates the message.
  • RMParser Parser object
  • the generic SURL message in Metadata format returned by the RM server 250 includes the following information:
  • each user report categroy there is a list of reports where each entry contains a UserRptID# indicating a user-defined report template ID, a UserRptTitle# indicating the user's report template title, and a UserRptCategory# indicating the user report category.
  • the SURL response is built inside an esql wrapper function after obtaining the necessary information through a stored procedure from the Informix database.
  • the Report Manager creates the RMServerSocket object and sends the SURL message back to the client.
  • the GURD message is sent having data as contained in the table shown in Appendix A.
  • a Communication Manager object is invoked to communicate with the RM server in order to obtain a SURD metadata message.
  • the CommunicationManager object first utilizes the RptManagerMsg object to create: 1) a GURD metadata message, 2) a WRSCommWrapper for direct communication with the backend, and 3) the RSReportManagerUtilParser to format the data returned.
  • the parser organizes the data into a series of nodes which are utilized to create the report builder tree on the report requestor customization screen. Later this data will be extracted from the node and used to construct the screen related to the node.
  • the Report Manager server creates the
  • MCIDispatcher object which contains the business logic for handling metadata messages at the back-end and utilizes the services of the RMParser class.
  • the Report Manager upon receiving a message, creates the Parser object (RMParser) which takes the message apart, invokes a validation object which validates the message and builds a response inside the esql wrapper function after obtaining the necessary information through the stored procedure from the Informix database.
  • the Report Manager creates the RMServerSocket object and sends the SURD/SRTD message back to the client.
  • NODEl ⁇ node levell, label valuel, assigned unique screen identificationl, >,
  • N0DE2 ⁇ node level2 , label value2 , assigned unique screen identification2 , ⁇ control ID2.1 , field value2.1, data location2.1> , ⁇ control ID2.2 , field value2.2, data location2.2>, ⁇ . . , . . , » ,
  • NODE#n ⁇ node levelttn, label valuettn, assigned unique screen identification#n, ⁇ control ID#n.l, field value#n.l, data location#n.1> , ⁇ control ID#n.2, field value#n.2, data location#n.2>, ⁇ ..,..,.. »
  • This response thus may include the report information having detailed items including: UserReportlD (UserlD) , User's report name (UserName) , product (UserProd) , Threshold (UserThreshold) , User Report Description (UserDescript) , Report Columns (UserFields) , Report column headings (UserHeaders) , and, in addition, customization options with fields indicating, inter alia , columns to display (UserHeaders) , user-defined criteria (UserCriteria) , a sort order (UserOrder) and scheduling selections (UserSched) , the last update of this report (UserLastUpdate) and, the Report status (if adhoc) (UserStatus) , etc.
  • UserReportlD User's report name
  • UserProd product
  • Threshold UserThreshold
  • User Report Description UserDescript
  • the ARD metadata message having fields defined in the table provided in Appendix A is processed by the RM server 250.
  • An example message in metadata format to initiate the addition of a user- created report for TVS Inbound data is as follows:
  • the "NAME” field refers to the Report Name (e.g., city summary); the "PRODUCT” field refers to the report product (Vision) ; the “THRESHOLD” field refers to the record count; the “DESCRIPTION” field refers to the report description; the “COLUMNS” refers to the number of columns specified for a report by the user; the “BILLING” field refers to the specified report billing entitlement, i.e., billing hierarchy, the “IDAC” refers to the specified accounting code; the "GEO” field pertains to the geographic area which is being reported, i.e., geographical hierarchy; the “IACCESS” field refers to the inbound access type and the “OACCESS” refers to the outbound access; the "SORTBY” field indicates the report column sorting customization with "A” indicating column (s) having data to be sorted in ascending order and, "D” indicating column (s) having data to be sorted in descending order; the "SCHEDULE” field
  • the report manager server 250 responds to the Report Requestor with the processing results.
  • a new User Report ID is assigned and returned by RM.
  • the user may make changes to the Report Title, the Report
  • the CommunicationManager utilizes the RptManagerMsg object to create the GPL, the WRSCommWrapper for direct communication with the backend, and the WRSReportManagerUtilParser to format the data returned.
  • the Report Manager server creates the MCIDispatcher object and invokes the MCIRMParser class.
  • the appropriate member function is invoked to service the request.
  • the Report Manager upon receiving a message, creates the Parser object (RMParser) which takes the message apart and a validation object is invoked which validates the message.
  • the response is built inside the esql wrapper function after obtaining the necessary information through the stored procedure from the Informix database.
  • the Report Manager creates the RMServerSocket object and sends the GPLA message back to the client.
  • Figure 7(c) describes the next step 650 of presenting the user with report run and save options.
  • the user may select a save and exit option, depicted in Figure 9 (b) as button 322 or a save and run option, depicted in Figure 9 (b) as button 323.
  • an WRSEdit object enables a WRSScnMgr object to save the report to the RM server.
  • the WRSScnMgr object launches each screens save method which communicates with the DataManager object to place the screens data in its corresponding WRSNode.
  • the WRSScnMgr object calls the DataManager object's SaveReport method to build a hash table to contain all of the report's data.
  • the CommunicationManager utilizes the RptManagerMsg object to create the ARD metadata message from the hash table, the WRSCommWrapper for direct communication with the backend, and the WRSReportManagerUtilParser to handle any errors thrown by the server.
  • the Report Manager creates the Dispatcher object, and utilizes the services of the RMParser class and validation objects. Upon determining that the client has sent a valid message, the appropriate member function is invoked to service the request.
  • the response is built inside the esql wrapper function after obtaining the necessary information through the stored procedure from the RM database.
  • the Report Manager creates the RMServerSocket object and sends the ARDA message back to the client.
  • the selected report type and reporting criteria are sent to the Report Manager.
  • the report is marked as scheduled and saved in a user_table in the Report Scheduler server 260 via the report Manager.
  • the Report Scheduler server 260 sends the ARD message to the fulfilling server which queues the report and runs the report at the specified time(s) , as indicated at step 665.
  • the following sequence of operations are performed: First, in response to receipt of the ARD message, e.g., submitted to the fulfilling server by the Report Scheduler, the fulfilling server completes the report and compresses the report/data, as indicated at step 670. Then, the report/data is "pushed", implementing FTP, to the fulfilling server's directory on the Inbox server 270, as indicated at step 673.
  • Each application server e.g., TVS server 500, is responsible for generating unique file names within their directory on the Inbox server 270. For example, the following directory and file naming conventions used for reports generated by the TrafficView server are labeled inbox ⁇ files ⁇ tvs with text files having the suffix * . txt or *.txt_zip
  • the fulfilling server then verifies that the FTP process was successful, as indicated at step 676, and, at step 679, a notification is sent by the fulfilling server to the Report Manager to notify the Report Manager server 250 of the location of a scheduled report. This is accomplished by using a "NRL" metadata message.
  • Appendix B provides a table comprising the Notify Report Location parameters used for the NRL
  • Metadata messaging sent by a fulfilling server to the RM Server 250 when a requested report is complete is as follows:
  • the NRL message received by the RM server 250 includes parameters verifying whether or not the FTP process was successful. If it was successful, then the fulfilling server messages the Inbox that the file has been transmitted successfully by transmitting the report name (filename) and location. When the fulfilling server encounters a problem executing a report, a notification is sent to the Report Manager. Particularly, an error flag is placed in the status field of the User_report by the Report Manager which is displayed to the user during Report Request. The error message description will be placed in a text file and FTP'd to the fulfilling server's report location on the Inbox server (e.g., ⁇ inbox ⁇ f iles ⁇ tvs) by the fulfilling server.
  • the Inbox server e.g., ⁇ inbox ⁇ f iles ⁇ tvs
  • step 679 once the RM server 250 has received the NRL message from the fulfilling server, it verifies the file's presence, as indicated at step 682.
  • the RM server 250 then builds a metadata file, e.g., by compressing the appropriate metadata (for displaying the report) into a .MTD file, as indicated at step 685.
  • This .MTD file is utilized by the Report Viewer to know how to display the report.
  • the Report Manager server creates a file including the metadata using the same file name as the report/data file, but having the following suffix: *.mtd or *.mtd_zip indicating a metadata or compressed metadata file, respectively.
  • Appendix F details the parameters that are passed in the GET METADATA messaging for indicating to the Report Viewer how to display a requested report. For example, a GET METADATA message corresponding to an unpriced TVS fulfilling server report is as follows:
  • the RM ftp's the .MTD file to the Inbox server, as indicated at step 688, Figure 7(d).
  • the RM server additionally updates the User_report table status field with a status "C" indicating completion, as indicated at step 691.
  • the RM server 250 then adds the report to the user's Inbox, as indicated at step 693.
  • Appendix C provides a table showing the fields for the metadata messaging between the RM server 250 and the Inbox server 270 for adding an item into the StarWRS system Inbox server 270, and the respective acknowledgment message format back from the Inbox server.
  • the "LOC” field includes information about where the report data is located. For example, a metadata message indicating to the Inbox server that an unpriced TVS fulfilling server report is available is shown as:
  • the RM server supplies a metadata "A" message to the Inbox indicating the FTP file location.
  • the report is now available for viewing, downloading, saving, or printing by the user, as indicated at step 695.
  • the nMCI Interact Message Center icon 293 may be selected which will cause the display of a web page including the message center dialog box 325 such as shown in Figure 10(a) . From the dialog box 325, a user may select from among three tabs, a news tab 327, a reports tab 328 and a data tab 329.
  • Selection of the reports tab 329 enables the retrieval of both a data file and a metadata file from the Inbox Server corresponding to those reports that have been run and available for customer viewing.
  • Information provided for display by the message center display 325 is provided by the User_table which keeps track of the status of all reports for a particular user.
  • a report viewer application is enabled to display the chosen report on a web-page.
  • Figure 10(b) illustrates an example web-page presenting a text viewer screen 335 enabled by selecting the highlighted report 330 in Figure 10(a) .
  • the Report Viewer 215 interfaces with the user's Inbox 210 for presenting to the customer the various type of reports received at the Inbox. It should be understood that all Report Requestor and Report Viewer applications communicate with the RM server 250 through the use of the common object communication classes.
  • the Inbox server 270 interface with the Inbox Client 210 supports messaging that enables the User to remove an item from the Inbox, e.g., delete a report, or, to delete all items from the Inbox, e.g., for a particular Enterprise and User ID as well as other associated reports.
  • Appendix G illustrates the parameters used in the metadata messaging between the Inbox client and the Inbox server.
  • the List “L” message is a synchronous request for a list of all Inbox items for a specific user.
  • the Inbox fetch "F" function is a bulk transfer request that enables bulk transfer of the requested file to the Inbox client.
  • the user may simply select to save the report and exit.
  • the ARD message is sent from the Report Requestor client to the RM server and is saved in the RM inventory database for subsequent execution. Consequently, the report is flagged as incomplete in the User_table and may not be run until a run option for that report is chosen. Otherwise, the report may be immediately scheduled if the user selects the save and run button.
  • Metadata messaging is used throughout the various components of the StarWRS system 200.
  • the format of an interface message that is sent to the Report Scheduler server is identical to the format as shown in Table 1 as is the interface messaging format returned by the RS server 260 in Table 2.
  • a variation of the process outlined in Figure 7 (c) occurs at step 660, whereby the ARD request is instead sent from the report scheduler to the fulfilling server at the programmed frequency.
  • the Report scheduler server 260 Figure 6
  • the Report scheduler server 260 Figure 6
  • the fulfilling server Upon processing of the metadata message, the fulfilling server will respond to the report Scheduler with an acknowledgment of the command, and the process outlined in Figures 7 (c) and 7 (d) is executed.
  • the Report Scheduler server 260 is additionally capable of updating the User_ report status table and, preferably, is provided with a tracking mechanism for tracking the scheduling of user reports. If the report is an Adhoc report, it is marked as inactive in the user report table once the status is complete.
  • Figure 11(a) illustrates a flow diagram depicting the Report Scheduler process 800 employed for executing scheduled reports as listed in a User_table maintained by the Report Manager and Report Scheduler servers. Preferably, each of these steps are accomplished by invoking stored procedures within the report scheduler Informix database.
  • the first step 802 is for determining a check point value, which is a specified time used as an index for selecting the reports to be run from the User_report table. Then, at step 804, a determination is made to determine if it is time to run a type of report, e.g., adhoc, hourly, daily, weekly, monthly.
  • step 804 If at step 804 it is determined that a report is to be run, then at step 806, a list of user reports that have a date older than the checkpoint date is requested. This list is accessed from the User_report table maintained in the report scheduler Informix database. Then, at step 808, a determination is made as to whether any reports were returned in the request. If no reports were returned, then the process returns back to step 802. If there are reports returned, then at step 810, a determination is made as to whether the customer can still report on the "hierarchies" in the particular report.
  • the Report request is submitted to the fulfilling server.
  • Scheduler server verifies the user access to hierarchy nodes, which verification is done via a direct connection with the StarOE Informix database tables, as indicated at step 812 shown as broken lines in Figure 11 (a) .
  • Appendix I provides a list of the stored procedures called by the Report Scheduler process used to validate a user's security level, i.e., node, corp id, service location. If the StarOE returns false, the hierarchy table is updated accordingly. Particularly, the Report Scheduler server 260 validates the user's hierarchy requests with StarOE prior to sending the ARD to the fulfilling server (e.g., ODS) . Any hierarchies that are no longer valid for the user are removed from the ARD and placed in a Hierarchy Notification report (not shown), which is added to the user's inbox.
  • the fulfilling server e.g., ODS
  • step 814 After determining whether the user can report on the "hierarchies," then, at step 814, a determination is made as to whether the user can perform the report. If the user can not perform this report, e.g., due to a hierarchy conflict, then the report file is FTP'd to the Inbox server reporting that the request can not be performed, as indicated at step 816, and, at step 818, a metadata "A" message is sent to the Inbox from the RS server 260 indicating the FTP file location. Afterward, the process returns to step 802 and the process repeats. If at step 814 it is determined that the user can perform the report, the process proceeds to step 820, Figure 11(b) where a determination is made as to whether the user can report on any portion of the report.
  • the process ends and returns to the report scheduler process at step 802. If the user can report on any portion then at step 822, a request is sent to the fulfilling server to execute that portion of the report that the user is entitled. A determination as to whether there were portions of the report that could not be performed is then made at step 824. If there were portions that could not be reported, a file is FTP'd to the Inbox server at step 826 to report to the customer that portion of the request that could not be reported. That is, any hierarchies or 800 numbers that are no longer valid for the customer are removed from the ARD and placed in the Hierarchy Notification report, and added to the user's inbox.
  • Scheduler performs the FTP of the report/data file to a known directory on the Inbox server, i.e., a "push" from Report Scheduler to the Inbox.
  • a directory is pre-defined on the Inbox server for the Report Scheduler, e.g., /inbox/files/rs .
  • step 828 an "A" message is sent to the Inbox indicating the FTP file location, and the process repeats by returning to step 802. If there were no portions that could not be reported, the process proceeds to step 802.
  • the messages created by the client Java software are transmitted to the StarWeb (DMZ) Server 24 over HTTPS.
  • the DMZ Web servers 24 decrypt a request, authenticate and verify the session information.
  • the logical message format from the client to the Web server is shown as follows :
  • Figure 12 illustrates a specific message sent from the client browser to the desired middle tier server for the particular application.
  • the client message 340 includes an SSL encryption header 342 and a network- level protocol HTTP/POST header 344 which are decrypted by the DMZ StarWeb Server (s) 24 to access the underlying message; a DMZ Web header 346 which is used to generate a cookie 341 and transaction type identifier 343 for managing the client/server session; a dispatcher header 345 which includes the target proxy identifier 350 associated with the particular type of transaction requested; proxy specific data 355 including the application specific metadata utilized by the target proxy to form the particular messages for the particular middle tier server providing a service; and, the network- level HTTP/POST trailer 360 and encryption trailer 365 which are also decrypted by the DMZ Web server layer 24.
  • the request After establishing that the request has come from a valid user and mapping the request to its associated session, the request is then forwarded through the firewall 25 over a socket connection 23 to one or more decode/dispatch servers 26 located within the corporate Intranet 30.
  • the messaging sent to the Dispatcher will include the user identifier and session information, the target proxy identifier, and the proxy specific data.
  • the decode/dispatch server 26 authenticates the user's access to the desired middle-tier service.
  • the StarWeb server forwards the Dispatcher header and proxy- specific data to the Dispatcher, "enriched" with the identity of the user (and any other session- related information) as provided by the session data/cookie mapping, the target proxy identifier and the proxy- specific data.
  • the dispatch server 26 receives the requests forwarded by the Web server (s) 24 and dispatches them to the appropriate application server proxies. Particularly, as explained generally above with respect to Figure 6, 5 the dispatch server 26 receives request messages forwarded by the DMZ Web servers and dispatches them to the appropriate server proxies.
  • the message wrappers are examined, revealing the user and the target middle- tier service for the request.
  • the message is then forwarded to the desired service's proxy, which, in the accordance with the principles described herein, comprises: 1) a report manager proxy 250' corresponding to the RM Server 250, 2) a report
  • Each of these proxy processes further performs: a validation process for examining incoming requests and confirming that they include
  • Figure 13 (a) and 13 (b) are schematic illustrations showing the message format passed between the Dispatcher 26 and the application specific proxy ( Figure 13 (a) ) and the message format passed between the application specific proxy back to the Dispatcher 26 ( Figure 13 (b) ) .
  • Figure 13 (a) all messages between the Dispatcher and the Proxies, in both directions, begin with a common header 110 to allow leverage of common code for processing the messages.
  • a first portion of the header includes the protocol version 115 which may comprise a byte of data for identifying version control for the protocol, i.e., the message format itself, and is intended to prevent undesired mismatches in versions of the dispatcher and proxies.
  • the next portion includes the message length 120 which, preferably, is a 32 -bit integer providing the total length of the message including all headers.
  • the echo/ping flag portion 122 that is intended to support a connectivity test for the dispatcher-proxy connection. For example, when this flag is non-zero, the proxy immediately replies with an echo of the supplied header. There should be no attempt to connect to processes outside the proxy, e.g. the back-end application services.
  • the next portion indicates the Session key 125 which is the unique session key or "cookie" provided by the Web browser and used to uniquely identify the session at the browser.
  • the next portion of the common protocol header indicates the message type/mechanism 130 which may be one of four values indicating one of the following four message mechanisms and types: 1) Synchronous transaction, e.g., a binary 0; 2) Asynchronous request, e.g., a binary 1; 3) Asynchronous poll/reply, e.g., a binary 2; 4) bulk transfer, e.g., a binary 3.
  • the common protocol header section includes an indication of dispatcher- assigned serial number 135 that is unique across all dispatcher processes and needs to be coordinated across processes (like the Web cookie (see above) ) , and, further, is used to allow for failover and process migration and enable multiplexing control between the proxies and dispatcher, if desired.
  • a field 140 indicates the status is unused in the request header but is used in the response header to indicate the success or failure of the requested transaction. More complete error data will be included in the specific error message returned. The status field 140 is included to maintain consistency between requests and replies.
  • the proxy specific messages 375 are the metadata message requests from the report requestor client and can be transmitted via synchronous, asynchronous or bulk transfer mechanisms.
  • the proxy specific responses are metadata response messages 380 again, capable of being transmitted via a synch, asynch or bulk transfer transport mechanism.
  • the application server proxies can either reside on the dispatch server ' 26 itself, or, preferably, can be resident on the middle-tier application server, i.e., the dispatcher front end code can locate proxies resident on other servers .
  • the proxy validation process includes parsing incoming requests, analyzing them, and confirming that they include validly formatted messages for the service with acceptable parameters. If necessary, the message is translated into an underlying message or networking protocol. A list of Report Manager and Inbox proxy error messages can be found in Appendix E. If no errors are found, the proxy then manages the communication with the middle- tier server to actually get the request serviced.
  • the application proxy supports application specific translation and communication with the back-end application server for both the Web Server (Java applet originated) messages and application server messages.
  • the Report Manager server, the Report Scheduler server and Inbox server proxies each employ front end proxy C++ objects and components.
  • a utils.c program and a C++ components library is provided for implementing general functions/objects.
  • Various C++ parser objects are invoked which are part of an object class used as a repository for the RM metadata and parses the string it receives.
  • the class has a build member function which reads the string which contains the data to store. After a message is received, the parser object is created in the RMDispatcher .
  • RMSErverSocket . c is a class implementing the message management feature in the Report Manager server. Public inheritance is from MCIServerSocket in order to create a specific instance of this object.
  • Socket. C is inherited by ClientSocket .C : : Socket (theSocketType, thePortNum) and ServerSocket . C : : Socket (theSocketType, thePortNum) when ClientSocket or ServerSocket is created.
  • a ServerSocket . c class implements client type sockets under Unix using either TCP/IP or TCP/UDP. ServerSocket .
  • C is inherited by RMServerSocket when RMServerSocket is created.
  • An InboxParser . c class used as a repository for the RM Metadata. The class' "build" member function reads the string which contains the data to store and the class parses the string it receives. After a message has been received, the MCIInboxParser object is created in inboxutl.c which is a file containing the functions which process the Inbox requests, i.e, Add, Delete, List, Fetch and Update. Additional objects/classes include: Environ. c which provides access to a UNIX environment; Process. c which provides a mechanism to spawn slave processes in the UNIX environment; Daemon.
  • ESQL code for RM/database interface includes the ESQC C interface (Informix) stored procedures for performing the ARD, DRD, DUR, URS, GRD, CRD, GPL, and GRINF messages.
  • the functions call the stored procedures according to the message, and the response is build inside the functions depending on the returned values of the stored procedures.
  • a mainsql.c program provides the ESQL C interface for messages from the report manager and report viewer.
  • a proxy listener socket on a middle- tier server e.g., report manager server
  • a proxy signal handler is invoked at step 904 to set all of the signals that the proxy is interested in handling. Then, as indicated at step 905, it waits for a connection signal from the dispatcher server, as indicated at step 905.
  • a determination is made as to whether the Proxy has accepted a connection request from the dispatcher. If the proxy could not accept the connection, a SignalHandler Routine is invoked as indicated at step 908 and described with reference to Figure 14 (b) . If the proxy accepts the connection, a child process is instantiated as indicated at step 910.
  • step 911 A determination is next made at step 911 to determine if the forked process was successful. If the forked process was successful, then a check is made at step 912 to determine if the child process was created for that session. If the child process was created, then the child process is invoked at step 915 as described with reference to Figure 14 (c) . If the child process was not created, a determination is made at step 916 to determine whether the parent proxy process is still executing. If the parent is still executing, then the current conversation socket is closed, as indicated at step 918, and the process returns to step 905. If the parent is not alive, then an error handler routine is invoked at step 920, and the process returns to step 905.
  • the Signal Handler routine is described with reference to Figure 14(b) . As shown at step 922, the SignalHandler routine first blocks all signals except the current signal.
  • step 924 it is determined that the received signal is equal to SIGBUS, then the process quit signal "SIGQUIT" is generated at step 932, and the process returns to step 930. If, at step 926, it is determined that the received signal is equal to "SIGQUIT”, then a SignalExit process is invoked to exit the process, as indicated at step 934, and the process returns to step 930. If, at step 928, it is determined that the received signal is equal to "SIGCHLD”, then a CleanupChild process is invoked to free-up the resource that the child process had used, as indicated at step 936, and the process returns to step 930.
  • step 935 If none of these signals were generated and no signals are pending, then at step 935 all signals are restored and the process returns to step 905, Figure 14(a) . If it is determined that a signal is pending at step 930, then the process proceeds to step 944. At step 944, a determination is made as to whether the received signal is equal to the SIGBUS indicating a bus error. If the received signal is not equal to SIGBUS, then a determination is made at step 946 as to whether the received signal is equal to the SIGQUIT. If the received signal is not equal to SIGQUIT, then a determination is made at step 948 as to whether the received signal is equal to the SIGCHLD. If the received signal is not equal to SIGCHLD, then the process proceeds to step 935 where all signals are restored and the process returns to step 905, Figure 14(a) .
  • step 944 it is determined that the received signal is equal to SIGBUS, then a SIGQUIT signal is generated at step 952, and the process returns to step 935. If, at step 946, it is determined that the received signal is equal to SIGQUIT, then a SignalExit process is invoked as indicated at step 954, and the process returns to step 935. If, at step 948, it is determined that the received signal is equal to SIGCHLD, then a CleanupChild process is invoked to free up the resource that the child had used, as indicated at step 956, and the process returns to step 935. If none of these signals were generated all signals are restored at step 935 and the process returns to step 905, Figure 14 (a) .
  • the client request is processed by the forked child process as indicated at step 915.
  • This procedure is described with reference to Figure 14(c) where, at step 960, the proxy header is received from the Dispatcher. If the header does not conform to the protocol, then at step 964, an error handling routine is invoked, and the socket connection to the Dispatcher is closed, as indicated at step 968, and the process terminates by returning at step 969 to the invoking procedure ( Figure 14 (a) ) . If the header conforms to the messaging protocol as determined at step 962, then a validation step is performed at step 965 wherein a connection to the Web server cookie jar is implemented to determine the validity of the current session.
  • the proxy application receives the metadata message.
  • the program will handle the error as indicated at step 987 and close the socket connection to the dispatcher server as indicated at step 995. Otherwise, as indicated at step 990, the proxy data obtained from the proxy application is sent to the dispatcher in accordance with the specified transaction mechanism. A determination is made at step 992 as to whether an error occurs when sending the proxy data back to the Dispatcher server. If an error occurs, the program will handle the error as indicated at step 987 and close the socket connection to the dispatcher as indicated at step 995. If the transmission is successful, the socket connection to the Dispatcher server closes, as indicated at step 995 and the process returns to step 905, Figure 14(a), to await the next proxy connection request.
  • Outgoing (server-to-client) communications follow the reverse route, i.e., the proxies feed responses to the decode/dispatch server and communicate them to the DMZ Web servers over the socket connection.
  • the Web servers will forward the information to the client using SSL.
  • the logical message format returned to the client from the middle tier service is shown as follows :
  • REPORTID Standard Report Char (10) Yes Report ID (i.e., ID 2, 44)
  • USERRPTID User Report ID Char (10) No User Report ID (i.e., 245). Limit on unique user report Ids is 2147483647
  • PL_LANG Pick List Type Character Yes Language code
  • OECountrylnfoRsp getCountryList Returns a list of Vector of objects — country objects. Contains These country OECountryinfo objects objects need to be that hold countries. further broken down to retrieve the two parts of a country (ID and long name).
  • OECountryinfo getField Returns a Field Field object that contains either a list of country ID's or a list of country long names.
  • OEStatelnfoRsp getStateList Returns a list of Vector - Contains states.
  • the Report strings to display to the Requestor displays user.
  • this this list of states to a list could contain the user in the following: CO, HI, Rl. geographic hierarchy.
  • OECitylnfoRsp getCityList Returns a list of Vector- Contains cities.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Development Economics (AREA)
  • Strategic Management (AREA)
  • Finance (AREA)
  • Game Theory and Decision Science (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer And Data Communications (AREA)

Abstract

Un système d'établissement de rapports basé sur le Web/Internet fournit une interface utilisateur graphique commune permettant la demande, la personnalisation, la planification et la visualisation de divers types de rapports produits par différentes applications (400, 500) et/ou plate-formes d'applications de serveurs. Le système d'établissement de rapports comprend des applications gestionnaire (250) de rapports, programmateur (250) et de demandeur (212) de rapports capables de définir, de créer, de gérer et de localiser des rapports spécifiques disponibles aux clients selon les droits du client. Une messagerie de métadonnées est employée pour permettre la présentation d'options de rapports spécifiques, la personnalisation des rapports ainsi que des options d'exécution/programmation de rapports. Une infrastructure de système basée sur le Web permet l'acquisition et la présentation sécurisées de rapports de clients à des clients à partir de n'importe quelle application du navigateur des clients.
PCT/US1998/020144 1997-09-26 1998-09-25 Interface mandataire integree pour ensemble d'outils demandeurs de rapports basee sur le web WO1999015976A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU96674/98A AU9667498A (en) 1997-09-26 1998-09-25 Integrated proxy interface for web based report requester tool set

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US6066597 1997-09-26
US60/060,665 1997-10-02

Publications (1)

Publication Number Publication Date
WO1999015976A1 true WO1999015976A1 (fr) 1999-04-01

Family

ID=22031002

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1998/020144 WO1999015976A1 (fr) 1997-09-26 1998-09-25 Interface mandataire integree pour ensemble d'outils demandeurs de rapports basee sur le web

Country Status (2)

Country Link
AU (1) AU9667498A (fr)
WO (1) WO1999015976A1 (fr)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001047183A2 (fr) * 1999-12-22 2001-06-28 Celeritas Technologies, L.L.C. Systeme de gestion de reseau geographique
EP1282294A2 (fr) * 2001-07-30 2003-02-05 Alcatel Méthode et système personalisé de fourniture de services de télécommunication
US7447509B2 (en) 1999-12-22 2008-11-04 Celeritasworks, Llc Geographic management system
EP2458532A1 (fr) * 2010-11-24 2012-05-30 Business Objects Software Ltd. Détection et affichage d'erreurs sémantiques dans un outil de rapport
US8224867B2 (en) 1999-12-22 2012-07-17 Celeritasworks, Llc Spatial data portal
CN106372048A (zh) * 2016-08-30 2017-02-01 北京北信源软件股份有限公司 一种报表生成系统及报表生成方法
US20170163565A1 (en) * 2015-12-04 2017-06-08 Bank Of America Corporation System for analysis of resource usage and availability
CN112329410A (zh) * 2020-10-30 2021-02-05 中盈优创资讯科技有限公司 一种图形化报表批量生成工具

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5696906A (en) * 1995-03-09 1997-12-09 Continental Cablevision, Inc. Telecommunicaion user account management system and method

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5696906A (en) * 1995-03-09 1997-12-09 Continental Cablevision, Inc. Telecommunicaion user account management system and method

Cited By (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8452776B2 (en) 1999-12-22 2013-05-28 Celeritasworks, Llc Spatial data portal
US9118579B2 (en) 1999-12-22 2015-08-25 Celeritas Works, LLC Geographic management system
US10187268B2 (en) 1999-12-22 2019-01-22 Celeritasworks, Llc Geographic management system
US9363146B2 (en) 1999-12-22 2016-06-07 Celeritasworks, Llc Geographic management system for determining and displaying network data and geospatial data
WO2001047183A2 (fr) * 1999-12-22 2001-06-28 Celeritas Technologies, L.L.C. Systeme de gestion de reseau geographique
US7469247B2 (en) 1999-12-22 2008-12-23 Celeritasworks, Llc Geographic management system
WO2001047183A3 (fr) * 1999-12-22 2002-11-07 Celeritas Technologies L L C Systeme de gestion de reseau geographique
US8224867B2 (en) 1999-12-22 2012-07-17 Celeritasworks, Llc Spatial data portal
US7447509B2 (en) 1999-12-22 2008-11-04 Celeritasworks, Llc Geographic management system
EP1282294A3 (fr) * 2001-07-30 2004-12-08 Alcatel Méthode et système personalisé de fourniture de services de télécommunication
EP1282294A2 (fr) * 2001-07-30 2003-02-05 Alcatel Méthode et système personalisé de fourniture de services de télécommunication
US8775463B2 (en) 2010-11-24 2014-07-08 Business Objects Software Limited Detection and display of semantic errors in a reporting tool
EP2458532A1 (fr) * 2010-11-24 2012-05-30 Business Objects Software Ltd. Détection et affichage d'erreurs sémantiques dans un outil de rapport
US20170163565A1 (en) * 2015-12-04 2017-06-08 Bank Of America Corporation System for analysis of resource usage and availability
CN106372048A (zh) * 2016-08-30 2017-02-01 北京北信源软件股份有限公司 一种报表生成系统及报表生成方法
CN112329410A (zh) * 2020-10-30 2021-02-05 中盈优创资讯科技有限公司 一种图形化报表批量生成工具

Also Published As

Publication number Publication date
AU9667498A (en) 1999-04-12

Similar Documents

Publication Publication Date Title
US6631402B1 (en) Integrated proxy interface for web based report requester tool set
US7058600B1 (en) Integrated proxy interface for web based data management reports
US6859783B2 (en) Integrated interface for web based customer care and trouble management
US6745229B1 (en) Web based integrated customer interface for invoice reporting
US6714979B1 (en) Data warehousing infrastructure for web based reporting tool
US7225249B1 (en) Integrated systems for providing communications network management services and interactive generating invoice documents
US6515968B1 (en) Integrated interface for real time web based viewing of telecommunications network call traffic
US6032184A (en) Integrated interface for Web based customer care and trouble management
US20040193512A1 (en) Web based integrated customer interface for invoice reporting
WO1999015976A1 (fr) Interface mandataire integree pour ensemble d'outils demandeurs de rapports basee sur le web

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AU BR CA JP MX SG

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: CA