Patent Application
20170168664
Embodiments generally relate to computer systems and more particularly to methods and systems to provide real time data analytics and visualization.
With the increasing deployment of cloud based services, web based applications, software as a service, service oriented architectures, and so forth, the locations of services and applications are crossing physical, jurisdictional, and security boundaries. Cloud platform provides a set of modular cloud based services with a set of development tools. One of the challenges with cloud platforms is providing analytics as a service (AaaS) and exposing a large volume of data to the AaaS provider in a secure way. AaaS refers to a provision of analytics software and operations through web-delivered technologies. Analytics tools in the cloud based services may depend on hardcore data model for analyzing data.
The claims set forth the embodiments with particularity. The embodiments are illustrated by way of examples and not by way of limitation in the figures of the accompanying drawings in which like references indicate similar elements. The embodiments, together with its advantages, may be best understood from the following detailed description taken in conjunction with the accompanying drawings.
Embodiments of techniques to provide real time data analytics and visualization are described herein. In the below description, numerous specific details are set forth to provide a thorough understanding of embodiments. One skilled in the relevant art will recognize, however that the embodiments can be practiced without one or more of the specific details or with other methods, components, techniques, etc. In other instance, well-known operations or structures are not shown or described in detail.
Reference throughout this specification to “one embodiment”, “this embodiment” and similar phrases, means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one of the one or more embodiments. Thus, the appearances of these phrases in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
In this document, various methods, processes and procedures are detailed. Although particular steps may be described in a certain sequence, such sequence is mainly for convenience and clarity. A particular step may be repeated more than once, may occur before or after other steps (even if those steps are otherwise described in another sequence), and may occur in parallel with other steps. A situation where upon completion of the first step, a second step is executed will be specifically pointed out when not clear from the context. A particular step may be omitted. A particular step is required only when its omission would materially impact another step.
In this document, various computer-implemented methods, processes and procedures are described. It is to be understood that the various actions (determining, identifying, receiving, rendering, storing, retrieving, displaying etc.) are performed by a hardware device (e.g., computing system), even if the action may be authorized, initiated or triggered by a user, or even if the hardware device is controlled by a computer program, software, firmware, and the like. Further, it is to be understood that the hardware device is operating on data, even if the data may represent concepts or real-world objects, thus the explicit labeling as “data” as such is omitted.
The system 100 includes a database layer (e.g., database 110) to persist the transactional data corresponding to microservices such as “customers”, “orders”, “employees” and the like. The database 110 can be a cross-platform document oriented database including a set of collections. A collection holds a set of documents. The documents may have dynamic schema. Dynamic schema may refer to the documents in the same collection may not have the same set of fields or structure, and common fields in the documents may hold different types of data. An example of the database 110 is MongoDB®. MongoDB eschews the traditional table-based relational database structure in favor of JavaScript® Object Notation (JSON) like documents, making the integration of data in applications easier. Further, actions such as inserting, updating and deleting data on the database 110 is achieved via another layer, called a document repository layer (e.g., document repository 120) as the data in the database 110 is restricted to registered users. The document repository 120 is responsible for create, read, update and delete (CRUD) operations in the database 110. The document repository 120 provides a service to store or retrieve the data in form of multi tenancy. Thereby, the customers can have their own documents stored. For example, the document repository 120 is called to create microservice's own data persisted in the database 110.
The system 100 includes microservices 130. In the microservices 130, an option is provided to create a microservice, e.g., for a particular test. For example, joined data can be retrieved by creating another service, known as Mashup, which can get the data from different microservices and integrate as one response. Mashup uses content from more than one microservice to create a single new service displayed in a graphical user interface (GUI), e.g., on a user device.
In one embodiment, the system 100 includes visualizer 140 to generate real time reports using REST services built on the cloud platform. The visualizer 140 analyzes transactional data, during run time, associated with the microservices to generate analytical rich data using analyzer 150. Further, the analytical rich data is displayed on the GUI as a report. Further, the report can be persisted in a form of a visualization package (e.g., at visualization package repository 160). The visualization package can be used in other applications using the public shared uniform resource locator (URL) into an iframe tag, for instance. The iframe tag specifies an inline frame. The inline frame may be used to embed another document within a current hypertext markup language (HTML) document. In one exemplary embodiment, the visualizer 140 can be integrated into a platform layer itself and can be provided as Analytics as a Service (AaaS) to analyze large volume of data in real time. Further, the visualizer 140 displays the analyzed data on the GUI using different visualization types.
In one exemplary embodiment, a network allows user devices and the visualizer 140 to communicate and exchange data. The user device may be a computing device, such as a desktop computer, a laptop computer, a mainframe computer, a handheld computer, a tablet computer, a personal digital assistant (PDA), a cellular telephone, a network appliance, a camera, a smart phone, an enhanced general packet radio service (EGPRS) mobile phone, a media player, a navigation device, an email device, a game console, or an appropriate combination of two or more of such devices or other data processing devices, that is capable of accessing the visualizer 140. Thereby, an embedded analytics or analytics as a service in the cloud platform is achieved by the visualizer 140.
In one exemplary embodiment, the GUI includes different portions. One portion of the GUI renders the microservices to be analyzed. Example of microservices can be, but are not limited to “customers”, “products” and “orders.” Further, a microservice includes one or more microservice dimensions or attributes. For example, microservice “customers” includes microservice dimensions such as “customer names”, “customer ID”, “customer gender”, “customer age” and “customer status.”
At 220, a request is received for analyzing the microservices. The request includes selection of a visualization type and at least one of the microservices. The visualization type includes at least one of a histogram, a graph, a timeline, a chart, a popup, a list and a table. Further, the visualization type may include combination of different graphs or tables based on number of layouts on the GUI. Further, the request may include selection of at least one of an analytical dimension and a microservice dimension or a presentation dimension. The analytical dimension defines analytical parameter based on which the microservices are analyzed. The analytical dimension can be, but not limited to “count”, “group”, and “sum.” The microservice dimension defines attribute of the microservice such as “customer ID”, “customer status”, “customer gender” and the like. For example, a microservice “customer”, a microservice dimension “customer status” and an analytical dimension “count” is selected as input. In one exemplary embodiment, one portion of the GUI provides an option to input the request.
At 230, the microservices are analyzed based on the selection of the at least one of the microservices, and the corresponding at least one of the analytical dimension and the microservice dimension. In the example, the count (e.g., analytical dimension) of number of customers (e.g., microservice) having “inactive” status and “active” status (e.g., microservice dimension) are determined based on the request. At 240, the results of the analysis are displayed on the GUI based on the selected visualization type. For example, when the histogram is selected as the visualization type, the count of number of “active” customers and the count of number of “inactive” customers are displayed on a bar chart. In one exemplary embodiment, the visualizer enables advanced operations such as, but not limited to drill down, comparison of results of a query and an order in which the results are sorted, which are illustrated in
Second portion (e.g., 340) provides a list of visualization types such as, but not limited to a histogram, a line graph, a pie chart. In one exemplary embodiment, a user can select a type of graph on which analyzed data can be visualized by performing actions such as, but are not limited to dragging and dropping desired chart, double clicking the chart. Another portion on the GUI provides an option (e.g., layouts 360) to display the analytics in multiple layouts. For example, when a user desire to visualize multiple charts, the user can select multiple layouts to be displayed on the GUI. Further, third portion (e.g., 350) provides an option to receive request for analytics and display results of the analysis based on the received request, which are illustrated in
Further, the pop-up may include optional features (e.g., 440) such as, but limited to, comparing results of a query and sorting the results based on the comparison. For example, the features include an option to provide query (e.g., “q: customer ID”), sort in an order (e.g., ascending order, descending order), number of results to be displayed in a page (e.g., page size) and page numbers.
When a user desire to analyze the data in Table 1 by grouping customer based on gender, an input including a visualization type (e.g., pie chart), microservices (e.g., customers), corresponding analytical dimension (e.g., group) and microservice dimension (e.g., customer gender) is provided to a visualizer. Based on the input, a graph (e.g., 610) is displayed on the GUI depicting grouping of customers as per genders. Thereby, the portion 350 of the visualizer 310 displays analysis of microservices based on the input including visualization type as pie chart and grouping based on the gender of the customers.
The process described above is not limited to embodiments that solve any disadvantages or that operate only in environments such as those described above. Further, the above described process to model the data internally and provide analytical capability and configured to visualize the analysis.
Some embodiments may include the above-described methods being written as one or more software components. These components, and the functionality associated with them, may be used by client, server, distributed, or peer computer systems. These components may be written in a computer language corresponding to one or more programming languages such as, functional, declarative, procedural, object-oriented, lower level languages and the like. They may be linked to other components via various application programming interfaces and then compiled into one complete application for a server or a client. Alternatively, the components maybe implemented in server and client applications. Further, these components may be linked together via various distributed programming protocols. Some example embodiments may include remote procedure calls being used to implement one or more of these components across a distributed programming environment. For example, a logic level may reside on a first computing system that is remotely located from a second computing system containing an interface level (e.g., a graphical user interface). These first and second computing systems can be configured in a server-client, peer-to-peer, or some other configuration. The clients can vary in complexity from mobile and handheld devices, to thin clients and on to thick clients or even other servers.
The above-illustrated software components are tangibly stored on a computer readable storage medium as instructions. The term “computer readable storage medium” should be taken to include a single medium or multiple media that stores one or more sets of instructions. The term “computer readable storage medium” should be taken to include any physical article that is capable of undergoing a set of physical changes to physically store, encode, or otherwise carry a set of instructions for execution by a computing system which causes the computing system to perform any of the methods or process steps described, represented, or illustrated herein. A computer readable storage medium may be a non-transitory computer readable storage medium. Examples of a non-transitory computer readable storage media include, but are not limited to: magnetic media, such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROMs, DVDs and holographic devices; magneto-optical media; and hardware devices that are specially configured to store and execute, such as application-specific integrated circuits (“ASICs”), programmable logic devices (“PLDs”) and ROM and RAM devices. Examples of computer readable instructions include machine code, such as produced by a compiler, and files containing higher-level code that are executed by a computer using an interpreter. For example, an embodiment may be implemented using Java. C++, or other object-oriented programming language and development tools. Another embodiment may be implemented in hard-wired circuitry in place of, or in combination with machine readable software instructions.
A data source is an information resource. Data sources include sources of data that enable data storage and retrieval. Data sources may include databases, such as, relational, transactional, hierarchical, multi-dimensional (e.g., OLAP), object oriented databases, and the like. Further data sources include tabular data (e.g., spreadsheets, delimited text files), data tagged with a markup language (e.g., XML data), transactional data, unstructured data (e.g., text files, screen scrapings), hierarchical data (e.g., data in a file system, XML data), files, a plurality of reports, and any other data source accessible through an established protocol, such as. Open Data Base Connectivity (ODBC), produced by an underlying software system (e.g., ERP system), and the like. Data sources may also include a data source where the data is not tangibly stored or otherwise ephemeral such as data streams, broadcast data, and the like. These data sources can include associated data foundations, semantic layers, management systems, security systems and so on.
Although the processes illustrated and described herein include series of steps, it will be appreciated that the different embodiments are not limited by the illustrated ordering of steps, as some steps may occur in different orders, some concurrently with other steps apart from that shown and described herein. In addition, not all illustrated steps may be required to implement a methodology in accordance with the one or more embodiments. Moreover, it will be appreciated that the processes may be implemented in association with the apparatus and systems illustrated and described herein as well as in association with other systems not illustrated.
The above descriptions and illustrations of embodiments, including what is described in the Abstract, is not intended to be exhaustive or to limit the one or more embodiments to the precise forms disclosed. While specific embodiments of, and examples for, the embodiments are described herein for illustrative purposes, various equivalent modifications are possible within the scope of the embodiments, as those skilled in the relevant art will recognize. These modifications can be made in light of the above detailed description. Rather, the scope is to be determined by the following claims, which are to be interpreted in accordance with established doctrines of claim construction.
