Data provider independent change handling in mobile client applications

Abstract

In one embodiment, change handling in a mobile client application may be facilitated by intermediate storage of changes using a data provider-independent change object schema. Input is received on a mobile device indicating a create, update, or delete action on a data object stored in a remote data store. In response to receiving the input, a description of the action on the data object is created in a syntax that is independent with respect to the type of remote service provider used to interact with the remote data store. The description of the action is translated into the syntax of a first remote service provider to create a command configured to cause the first remote service provider to perform the action. The command is transmitted over a network to the first remote service provider to cause the action to be performed on the data object in the remote data store.

Description

[Background technology]

[0001] background Software applications hosted on mobile client devices ("mobile applications") typically interact with backend (or otherwise remote) data providers hosted on backend servers over a network to access and manipulate application data stored in backend databases. For example, if (i) network connectivity between the client device and the backend server is poor or nonexistent, or (ii) the backend server is unresponsive or unavailable, the mobile application cannot interact with the backend data provider.

[0002] Users of mobile applications often desire to access and manipulate application data when the mobile application is unable to interact with a backend data provider. Application functionality may therefore include the ability to operate in an "offline mode" that allows the mobile application to access and manipulate application data locally on the mobile client device while it is not connected to the backend data provider. Changes to application data are persisted locally on the mobile client device and synchronized with the backend database when interaction with the backend data provider resumes. This may be referred to as "offline write" or "deferred write access."

[0003] Currently, when a mobile application attempts to update data while in offline mode, the changes are persisted in offline (local) data storage in a manner that is tightly coupled to a schema specific to the backend data provider. While this model works, it does not anticipate when there are multiple such backend data providers with different and diverse structural representations of an entity. Mobile applications that store changes in a manner that strictly adheres to the backend data provider's schema cannot connect to multiple data providers, each with a unique schema to represent an object. They also cannot be modified at runtime to accommodate new entities, relationships, and functions that are customized for business processes. Also, if a remote system is updated while the mobile application is offline and the update alters the schema or structure due to the changes, the stored changes may become invalid, causing synchronization to fail. Storing changes in a schema or structure specific to a remote provider is often lossy; it may not be possible to reconstruct the original changes or convert the stored changes to a different format. For this reason, offline changes stored in a schema or structure specific to one particular remote provider have clear drawbacks. Summary of the Invention [Means for solving the problem]

[0004] overview In one embodiment, a computer-implemented method includes receiving input on a mobile device indicating a create, update, or delete action on a data object stored in a remote data store; in response to receiving the input, creating a description of the action on the data object in a syntax that is independent with respect to a type of remote service provider used to interact with the remote data store; converting the description of the action into a syntax of a first remote service provider to create a command configured to cause the first remote service provider to perform the action; and sending the command over a network to the first remote service provider to cause the action to be performed on the data object in the remote data store.

[0005] In one embodiment, the computer-implemented method further includes determining that the first remote service provider is unavailable to receive the command, storing a description of the action on the mobile device, and delaying creating the command until after an indication that the first remote service provider is available is received by the mobile device.

[0006] In one embodiment, the computer-implemented method further includes determining that a second remote service provider is unavailable to receive the command, and in response to determining that the second remote service provider is unavailable to receive the command, formulating the command in a syntax of the first remote service provider and sending the command to the first remote service provider.

[0007] In one embodiment, the computer-implemented method further includes selecting a first remote service provider from among a set of two or more remote service providers each having access to the remote data store, the selection being based on the first remote service provider satisfying one or more criteria including at least one of: (i) current availability of the remote service provider; and (ii) complexity of the action.

[0008] In one embodiment, in a computer-implemented method, an agnostic syntax for describing an action on a data object includes, for each attribute of the data object that the action modifies, (i) an indication that the change to that attribute is one of an “update,” “delete,” or “create” action, and (ii) if the change is an “update” or “create” action, an indication of the new value for that attribute; and, for each child object of the data object that the action modifies, (i) an indication that the child object is a child object, (ii) an indication that the change to the child object is one of an “update,” “delete,” or “create” action, (iii) an indication of the value of the primary key for the child, and (iv) an indication of the change to that child object, wherein the indications of the changes are described using the agnostic syntax.

[0009] In one embodiment, the computer-implemented method, wherein a syntax of a first remote service provider is stored on the mobile device, further comprising retrieving a semantic description for the type of data object from the first remote service provider, and wherein converting the description of the action into the syntax of the first remote service provider is based on the retrieved description of the semantics.

[0010] In one embodiment, a non-transitory computer-readable medium storing computer-executable instructions that, when executed by at least a processor of a computer, cause the computer to: receive input on a mobile device indicating a create, update, or delete action on a data object stored in a remote data store; in response to receiving the input, create a description of the action on the data object in a syntax that is independent with respect to a type of remote service provider used to interact with the remote data store; convert the description of the action into the syntax of the first remote service provider to create a command configured to cause the first remote service provider to perform the action; and send the command over a network to the first remote service provider to cause the action to be performed on the data object in the remote data store.

[0011] In one embodiment, the non-transitory computer-readable medium further includes instructions that, when executed by at least the processor, cause the computer to determine that the first remote service provider is unavailable to receive the command, store a description of the action on the mobile device, and delay creating the command until after an indication that the first remote service provider is available is received by the mobile device.

[0012] In one embodiment, the non-transitory computer-readable medium further includes instructions that, when executed by at least a processor, cause the computer to determine that a second remote service provider is unavailable to receive the command, and in response to determining that the second remote service provider is unavailable to receive the command, formulate a command in the syntax of the first remote service provider and send the command to the first remote service provider.

[0013] In one embodiment, the non-transitory computer-readable medium further includes instructions that, when executed by at least the processor, cause the computer to select a first remote service provider from among a set of two or more remote service providers, each having access to the remote data store, the selection being based on the first remote service provider satisfying one or more criteria including at least one of (i) current availability of the remote service provider, and (ii) complexity of the action.

[0014] In one embodiment, in a non-transitory computer-readable medium, the agnostic syntax for a description of an action on a data object includes, for each attribute of the data object that the action modifies, (i) an indication that the change to that attribute is one of an “update,” “delete,” or “create” action, and (ii) if the change is an “update” or “create” action, an indication of the new value for that attribute; and, for each child object of the data object that the action modifies, (i) an indication that the child object is a child object, (ii) an indication that the change to the child object is one of an “update,” “delete,” or “create” action, (iii) an indication of the value of the primary key for the child, and (iv) an indication of the change to that child object, wherein the indications of the changes are described using the agnostic syntax.

[0015] In one embodiment, a non-transitory computer-readable medium, wherein the syntax of the first remote service provider is stored on the mobile device and further includes instructions that, when executed by at least a processor, cause the computer to retrieve a semantic description for the type of data object from the first remote service provider, and wherein converting the description of the action into the syntax of the first remote service provider is based on the retrieved description of the semantics.

[0016] In one embodiment, a computing system includes a processor; a memory operably connected to the processor; and a non-transitory computer-readable medium operably connected to the processor and the memory and storing computer-executable instructions, which when executed by at least the processor, cause the computing system to: receive input on a mobile device indicating a create, update, or delete action on a data object stored in a remote data store; in response to receiving the input, create a description of the action on the data object in a syntax that is independent with respect to a type of remote service provider used to interact with the remote data store; convert the description of the action into the syntax of the first remote service provider to create a command configured to cause the first remote service provider to perform the action; and send the command over a network to the first remote service provider to cause the action to be performed on the data object in the remote data store.

[0017] In one embodiment, in a computing system, the non-transitory computer-readable medium of the claim further includes instructions that, when executed by at least a processor, cause the computing system to determine that a first remote service provider is unavailable to receive commands, store a description of the action on the mobile device, and delay creating the command until after an indication that the first remote service provider is available is received by the mobile device.

[0018] In one embodiment, in a computing system, the non-transitory computer-readable medium of the claim further includes instructions that, when executed by at least a processor, cause the computing system to determine that a second remote service provider is unavailable to receive the command, and in response to determining that the second remote service provider is unavailable to receive the command, formulate a command in the syntax of the first remote service provider and send the command to the first remote service provider.

[0019] In one embodiment, in a computing system, the non-transitory computer-readable medium of the claim further includes instructions that, when executed by at least a processor, cause the computing system to select a first remote service provider from among a set of two or more remote service providers, each having access to a remote data store, the selection being based on the first remote service provider satisfying one or more criteria including at least one of (i) current availability of the remote service provider, and (ii) complexity of the action.

[0020] In one embodiment, in a computing system, an agnostic syntax for describing an action on a data object includes, for each attribute of the data object that the action modifies, (i) an indication that the change to that attribute is one of an “update,” “delete,” or “create” action, and (ii) if the change is an “update” or “create” action, an indication of the new value for that attribute; and, for each child object of the data object that the action modifies, (i) an indication that the child object is a child object, (ii) an indication that the change to the child object is one of an “update,” “delete,” or “create” action, (iii) an indication of the value of the primary key for the child, and (iv) an indication of the change to that child object, wherein the indications of the changes are described using the agnostic syntax.

[0021] In one embodiment, the computing system, wherein the syntax of the first remote service provider is stored on the mobile device, further comprising instructions that, when executed by at least the processor, cause the computing system to retrieve a semantic description for the type of data object from the first remote service provider, and wherein converting the description of the action into the syntax of the first remote service provider is based on the retrieved description of the semantics.

[0022] BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate various systems, methods, and other embodiments of this disclosure. It will be understood that any depicted element boundaries (e.g., boxes, groups of boxes, or other shapes) in the drawings represent one embodiment of that boundary. In some embodiments, one element may be realized as multiple elements, or multiple elements may be realized as one element. In some embodiments, an element shown as an internal component of another element may be realized as an external component, and vice versa. Additionally, elements may not be drawn to scale. [Brief explanation of the drawings]

[0023] [Figure 1] FIG. 1 illustrates an embodiment of a system associated with data provider-independent change handling in mobile client applications. [Figure 2] FIG. 1 illustrates an embodiment of an environment associated with data provider-independent change handling in mobile client applications in which the system may operate. [Figure 3] FIG. 1 illustrates one embodiment of a schema for a data provider independent change object associated with data provider independent change handling in a mobile client application. [Figure 4]FIG. 10 illustrates an exemplary data provider independent change object instance that describes various changes made to an exemplary row object instance. [Figure 5] FIG. 1 illustrates an embodiment of a method associated with data provider independent change handling in a mobile client application. [Figure 6] FIG. 1 illustrates an embodiment of a method associated with deferred write access using data provider-independent change handling in a mobile client application. [Figure 7] FIG. 1 illustrates an embodiment of a method associated with deferred write access through multiple remote service providers using data provider-agnostic change handling in a mobile client application. [Figure 8] FIG. 1 illustrates an embodiment of a method associated with deferred write access through selectable alternative service providers using data provider-agnostic change handling in a mobile client application. [Figure 9] FIG. 1 illustrates one embodiment of a computing system configured using the disclosed example systems and / or methods. [Figure 10] FIG. 1 illustrates one embodiment of a mobile device configured with the disclosed example systems and / or methods. DETAILED DESCRIPTION OF THE INVENTION

[0024] Detailed Description Systems and methods are described herein that provide data provider-agnostic change handling in mobile client applications. The data provider-agnostic change handling overcomes the limitation of caching data for offline writes with a schema that conforms to the schema of a backend data provider. Instead, in one embodiment, a data provider-agnostic change object is implemented to capture updates from the mobile application. (For convenience, the data provider-agnostic change object may be referred to herein simply as a "change object.") A data provider-independent change object enables a mobile application on a client device to provide access to adjust, reorganize, correct, and merge data and features independently of the remote service provider to which it connects on a backend server. A data provider-independent change object enables a mobile application to (i) present a logically consistent view of local data to the user, and (ii) maintain individual user actions as transactions that can be individually tracked, applied, and mitigated.

[0025] In one embodiment, a mobile application is defined to include a data storage model that can be interpreted and used by a client device to store and access data and features while lacking a connection to a backend server. In addition, the mobile application implements an algorithm for storing changes to this data in the storage model in a manner that is unique and independent of the provider itself. In one example, this can be a data provider-independent change object. The mobile application also implements a change resolver that converts updated data to the data provider's format when changes are synchronized.

[0026] The data storage model includes unique identifiers specified on the request, which are included in the response from the server and used to store its component fragments in the local store, and which are used to identify the specific record from the collection that has changed.

[0027] In one embodiment, a method and system are presented for defining an object- and data-provider-independent change handling mechanism within an offline synchronization model. A mobile device stores user changes made while connected or disconnected and then synchronizes with a remote server. The mobile device updates a combination of tables defined in memory in a manner that optimizes data storage and seamless real-time data merging. Requests are stored in memory as locations identified by a first universal identifier. The requests constitute changes that conform to a custom, data-provider-independent schema and will include a set of keys, each describing the action taken along with the change itself. When retrieved by a local client, the modified data is merged with the original state of the object to provide a consistent local view of the application while maintaining the recorded order of individual transactions that can be applied, undone, or mitigated separately. Prior to submission to the remote server, the change data is converted to a format defined by the remote service provider, thereby allowing the model to be loosely coupled with the remote system.

[0028] Mobile applications constructed in accordance with the systems and methods described herein offer significant improvements over previous mobile application implementations. The polymorphic behavior of mobile applications constructed in accordance with the systems and methods described herein allows records of data changes (change objects) to not be tied to a specific schema when the object is created. Instead, records of data changes are represented using a generic schema and transformed to different schemas on the fly to coordinate with changes to the application definition as the object is synchronized at runtime. This is unique compared to existing applications that use predefined static models to persist objects to their state.

[0029] Mobile applications configured according to the systems and methods described herein also offer significant advantages. Change data objects created as users make changes are independent of the schema of objects on remote servers. In one example, a system can be kept up to date based on information retrieved from multiple different types of back-end data providers or other servers. For example, one data provider may represent data as a complex graph, while another data provider may represent data as an oversimplified hierarchical entity-to-entity relationship. Generally, modifications to a client conform to a specific, well-defined shape and are cached as is. This problem is addressed using a method and system for defining data provider-independent change objects to capture updates from an application. This model enables a client application to provide access to adjust, reorganize, correct, and merge data and features independently of the remote provider to which it connects on the server. This model can present a logically consistent view of local data to the user and maintain individual user actions as transactions that can be individually tracked, applied, and mitigated.

[0030] In one embodiment, a change object contains a collection of keys that each describe the action taken along with the change itself. Prior to submission to a remote server, the change data is converted into a format defined by the remote service provider, thus allowing the model to be loosely coupled with the remote system.

[0031] Exemplary system for data provider independent change handling FIG. 1 illustrates one embodiment of a system 100 associated with data provider-independent change handling in a mobile client application. On the client side 105, the system 100 includes a mobile application 110. The mobile application 110 includes a user interface 115, a transaction handler 120, and a persistence manager 125. The mobile application 110 also includes one or more data providers 130 for interfacing with various remote service providers 131 on the server side 135. The data providers 130 may include an XML data provider 140 for interfacing with a remote XML provider 141. The data providers 130 may include a graph query data provider 145 for interfacing with a remote graph query provider 146. The data providers 130 may include a REST data provider 150 for interfacing with a remote REST provider 151. The data providers 130 may include an elastic data provider 155 for interfacing with a remote elastic provider 156. The data provider 130 may also include other data providers 160 configured to interface with other remote service providers 161. The data provider 130 interfaces with the remote service provider 131 through electronic communication over a network using various network communication protocols. The remote service provider 131 is connected to a data store 165 associated with the mobile application 110. The transaction handler 120 includes a data manager 170, a change data constructor 175, and a transaction processor 180. In one embodiment, each of the components of the system 100 may be implemented as a module.

[0032] In one embodiment, the mobile application 110 is a client application for accessing and manipulating data stored in the data store 165. For example, the mobile application 110 may be a client application for an enterprise sales and service tool that hosts data on the data store 165 and provides one or more services through a remote service provider 131. In one embodiment, the mobile application 110 is the Oracle® CX Mobile Client. The client application may be downloaded from a third-party seller of mobile applications, such as the Google® Play Store or the Apple® Store, or from a system associated with the operator of the sales tool. The mobile application 110 may then be used, for example, by sales or service staff to view sales opportunities or service requests, create new sales opportunities in the tool, submit service requests in the tool, look up sales opportunities or service requests related to contact information, or perform other operations that create, read, update, or delete information in the data store 165.

[0033] In one embodiment, the mobile application 110 requests the execution of data operations in the tool through application programming interface (API) requests to the remote service provider 131. In one embodiment, these requests are requests to and from a web server (e.g., remote representational state transfer (REST) ​​requests using JavaScript object notation (JSON) as the data exchange format), as in the case of the remote graph query provider 146, the REST provider 151, and the remote elastic provider 156. In one embodiment, these requests are SOAP requests to and from an XML server, such as the remote xml provider 141. The mobile application 110 is configured to perform operations that support offline write or deferred write access when connectivity between the mobile application 110 and the data store 165 is limited or non-existent. The mobile application 110 may store data retrieved from the data store 165 in a local cache using the persistence manager 125. Data in the local cache can be manipulated by a user of the mobile application 110 while connectivity between the client side 105 and the server side 135 is limited or non-existent, and then synchronized with the server side when connectivity is restored.

[0034] In one embodiment, user interface 115 is a graphical user interface (GUI) to mobile application 110. The GUI may include user interface elements such as images, container windows, browser windows, text terminal windows, dialog boxes, drop-down menus, context menus that become visible in response to user interaction with the graphical user interface, icons, buttons, radio buttons, check boxes, etc. The GUI may accept input from a user of mobile application 110, for example, by mouse clicks or taps on a touchscreen, keystrokes from a physical or virtual keyboard, or speech-to-text conversion. User input may be accepted through user interface elements. User input may describe or indicate a create, read, update, or delete operation for a data object (such as a row object). Some or all of the contents of the data object may be retrieved and displayed to the user through user interface 115. The operation or action described by the input may be for a data object stored remotely in data store 165 or stored locally by persistence manager 125. Create, update, or delete operations described by user input through user interface 115 are submitted to data manager 170 for further processing.

[0035] In one embodiment, transaction handler 120 includes a "commit" or "save" function that instructs the data manager to finalize create, update, or delete operations entered by the user. In one embodiment, user interface 115 includes a button or other interface element that invokes the "commit" or "save" function of transaction handler 120 in response to a selection by the user.

[0036] In one embodiment, change data constructor 175 operates to create a data provider-independent change object to describe a particular transaction (including a create, update, or delete data operation). The transaction may be described by user input through user interface 115. In one embodiment, change data constructor 175 creates a data provider-independent change object in response to execution of a "commit" or "save" function (e.g., executed in response to user input indicating selection of the "commit" or "save" function).

[0037] In one embodiment, data manager 170 makes the decision as to where a transaction is routed, whether locally or to a remote provider, and also as to which provider is used. For example, if there is connectivity between client side 105 and server side 135, data manager 170 will route the change object created by the “commit” or “save” function to server side 135 to make the changes described by the change object effective in data store 165. Data manager 170 will select an appropriate data provider 130 for routing and send the change object to that data provider 130 for conversion to a schema specific to the associated remote service provider 131. Alternatively, for example, if there is limited or no connectivity between client side 105 and server side 135, data manager 170 will route the change object created by the “commit” or “save” function to persistence manager 125 to be stored locally until connectivity is restored. In another example, if the remote service provider 131 to which the transaction is to be routed has low availability or is incapable of processing the request, the data manager 170 will route the change objects created by the "commit" or "save" functions to the persistence manager 125 to be stored locally until availability is restored. In yet another example, if the remote service provider 131 to which the transaction is to be routed has low availability or is incapable of processing the request, the data manager 170 will route the change objects created by the "commit" or "save" functions through a different data provider 130 to a different associated remote service provider that can similarly process the transaction.

[0038] In one embodiment, while (i) connectivity between the client side 105 and the server side 135 is unavailable or limited, or (ii) one or more remote service providers 131 have low availability or are unable to process requests, transactions are stored locally in the persistence manager 125 as data provider-independent change objects for subsequent synchronization with the data store 165. The transaction processor 180 maintains a list of each locally stored data provider-independent change object in memory, e.g., as a data structure. The list maintains the chronological order of the change objects. When connectivity or availability is restored, the transaction processor 180 retrieves the locally stored change objects from the persistence manager 125. The transaction processor enforces the chronological order of change objects affecting the same row object to prevent race condition errors. The transaction processor 180 determines how to route transaction requests to the server side 135 to make the changes described by the change objects effective in the data store 165. The transaction processor 180 selects the appropriate data provider 130 for routing and sends the change object to that data provider 130 for transformation into a schema specific to the associated remote service provider 131 .

[0039] In one embodiment, each data provider 130 operates to create instructions for effecting changes described by received change objects using a schema or structure specific to the data provider's respective remote provider 131. Each data provider 130 maintains a copy of the syntax for interacting with the data provider's respective remote provider 131. Each data provider 130 maintains a copy of the definitions of the data types accepted by the data provider's respective remote provider 131. In one embodiment, the syntax and definitions are maintained in local storage through persistence manager 125. Each data provider 130 operates to create instructions for effecting changes using the syntax and data types appropriate for the data provider's respective remote provider 131.

[0040] For example, in response to receiving a change object from data manager 170 or transaction processor 180, REST data provider 150 uses the remote REST provider-specific description of the transaction to create instructions for effecting the changes described by the change object. For example, a REST request can be created by remote REST provider 151 having a payload that describes the changes in a schema specific to REST data provider 150. REST data provider 150 translates the actions described by the change object into instructions in a syntax for interacting with the remote REST provider to modify objects of the data type described by the definition for the remote REST provider. The REST request can then be sent by REST data provider 150 to remote REST provider 151 over a network connection between client side 105 and server side 135 of system 100.

[0041] In one embodiment, the remote service provider 131 is an interface (e.g., an API) on a database or data store 165 of the system 100. The remote service provider accepts API requests (from the data provider 130) and queries the data store 165 to effectuate these requests. The remote service provider 131 can also return information retrieved from the data store 165 to the remote application 110 through the data provider 130 for various purposes, such as display by the user interface 115.

[0042] In one embodiment, all remote service providers 131 have access to the same data (from data store 165) on system 100. However, different remote service providers 131 may not share the same capabilities. Some may not accept submissions at all, while others may accept submissions for some changes but not for other changes. Some remote service providers 131 may be more performance-sensitive than others.

[0043] In one embodiment, data store 165 is an Oracle® database connected to an application server that exposes one or more of the interfaces of remote provider 131 to the network. In one embodiment, the application server is an Oracle® WebLogic® application server.

[0044] In one embodiment, the server side 135 may be located remotely from the client side 105. As mentioned above, the connection between the client side 105 and the server side 135 may be intermittent. The data provider 130 and the remote service provider 131 operate to synchronize data operations (such as create, update, and delete operations) performed by the mobile application 110 in the event that the client side 105 does not communicate with the server side 135.

[0045] An exemplary environment for data provider independent change handling FIG. 2 illustrates one embodiment of an environment 200 associated with data provider-independent change handling in mobile client applications in which system 100 may operate. 10 may be installed on any of the client computing devices 205. 10 Upon installation of the change handling logic, the client computing device 205 includes data provider-independent change handling logic. The client computing device 205 may include devices such as a server 210, a workstation 215, a laptop 220, a smartphone 225, a tablet computer or personal digital assistant (PDA) 230, or other computing devices. The client computing device 205 is connected to an electronic communications network 235, such as the Internet, by a wired or wireless connection. The network 235 is further connected to a cloud application infrastructure 240 by a wired or wireless connection. The cloud application infrastructure includes one or more servers 245 and one or more data storage devices 250, each interconnected by a local network 255.

[0046] In one embodiment, the features shown and described with reference to FIG. 1 as belonging to the client side 105 are implemented by one or more client computing devices 205, and the features shown and described as belonging to the server side 135 are implemented by a cloud application infrastructure.

[0047] In one embodiment, the servers 245 may be configured as a stack for executing the functionality of the remote service providers 131. For example, one or more of the remote service providers 131 may be implemented as containers, or one or more of the remote service providers 131 are components of a web application that is implemented as a container. Here, the servers 245 are configured as a stack for executing the containerized remote service providers 131. Alternatively, for example, one or more of the remote service providers 131 may be implemented on a virtual machine, or one or more of the remote service providers are components of a web application that may be implemented on a virtual machine. Here, the servers 245 are configured as a stack for hosting the virtual machines that implement the remote service providers 131. Alternatively, in another example, one or more remote service providers may be executed directly by one or more of the servers 245.

[0048] Storage device 250 may include a solid-state memory drive, a hard drive disk, a network attached storage (NAS) device, or other storage device. In one embodiment, storage device 250 is a component of server 245. In one embodiment, data structures associated with data store 165 are hosted by storage device 250.

[0049] Exemplary Data Provider Independent Change Specification In one embodiment, a data object may be a row object, which represents a row in a tabular data structure. A row object may contain one or more attributes. A row object may also contain one or more links to "children," i.e., a collection of one or more additional row objects subordinate to a higher-level row object. When a row object is instantiated, it is provided with a definition indicating the number of each attribute and a description for each attribute, and an initial value for each attribute (if available).

[0050] For each attribute in a row object, the row object includes an original value for that attribute and an updated value for that attribute. Data initially retrieved by the mobile application 110 from the data store 165 on the server side 135 of the system 100 is stored in local storage by the persistence manager 125 as one or more instances of a row object. The values ​​of the attributes retrieved from the data store 165 are stored as original values ​​for each attribute of the row object instance. The mobile application 110 may manipulate the values ​​of one or more attributes in a row object instance in response to user input, for example, through the user interface 115. The mobile application 110 may further add attributes, remove attributes, or delete the entire row object instance. Changes to the row object instance are stored as updated values ​​for the attributes. The mobile application 110 may save or commit changes to a row object instance by executing a “save” or “commit” function to indicate that these changes should be applied to the row object.

[0051] For example, if the original value of an attribute is changed by the mobile application 110, the updated value of the attribute will store the change. Any previous updated value will be overwritten by the change. In another example, if the original value is to be deleted, a null or blank value may be stored in the updated value. In another example, if the attribute itself is to be deleted, the updated value for the attribute may be changed to a special value indicating deletion. In another example, if the entire row object instance is to be deleted, the attribute that is the unique key for the row object instance may be changed to a special value indicating deletion. Other methods of tracking the original and updated values ​​of a row object instance may also be employed.

[0052] In one embodiment, execution of a "save" or "commit" function for a row object instance triggers execution of change data constructor 175 for that row object instance and for all child row object instances linked from that row object instance. Change data constructor 175 parses and compares the original and updated values ​​of all attributes in the row object instance. Change data constructor 175 creates a data provider-independent change object instance that describes all changes to the row object instance.

[0053] In one embodiment, the change data constructor 175 may be applied to other data objects, such as objects representing tables, table columns, or other data structures.

[0054] FIG. 3 illustrates one embodiment of a schema 300 for a data provider-independent change object associated with data provider-independent change handling in a mobile client application. The change object schema 300 includes an attribute entry 305 for all changed attributes (if any) in a row object instance, as shown at line 02, columns 06 through 05, column 26 of the schema 300. The change object may include 0 through n attributes, as shown at line 02, columns 06 through 24 of the schema 300. The change object schema 300 describes the changes to those attributes. The change object schema 300 also includes a child entry 310 for all changed children (if any) of the row object instance, as shown at line 06, columns 06 through 14, column 22 of the schema 300. The change object may also include 0 through m children, as shown at line 06, columns 06 through 19 of the schema 300. The change object schema 300 describes the changes to the attributes of those children. The change object describes these changes in a data provider independent and data object independent format.

[0055] Change object schema 300 includes an attribute name 315 for each attribute entry 305. Attribute name 315 is the name of the modified row object attribute for which attribute entry 305 is generated. In one embodiment, change data constructor 175 generates attribute entries 305 when creating a change object instance for a row object instance. Change data constructor 175 parses the row object instance to identify the names of the modified row object attributes. Change data constructor 175 adds the identified names to the change object instance as the AttributeName 315 of the attribute entry 305 for the modified row object attribute, as shown in line 02, columns 06-18 of schema 300.

[0056] Attribute input 305 includes change type 320, which indicates the type of change to the modified row object attribute, as shown in line 03, columns 31-66 of schema 300. Change type 320 can be one of "updated," "deleted," or "created." In one embodiment, change data constructor provides change type 320 when creating a change object instance for a row object instance. Change data constructor 175 analyzes the update value of the modified attribute to identify the type of change made to the modified row object attribute. Change data constructor 175 adds the identified type to the change object instance as change type 320, as shown in line 03, columns 31-66 of schema 300.

[0057] The "updated" type means that the original value and the updated value of the changed attribute are different, indicating a change in value for that attribute. When the change type is "updated," attribute input 305 further includes value 325, which reflects the updated value of the changed attribute, as shown in line 04, columns 31-48 of schema 300. In one embodiment, change data constructor 175 extracts value 325 when creating a change object instance for the row object instance. Change data constructor 175 parses the updated value of the changed row object attribute to identify the value. Change data constructor 175 adds the identified value to the change object instance as the "new value" for value 325, as shown in line 04, columns 31-48 of schema 300.

[0058] A type of "created" means that a modified attribute has been added to the row object instance. When the modification type is "created," attribute input 305 further includes value 325 reflecting the updated value of the modified attribute (if provided), as shown in line 04, columns 31-48 of schema 300. In one embodiment, when creating a modification object instance for a row object instance, modification data constructor 175 determines whether there is an updated value for the modified (newly created) row object attribute. If there is an updated value, modification data constructor 175 parses the updated value of the modified (newly created) attribute to identify the value and adds the identified value to the modification object instance as a "new value" for value 325, as shown in line 04, columns 31-48 of schema 300. In a special case, when attribute name 315 indicates a unique identifier or key for the attribute, a type of "created" means that the entire row object instance is newly created. In one embodiment, the modified data constructor 175 may analyze the name of the modified row object attribute or attribute names 315 to determine whether a special "row instantiation" case applies.

[0059] A type of "deleted" means that the attribute named in 315 has been removed from the row object instance. In a special case, if the attribute name 315 indicates a unique identifier or key for the attribute, then a type of "deleted" means that the entire row object instance has been deleted. In one embodiment, change data constructor 175 may analyze the name of the changed row object attribute or attribute name 315 to determine whether the special "row instance deleted" case applies.

[0060] Change object schema 300 includes a child name 330 (or top-level attribute) for each child entry 310. The child name 330 is the name of the modified row object child for which the child entry 310 is created. In one embodiment, change data constructor 175 generates the child entries 310 when creating a change object instance for a row object instance. Change data constructor 175 parses the row object instance to identify the name of the modified row object child. Change data constructor 175 adds the identified name to the change object instance as the child name (ChildName) 330 of the child entry 310 for the modified row object child, as shown at line 06, columns 06-14 of schema 300. Change data constructor 175 also adds a type of structure 335, as shown at line 07, columns 26-39 of schema 300, indicating that the child 310 is a child structure rather than an attribute structure.

[0061] Each child entry 310 includes a collection of sub-objects, or "children" 340, associated with the row object, as shown in line 8, column 26 through line 13, column 36 of schema 300. The association between a row object and its children may be described as "tightly coupled" because the information stored by the children may not be meaningful if separated from the row object. For example, a child such as a line item for a purchase order is not meaningful outside the context of a row object instance that describes the purchase order, and a child such as an address line is not useful outside the context of a row object instance that describes a contact.

[0062] Each member of the set of children 340 has a change type 345 (similar to change type 320), a primary key 350, and a list of changes 355. In one embodiment, change data constructor 175 parses the row object instance to identify the change type and primary key of each member of the set of children 340. Change data constructor 175 adds the identified change type to the change object instance as change type 345, as shown at line 09, columns 41-74 of schema 300. Change data constructor 175 adds the identified primary key to the change object instance as primary key 350, as shown at line 10, columns 41-68 of schema 300. Change data constructor 175 uses primary key value 350 to retrieve the sub-row (member of the set of children 340) from local storage, for example, by requesting the sub-row by primary key from persistence manager 125. Change data constructor 175 then analyzes the retrieved sub-row for changes as described above and creates a description of the changes to the sub-row 355. This may be a change object that conforms to the format of schema 300 for a sub-row, as set forth in line 11, column 41 through line 12, column 78 of schema 300. This creation of change object instances for children (sub-rows) may occur recursively through successive layers of children until a sub-row that has no more children is reached.

[0063] The change object is data provider independent because it does not contain specific details of the provider definition for any service provider to which the change may ultimately be directed, and because it captures a description of the actions taken on the object by the user, not just a description of what that service provider needs to update. Thus, the change object can be routed losslessly through any service provider's respective data providers 130 to that service provider 131. This enables "offline writes" or "deferred write access" through multiple service providers. It also enables "offline writes" or "deferred write access" where the provider definition is modified before write access resumes.

[0064] A change object is data object independent because it does not contain the specific details of the data object definition for the instance of the data object that it describes. Because of this, a change object can support changes to the definition that describes a row object instance. For example, a change object allows adding or removing attributes themselves, as well as updating or deleting values.

[0065] 4 illustrates an example data provider-independent change object instance 400 that describes various changes made to an example row object instance. The example row object instance and the changes to that example row object instance described by change object instance 400 are intended to illustrate various features described herein.

[0066] The exemplary change object instance 400 is a record of changes made to the exemplary row object by the mobile application 110. The recorded changes can then be read by the data provider 130 and converted into a format that instructs the corresponding remote service provider 131 to make the recorded changes effective in the data store 165. The changes to the exemplary row object described by the exemplary change object instance 400 are as follows:

[0067] At line 02, 405, the attribute "SrNumber" is removed from the exemplary row object instance.

[0068] At line 03 410, the attribute "Title" in the exemplary row object instance is updated to have a value of "new title."

[0069] At line 04 415, an attribute "ABC" is added to the exemplary Row object instance and assigned a value of "123".

[0070] Lines 05-33 420 describe the operations on a child set called "contacts."

[0071] At 425 on lines 08-15, the first child object instance with a primary key of "111" is updated. At 430 on line 12, the "JobTitle" attribute of the first child object instance is updated to have a value of "New Title." At 435 on line 13, an "XYZZY" attribute is added to the first child object instance and assigned a value of "345."

[0072] At 440 on lines 16-22, a second child object instance having a primary key of "222" is updated. At 445 on line 20, an attribute "PhoneNumber" is deleted from the second child object instance. Note that even though the change is to delete the "PhoneNumber" attribute from the second child object instance, the type of action for the second child object instance is "updated" rather than "deleted." As also shown with reference to 450 on line 31 below, an action of type "deleted" operates to delete an object instance.

[0073] In lines 23-29, 455, a third child object with a primary key of "777" is created. At 460 on line 27, the attribute "MemberID" of the third child object instance is updated to have a value of "777". At 46 on line 28, 5 Then the attribute "Title" of the third child object instance is updated to have the value "Support Level 1."

[0074] At 450 on line 31, the fourth child object instance with a primary key of 123 is deleted.

[0075] Thus, in one embodiment, a change object (which may be described as an agnostic syntax for describing actions on a data object) includes, for each attribute of the data object that the action modifies, (i) an indication that the change to that attribute is one of an "update," "delete," or "create" action, and (ii) if the change is an "update" or "create" action, an indication of the new value for that attribute. The change object may also include, for each child object of the data object that the action modifies, (i) an indication that the child object is a child object, (ii) an indication that the change to the child object is one of an "update," "delete," or "create" action, (iii) an indication of the value of the primary key for the child, and (iv) an indication of the change to that child object, where the change indication may be described using the agnostic syntax.

[0076] Exemplary Method for Data Provider Independent Change Handling In one embodiment, each step of the computer-implemented method described herein may be performed by a processor (such as processor 910 as shown and described with reference to FIG. 9 ) of one or more computing devices configured with (i) memory (such as memory 915 and / or other computing device components shown and described with reference to FIG. 9 ) and (ii) logic to cause the system to perform the method steps (such as unmet demand minimization logic 930 shown and described with reference to FIG. 9 ). For example, the processor accesses, reads from, or writes to memory to perform the computer-implemented method steps described herein. These steps may include (i) retrieving any necessary information, (ii) calculating, determining, generating, classifying, or otherwise creating any data, and (iii) storing any calculated, determined, generated, classified, or otherwise created data. References to storage or storing refer to storage as a data structure in the memory of a computing device or storage / disk (such as the memory 915 or storage / disk 935 of the computing device 905 or remote computer 965 shown and described with reference to FIG. 9). In one embodiment, the processor is the signal processing and / or control circuitry 1020 of a mobile device such as the mobile device 1000 shown and described with reference to FIG. 10.

[0077] In one embodiment, each next step of the method is initiated in response to analyzing a received signal or retrieved stored data that indicates that the previous step has occurred at least to the extent necessary for the next step to begin. Generally, the received signal or retrieved stored data indicates completion of the previous step. Each step of the method may include multiple substeps, which may or may not be described herein.

[0078] In one embodiment, the method steps described herein are performed by a client computing device 205 (as shown and described with reference to FIG. 2). In one embodiment, the client computing device 205 is a dedicated computing device (such as computing device 905) configured with data provider-independent change handling logic.

[0079] 5 illustrates one embodiment of a method 500 associated with data provider-independent change handling in a mobile client application. Method 500 may be initiated based on various triggers, such as (i) a user (or administrator) of system 100 initiating method 500, (ii) a user of mobile application 110 initiating a "save changes" or "commit changes" action, (iii) the client computing device 205 (executing mobile application 110) having no or poor network connectivity to cloud application infrastructure 240, or (iv) receiving a signal over the network or analyzing stored data indicating that one or more remote service providers 131 associated with mobile application 110 have low availability or are unable to process requests. Method 500 initiates at start block 505 in response to analyzing a received signal or retrieved stored data and determining that the signal or stored data indicates that method 500 should begin. Processing continues to process block 510.

[0080] At processing block 510, the processor receives input to the mobile device indicating a create, update, or delete action on a data object stored in a remote data store.

[0081] In one embodiment, the processor of the client computing device 205 accepts one or more inputs received through the user interface 115 that describe one or more create, update, or delete operations on a data object. The data object may be associated with the application 110. The data object may be a particular instance of a row object.

[0082] In one embodiment, the processor parses the input to identify a create, update, or delete operation, an attribute of the data object to be created, updated, or deleted, and a value for that attribute (if any value is provided). (In one embodiment, multiple attributes of the data object are to be created, updated, and / or deleted based on the input. Steps described with respect to a single attribute may be applied for multiple attributes of the data object.) The processor applies the identified create, update, or delete operation to a local copy of the data object stored locally on the client computing device 205.

[0083] For example, if the operation is an update operation, the processor writes the value for the attribute to an update field for that attribute in the local copy of the data object. Or, for example, if the operation is a create operation, the processor adds the attribute to be created to the data object and writes the value for the attribute to an update field for that attribute. Or, as another example, if the operation is a delete operation, the processor writes a special value indicating the deletion of the attribute to an update field for that attribute.

[0084] In one embodiment, the processor parses the input and determines that an entire data object is to be created. The processor creates a local instance of the data object stored locally on the client computing device 205 and writes any values ​​for attributes found in the input into update fields for the respective attributes. The processor writes the new primary key into the update field for the primary key attribute.

[0085] In one embodiment, the processor parses the input and determines that the entire data is to be deleted. The processor writes a special value to the update field for the primary key to indicate the deletion of the primary key (or unique identifier).

[0086] In one embodiment, the processor performs one or more functions of the persistence manager 125 to interact with local storage, including writing to update fields.

[0087] Once the processor has thus completed receiving input to the mobile device indicating a create, update, or delete action on a data object stored in a remote data store, processing at processing block 510 is complete and processing continues to processing block 515.

[0088] At processing block 515, in response to receiving the input, the processor creates a description of the action on the data object in a syntax that is independent of the type of remote service provider used to interact with the remote data store.

[0089] In one embodiment, a processor of a client computing device parses an input indicating that changes to a data object indicated by the input are to be saved or committed. In response, the processor parses a local copy of the data object to identify the values ​​stored in the original and updated fields for each attribute. For each attribute, the processor compares the updated field value with the original field value. If these values ​​differ, the processor generates a description of the change between the original and updated field values ​​for the attribute and writes it to a data provider-independent change object for the data object in local storage. The change object is specific to the data object. In one embodiment, the processor creates the change object by executing one or more functions of a change data constructor 175.

[0090] For example, if the attribute is a primary key and the update field value for that attribute is a special value indicating deletion, change data constructor 175 will write a description for the primary key of the original field value indicating the type of change is "deleted," similar to the description shown at 450 on line 31 of exemplary change object instance 400. Or, for example, if the attribute is not a primary key and the update field value is a special value indicating deletion, change data constructor 175 will write a description for the attribute indicating the type of change is "deleted," similar to the description shown at 405 on line 02 of exemplary change object instance 400. Or, as another example, if the update field value is not a special value indicating deletion but is different from the original field value, change data constructor 175 will write a description for the attribute indicating the type of change is "updated" and that the value for that attribute is an update field value, similar to the description shown at 410 on line 03 of exemplary change object instance 400. Or, in yet another example, if the attribute is not a primary key and the original field value is null or otherwise indicates that there was no previous value for this attribute, and an update field value is assigned, change data constructor 175 will write a description indicating that the type of change for the attribute is "created" and that the value for the attribute is the update field value. Or, in yet another example, if the attribute is a primary key and the original field value is null or otherwise indicates that there was no previous primary key, and an update field value is assigned, change data constructor 175 will write a description indicating that the type of change is "created" for the primary key of the update field value.

[0091] In one embodiment, the processor determines that the value stored in the update field of the attribute of the local copy of the data object is a pointer, link, or other connection to one or more child data structures. The processor analyzes the attribute to determine the location of the child data structures and retrieves them from storage. The processor then analyzes the child data structures to determine whether any changes have been made to them. If changes have been made, the change data constructor 175 will write child entries to the change data object indicating that the local copy of the data object has child data structures, similar to the child entries shown at 420 on lines 05-33 of the exemplary change object instance 400. This child entry may include a top-level attribute name for the child structure, such as the name "contacts" shown on line 05 of the exemplary change object instance 400. This child entry may include a structure type indicating that the child entry is a child structure rather than an attribute structure, as shown, for example, on line 06 of the exemplary change object instance 400. The child entries may include the type of change for the child data structures included in the child entries and a primary key for identifying the child data structures included in the child entries, as shown, for example, at lines 09 and 10 of exemplary change object instance 400. The child entries may include a list of changes to attributes of child data structures that recursively follow the same schema 300 as the parent change object, as shown, for example, at 430 on line 12 and 435 on line 13 of exemplary change object instance 400.

[0092] Once the processor has thus completed creating a description of an action on a data object in a syntax that is independent of the type of remote service provider used to interact with the remote data store in response to receiving input, processing at processing block 515 is complete and processing continues at processing block 520.

[0093] At processing block 520, the processor translates the description of the action into the syntax of the first remote service provider to create a command configured to cause the first remote service provider to perform the action.

[0094] In one embodiment, the processor of the client computing device 205 has already received one or more definitions of data types accepted by a first remote service provider, such as remote REST provider 151, and a copy of the syntax for interacting with the first remote service provider. These definitions and syntax are maintained in local storage by a local first data provider corresponding to the first remote service provider, such as REST data provider 150. Each pairing of a data provider 130 and a remote service provider 131 may have definitions and syntax specific to that pairing.

[0095] In one embodiment, if the type of change is an update, the processor searches these definitions for a definition that corresponds to the data type of the local copy of the row object. The processor then searches the definition for the attribute name of each attribute entry listed in order in the change object. When the attribute name is found in the definition, the processor accesses syntax to create instructions for that attribute entry to effect the change recorded by that attribute entry. The processor will create an electronic message according to the syntax for an "update" type change to cause the first remote service provider to assign a new value to the attribute of the data object in data store 165.

[0096] For example, in response to parsing the attribute input for the "Title" attribute shown at 410 on line 03 of exemplary change object instance 400, the processor would search the definition corresponding to this particular type of row object for the "Title" attribute. The processor would retrieve syntax for an "update" type change operation. The processor would create an electronic message according to the syntax for an "update" type change to cause the first remote service provider to assign the value "New Title" to the title attribute of the data object in data store 165.

[0097] In one embodiment, if the type of change is a create, the processor will search for syntax for a "create" type change operation. The processor will create an electronic message according to the syntax for a "create" type change to cause the first remote service provider to create a new attribute of a data object in data store 165 (or, in special cases, create an entire new data object).

[0098] In one embodiment, if the type of change is a delete, the processor will search for syntax for a "delete" type change operation. The processor will create an electronic message according to the syntax for a "delete" type change to cause the first remote service provider to delete an attribute of the data object in data store 165 (or, in special cases, delete the entire data object).

[0099] For each type of change operation that can be represented by a change object, the semantics of creating an electronic message are defined by the data type definition for the data object, as well as whether fields are required, locked for editing, non-deletable, and whether fields can be added to the data object.

[0100] In one embodiment, the processor performs one or more functions of the data provider 130 to create the electronic message.

[0101] In one embodiment, the processor updates the syntax and / or definitions. For example, the processor downloads the syntax and / or definitions in response to (i) determining that network connectivity to the first remote service provider has been restored or (ii) determining that the first remote service provider has resumed availability to process transactions. In one example, the processor may do so if it detects that a new version of the definition or syntax was implemented by the first remote service provider while the service provider's network connectivity was interrupted or unavailable.

[0102] In one embodiment, the syntax of the first remote service provider is stored on the mobile device, and the method further includes retrieving a semantic description for the type of data object from the first remote service provider, wherein converting the description of the action into the syntax of the first remote service provider is based on the retrieved description of the semantics.

[0103] Once the processor has thus completed converting the description of the action into the syntax of the first remote service provider to create a command configured to cause the first remote service provider to perform the action, processing at processing block 520 is complete and processing continues to processing block 525.

[0104] At processing block 525, the processor sends a command over the network to the first remote service provider to cause an action to be taken on a data object in the remote data store.

[0105] In one embodiment, the processor of the client computing device 205 retrieves the generated message from local memory using the first data provider, addresses it to a first remote service provider corresponding to the first data provider, and sends it as a command over the network to the first remote service provider to cause an action to be taken on a data object in the remote data store.

[0106] Once the processor has thus completed sending the command over the network to the first remote service provider to cause an action to be taken on the data object in the remote data store, processing at processing block 525 is complete and processing continues to end block 530 where method 500 ends.

[0107] In response to receiving the command, the first remote service provider parses the command and creates database commands to effect actions on data objects in a data store, such as data store 165. The database commands may be created in structured query language (SQL) or other languages ​​for interacting with databases, such as relational databases. The first remote service provider sends the database commands to data store 165, which performs the actions on the data objects.

[0108] Applies to deferred write access situations 6 illustrates one embodiment of a method 600 associated with deferred write access using data provider-independent change handling in a mobile client application. Method 600 may be initiated based on various triggers, such as (i) a user (or administrator) of system 100 initiating method 600, (ii) a user of mobile application 110 initiating a "save changes" or "commit changes" action, (iii) the client computing device 205 (executing mobile application 110) having no or poor network connectivity to cloud application infrastructure 240, or (iv) receiving a signal over the network or analyzing stored data indicating that one or more remote service providers 131 associated with mobile application 110 have low availability or are unable to process requests. Method 600 initiates at start block 605 in response to analyzing a received signal or retrieved stored data and determining that the signal or stored data indicates that method 600 should begin. Processing continues through processing blocks 610 and 615 to a deferred write access loop 620. Processing blocks 610 and 615 are performed in a manner similar to that described for processing blocks 510 and 515, respectively, as shown and described with respect to FIG.

[0109] Processing continues at decision block 625. In one embodiment, at decision block 625, the processor of the client computing device 205 detects whether the first remote service provider is unavailable. For example, the processor may ping the internet protocol (IP) address of the server 245 hosting the first remote service provider to determine network latency between the client computing device 205 and the server 245. The processor then compares the detected network latency to a threshold that indicates a slow, poor, or otherwise limited network connection between the client computing device 205 and the server 245. In another example, the processor may detect a network disconnection between the client computing device 205 and the server 245 by pinging the IP address of the server 245 and determining that no response is received from the server. In another example, the processor may detect that the first remote service provider has low availability or no availability by receiving and analyzing a message from the first remote service provider that it is offline or busy. If the threshold is exceeded, or if the network is disconnected, or if the first remote service provider reports that it is down or busy (has a high processing load), then the first remote service provider is unavailable (“No”) and processing continues to processing block 630. Otherwise, the first remote service provider is available (“Yes”) and processing continues to processing block 635.

[0110] At processing block 630, the processor stores a description of the action on the mobile device. In one embodiment, the processor executes the persistence manager 125 to write the changed object to local memory. Processing at processing block 630 is complete and proceeds to decision block 640.

[0111] At decision block 640, the processor determines whether it has received an indication that the first remote service provider is available, in a manner similar to decision block 625. For example, the processor may ping server 245 to determine that network latency has dropped below a threshold. Or, the processor may ping server 245 to determine that network connectivity has been restored. Or, the processor may receive and analyze a message from the first remote service provider that it is available or that it is no longer offline or in use. If the processor receives either of these indications (“yes”), the first remote service provider is available, and processing continues at processing block 635. Otherwise (“no”), processing continues at processing block 645. At processing block 645, the processor waits a set time interval, e.g., 1-10 minutes, before returning to decision block 640 to determine whether there is an indication that the first remote service provider is available. This has the effect of delaying the creation of the command described in process block 635 until after an indication that the first remote service provider is available is received by the mobile device.

[0112] Processing continues through processing blocks 635 and 650 to end block 655, where method 600 ends. Processing blocks 635 and 650 are performed in a manner similar to that described for processing blocks 520 and 525, respectively, as shown and described with respect to FIG.

[0113] Applying to multiple remote service providers 7 illustrates one embodiment of a method 700 associated with deferred write access through multiple remote service providers using data provider-agnostic change handling in a mobile client application. Method 700 may be initiated based on various triggers, such as (i) a user (or administrator) of system 100 initiating method 700, (ii) a user of mobile application 110 initiating a “save changes” or “commit changes” action, (iii) the client computing device 205 (executing mobile application 110) having no or poor network connectivity to cloud application infrastructure 240, or (iv) receiving a signal over the network or analyzing stored data indicating that one or more remote service providers 131 associated with mobile application 110 have low availability or are unable to process requests. Method 700 initiates at start block 705 in response to analyzing a received signal or retrieved stored data and determining that the signal or stored data indicates that method 700 should begin. Processing continues through processing blocks 710 and 715 to a deferred write access loop 720. Processing blocks 710 and 715 are performed in a manner similar to that described for processing blocks 510 and 515, respectively, as shown and described with respect to FIG.

[0114] Processing continues at decision block 725. In one embodiment, at decision block 725, the processor of the client computing device 205 detects whether the first remote service provider is unavailable, for example, by performing an analysis similar to the analysis performed at decision block 625 with respect to the first remote service provider as shown and described with reference to FIG. 6. If the first remote service provider is available (“NO”), processing proceeds through processing blocks 730 and 735 to end block 740, where method 700 ends. Processing blocks 730 and 735 are performed with respect to the first remote service provider in a manner similar to that described for processing blocks 520 and 525 as shown and described with reference to FIG.

[0115] Referring again to decision block 745, if the first remote service provider is unavailable (“YES”), processing continues to decision block 745. In one embodiment, at decision block 745, the processor of the client computing device 205 detects whether the second remote service provider is unavailable by, for example, performing an analysis similar to the analysis performed at decision block 625 with respect to the first remote service provider as shown and described with reference to FIG. 6. If the second remote service provider is available (“NO”), processing proceeds through processing blocks 750 and 755 to end block 740, where method 700 ends. Processing blocks 750 and 755 are performed with respect to the second remote service provider in a manner similar to that described for processing blocks 520 and 525 as shown and described with reference to FIG. 5. Thus, if the first remote service provider is unavailable for any reason, the second remote service provider may handle the change. In one embodiment, after determining that the first remote service provider is unavailable to receive the command, the method includes formulating the command in the syntax of a second remote service provider and sending the command to the second remote service provider in response to determining that the first remote service provider is unavailable to receive the command. In one embodiment, the second remote service provider is a different type of provider than the first remote service provider. For example, the first remote service provider may be a remote REST-type service provider 151, while the second remote service provider is a remote elastic-type service provider 156 or another type of remote service provider.

[0116] Referring again to decision block 745, if the second remote service provider is unavailable (“YES”), processing continues to decision block 760. In one embodiment, at decision block 760, the processor of the client computing device 205 detects whether the Nth remote service provider is unavailable by, for example, performing an analysis similar to the analysis performed at decision block 625 with respect to the first remote service provider as shown and described with reference to FIG. 6. If the Nth remote service provider is available (“NO”), processing proceeds through processing blocks 765 and 770 to end block 740, where method 700 ends. Processing blocks 765 and 770 are performed with respect to the second remote service provider in a manner similar to that described for processing blocks 520 and 525 as shown and described with reference to FIG. 5. Thus, any number of available remote service providers may be included in the failover sequence in the deferred write access loop 720. This case can therefore be generalized to after determining that the first N-1 remote service providers are unavailable to receive the command, formulating the command in the syntax of the Nth remote service provider and sending the command to the Nth remote service provider in response to determining that the N-1 remote service providers are unavailable to receive the command.

[0117] Referring again to decision block 760, if the Nth remote service provider is unavailable (“YES”), processing continues at process block 775. At process block 775, the processor stores a description of the action for the mobile device and processing continues at decision block 780. At decision block 780, the processor determines whether there is an indication that any of the first through Nth remote service providers are available. If available (“YES”), processing returns to decision block 725 and continues using the available remote service provider. If not available (“NO”), processing continues at process block 785, where the process waits for a period of time and then returns to decision block 780. Process elements 775, 780, and 785 are performed in a manner similar to process elements 630, 640, and 645 as shown and described with reference to FIG. 6.

[0118] Choose from multiple remote service providers 8 illustrates one embodiment of a method 800 associated with deferred write access through selectable alternative service providers using data provider-agnostic change handling in a mobile client application. Method 800 may be initiated based on various triggers, such as (i) a user (or administrator) of system 100 initiating method 800; (ii) a user of mobile application 110 initiating a "save changes" or "commit changes" action; (iii) the client computing device 205 (executing mobile application 110) having no or poor network connectivity to cloud application infrastructure 240; or (iv) receiving a signal over the network or analyzing stored data indicating that one or more remote service providers 131 associated with mobile application 110 have low availability or are unable to process requests. Method 800 initiates at start block 805 in response to analyzing a received signal or retrieved stored data and determining that the signal or stored data indicates that method 800 should begin. Processing continues through process blocks 810 and 815 to decision block 820. Process blocks 810 and 815 are performed in a manner similar to that described for process blocks 510 and 515, respectively, as shown and described with respect to FIG.

[0119] At decision block 820, the processor selects a remote service provider from a set of two or more remote service providers, each having access to the remote data store. The selection from among the two or more remote service providers, remote service providers 1-N, is based on the remote service provider satisfying one or more criteria. The processor retrieves the one or more criteria from local storage. The criteria may be, for example, one or more of: (i) the current availability of the remote service provider; and (ii) the complexity of the action to be provided to the remote service provider.

[0120] With respect to current availability, the processor may evaluate the availability of each of the remote service providers and determine how available each remote service provider is in a process similar to decision blocks 625 and 640 as shown and described with reference to FIG. 6. The processor compares the relative availability of the remote service providers based on, for example, one or more of network connectivity, network latency, and load on the remote service provider. The processor selects the most available service provider based on the availability metric employed by the processor.

[0121] With respect to the complexity of the action, the remote elastic provider 156 and the remote graph query provider 146 may have a performance advantage over the remote REST provider 151 or the remote XML provider 141. For example, the remote graph query provider 146 can process complex unified queries (written in GraphQL), while the remote REST provider 151 or the remote XML provider 141 may require multiple interactions to achieve the same result. Also, for example, the remote elastic provider 156 can process queries more quickly because it maintains a persistent data store on the server 245 rather than querying data piecemeal from the data store 165 in response to interactions with the remote REST provider 151 or the remote XML provider 141. In one embodiment, the processor evaluates whether an action is complex based on the number of changes included in the action. If the number of changes is below a threshold indicating a simple action, e.g., fewer than 10, the processor selects a remote service provider, such as the remote REST provider 151 or the remote XML provider 141, from among the available remote service providers to handle the simple action. If the threshold is met or exceeded, the processor selects from among the available remote service providers a remote service provider that can handle complex actions, such as the remote elastic provider 156 or the remote graph query provider 146 .

[0122] Exemplary Use Cases In one embodiment, the mobile application 110 is an application for submitting and editing purchase orders as part of an e-commerce system. The data store 165 includes many line objects representing purchase orders. An exemplary line object representing an exemplary purchase order is retrieved by the mobile application 110 from the data store 165 through a data provider and its corresponding remote service provider and stored in local storage on the client device 205 of the client side 105 using the persistence manager 125. A user of the mobile application 110 enters input through the user interface 115 to manipulate the exemplary purchase order. The user interface 115 makes changes to the exemplary line object. The user then selects an option presented by the user interface 115 to save or commit the changes made to the exemplary purchase order.

[0123] In response to a save or commit operation, change data constructor 175 analyzes the changes made to the example row object and records all changes to the example row object in a data provider-independent change object. For example, a change to an example row may include an update to an attribute called "Buyer Name." Also, for example, a change to an example row may include an update to an attribute called "Quantity" of a line item in a purchase order from "5" to "10." Change data constructor 175 generates an attribute entry for the Buyer Name attribute that updates the Buyer Name value to "John Smith" in the change object. Change data constructor 175 also generates a child entry for the top-level attribute Line Item that includes an update to the Quantity value to "10."

[0124] In one embodiment, the data manager 170 sends the change object to the data provider 150 to convert it into a message in the API format for the remote REST provider 151 and sends the generated message to the remote REST provider 151. In one embodiment, the processor detects that the remote REST service provider 151 is unavailable due to (i) a lack of network connectivity with the server 245 or (ii) a high load on the provider 151. If the unavailability of the remote REST service provider 151 is due to a lack of network connectivity, the data manager 170 sends the change object to the persistence manager 125 to be stored locally. Once connectivity is restored, the transaction processor 180 will retrieve the change object and retry the conversion and transmission. If the unavailability of the remote REST provider 151 is due to a high load on the provider 151, the data manager sends the change object to the graph query data provider to convert it into a message in the API format for the remote graph query provider 146 and sends the generated message to the remote graph query provider 146. The remote graph query provider 146 executes the message's API payload, causing the changes to be applied to a server-side copy of the exemplary row object in the data store 165. Note that the change object can be widely used as a format for local storage and for submission to a data provider.

[0125] Cloud or Enterprise Implementation In one embodiment, the automated scoping tool 103 and / or other systems shown and described herein are computing / data processing systems that include a database application or a collection of distributed database applications. The applications and data processing systems may be configured to operate using or implemented as a cloud-based networking system, a software-as-a-service (SaaS) architecture, a platform-as-a-service (PaaS) architecture, an infrastructure-as-a-service (IaaS) architecture, or other type of networked computing solution. In one embodiment, the cloud computing system 100 is a server-side system that provides at least the functionality disclosed herein and is accessible by many users via computing devices / terminals that communicate with the cloud computing system 100 (acting as a server) over a computer network.

[0126] Software Module Embodiments Generally, software instructions are designed to be executed by a suitably programmed processor. These software instructions may include, for example, computer-executable code and source code that may be compiled into computer-executable code. These software instructions may also include instructions written in interpreted programming languages, such as scripting languages.

[0127] In complex systems, such instructions are typically organized into program modules, each of which performs a particular task, process, function, or operation. The entire set of modules may have their operations controlled or coordinated by an operating system (OS) or other type of organizational platform.

[0128] In one embodiment, one or more of the components, functions, methods, or processes described herein are configured as modules stored on a non-transitory computer-readable medium, the modules being configured with at least stored software instructions that, when executed by a processor accessing memory or storage, cause the computing device to perform the corresponding functions as described herein.

[0129] In one embodiment, one or more of the mobile application 110, the user interface 115, the transaction handler 120, the persistence manager 125, the data provider 130, the remote service provider 131, the data manager 170, the change data constructor 175, and the transaction processor 180 are configured as modules stored on a non-transitory computer-readable medium.

[0130] Computing Device Embodiments FIG. 9 illustrates an exemplary computing device configured and / or programmed with one or more of the example systems and methods described herein, and / or equivalents. The exemplary computing device may be a computer 900 including a processor 910, a memory 915, and input / output ports 920 operatively connected by a bus 925. In one example, the computer 900 may include data provider-independent change handling logic 930 configured to facilitate data provider-independent change handling in a mobile client application, similar to the logic, systems, and methods shown and described with reference to FIGS. 1-8. In different examples, the logic 930 may be implemented in hardware, a non-transitory computer-readable medium having stored instructions, firmware, and / or combinations thereof. While the logic 930 is shown as a hardware component attached to the bus 925, it should be understood that in other embodiments, the logic 930 may be implemented in the processor 910, stored in the memory 915, or stored on a disk 935.

[0131] In one embodiment, logic 930 or a computer is a means (e.g., structure: hardware, non-transitory computer-readable medium, firmware) for performing the described actions. In some embodiments, the computing device may be a server operating in a cloud computing system, a server configured in a Software as a Service (SaaS) architecture, a smartphone, a laptop, a tablet computing device, etc.

[0132] These means may be implemented, for example, as an ASIC programmed to facilitate data provider-independent change handling in mobile client applications. These means may also be implemented as stored computer-executable instructions that are temporarily stored in memory 915 and presented to computer 900 as data 940 that are then executed by processor 910.

[0133] The logic 930 may also provide the means (eg, hardware, non-transitory computer-readable medium storing executable instructions, firmware) for performing data provider-independent change handling in the mobile client application.

[0134] To generally describe an exemplary configuration of computer 900, processor 910 may be a wide variety of processors, including dual microprocessors and other multi-processor architectures. Memory 915 may include volatile memory and / or non-volatile memory. Non-volatile memory may include, for example, ROM, PROM, etc. Volatile memory may include, for example, RAM, SRAM, DRAM, etc.

[0135] The storage disk 935 may be operatively connected to the computer 900, for example, via an input / output (I / O) interface (e.g., card, device) 945 and an input / output port 920. The disk 935 may be, for example, a magnetic disk drive, a solid-state disk drive, a floppy disk drive, a tape drive, a zip drive, a flash memory card, a memory stick, etc. Additionally, the disk 935 may be a CD-ROM drive, a CD-R drive, a CD-RW drive, a DVD ROM, etc. The memory 915 may store, for example, processes 950 and / or data 940. The disk 935 and / or memory 915 may store an operating system that controls and allocates resources of the computer 900.

[0136] The computer 900 can interact with input / output (I / O) devices via an I / O interface 945 and input / output ports 920. The input / output devices can be, for example, a keyboard, a microphone, a pointing and selection device, a camera, a video card, a display, a disk 935, a network device 955, etc. The input / output ports 920 can include, for example, serial ports, parallel ports, and USB ports.

[0137] The computer 900 can operate in a networked environment and, as such, can be connected to a network device 955 via the I / O interface 945 and / or the I / O port 920. Through the network device 955, the computer 900 can interact with a network. Through the network, the computer 900 can be logically connected to a remote computer. The networks with which the computer 900 can interact include, but are not limited to, a LAN, a WAN, and other networks.

[0138] Mobile Device Embodiments Reference is now made to FIG. 10 , which illustrates an exemplary mobile device 1000 configured and / or programmed with one or more of the example systems and methods described herein, and / or equivalents. In one example, the mobile device 1000 may include data provider-independent change handling logic 1005 configured to facilitate data provider-independent change handling in a mobile client application, similar to the logic, systems, and methods shown and described with reference to FIGS. 1-8 . The mobile device 1000 may include a cellular antenna 1010. An exemplary embodiment may implement signal processing and / or control circuitry generally identified at 1020 in FIG. 10 . In some implementations, the mobile device 1000 includes a microphone 1030, an audio output 1040, such as a speaker and / or audio output jack, a display 1050, and / or input devices 1060, such as a keypad, pointing device, voice activation, and / or other input devices. Signal processing and / or control circuitry 1020 and / or other circuitry (not shown) in mobile device 1000 may process data, perform encoding and / or encryption, perform calculations, format data, and / or perform other mobile phone functions.

[0139] The mobile device 1000 may communicate with mass data storage 1070, which stores data in a non-volatile manner, such as in optical and / or magnetic storage devices including, for example, a HDD and / or DVD. The HDD may be a mini HDD including one or more platters having a diameter less than approximately 1.8 inches. The mobile phone 1000 may be connected to memory 1080, such as RAM, ROM, low-latency non-volatile memory such as flash memory, and / or other suitable electronic data storage. The mobile device 1000 may also support connectivity with a WLAN via a WLAN network interface 1090. The mobile device 1000 may include a WLAN antenna 1095. In this exemplary embodiment, the exemplary system and method may be implemented using this WLAN network interface 1090, although other configurations are possible.

[0140] Definitions and Other Embodiments In another embodiment, the described methods and / or their equivalents may be implemented using computer-executable instructions. Thus, in one embodiment, a non-transitory computer-readable / storage medium is configured having stored thereon computer-executable instructions for an algorithm / executable application that, when executed by a machine, causes the machine (and / or associated components) to perform a method. Exemplary machines include, but are not limited to, processors, computers, servers operating in a cloud computing system, servers configured in a Software-as-a-Service (SaaS) architecture, smartphones, etc. In one embodiment, a computing device is implemented with one or more executable algorithms configured to perform any of the disclosed methods.

[0141] In one or more embodiments, the disclosed methods or their equivalents are performed by either computer hardware configured to perform the methods or by computer instructions embodied in modules stored on a non-transitory computer-readable medium, the instructions configured as an executable algorithm configured to perform the methods when executed by at least a processor of a computing device.

[0142] For simplicity of explanation, the illustrated methodologies in the figures are shown and described as a series of algorithmic blocks, but it should be understood that these methodologies are not limited by the order of the blocks. Some of the blocks may occur in a different order than shown and described and / or concurrently with other blocks. Also, not all illustrated blocks may be used to implement an example methodology. Blocks may be combined or separated into multiple actions / components. Furthermore, additional and / or alternative methodologies may employ additional actions not shown in the blocks.

[0143] The following contains definitions of selected terms employed herein. These definitions include various examples and / or forms of components that fall within the scope of the terms and that may be used to implement them. These examples are not intended to be limiting. Both singular and plural forms of terms may be within the scope of these definitions.

[0144] References to "one embodiment," "embodiment," "one example," "example," etc. indicate that the embodiment or example so described may include a particular feature, structure, characteristic, property, element, or limitation, but not all embodiments or examples necessarily include that particular feature, structure, feature, property, element, or limitation. Furthermore, repeated use of the phrase "in one embodiment" does not necessarily refer to the same embodiment, although it may.

[0145] ASIC (application specific integrated circuit): An integrated circuit for a specific application. CD (compact disk): Compact disc.

[0146] CD-R (CD recordable): Recordable CD. CD-RW (CD rewriteable): Rewritable CD.

[0147] DVD: Digital versatile disk and / or digital video disk.

[0148] HTTP (hypertext transfer protocol): Hypertext Transfer Protocol. LAN (local area network): Local area network.

[0149] RAM (random access memory): Random access memory. DRAM (dynamic RAM): Dynamic RAM.

[0150] SRAM (synchronous RAM): Synchronous RAM. ROM (read only memory): Read-only memory.

[0151] PROM (programmable ROM): Programmable ROM. EPROM (erasable PROM): Erasable PROM.

[0152] EEPROM (electrically erasable PROM): Electrically erasable PROM. SQL (structured query language): Structured query language.

[0153] USB (universal serial bus): Universal Serial Bus. XML (extensible markup language): Extensible Markup Language.

[0154] WAN (wide area network): Wide area network. WLAN (Wireless LAN): Wireless LAN.

[0155] As used herein, a "data structure" is an organization of data in a computing system, stored in memory, a storage device, or other computerized system. A data structure may be, for example, any one of a data field, a data file, a data array, a data object, a data record, a database, a data table, a data row, a data column, a graph, a tree, a linked list, etc. A data structure may be formed from and contain many other data structures (e.g., a database contains many data records). According to other embodiments, other examples of data structures are possible as well.

[0156] As used herein, "computer-readable medium" or "computer storage medium" refers to a non-transitory medium that stores instructions and / or data that, when executed, are configured to perform one or more of the disclosed functions. In some embodiments, data may function as instructions. Computer-readable media may take forms including, but not limited to, non-volatile media and volatile media. Non-volatile media may include, for example, optical disks, magnetic disks, and the like. Volatile media may include, for example, semiconductor memory, dynamic memory, and the like. Common forms of computer-readable media may include, but are not limited to, floppy disks, flexible disks, hard disks, magnetic tape, other magnetic media, application-specific integrated circuits (ASICs), programmable logic devices, compact disks (CDs), other optical media, random access memory (RAM), read-only memory (ROM), memory chips or cards, memory sticks, solid-state storage devices (SSDs), flash drives, and other media with which a computer, processor, or other electronic device can function. Each type of media may include stored instructions of an algorithm that, when selected for implementation in an embodiment, is configured to perform one or more of the disclosed and / or claimed functions.

[0157] As used herein, "logic" refers to components implemented using computer or electrical hardware, non-transitory media having executable application or program module instructions stored thereon, and / or combinations thereof, to perform any of the functions or actions as disclosed herein and / or to cause functions or actions from other logic, methods, and / or systems to be performed as disclosed herein. Equivalent logic may include firmware, a microprocessor programmed with an algorithm, discrete logic (e.g., an ASIC), at least one circuit, analog circuit, digital circuit, programmed logic device, memory device containing algorithmic instructions, etc., any of which may be configured to perform one or more of the disclosed functions. In one embodiment, logic may include one or more gates, combinations of gates, or other circuit components configured to perform one or more of the disclosed functions. Where multiple logics are described, it may be possible for the multiple logics to be incorporated into one logic. Similarly, where a single logic is described, it may be possible for the single logic to be distributed among multiple logics. In one embodiment, one or more of these logics are corresponding structures associated with performing the disclosed and / or claimed functions. The choice of which type of logic to implement may be based on desired system requirements or specifications. For example, if faster speed is a consideration, hardware would be selected to implement the function. If lower cost is a consideration, stored instructions / executable applications would be selected to implement the function.

[0158] An "operable connection," or a connection by which entities are "operably connected," is a connection through which signals, physical communications, and / or logical communications may be sent and / or received. An operable connection may include a physical interface, an electrical interface, and / or a data interface. An operable connection may include different combinations of interfaces and / or connections sufficient to enable operable control. For example, two entities may be operably connected to communicate signals with each other directly or through one or more intermediary entities (e.g., a processor, an operating system, logic, a non-transitory computer-readable medium). Logical and / or physical communication channels may be used to create an operable connection.

[0159] As used herein, a "user" includes, but is not limited to, one or more humans, one or more computers or other devices, or any combination thereof.

[0160] While the disclosed embodiments have been illustrated and described in considerable detail, it is not intended to limit or in any way restrict the scope of the appended claims to such detail. It is, of course, not possible to describe every conceivable combination of components or methodologies for describing various aspects of the subject matter. Accordingly, this disclosure is not limited to the specific details or illustrative examples shown and described.

[0161] To the extent the terms "include" or "comprising" are used in the detailed description or claims, they are intended to be inclusive in the same manner as the term "comprises" is interpreted when used as a transitional phrase in the claims.

[0162] To the extent the term "or" (e.g., A or B) is used in the detailed description or claims, it is intended to mean "A or B or both." If applicant intended to indicate "A or B only, but not both," the phrase "A or B only, but not both" would be used. Thus, use of the term "or" herein is inclusive, not exclusive.

Claims

1. A mobile device computer-implemented method, comprising: receiving an input on the mobile device indicating a create, update, or delete action on a data object stored in a remote data store; In response to receiving the input, creating a description of the action on the data object in a syntax that is independent as to the type of remote service provider used to interact with the remote data store; converting the description of the action into a syntax of a first remote service provider to create a command configured to cause a first remote service provider to perform the action; transmitting the command from the mobile device over a network to the first remote service provider to cause the action to be performed on the data object in the remote data store; The independent syntax of the description of the action on the data object is: for each attribute of the data object that the action modifies: (i) an indication that the modification to that attribute is one of an "update," "delete," or "create" action; and (ii) if the modification is an "update" or "create" action, an indication of a new value for that attribute; 10. The computer-implemented method of claim 1, further comprising: for each child object of the data object that the action modifies, (i) an indication that the child object is a child object; (ii) an indication that the change to the child object is one of an "update," "delete," or "create" action; (iii) an indication of a primary key value for the child; and (iv) an indication of the change to that child object, wherein the indication of the change is written using the agnostic syntax.

2. determining that the first remote service provider is unavailable to receive the command; storing the description of the action for the mobile device; 2. The computer-implemented method of claim 1, further comprising: delaying creating the command until after an indication that the first remote service provider is available is received by the mobile device.

3. determining that a second remote service provider is unavailable to receive the command; 3. The computer-implemented method of claim 1, wherein in response to determining that the second remote service provider is unavailable to receive the command, formulating the command in the syntax of the first remote service provider and sending the command to the first remote service provider.

4. selecting the first remote service provider from a set of two or more remote service providers each having access to the remote data store; 4. The computer-implemented method of claim 1, wherein selection is based on the first remote service provider satisfying one or more criteria including at least one of: (i) the current availability of the remote service provider; and (ii) the complexity of the action.

5. A program for causing a computer to carry out the method according to any one of claims 1 to 4.

6. 1. A computing system comprising: a processor; a memory operatively connected to the processor; a non-transitory computer-readable medium operatively connected to the processor and the memory and storing computer-executable instructions, the computer-executable instructions, when executed by at least the processor, causing the computing system to perform the method of any one of claims 1 to 4.

Images