Patent Application
20150007129
Business Intelligence (BI) includes a category of software systems and applications that are used to improve business enterprise decision-making and governance. These software tools provide techniques for analyzing and leveraging enterprise applications and data. These tools are commonly applied to financial, human resource, marketing, sales, service provision, customer, and supplier analyses. BI tools work with data management systems to collect, store, and manage raw data and transactional data generated by enterprise systems.
Business Intelligence tools available today can generate reports from diverse data sources that aid in decision-making. While handling complex algorithm associated with multi-threaded programs, viewing a potential resultant of a business process ahead of execution helps in decision making. This requires simulation of the business process with actual 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 generate a business intelligence (BI) script execution framework are described herein. A BI script execution framework allows a user of the framework to write a script containing business logic to execute a corresponding business process. Such a script is processed using the BI script framework such that multithreaded processes associated with the business process are simulated and a semantically operational report is generated. The report containing potential resultant of the execution of the business process may be used to make business decisions. For instance, if a sales report of the month January 2013 can be simulated ahead of time, say on 15th day of January 2013, instead of waiting till the 1st day of (the subsequent month) February 2013, business decisions can be taken to rectify or improve actual resultant based on the simulated resultant. For instance, business decisions like: increasing production to maintain planned revenue, can be taken ahead of time instead of waiting till the actual execution of the business process.
In the following description, numerous specific details are set forth to provide a thorough understanding of the 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, materials, etc. In other instances, well-known structures, materials, or operations 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 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 an embodiment, a business process may be simulated ahead of an actual execution using script execution framework 110. A business process represents any group of activities that are required to be executed to achieve an end result. For instance, execution of “sales report for year 2013” can depict a business process to achieve an end result “revenue generated for year 2013”. Business logics, representing instructions to handle information exchange and processing between two entities, may be involved in executing the business processes. Such business logics include business rules and workflows representing business policies and orchestrations of tasks, respectively. The business policies and/or the orchestrations of tasks may depend on various attribute based on an end-user requirement and an intended result. In such cases, a configuration module (e.g. a system) or an administrator (e.g. a user) of a system, associated with system 100 may need to have an awareness and understanding about source codes associated with the execution of the business process. In addition, the configuration module or the administrator should be aware of various business data service providers (e.g. domain specific languages, business warehouse, reporting and analytical tools) and their respective functionalities available to carry out such business processes.
A BI script framework such as script execution framework 110 acts as a BI functionality that allows scripts to be generated by the configuration module and/or written by the user, which are compiled with the existing instructions to execute the business process. The instructions along with metadata related to the business process may be stored in storage 120. These scripts (also referred to as “Bi scripts) may be as elaborate as writing an entire source program for execution, or as minimal as changing one or more values of policies or instructions associated with the business logic. An elaborate script writer (user or module) may write the entire source codes corresponding to the business data service providers and the functionalities associated with the business process. A minimal script writer (a user or a script generation module) may write mere variables in the available source codes as inputs to script execution framework 110.
Providing such a BI script framework (e.g. 110) enables a client system 105 (e.g. a user or a system) to execute the business process at server system 115, even with nominal input from client system 105. BI script framework 110 provides a feature of simulating the business process at server system 115, with the input received from client system 105. Simulating the business process may be advantageous to be able to view a potential resultant of the business process in correspondence with the input received, ahead of an actual execution. In this way, the actual execution of the business process and any operations related to the execution are imitated by BI script framework 110, in advance of the actual execution. Based on the simulated results, business decisions, such as of betterment or advancement or modification of the actual execution of the business process, can be constructed.
In an embodiment, from a user interface (UI) associated with user interface component 215, client-side system 205 sends a selection of a business process to simulate an execution of the selected business process. In an embodiment, server-side system 210 renders a list of business processes, and client-side system 205 selects at least one business process for execution. A selection of a data service provider may also be received via the UI associated with UI component 215. This selection may be initiated by client-side system 205 or server-side system 210. For client-side system 205 to select the data service provider, server-side system 210 may render a list of data service providers available to execute the selected business process. Upon receiving the selection of the business process and the selection of the data service provider to process the business process, server-side system 210 generates a list of script-patterns available for the selected data service provider. Upon selecting a script-pattern via UI component 215, script execution framework 220 is triggered for simulation. In an embodiment, script-pattern represents parameters associated with the execution of a corresponding business process. Script-patterns represent the parameters that include executable instructions or machine codes, or instructions available with server-side system 210 to execute a corresponding business process. In an embodiment, source tags represent parameters that receive input from a user or a machine, to execute a corresponding business process. In an embodiment, unstructured data store 265 stores the parameters and associated data for retrieval. In an embodiment, information related to the data service provider is stored in data store 250.
Upon receiving the trigger to simulate the execution from UI component 215, query module 235 associated with script execution framework 220 generates a query by determining a plurality of result objects and a plurality of query filters. Result objects and query filters represent a plurality of source tags operable to receive an input. Based upon the input to the source tags associated with the script-pattern, an analytical report is generated as a resultant of the execution of the business process. Result objects may include a plurality of fields that are represented as report fields the analytical report, and the query filters may include a plurality of conditions to be satisfied to generate the analytical report. For instance, consider a business process, “a university admission process”. Result objects include ‘name of student’, ‘aggregate score of eight subjects’ and ‘aggregate science score of three subjects’; and query filters include ‘total score greater than or equal to 700’, ‘science score greater than or equal to 260’, and ‘literature score greater than or equal to 150’. The query including the result objects and the query filters is generated by query module 235.
For the query, one or more business rules are obtained to generate the analytical business report associated with the business process. In an embodiment, BI script is received from client-side system 205 in the form of the business rules. The business rules include conditions to execute the business process. Exemplary business rules for the university admission process are illustrated in the following table, Table 1.
In an embodiment, query module 235 determines one or more source tags associated with the select script-pattern. Source tags are operable to receive BI script as input to execute the business process. The input received for the source tags include the result objects, the query filters, and the business rules to execute the business process. In an embodiment, the source tags are operable to receive elementary inputs, including mere variables or values for variables present in an available BI script, associated with the selected script-pattern. In another embodiment, the source tags are operable to receive an entire source code, business data, variables, values, functionalities and the like. In an embodiment, BI script is received from client-side system 205 in the form of input to the source tags.
Validation module 240 embeds the received BI script along with the selected script-pattern to generate a BI source code. Embedding the BI script along with the script-pattern includes receiving the input to the source tags (as variables, values, etc.) present in the script-pattern. For instance, if the BI script included one or more values to corresponding source tags associated with the selected script-pattern, the values received in the form of the BI script is embedded in the script-pattern to generate an executable BI source code. In another instance, if the BI script included an entire source code as input to corresponding source tags associated with the selected script-pattern, the source code is implanted in the script-pattern, along with other parameters associated with the selected business process to generate the executable BI source code.
Upon embedding the received BI script along with the selected script-pattern (e.g. parameters), the BI source code that is generated is validated by validation module 240. Validating the BI source code includes a determination that the BI source code meets necessary specifications to execute the business process. These specifications may represent a protocol to represent the BI source code to script execution framework 220, for execution/simulation. Upon validating the 131 source code, script execution framework 220 simulates an execution of the business process, and generates a data visualization depicting the simulation. In an embodiment, based on the BI Script, an instance of the script execution framework is generated to simulate the execution of the business process.
In an embodiment, server-side system 210 is operable to receive a trigger to simulate the execution of the business process. In response to the trigger, server-side system 210 simulates the execution by operating script execution framework 220. Operating the script execution framework 220 includes receiving the selection of a script-pattern from the plurality of script-patterns residing in script-pattern repository 255; embedding the BI script received and the script-pattern selected to generate the BI source code and to simulate the execution to generate the data visualization. This data visualization may be an exemplary BI report including potential resultant of the execution of the business process, to make business decisions. In an embodiment, script execution framework 220 receives the BI source code and generates a plurality of BI classes. Based upon the BI classes, the BI source code is executed in script execution framework 220 to generate the BI report for the business process. In an embodiment, generating the plurality of BI classes includes generating an actual class and a nested class of each BI class. The actual class and the nested class are operable to receive user content. Publication conditions may be associated with the user content, to restrict access and/or publication of the content to all the users. For example, consider a business process “SALES REPORT FOR YEAR 2013” involving two sales persons X and Y. A sales manager who accesses this business report may not want X to see Y's performance, and vice versa. In this situation, publication conditions may be created for rendering certain business content as a resultant of execution of the business process. Such publication conditions associated with the received user content is determined and stored along with the user content in an associated temporary bin. While an execution is performed, processor 225 may parse the temporary bin to determine any associated publication content. Similarly, the actual class and the nested classes are stored along with the selected BI pattern in the temporary bin. In an embodiment, client-side system 205 is operable to receive the request to execute the business process. Upon receiving the selected business process, client-side system 205 generates a plurality of script-patterns, and receives a selection of one of the script-pattern. Client-side system 205 provides the BI script as the input to the source tags associated with the selected script-pattern, and triggers the simulation to execute the business process. In an embodiment, generating the script-patterns configuring the script-patterns based upon a selected data service provider. The script-patterns include reusable instructions, solutions and content to commonly occurring codes in a program. A script-pattern may be a complete or an incomplete reusable solution that can be transformed to source code by appending corresponding inputs from client-side system 205. Such script-patterns are configurable depending on the selected data service provider and the business process to be executed. By doing so, a set of script-patterns are available for multiple executions of the business process associated with the data service provider, at various instances. To configure such script-patterns, pattern keys and display values are generated for the selected data service provider. Pattern keys and display values represent various functionalities and classifications of script-pattern. Utility methods and associated member variables are generated for the selected business process. Utility methods represent structures, collaborations, implementations, and various other contexts in which the script-pattern can be utilized. Input member variables provided for such methods are applied according to documentation formats of the script-pattern. Based upon the input received for the pattern keys and the display values, the script-patterns may be configured for the corresponding business process.
In an embodiment, script execution framework 220 is in communication with server-side system 210 and client-side system 205 to simulate the execution of the business process. Script execution framework 220 is also operable to receive a script written by a client machine and execute the script along with a corresponding source code on a server machine. Various business logics may be involved in executing complex business processes having multiple threads. The multiple threads of business process may illustrate sequence of programmed instructions that are executed independently and/or interdependently to achieve an end result. For instance, determining relationships between ten family members may represent a multithreaded business process. The multithreaded illustration can be described by the number of relationships each member shares between each other. Script execution framework 220 is operable to execute multithread processes.
Analysis module 245 associated with script generation framework 220 is operable to receive a plurality of filters and a plurality of result objects as query elements. Analysis module 245 queries relational database 260, to retrieve parameters corresponding to the business process (multithreaded process). Analysis module 245 is operable to provide the business process in script execution framework 220, based on the query elements.
Upon selecting one such service provider, an associated processor retrieves a plurality of script-patterns corresponding to the selected service provider. In an embodiment, at 305, a selection of a script-pattern from the plurality of script-patterns residing in a data source (associated with the exemplary selected data service provider) is received. The selected script-pattern is analyzed to determine a plurality of source tags associated with the script-pattern, which are operable to receive an input, at 310.
At 315, a business intelligence (BI) script is received as an input to the source tags corresponding to the selected script-pattern, to execute the business process. The received BI script and the selected scrip-pattern are embedded to generate a BI source code, at 320. In an embodiment, the source code includes a complete program that is operable to execute the business process according to a plurality of business logics specified in the BI script. The BI source code is validated and a BI script framework is generated at 325, to execute a business process.
In an embodiment, the BI script is configured to receive the BI source code and generate a plurality of BI classes, each representing an instance of the business process according to the BI script. The BI source code is executed based upon the BI classes, to generate a BI report of the business process. The BI report may include simulated analytical data of the business process.
In another embodiment, the BI script framework is configured to simulate the business process according to a planned business rule, and generate a semantic analysis for the execution of the business process according to an actual business rule. For instance, consider a “seat-selection process for Wimbledon tennis tournament” to be the business process that needs to be executed. Simulating the business process ahead of the actual execution may be beneficial to determine the number of selections for every match, every set and every game. Consider a spectator ‘A’ who wants to watch the first and the second set of a particular match; spectator ‘B’ wants to watch the second and the third set; spectator ‘C’ wants to watch the entire match; and spectator ‘D’ wants to watch all the matches played on a particular day. If spectator ‘D’ were to choose a particular seat number ‘Z12’ for the entire day, the seat ‘Z12’ needs to be removed during the seat selection for the rest of the spectators. Also, if spectator ‘D’ were to choose the seat after spectator ‘A’ choose his seat, the availability of seat number ‘Z12’ may be provided to spectator ‘D’ for the rest of the game and rest of the day. Such planned business rule may be submitted as the BI script for a selected pattern associated with the execution of the “seat-selection process for Wimbledon tennis tournament”. By simulating such a business process, the analytical data of the actual resultant—which may include an actual availability of seats for selection at actual instances, may be determined. If any modifications or adjustments need to be made to the seats available, or the number of highest-opted seats, or a row of seats under maintenance, and the like, an event-manager responsible for booking the seats may be informed ahead of time. The instances of an actual seat-selection carried out by each spectator may represent the actual business rule.
To generate the script execution framework, a selection of a script-pattern residing in a data source—is received. Source tags corresponding to the selected script-pattern are determined, to be able to receive an input. From an associated user interface, business intelligence (BI) script is received as an input to the source tags, to execute the business process. The BI script received from the UI is embedded with the selected script-pattern to generate a BI source code. The generated BI source code is validated and processed to generate the script execution framework. Such a generated BI script execution framework is operable to simulate the business process and generate a corresponding BI report, which can be used for decision-making.
Accordingly, result objects 520 including NAME 522, PCM (physics, chemistry, and math) AGGREGATE 524, PCB (physics, chemistry, and biology) AGGREGATE 526 and AVERAGE TOTAL SCORE 528 are selected as report fields to be visualized in the analytical report (to be generated, at this instance).
Query filters 530 representing business rules: ‘COURSE NAME: SELECT FROM LIST: ENGINEERING’ 532; ‘PCM (Physics Chemistry Math) SCORE: GREATER THAN OR EQUAL TO: PCM_CUTOFF’ 534; ‘PCB SCORE: GREATER THAN OR EQUAL TO: PCB_CUTOFF’ 536; AND ‘TOTAL SCORE: GREATER THAN OR EQUAL TO: OVERALL_CUTOFF’ 538 are provided as filters to process data in the data structure.
Based upon selected SCRIPT-PATTERN 1510A, other source tags including ‘IMPORT STATEMENTS AND APT’ 542, ‘CLASS LEVEL CODE’ 544, and ‘ALGORITHM AND RESULT OBJECT ASSIGNED TO OUTPUT’ 546 are provided to receive a BI script. For instance, consider a cutoff score for engineering admission is 240 out of 300 marks scored in physics, chemistry and math; and that for medical admission is 270 out of 300 marks scored in physics, chemistry and biology. The BI script (e.g. 520, 530, 540) thus written is embedded along with selected SCRIPT-PATTERN 1510A, to generate a BI source code, SCRIPT-PATTERN 1510A includes rest of the program associated with the execution of UNIVERSITY SEAT SELECTION 505. For instance, SCRIPT-PATTERN 1510A includes reusable instructions and/or code for every business process that does not contain source tags configured to receive input.
In another example, SCRIPT-PATTERN 1510A is completely available for modification, and based upon an expected resultant, an entire BI source code is written and provided as an input. In certain examples, SCRIPT-PATTERN 1510A includes an entire BI source code, and is operable to receive various values for parameters in the BI source code. Here, only such parameters operable to receive values as input are rendered on UI 500. Thus, BI script elements may include any one or more of result objects 520, query filters 530, BI script elements 540, import statements and predefined application program interfaces (APIs) 542, class level code 544 and algorithm and result object assigned to output 546.
Upon embedding the BI script along with SCRIPT-PATTERN 1510A, a BI source code is generated. The BI source code is validated to determine whether the BI source code meets necessary specifications to execute the business process. If a result of the validation is negative, any errors occurring in the generated BI source code may be fixed. Upon validation, a trigger to simulate the execution of business process UNIVERSITY SEAT SELECTION 505 is received. Simulating UNIVERSITY SEAT SELECTION 505 includes parsing every element (row) from the data structure illustrated in
If AARON is eligible for engineering admission only, AARON is assigned to the engineering admission list, if AARON was eligible to both, and prefers engineering, AARON's name is entered in engineering admission list only. If AARON was eligible to both, and prefers medical, AARON's name is entered in medical admission list only. If AARON is neither eligible to medical nor to engineering, AARON's name is entered in literature admission list. Thus, by simulating the multithreaded admission process of medical admission, engineering admission and literature admission, an actual UNIVERSITY SEAT SELECTION admission list can be prepared beforehand, HAVA (ROW 7) is eligible for engineering admission, but her preference is medical admission. Here, the eligibility overrides the preference, and the admission column for ROW 7 is updated as engineering. LADD (ROW 11) prefers medical admission, and his eligibility is medical or engineering. Hence, the admission column of ROW 11 is updated as medical, SEGER (ROW 16) is eligible for literature alone. Hence, though his preference is medical or engineering, the admission column of ROW 16 is updated as literature.
The business process UNIVERSITY SEAT SELECTION 505 (
Sonic embodiments may include the above-described methods being written as one of more software components. These components, and the functionality associated with each, 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 computer system that is remotely located from a second computer system containing an interface level (e.g., a graphical user interface). These first and second computer 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 computer system which causes the computer 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.
In the above 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 instances, well-known operations or structures are not shown or described in detail.
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 one or more embodiments to the precise forms disclosed. While specific embodiments of and examples for, the one or more embodiments are described herein for illustrative purposes, various equivalent modifications are possible within the scope, 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.
