Data surfacing control framework

A parallel processing framework comprises, in one example, a data gathering system configured to receive a set of data requests, each corresponding to at least one structured data representation (SDR). The data gathering system is configured to obtain a data set for each of the data requests. The parallel processing framework comprises an SDR generation system configured to receive indications of the plurality of data requests and, for each data request, an indication as to whether the data set corresponding to the data request has been obtained by the data gathering system. The SDR generation system is configured to generate the plurality of SDRs based on the data sets obtained by the data gathering system.

BACKGROUND

Computing systems are currently in wide use. As one example, a computing system stores data as entities or other data records, and commonly includes process functionality that facilitates performing various processes or tasks on the data. Users log into or otherwise access the computing system in order to perform the processes and tasks. The data can include user data as well as entities or records that are used to describe various aspects of the computing system.

An organization may use a computing system to create, track, and manage various aspects of the organization and to conduct a variety of different activities. A user may desire to surface data about various aspects related to the organization, such as to generate reports. These reports can be sent to a variety of destinations. For example, they can be printed, saved to file, and/or electronically sent to recipients.

SUMMARY

In a computing system, a data store stores data including, but not limited to, user data as well as entities and records that are used to describe various aspects of the computing system. The computing system includes a framework for surfacing the data, for example in response to a user request.

In one example, a parallel processing framework comprises a data gathering system configured to receive a set of data requests, each corresponding to at least one structured data representation (SDR). The data gathering system is configured to obtain a data set for each of the data requests. The parallel processing framework comprises an SDR generation system configured to receive indications of the plurality of data requests and, for each data request, an indication as to whether the data set corresponding to the data request has been obtained by the data gathering system. The SDR generation system is configured to generate the plurality of SDRs based on the data sets obtained by the data gathering system.

DETAILED DESCRIPTION

FIG. 1is a block diagram of one example of a data accessing architecture100. Architecture100includes a computing system102that is accessible by one or more users through one or more user interface displays. As shown inFIG. 1, computing system102includes one or more processor(s)104and a user interface component106. User interface component106generates user interface display(s)108with user input mechanisms110, for interaction by a user112. Computing system102can include other items107as well.

User112can access computing system102locally or remotely. In one example, user112uses a client device that communicates with computing system102over a wide area network, such as the Internet. User112interacts with user input mechanisms110in order to control and manipulate computing system102. For example, using user input mechanisms110, user112can access data in a data store114. User data access can include, but is not limited to, read access, write access, and/or update access to the data. Updating data can include modifying and/or deleting data in data store114.

User input mechanisms110sense physical activities, for example by generating user interface display(s)108that are used to sense user interaction with computing system102. The user interface display(s)108can include user input mechanism(s)110that sense user input in a wide variety of different ways, such as point and click devices (e.g., a computer mouse or track ball), a keyboard (either virtual or hardware), and/or a keypad. Where the display device used to display the user interface display(s)108is a touch sensitive display, the inputs can be provided as touch gestures. Similarly, the user inputs can illustratively be provided by voice inputs or other natural user interface input mechanisms as well.

Computing system102can be any type of system accessed by user112. In one example, but not by limitation, computing system102can comprise an electronic mail (e-mail) system, a collaboration system, a document sharing system, a scheduling system, and/or an enterprise system. In one example, computing system102comprises a business system, such as an enterprise resource planning (ERP) system, a customer resource management (CRM) system, a line-of-business system, or another business system.

As such, computing system102includes applications116that can be any of a variety of different application types. Applications116are executed using an application component117that facilitates functionality within computing system102. By way of example, application component117can access information in data store114. For example, data store114can store data118and metadata120. The data and metadata can define work flows122, processes124, entities126, forms128, and a wide variety of other information130. By way of example, application component117accesses the information in data store114in implementing programs, workflows, or other operations performed by application component117.

Processor(s)104comprises a computer processor with associated memory and timing circuitry (not shown). The processor is illustratively a functional part of system102and is activated by, and facilitates the functionality of, other systems, components and items in computing system102.

FIG. 1shows a variety of different functional blocks. It will be noted that the blocks can be consolidated so that more functionality is performed by each block, or they can be divided so that their functionality is further distributed. It should also be noted that data store114can be any of a wide variety of different types of data stores. Further, the contents of data store114can be stored in multiple data stores. Also, the data stores can be local to the environments, agents, modules, and/or components that access them, or they can be remote from and accessible by those environments, agents, modules, and/or components. Similarly, some can be local while others are remote.

Computing system102includes a data surfacing system134that facilities surfacing of data to one or more destinations. In the example ofFIG. 1, data surfacing system134is configured to access data in data store114(e.g., data118or any other information in data store114) to generate one or more structured data representations136. Before describing the operation of data surfacing system134in further detail, a brief overview will be provided.

A structured data representation (SDR) comprises a collection of data in any format. For example, by not by limitation, an SDR comprises a document or a collection of documents that is consumed within computing system102and/or output for consumption by another system. In one particular example, an SDR comprises a report that is generated from data in data store114. By way of illustration, but not by limitation, in the case of an organization, a report can include invoices, statements, orders, etc.

Data surfacing system134accesses data store114to generate one or more SDRs136, which can be stored in an SDR store138and/or output to one or more destinations. In the illustrated example, an SDR output/rendering system140renders SDRs136to user112through user interface display(s)108. Alternatively, or in addition, SDRs136can be provided to other destination(s)142external to computing system102. In another example, SDRs136can be provided to destination(s)144within computing system102. An example of a destination includes, but is not limited to, an electronic display device, such as a computer screen. Another example of a destination includes a system that electronically transmits communications to recipients, such as by facsimile or electronic mail (e-mail). In another example, a destination for an SDR comprises an electronic file system. In another example, a destination for an SDR comprises a system that renders the SDR on a physical medium, such as a printer. These, of course, are examples only.

By way of example, but not by limitation, computing system102can be deployed by an organization that manufactures and sells products. As sales orders for a plurality of customers are processed by computing system102, SDR generation inputs158specify that packing slips need to be printed for each sales order. This can include printing both an original packing slip as well as a copy of the packing slip for each sales order. Further, shipping confirmations may need to be sent to a first customer's e-mail address, and multiple printed copies of the shipping confirmations may be printed for internal tracking of the order and to be sent to the customer along with the order. These packing slips and shipping confirmations are examples of SDRs that can be generated by data surfacing system134from data store114.

Embodiments described herein provide a number of features and advantages. By way of illustration, within an example computing environment, generating a document is usually a multi-step process. One step comprises selecting the data for the document and another step comprises generation of the document or report to include the selected data for output. When multiple documents are needed, these two steps are repeated once for each document. This sequential processing of the steps results in significant time and processing bandwidth to generate all documents. That is, the time needed to generate all documents is the sum of the time needed to generate each document. Further, in some computing environments that utilize multiple threads, each thread executes this serial document generation process which can result in the documents being generated out of order by the non-deterministic nature of the multi-threaded processing. Additionally, the repeated processing of each document one at a time results in the document generation process being invoked for each document. Initiating a new process for each document to be generated is computationally expensive as it requires significant processing overhead.

Embodiments described herein provide a parallel processing framework that facilitates the generation of SDRs in a computationally efficient manner that outputs the SDRs quickly. By parallel processing the data requests and corresponding SDR generation operations, the disclosed framework improves the performance of the computing environment in surfacing data, while reducing the required processing overhead and time. Further, as discussed in further detail below, when an output order for the SDRs is important, the framework can run the parallel processes asynchronously, and then resynchronize the generated SDRs for output in the correct output order even though the data generation is performed out of order.

FIG. 2is a block diagram of one example of data surfacing system134having a parallel processing framework150. Framework150comprises a data gathering system152and an SDR generation system154that are configured to operate in parallel to obtain data for and to generate SDRs136. Data gathering system152is configured to perform data gathering tasks to obtain, calculate, or otherwise gather data to be included in the SDRs136. SDR generation system154generates SDRs136with the data gathered by data gathering system152.

In the example ofFIG. 2, system134includes a controller component156that controls framework150, one or more processors160, a user interface component162, and a destination configuration component163. System134can include other items164as well.

Controller component156receives SDR generation inputs158. Inputs158can be received from any source that requests generation of SDRs136. For example, SDR generation inputs158can be provided by user112, as illustrated inFIG. 1. In another example, SDR generation inputs158can be provided from application component117as it executes workflows122and/or processes124. In any case, SDR generation inputs158request generation of SDRs136and can include corresponding parameters for the data to be included in SDRs136.

Based on inputs158, controller component156generates requests, with parameters, that are provided to data gathering system152and SDR generation system154. In the illustrated example, for a given input158to generate an SDR, controller component156divides or decomposes the input into one or more data requests157with parameters for gathering or generating the data for the SDR, and an SDR request159with parameters for generating the SDR with the data. For example, SDR request159can include the destination for the SDR and a format for the SDR. For instance, the format can identify a type of document or report to be generated.

In one example in which SDR generation inputs158request generation of a plurality of SDRs, controller component156breaks inputs158into a series of data requests157having a sequential order indicative of a desired output order for the SDRs136. Each data request157has a corresponding SDR request159that identifies the destination and/or format for the SDR136. For instance, an organization may desire to output mailing statements in numerical order by postal code. Controller component156provides the requests to data gathering system152and SDR generation system154.

Data gathering system152includes a data request store166configured to store data requests157and corresponding request parameters. In one example, data request store166includes a first-in-first-out (FIFO) queue168for storing requests157.

Data gathering system152also includes a data generator creation component170configured to generate or instantiate one or more data generators173to obtain the data for each of the data requests157. For example, component170can instantiate a plurality of data generators173that operate in parallel to obtain data for a plurality of data requests157. A data generator173can generate or obtain the data by executing SQL queries to return data from a relational database and/or perform computations on the returned data, for example. The data set obtained for each of the requests is stored in a data set store171. In one example, data set store171comprises a plurality of data tables, each data table being generated and storing data for a request processed by data gathering system152.

SDR generation system154receives SDR requests159and maps them to their corresponding data requests157. In one example, a request status store172stores SDR requests159along with indications as to whether the data sets for each corresponding data request157has been obtained by data gathering system152. In the illustrated example, request status store172is created, updated, and otherwise maintained by SDR generation system154. In another example, request status store172can be maintained external to and accessed by SDR generation system154.

In the illustrated example, request status store172includes a request table174having a plurality of entries, each entry representing one of the SDR requests159. As the data requests157are completed by data gathering system152, request table174is updated accordingly.

Using information in request status store172that indicates that one or more of the data requests157have been processed by system152to gather the corresponding data, an SDR generator creation component176creates or instantiates corresponding SDR generators177that generate SDRs136. One or more SDR generators177can be created for a given destination. Further, a plurality of SDR generators177can be instantiated to operate in parallel to generate SDRs for a plurality of SDR requests159.

The number of SDR generators177that are created for the given destination can be based on the type of destination (e.g., whether the given destination is order-dependent or order-independent). An order-dependent destination comprises a device or system where the order (e.g., SDR output order, SDR output grouping, etc.) in which the SDRs are provided to the destination is important for the end use. For example, in some implementations, a printer is an order-dependent destination. In another example, a computer screen can be order-dependent. Examples of order-independent destinations include a file system that stores the SDRs and an email system that electronically transmits the SDRs to recipients. Further, in one example, whether a given destination is considered order-dependent or order-independent for purposes of operation of system134is configurable using destination configuration component163. For instance, user112can provide destination configuration inputs to component163to set whether a computer screen is considered order-dependent.

A data combining component178is configured to combine data sets gathered by system152for multiple requests into a single task for a SDR generator177. For example, in the case of a printer destination, data combining component178can combine the data sets for a plurality of requests processed by framework150into a single print job to the printer destination.

To illustrate operation of parallel processing framework150,FIG. 3is a flow diagram of a method200for generating SDRs, in one example. For sake of illustration, but not by limitation, method200will be described in the context of architecture100and data surfacing system134.

At step202, SDR generation inputs158are received from user112by controller component156. The inputs158include data parameters204that define the data to be included in the SDRs and/or destination parameters206that define one or more destinations for the SDRs. For example, some of the SDRs can be generated for a printer destination while some of the SDRs are generated for an email system. Also, order parameters208can be obtained. The order parameters208define an output or rendering order for the SDRs, and can be explicitly defined in the inputs158and/or can be inferred from inputs158.

FIG. 4is a screenshot of one example of a user interface221provided to user112to receive SDR generation inputs158at step202. User interface221includes an SDR display window222that allows user112to create, view, and/or select one or more SDRs to configure. In the present example, user112has selected SDR223(i.e., “customer account statement”) which can have multiple SDR instances. In the present example, the selected SDR223comprises an original document224and a file copy document225that are both to be output by data surfacing system134.

The user selects one of the SDRs (i.e., either the original document SDR224or the file copy document SDR225), and configures the corresponding SDR generation settings in a configuration window226. For example, window226includes a destination field227that identifies the destination for the SDR and a format field228that defines a format for the SDR.

In the present example ofFIG. 4, inputs158through user interface221specify that account statements are to be generated for customers of an organization. The inputs158identify a plurality of customers, illustratively using customer groups229, for which the statements are to be generated. The inputs in field227define that the statements are to be emailed to each of the customers in customer group229using their primary email address.

Referring again toFIG. 3, at step210, controller component156creates or otherwise obtains sets of data requests157and SDR requests159. In one example, each SDR to be generated has at least one data request157with parameters that define the data to be obtained for the SDR and at least one SDR request159with parameters that define the destination and format of the SDR. In one example, controller component156breaks down the SDR generation inputs158into a series of SDR requests159, each corresponding to a given SDR. The requests are sent to parallel framework150at step212.

In one particular example of an SDR generation process, user112requests that customer statements are generated for ten thousand customers of an organization. In response, controller component156breaks down this generation input into sets of ten thousand data and SDR requests, which are then sent to parallel processing framework150.

At step214, framework150performs parallel processing, in which data gathering system152and SDR generation system154operate in parallel to process the requests. As illustrated, at step216data gathering system152operates to gather data for some of the data requests157while SDR generation system154operates to generate SDRs at step218. For example, SDR generation system154generates an SDR with data from one of the data requests157while data gathering system152gathers data for another of the requests157. At step220, the SDRs136are output by framework150.

FIG. 5is a flow diagram of one example of a method for sending a set of requests for generating SDRs to a parallel processing framework. For example, the method ofFIG. 5can be performed by controller component156at step212illustrated inFIG. 3. For sake of illustration, but not by limitation,FIG. 5will be described in the context of data surfacing system134.

As mentioned above, in one example controller component156generates or otherwise obtains a series of requests corresponding to a set of SDRs to be generated. At step230, controller component156sends a current data request157in the series (i.e., a first request in this iteration) with corresponding parameters to data gathering system152.

After receiving the current data request, data gathering system152stores the request and corresponding parameters (e.g., data parameters204) in data request store166. Then, system152sends a confirmation to controller component156that the request has been stored for eventual processing by a data generator173. This confirmation is received by controller component156at step232.

At step234, controller component156sends the corresponding SDR request159(or other indication of the current data request157) with parameters to SDR generation system154. In one example, the parameters sent at step234includes a data set identifier236(e.g., a data table ID) indicative of the data set that is being generated by data gathering system152for the current data request157and a destination identifier238(e.g., destination parameters206). Identifier238identifies the destination for the SDR corresponding to the current data request157. Also, the parameters can identify an SDR format239, such as a type of document or report to be generated with the data.

After receiving the request, SDR generation system154creates or updates the request status store172to indicate the current request159along with the corresponding parameters. Then, system154sends a confirmation to controller component156that the SDR request159has been stored for eventual processing by a SDR generator177. This confirmation is received by controller component156at step240.

At step242, controller component156proceeds to determine whether there are any additional requests to be sent to framework150. If so, the method returns to step230for a next data request157in the sequence of requests. If not, the method proceeds to step244in which controller component156determines that all of the data requests157have been sent and then sends a completion signal to data gathering system152indicating that all data requests157have been provided.

FIG. 6is a flow diagram of one example of a method for gathering data to generate SDRs. For example, the method ofFIG. 6can be performed by data gathering system152at step216illustrated inFIG. 3. For sake of illustration, but not by limitation,FIG. 6will be described in the context of data surfacing system134.

At step250, data generator creation component170creates or instantiates a data generator173for one or more of the requests stored in data request store166. In one example, step250can be initiated by a batch task at step252that batches or groups a plurality of the data requests. For instance, data gathering system152can collect a threshold number of data requests in data request store166before initiating step250to process the requests. Also, at step250, component170can create a plurality of data generators173to operate in parallel. Further, step250can be initiated in response to receiving an indication at step254that controller component156has sent all requests (e.g., the indication from step244).

At step256, each data generator173accesses data store114to gather the requested data based on the parameters of the data request. For example, data generator173can perform data store queries at step258and/or perform computations on the data at step260.

At step262, a data set is generated for each of the requests. The data set is stored in data set store171. For example, data gathering system152generates a temporary data table for each of the requests.

At step264, data gathering system152sends a signal to SDR generation system154indicating that the data set for the one or more data requests has completed. For example, the signal can be sent by the data generator173that generated the data set. The signal can comprise a table done event that is sent to SDR generation system154to indicate that data tables have been generated for the requests.

At step266, data gathering system152determines whether there are any more data requests stored in data request store166that need to be processed. If so, the method returns to step250to process those additional requests. If not, the method proceeds to step268in which data gathering system152sends a signal to SDR generation system154indicating that all of the data requests have been completed.

FIG. 7is a flow diagram of one example of a method for generating SDRs. For example, the method ofFIG. 7can be performed by SDR generation system154at step218illustrated inFIG. 3. For sake of illustration, but not by limitation,FIG. 7will be described in the context of data surfacing system134.

At step270, SDR generation system154receives an indication that the data set(s) for one or more of the data requests have been generated. For example, SDR generation system154receives the indication sent by data gathering system152at step264. The indication can include a reference to the data request and/or the data set generated for the data request. At step272, the request status store172is updated based on the indication received at step270. One example of a request table174, that is updated at step272, is illustrated inFIG. 8.

As shown inFIG. 8, request table174comprises a plurality of entries300-318, each representing a request for a corresponding SDR. In the illustrated example, the entries300-318are arranged in an order in which controller component156issued the corresponding data requests157. This order is identified by a sequence number field320. Additionally, each entry includes a destination identifier field322and a data set identifier field324. Data set identifier field324identifies the data set for the corresponding SDR. For example, data set identifier field324can comprise a data table ID that identifies the data table that will be or has been generated by data gathering system152. A completion field326indicates whether the data request has been completed. For example, completion field326can include a Boolean true/false flag that indicates whether the data set identified in field324has been generated.

Referring again toFIG. 7, at step274SDR generation system154determines whether any of the SDRs can be generated. In one example, step274accesses request table174at step276and identifies the requests for which the data gathering process has been completed (i.e., by analyzing field326). At step278, completed requests that have destinations that are not order-dependent are identified and selected for SDR generation at step284. In the example ofFIG. 8, entries312,314, and318are selected at step278.

Also, at step280, the method determines whether any completed requests have destinations that are order-dependent, where the completed request is next in the sequence for that destination. For instance, in the example ofFIG. 8, the request for entry300has an order-dependent destination (i.e., printer1). In this case, entry300is selected for SDR generation at step284. Additionally, the request from entry304can also be processed as it also has been completed, and is next in the sequence order for the same destination. Conversely, in this example, the request from entry310is not selected for SDR generation as it is not the next request in the sequence for its destination (i.e., printer2) because the request for entry306, also for printer2, has not been completed. Accordingly, step280, in one example, ensures that even if requests for an order-dependent destination are executed by data gathering system152out-of-order with respect to a desired SDR output/rendering sequence, they are reordered by SDR generation system154.

In one example of step274, an indication is received from data gathering system152indicating that all of the data requests have been processed. This is represented at step282. At this point, the method proceeds with selecting remaining entries for SDR generation at step284. This includes, in one example, ignoring or removing any data requests that have not been completed by data gathering system152as there has been no data gathered for those requests. To illustrate, in the case of generating balance due statements for a number of customers, it may be that a given customer does not have an outstanding balance. As such, data gathering system152may not return any data for that request.

In one example of step284, an SDR generator177is created or instantiated by component176at step286for each request selected at step274. Then, at step288, the SDR generator177retrieves the corresponding data set stored in data set store171to generate the SDR at step290.

At step292, the method removes the corresponding requests from request status store172. At step294, the method determines whether there are any more requests to be processed. If so, the method returns to step270.

It can thus be seen that the present description provides significant technical advantages. It provides a framework for surfacing data in which data gathering and SDR generation operations execute in parallel. As such, the framework improves the performance of the computing environment, itself, in surfacing data. For example, the framework can reduce the time required to perform a data surfacing process.

A number of data stores are also discussed. It will be noted they can each be broken into multiple data stores. All can be local to the systems accessing them, all can be remote, or some can be local while others are remote. All of these configurations are contemplated herein.

In the example shown inFIG. 9, some items correspond to those shown inFIG. 1and they are similarly numbered.FIG. 9specifically shows that computing system102is located in cloud502(which can be public, private, or a combination where portions are public while others are private). Therefore, a user504(e.g., user112) uses a user device506to access system102through cloud502.

FIG. 9also depicts another embodiment of a cloud architecture.FIG. 9shows that it is also contemplated that some components of computing system102are disposed in cloud502while others are not. In one example, data store114can be disposed outside of cloud502, and accessed through cloud502. In another example, data surfacing system134can be disposed outside of cloud502. In another example, SDR output/rendering system140can be disposed outside of cloud502. Regardless of where they are located, system102components can be accessed directly by device506, through a network (either a wide area network or a local area network), they can be hosted at a remote site by a service, or they can be provided as a service through a cloud or accessed by a connection service that resides in the cloud.FIG. 9also shows that system102, or parts of it, can be deployed on user device506. All of these architectures are contemplated herein.

FIG. 10is a simplified block diagram of one example of a handheld or mobile computing device that can be used as a user's or client's hand held device16, in which the present system (or parts of it) can be deployed.FIGS. 11-14are examples of handheld or mobile devices.

FIG. 10provides a general block diagram of the components of a client device16that can run modules or components of architecture100or that interacts with architecture100, or both. In the device16, a communications link13is provided that allows the handheld device to communicate with other computing devices and in some examples provides a channel for receiving information automatically, such as by scanning Examples of communications link13include an infrared port, a serial/USB port, a cable network port such as an Ethernet port, and a wireless network port allowing communication though one or more communication protocols including General Packet Radio Service (GPRS), LTE, HSPA, HSPA+ and other 3G and 4G radio protocols, 1×rtt, and Short Message Service, which are wireless services used to provide cellular access to a network, as well as 802.11 and 802.11b (Wi-Fi) protocols, and Bluetooth protocol, which provide local wireless connections to networks.

In other examples, applications or systems are received on a removable Secure Digital (SD) card that is connected to a SD card interface15. SD card interface15and communications link13communicate with a processor17(which can also embody processor(s)104fromFIG. 1and/or processor(s)160fromFIG. 2) along a bus19that is also connected to memory21and input/output (I/O) components23, as well as clock25and location system27.

Clock25comprises a real time clock component that outputs a time and date. It can also provide timing functions for processor17.

Memory21stores operating system29, network settings31, applications33, application configuration settings35, data store37, communication drivers39, and communication configuration settings41. It can also store a client system24which can be part or all of architecture100. Memory21can include all types of tangible volatile and nonvolatile computer-readable memory devices. It can also include computer storage media (described below). Memory21stores computer readable instructions that, when executed by processor17, cause the processor to perform computer-implemented steps or functions according to the instructions. Processor17can be activated by other modules or components to facilitate their functionality as well.

FIGS. 12 and 13provide additional examples of devices16that can be used, although others can be used as well. InFIG. 12, a feature phone, smart phone or mobile phone45is provided as the device16. Phone45includes a set of keypads47for dialing phone numbers, a display49capable of displaying images including application images, icons, web pages, photographs, and video, and control buttons51for selecting items shown on the display. The phone includes an antenna53for receiving cellular phone signals such as General Packet Radio Service (GPRS) and 1×rtt, and Short Message Service (SMS) signals. In some examples, phone45also includes a Secure Digital (SD) card slot55that accepts a SD card57.

The mobile device ofFIG. 13is a personal digital assistant (PDA)59or a multimedia player or a tablet computing device, etc. (hereinafter referred to as PDA59). PDA59includes an inductive display screen61that senses the position of a stylus63(or other pointers, such as a user's finger) when the stylus is positioned over the screen. This allows the user to select, highlight, and move items on the screen as well as draw and write. PDA59also includes a number of user input keys or buttons (such as button65) which allow the user to scroll through menu options or other display options which are displayed on display screen61, and allow the user to change applications or select user input functions, without contacting display screen61. Although not shown, PDA59can include an internal antenna and an infrared transmitter/receiver that allow for wireless communication with other computers as well as connection ports that allow for hardware connections to other computing devices. Such hardware connections are typically made through a cradle that connects to the other computer through a serial or USB port. As such, these connections are non-network connections. In one example, PDA59also includes a SD card slot67that accepts a SD card69.

Note that other forms of the devices16are possible.

Example 1 is a parallel processing framework for generating structured data representations (SDRs) in a computing system. The parallel processing framework comprises a data gathering system configured to receive a set of data requests, each corresponding to at least one structured data representation (SDR). The data gathering system is configured to obtain a data set for each of the data requests. The parallel processing framework includes an SDR generation system configured to receive indications of the plurality of data requests and, for each data request, an indication as to whether the data set corresponding to the data request has been obtained by the data gathering system. The SDR generation system is configured to generate the plurality of SDRs with the data sets obtained by the data gathering system.

Example 2 is the parallel processing framework of any or all previous examples, wherein the SDR generation system performs an SDR generation process to generate an SDR for one of the data requests while the data gathering system performs a data gathering process to obtain the data set for another one of the data requests.

Example 3 is the parallel processing framework of any or all previous examples, wherein the plurality of SDRs comprises a plurality of reports that are generated to include the data sets.

Example 4 is the parallel processing framework of any or all previous examples, wherein the data gathering system receives the set of data requests from a controller component, each data request including data request parameters that are used by the data gathering system to obtain the data set from a data store.

Example 5 is the parallel processing framework of any or all previous examples, wherein the SDR generation system receives the indications of the plurality of data requests from the controller component, each indication identifying a destination for the corresponding SDR and a location of the data set for the corresponding SDR.

Example 6 is the parallel processing framework of any or all previous examples, wherein the data gathering system stores the set of data requests in a queue.

Example 7 is the parallel processing framework of any or all previous examples, wherein the data gathering system is configured to perform a batch processing task on a plurality of the data requests in the queue.

Example 8 is the parallel processing framework of any or all previous examples, wherein the data gathering system is configured to send a signal to the SDR generation system based on obtaining a data set for a data request.

Example 9 is the parallel processing framework of any or all previous examples, wherein the data sets comprise a plurality of data tables, each data table being generated for one or more of the SDRs.

Example 10 is the parallel processing framework of any or all previous examples, and further comprising a request status store that stores a plurality of request entries, each entry representing a given one of the data requests and identifying whether the data set for the given data request has been obtained by the data gathering system.

Example 11 is the parallel processing framework of any or all previous examples, wherein the SDR generation system updates the request status store based on the signal received from the data gathering system.

Example 12 is the parallel processing framework of any or all previous examples, wherein the request status store comprises a request table that is generated by the SDR generation system.

Example 13 is the parallel processing framework of any or all previous examples, wherein the request status store indicates a sequential order of the set of data requests, and each entry in the request status store identifies a destination for the SDR corresponding to the given data request.

Example 14 is the parallel processing framework of any or all previous examples, wherein the SDR generation system is configured to generate the plurality of SDRs based on the sequential order of the set of data requests and a destination type for each SDR.

Example 15 is the parallel processing framework of any or all previous examples, wherein the SDR generation system is configured to generate the plurality of SDRs based on whether the destinations are order dependent destinations.

Example 16 is a computing system for generating structured data representations (SDRs). The computing system comprises a controller component configured to receive an SDR generation input for generating a set of SDRs and to obtain, based on the SDR generation input, a set of SDR generation requests, each SDR generation request having at least one corresponding data request with parameters that define data to be obtained for an SDR. The computing system comprises a data gathering system configured to obtain a data set for each data request, and an SDR generation system configured to perform an SDR generation process for one of the SDR generation requests while the data gathering system performs a data gathering process for another one of the SDR generation requests.

Example 17 is the computing system of any or all previous examples, comprising a request status store that stores a plurality of request entries, each entry representing at least one of the SDR generation requests and identifying whether a data set for the at least one SDR generation request has been obtained by the data gathering system.

Example 18 is the computing system of any or all previous examples, wherein the SDR generation system performs the SDR generation process based on the request status store.

Example 19 is a computer-implemented method, comprising receiving a set of structured data representation (SDR) requests, each request identifying data parameters for a corresponding SDR, and generating a set of SDRs using a parallel processing framework that simultaneously performs a data gathering process for the set of SDR requests and an SDR generation process for the set of SDR requests. The method includes outputting the set of SDRs.

Example 20 is the computer-implemented method of any or all previous examples, wherein the set of SDR requests define an order for the corresponding set of SDRs, and wherein generating the set of SDRs comprises obtaining data sets for the set of SDR requests in an order that is different than the defined order for the corresponding set of SDRs, and performing the SDR generation process to output the corresponding set of SDRs based on the defined order.