Custom validation for mobile application and system for script

Abstract

To provide a system and method for enabling client side implementation of a custom rule when a client is in an offline mode.SOLUTION: A method creates a custom rule on a mobile application client on a mobile application server, defines user account characteristics of the mobile application client. In response to establishment of connection between an instance of the mobile application client of a particular user account and a mobile application server, the instance of the mobile application client determines implementation of the custom rule at least partially based on a match between particular user account characteristics and defined characteristics, transmits the custom rule to the instance of the mobile application client, and allows the instance to implement the custom rule when the instance operates in an off-line mode.SELECTED DRAWING: Figure 3

Description

[Background technology]

[0001] background Business users are increasingly using mobile applications to perform daily work functions. For example, sales representatives making store visits can use their mobile devices to take orders or record other information, and technicians can use their mobile devices to perform service generalization tasks. Mobile application solution vendors may offer solutions to which customers would like to add customized functionality. However, customization of mobile application functionality has several limitations that limit the usefulness of such customizations. For example, changes to customizations may require a new build of the mobile application client software. Also, customized functionality may not function when the mobile client software is operating in offline mode.

[0002] What is needed are techniques to overcome these and other limitations on the availability of customization to mobile applications. Summary of the Invention

[0003] overview In one embodiment, a computer-implemented method for enabling client-side enforcement of custom rules includes creating a custom rule on a mobile application server for enforcement on a mobile application client, the mobile application client configured to enforce one or more custom rules when operating in an offline mode, the method further includes defining characteristics of a user account for which the mobile application client will enforce the custom rule, and in response to a connection being established between an instance of the mobile application client for a particular user account and the mobile application server, determining that the instance of the mobile application client should enforce the custom rule based at least in part on a match between characteristics of the particular user account and the defined characteristics, and sending the custom rule to the instance of the mobile application client to enable the instance to enforce the custom rule when the instance is operating in the offline mode.

[0004] In one embodiment, the computer-implemented method for enabling client-side enforcement of custom rules further includes formulating a query to retrieve supporting data queried during enforcement of the custom rules from a mobile application database; executing the query on the mobile application database to obtain the supporting data; sending the supporting data to the instance of the mobile application client to further enable the instance to enforce the custom rules when the instance is operating in an offline mode; in response to detecting a lack of network connectivity to the mobile application server, placing the instance of the mobile application client in the offline mode; and, while the instance of the mobile application client is operating in the offline mode, (i) accepting user input to the instance of the mobile application client that triggers enforcement of the custom rules; and (ii) loading a portion of the supporting data. and retrieving the custom rule from local storage and executing all functions of the custom rule locally by the instance of the mobile application client to enable the instance of the mobile application client to immediately implement the custom rule.

[0005] In one embodiment, a computer-implemented method for enabling client-side enforcement of custom rules further includes adding the custom rule to a database of rules associated with the mobile application server; incrementing a current version number of the database; in response to establishing a connection, comparing the current version number of the database with a version number of the database stored by the mobile application client to determine that the current version number exceeds the stored version number; and in response to determining that the current version number exceeds the stored version number, comparing the characteristic of the particular user account with the defined characteristic to find the match.

[0006] In one embodiment, a computer-implemented method for enabling client-side enforcement of custom rules, wherein the custom rules are scripts, and the mobile application client is configured to execute the scripts to enforce the custom rules without requiring modifications to a build of the mobile application client.

[0007] In one embodiment, in a computer-implemented method for enabling client-side enforcement of custom rules, the characteristics of the user account include one or more of: (i) a geographic region associated with the user account; and (ii) a user role associated with the user account.

[0008] In one embodiment, in a computer-implemented method for enabling client-side enforcement of custom rules, creating the custom rule further includes identifying an object of the mobile application client to which the custom rule applies, selecting an event for the object that triggers enforcement of the custom rule, and sending the selected event for the object and an identifier to the instance of the mobile application client to further enable the instance to enforce the custom rule when the instance is operating in an offline mode.

[0009] In one embodiment, in a computer-implemented method for enabling client-side implementation of custom rules, creating the custom rule further includes generating instructions to present a graphical user interface (GUI) for creating one or more custom rules, sending the instructions to a client computing device associated with an administrator account to cause the GUI to be displayed, and accepting user input received via the GUI to create the custom rule.

[0010] In one embodiment, in a computer-implemented method for enabling client-side enforcement of custom rules, a GUI presented by the instance of the mobile application client displays the results of the custom rule immediately upon receiving an input that triggers the custom rule.

[0011] In one embodiment, a computer-implemented system is provided to enable client-side enforcement of custom rules. In a method implemented by the data processor, the custom rule is one of (i) a validation rule and (ii) a business logic rule.

[0012] In one embodiment, a computing system comprises a processor, a memory operatively connected to the processor, and a non-transitory computer readable medium operatively connected to the processor and the memory and storing computer-executable instructions, which when executed at least by the processor, cause the computing system to create custom rules on a mobile application server for implementation on a mobile application client, the mobile application client configured to implement one or more custom rules when operating in an offline mode, and which when executed at least by the processor, cause the computing system to define characteristics of a user account for which the mobile application client will implement the custom rules, and in response to a connection being established between an instance of the mobile application client for a particular user account and the mobile application server, determine that the instance of the mobile application client should implement the custom rules based at least in part on a match between characteristics of the particular user account and the defined characteristics, and send the custom rules to the instance of the mobile application client to enable the instance to implement the custom rules when the instance is operating in the offline mode.

[0013] In one embodiment, the computing system further comprises instructions, the non-transitory computer readable medium which, when executed by at least the processor, causes the computing system to, in response to detecting a lack of network connectivity to the mobile application server, place the instance of the mobile application client in the offline mode, and while the instance of the mobile application client is operating in the offline mode, (i) accept user input to the instance of the mobile application client that triggers implementation of the custom rule, and (ii) retrieve a portion of the supporting data from local storage and cause all functions of the custom rule to be executed locally by the instance of the mobile application client to immediately implement the custom rule.

[0014] In one embodiment, the computing system further comprises instructions, the non-transitory computer readable medium which, when executed by at least the processor, causes the computing system to construct a query to retrieve supporting data from a mobile application database to be queried during implementation of the custom rule, execute the query on the mobile application database to obtain the supporting data, and transmit the supporting data to the instance of the mobile application client to further enable the instance to implement the custom rule when the instance is operating in an offline mode.

[0015] In one embodiment, the computing system includes a non-transitory computer readable medium that, when executed by at least the processor, causes the computing system to add the custom rule to a database of rules associated with the mobile application server, increment a current version number of the database, and, in response to establishing a connection, update the current version number of the database to a version number of the database stored by the mobile application client. and, in response to determining that the current version number exceeds the stored version number, causing a comparison of the characteristics of the particular user account with the defined characteristics to find the match.

[0016] 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 create custom rules on a mobile application server for implementation on a mobile application client, the mobile application client configured to implement one or more custom rules when operating in an offline mode, the computer-executable instructions further, when executed by at least the processor of the computer, cause the computer to define characteristics of a user account for which the mobile application client will implement the custom rules, and, in response to a connection being established between an instance of the mobile application client for a particular user account and the mobile application server, determine that the instance of the mobile application client should implement the custom rule based at least in part on a match between characteristics of the particular user account and the defined characteristics, and send the custom rule to the instance of the mobile application client to enable the instance to implement the custom rule when the instance is operating in the offline mode.

[0017] In one embodiment, the non-transitory computer readable medium further comprises instructions that, when executed by at least the processor, cause the computer to, in response to detecting a lack of network connectivity to the mobile application server, place the instance of the mobile application client in the offline mode, and while the instance of the mobile application client is operating in the offline mode, (i) accept user input to the instance of the mobile application client that triggers implementation of the custom rule, and (ii) cause all functions of the custom rule to be executed locally by the instance of the mobile application client to immediately implement the custom rule.

[0018] BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate various systems, methods, and other embodiments of the present disclosure. It will be understood that the illustrated element boundaries (e.g., boxes, groups of boxes, or other shapes) in the figures represent one embodiment of the boundaries. 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 description of the drawings]

[0019] [Figure 1] 1 illustrates one embodiment of an environment associated with implementing custom validation and business logic (custom rules) scripting for mobile application offline mode operation. [Diagram 2] 1 illustrates one embodiment of a mobile application runtime environment associated with implementing custom validation and business logic (custom rules) scripting. [Diagram 3]1 illustrates one embodiment of a methodology associated with implementing custom validation and business logic (custom rules) scripting. [Figure 4] FIG. 1 illustrates an example script authoring system associated with implementing custom validation and business logic (custom rules) scripting. [Diagram 5] 1 illustrates one embodiment of a methodology associated with implementing custom validation and business logic (custom rules) scripting in an "offline mode" operation of a mobile application client. [Figure 6] 1 illustrates one embodiment of a methodology associated with implementing custom validation and business logic (custom rules) scripting with supporting data in an "offline mode" operation of a mobile application client. [Figure 7] 1 illustrates a portion of a method that includes additional parallel method steps associated with providing data for supporting custom rules during offline operation. [Figure 8] 1 illustrates one embodiment of a method associated with implementing custom validation and business logic (custom rule) scripting, and in particular generating a selective update set of custom rules for sending to a mobile application client instance based on user account characteristics. [Figure 9] 1 illustrates one embodiment of a method associated with providing custom validation and business logic (custom rule) scripting, and in particular, associating mobile application objects and trigger events with custom rules. [Figure 10] 1 illustrates one embodiment of a method associated with providing custom validation and business logic (custom rule) scripting, and in particular, accepting user input to create custom rules. [Figure 11] 1 illustrates an example embodiment of a "Create Script" dialog for creating a new custom rule script using a script editor. [Figure 12] 1 illustrates an example embodiment of a mobile application script editor GUI. [Figure 13] 1 illustrates an example client GUI for a mobile application client instance associated with implementing custom validation and business logic (custom rules) scripting during offline mode operation. [Figure 14] 1 illustrates an example client GUI for a mobile application client instance associated with implementing custom validation and business logic (custom rules) scripting during offline mode operation. [Figure 15] 1 illustrates an example computing device configured and / or programmed with one or more of the example systems and methods described herein, and / or equivalents. [Figure 16] 1 illustrates an example mobile device configured and / or programmed with one or more of the example systems and methods described herein, and / or equivalents. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0020] Detailed Description Described herein is a system and method for custom validations and scripts for mobile applications that may be executed on the mobile application regardless of whether the mobile application is running in online or offline mode. Mobile application systems such as mobile apps include, but are not limited to, representational state transfer (REST) ​​data control, offline read and / or write, Oracle Mobile Application Framework (MAF) is a platform that provides a wide range of mobile applications, including features including scalability, login and security, application updates, application user interfaces and / or user experience patterns, in addition to the development of horizontal mobile applications ("generic" applications designed to be used by many different types of users and businesses) and vertical mobile applications ("vertical" applications built to deliver specific functionality and processes unique to a particular user or business). The IEEE 802.11a standard may be provided for both "purpose-built" applications.

[0021] Business entities may implement mobile applications to enhance business productivity. Mobile applications targeted at various business objectives, such as customer relationship management (CRM), may be offered by many vendors and include standard features that enable or enhance common tasks that support that objective, such as sales tools, communication tools, and customer interaction tools. However, business entities may wish to extend or modify mobile applications to address business situations specific to their organization, personnel, geography, customers, or other aspects. Thus, some mobile applications may be customized to include custom business logic and / or validations specific to the particular needs of the business enterprise implementing the mobile application. Custom business logic and custom validations may be collectively referred to herein as "custom rules." Mobile applications, such as those implemented on the Oracle® CX platform, may be customized to some extent, for example, by adding new standard and / or custom objects, customizing page layouts, configuring saved searches, and managing application settings, but these actions alone do not enable the ability to execute custom rules locally on the mobile device, especially when the mobile device is disconnected from the network.

[0022] In one particular example, field-level triggers for enforcing custom validation rules do not work for representational state transfer (REST) ​​transactions. As a result, transactions from mobile applications may not undergo required validation, leading to downstream impacts with inaccurate data.

[0023] Often, business users are working in areas with no or poor network connectivity, during which the mobile device will continue to operate in "offline mode". Under such circumstances, it is crucial that users can continue to work with their mobile apps and still have all custom business logic and validations operational and enforced. However, if the custom business logic and validations are implemented on the server side of the mobile application, loss of network connectivity may cut off the mobile client's access to these custom rules and also cut off access to data necessary to properly execute the custom rules. In offline mode, such mobile applications with server-side implementation of custom rules may delay custom validations or business logic until network connectivity is restored. This allows users to execute transactions with minimal validations native to (i.e., included in) the mobile application client, but the custom validations and custom business logic are not applied or enforced until such time that data is synchronized from the mobile application to the server.

[0024] For example, a salesperson may use a mobile application with the mobile application running in offline mode during the day. As the salesperson visits his / her stores, he / she sells various promotional items and / or enters orders. The salesperson then returns to the distribution center where the mobile application will synchronize over the local network. Only then will custom business logic and / or validations be performed. However, if a transaction performed in offline mode has a contractually binding effect (such as taking an order at a store), it is important that all validations are performed at the time such transaction is performed. In another example, where a transaction performed in offline mode includes a promotional discount (implemented by custom business logic), the discount should be reflected in the order total. By the time the sales rep gets back to the distribution center, it is too late to perform any custom business logic or implement custom validation.

[0025] To overcome these and other challenges, the systems and methods disclosed herein enable the creation of custom business logic and custom validations that can be immediately implemented on a mobile client when a transaction is performed, regardless of the state of network connectivity between the mobile client and a server. Specifically, the systems and methods described herein present (1) a simple way for a business entity to write custom business logic or validations and deploy the custom logic or validations in the business entity's mobile applications, and (2) a way to ensure that these custom validations and business logic work regardless of the state of network connectivity while the application is in use.

[0026] The systems and methods described herein allow business users to use mobile applications in offline or online modes with the same set of business logic and validations performed regardless of network connectivity. This allows users to use mobile applications in the most efficient manner. The systems and methods described herein also allow data validation at transaction execution time to ensure that the data meets any or all contractual requirements regardless of network connectivity state. The systems and methods described herein improve data validation in mobile applications. Validated data also ensures good quality data input into the system, which ensures better results in business intelligence and artificial intelligence systems that utilize the input data. The systems and methods described herein also allow custom business logic to run within mobile apps regardless of network connectivity. This allows mobile users to perform all aspects of their work from their mobile devices. The systems and methods described herein also allow instant validation instead of validation that occurs later in asynchronous mode. Instant validation provides users with a greatly improved user experience and usability of mobile applications.

[0027] -Example environment for custom rules for mobile apps- FIG. 1 illustrates an embodiment of an environment 100 associated with implementing custom validation and business logic (custom rule) scripting for mobile application offline mode operation. In one embodiment, a mobile application server system 105 is connected to one or more client computing devices 115 and one or more mobile devices 120 (including a first mobile device 123, a second mobile device 125, and an Nth mobile device 127) by a network 110. There may be many mobile devices 120 connected to the mobile application server system 105. In one embodiment, the number N of mobile devices 120 operating in the environment 100 may approximate the number of authorized users of the mobile application server system 105, since most users of a mobile application will have a dedicated mobile device 120. Each mobile device 120 is connected to the network by a wireless network connection 130, such as wi-fi or a cellular data network. In one embodiment, the mobile application server system 105 includes one or more data stores 135, a web interface server module 140, a mobile application module 145, and a custom rules scripting module 150, which in one embodiment are interconnected by a backend network 155. In one embodiment, each of the mobile devices 120 is configured with an instance of a mobile application client 170: a first mobile device 123 is configured with a mobile application client instance 1 173, a second mobile device 124 is configured with a mobile application client instance 1 174, and a third mobile device 126 is configured with a mobile application client instance 1 175. The second mobile device 125 is configured with mobile application client instance 2 175, and the Nth mobile device 127 is configured with mobile application client instance N 177. In practice, there may be a virtually unlimited number of client instances, limited only by the capacity of the server-side hardware to support the client demands. In one embodiment, the client computing device 115 is configured with an administration client instance 180.

[0028] In one embodiment, any or all of these components 135-165 are depicted as separate components of the mobile application server system 105, but may be realized by one or more different hardware systems and components. For example, the mobile application server system 105 may be hosted on a distributed computing system comprised of at least one, but possibly multiple "servers." A server is a physical computer dedicated to providing data storage and execution environments for one or more software applications or services intended to serve the needs of users of other computers in data communication with the server over a public network, such as the Internet, or a private "intranet" network. Servers, and the services they provide, may be referred to as "hosts," and the remote computers they service, and the software applications running on the remote computers, may be referred to as "clients." Depending on the computing services they provide, the servers may be referred to as application servers, database servers, data storage servers, file servers, mail servers, print servers, web servers, or other service descriptive names.

[0029] In one embodiment, the mobile application server system 105 may be implemented using cloud-based infrastructure components to provide the functionality described for the components of the mobile application server system 105 (or other functionality disclosed herein). In one exemplary configuration, the mobile application server system 105 is operated by a third party for the benefit of multiple account holders / tenants in a multi-tenant architecture. In one embodiment, the mobile application server system 105 is part of a cloud-based CRM system, such as Oracle® Customer Experience Cloud (Oracle® CX Cloud), which provides a suite of cloud-based tools (or mobile applications) for customer relationship management, sales, marketing, customer service, e-commerce, price quoting, and other tools.

[0030] In one embodiment, the mobile application module 145 is an application server configured with sub-modules to perform back-end operations of mobile applications for CRM, enterprise resource planning (ERP), or other business functions. In one embodiment, the CRM module may include, but is not limited to, a sales force automation (SFA) module, a marketing automation module, a contact list module, a call center support module, a web-based customer support module, a reporting and analytics module, a contact management module, a return management authorization (RMA) module, and a loyalty program module, as well as other CRM-related modules. In one embodiment, the ERP module may include, but is not limited to, a finance and accounting module, an order processing module, a time and billing module, an inventory management and delivery module, an employee management and payroll module, a calendaring and collaboration module, a reporting and analytics module, a retail point of sale (POS) module, a product information management (PIM) module, a demand / materials requirements planning (MRP) module, a purchasing module, and other ERP-related modules. In one embodiment, the mobile application module 145 may also include other modules, for example, a content management system (CMS) and a human resource management module. Additionally, the mobile application server system 105 may further include a user management module for managing mobile application client access or other access to the mobile application server system 105 by tenants and users. In many cases, it will be desirable for modules of the mobile application server system 105 to share methods, procedures, libraries, databases, subroutines, variables, and / or other callable units or software components.

[0031] In one embodiment, the data store 135 is configured to provide a repository for persistently storing and managing collections of data generated and / or used by the mobile application server system 105. In one embodiment, the data store 135 is operated by a database server, a data storage server, or a file server. In one embodiment, the data store 135 may be implemented using a network attached storage (NAS) device or other dedicated server device. The data store may be implemented using any suitable data storage technology, including a structured query language (SQL) based relational database management system (RDBMS). In one embodiment, the data store 135 may include a separate dedicated data store for administration of the mobile application server system 105 and a separate dedicated data store for the operation of the mobile application module 145 and the custom rule scripting module 150. In a multi-tenant embodiment of the mobile application server system 105, each tenant may have its own separate dedicated data store for the operation of the mobile application module 145 and the custom rule scripting module 150 that is not shared with other tenants.

[0032] In one embodiment, web interface server 140 is configured to enable remote clients (such as mobile application client 170 instances 173, 175, 177 or administration client instance 180) to access resources and / or services provided by mobile application server system 105 through network 110. In one embodiment, network 110 is the Internet. In one embodiment, network 110 is a private network. In one embodiment, web interface server 140 is configured to include a REST data provider, an XML data provider, or other data provider.

[0033] In one embodiment, the custom rules scripting module 150 is configured for the creation and implementation of custom rules, such as custom data validation and custom business logic, to extend the functionality of mobile applications implemented by the mobile application server system 105 and the mobile application client 170.

[0034] - Example client-side script execution - runtime - In one embodiment, the mobile application client 170 is a client application for accessing and manipulating data stored in the data store 135 in association with the functionality provided by the mobile application modules 145. For example, the mobile application client 170 may be a client application for an enterprise sales and service tool that hosts data on the data store 135. In one embodiment, the mobile application client 170 is an Oracle® CX mobile client and the mobile application server system hosts the Oracle® CX cloud service. The client application The applications may be downloaded from a third party distributor of mobile applications, such as the Google® Play Store or the Apple® Store, or from a system associated with the operator of the mobile application server system 105. The mobile application client 170 may then be used, for example, by sales or service staff to browse sales opportunities or service requests in the data store 135, create new sales opportunities in the tool, submit service requests in the tool, look up contact information related to the sales opportunity or service request, enter purchase orders, or perform other actions that create, read, update, or delete information.

[0035] 2 illustrates one embodiment of a mobile application runtime environment 200 associated with implementing custom validation and business logic (custom rule) scripting. The environment 200 includes a server-side 205 component and a client-side 210 component.

[0036] On the server side 205, in one embodiment, a mobile application server instance 215 is deployed on the mobile application server system 105. The mobile application server instance 215 includes a mobile application composer 220, a mobile repository 225, and a configuration service 230.

[0037] In one embodiment, the custom rules are one or more of validation rules and business logic rules. In one embodiment, the custom rules are scripts (e.g., written in JavaScript) configured in the mobile application composer 220 for execution by the mobile application server system 105 and / or the mobile application client 170. The mobile application composer 220 may be implemented in whole or in part by the custom rule scripting module 150 and in part by the mobile application module 145. The mobile application composer 220 includes a rule editor or script editor (e.g., as described in detail herein with reference to Figures H, I, and L). Scripts written in the mobile application composer 220 are stored in the mobile repository 225. In one embodiment, the mobile repository 225 may be a database or other data structure hosted by the data store 135. The mobile application composer 220 also maintains one or more sandbox environments for custom rule development and testing. The scripts of the custom rules created by the mobile application composer 220 are maintained in the sandbox environment until the custom rules are promoted from the sandbox environment to the production environment. In one embodiment, following promotion to production, the custom rules are retrieved from the mobile repository 225 and provided to the composition service 230.

[0038] Thus, a script for a custom rule is initially authored in the mobile application composer 220 and stored in the mobile repository 225. The script can be modified one or more times by retrieving the script from the mobile repository 225, editing it within the mobile application composer 220, and storing the modified script back in the mobile repository 225. If the script satisfactorily describes the behavior of the custom rule, the script author or other user can commit the script to production and use by the configuration service 230. The configuration service 230 is then configured to send the script to the appropriate mobile client.

[0039] In one embodiment, the configuration service 230 executes the script in the mobile application runtime 240 environment of the mobile application client instance 170. The configuration manager 235 parses the scripts received from the configuration service 230 (and other messages received from the application server 105) responses and directs the information extracted by the parsing to a destination within the mobile application runtime 240 environment. The configuration manager 235 saves or persists the scripts in the file system 245, sends the scripts to the scripting engine 250, and / or sends the scripts to the view controller 255.

[0040] In one embodiment, the mobile application client 170 requests the performance of a data operation on the mobile application server 105 by generating an Application Programming Interface (API) request to one or more data providers (such as a REST data provider or an XML data provider) of the web interface server 140 in conjunction with the configuration manager 235 or other network interface module. In one embodiment, the request is a remote data request exchanged between the mobile application client 170 and the web interface server 140 using JavaScript Object Notation (JSON) as the data exchange format. The requests are representational state transfer (REST) ​​requests. In one embodiment, the requests are SOAP requests exchanged between the mobile application client 170 and the web interface server 140 using XML.

[0041] In one embodiment, the scripting engine 250 is a script execution engine or execution environment designed to execute scripted instructions that describe the behavior of custom rules locally on the mobile device 120. In one embodiment, the scripting engine 250 is configured to execute one or more scripts associated with one or more selected objects of the mobile application in response to the occurrence of a trigger event (or scripting event) associated with the script that indicates that the script should be executed. Scripting events that may be used as trigger events for custom rules are listed and described in Table 1 below:

[0042] [Table 1]

[0043] The trigger event may be detected by analyzing the operation of the mobile application executed by the data control module 260. The custom rule execution engine 250 then executes the script to implement the custom rule in conjunction with the operation executed by the data control module 260.

[0044] The custom rule execution engine 250 may be, for example, a Nashorn (http: / / openjdk.java.net / projects / nashorn / ) specially configured in accordance with the systems and methods described herein. The implementation may include a JavaScript execution engine such as Nashorn (available at http: / / openjdk.java.net / projects / graal / ), GraalJS (available at http: / / openjdk.java.net / projects / graal / ), or JSCore (available at jscore.sourceforge.net / ). Note that Nashorn may be preferred over GraalJS due to its significantly lower library size (2MB and 18MB, respectively). Additionally, Nashorn may be preferred over JSCore because JSCore may not be suitable for standalone operation outside the context of a web page view. Note that the GraalJS engine provides time boxing and memory boxing capabilities that are not necessarily provided by the Nashorn engine. Both Graal JS and Nashorn provide access to the Java Application Programming Interface (API). In another embodiment, the custom rule execution engine 215 may include an expression language execution engine. In another embodiment, the custom rule execution engine 215 includes an Apache Groovy execution engine. Good too.

[0045] Note that the scripting engine 250 may also execute certain system “helper” functions or JavaScript wrapper APIs that allow scripts to be executed to interact with data objects in the mobile application runtime 240. The wrapper APIs and system functions are listed in Table 2 below:

[0046] [Table 2]

[0047] The mobile application runtime includes a data control module 260. In one embodiment, the data control module 260 includes logic for executing uncustomized functionality of the mobile application client 170. In one embodiment, the data control module includes a baseline set of actions and objects that may be further extended or modified by execution of custom rules by the scripting engine 250. Exemplary custom rules that may be implemented on the client side include: (1) conditionally making a field mandatory and / or conditionally making it read-only; (2) conditionally showing and / or hiding a field on a graphical user interface layout; (3) performing field validation actions, such as checking that some upcoming date is greater than "today", that Revenue = Quantity * Amount - Discount, or that the revenue amount is greater than a value specified in logic; and (4) conditionally enabling and / or disabling a button (e.g., a "Save" button) based on one or more values ​​entered into the field or based on validation actions performed on the field. (5) automatically populating fields based on formulas expressed in script; (6) pre-populating one or more fields on create page by first querying the object and assigning the returned value to the field, e.g., pre-populating the country based on the country on the account when creating an opportunity from the account; (7) disabling server-side scripting for transactions running on a mobile application client.

[0048] In one embodiment, the local data store 265 may be included in the mass data storage 1670 or memory 1680 of the mobile device 1600 (as shown and described with reference to FIG. 16 ). The mobile application client 170 may store data from the mobile application server system 105 (e.g., retrieved from the data store 135) in the local data storage 265. The data in the local data storage 265 may be manipulated by a user of the mobile application client 170 through a view controller 255. In one embodiment, the view controller 255 controls the presentation of a graphical user interface (GUI) for the mobile client application 170, for example, using a display 1650 and input devices 1660 (as shown and described with reference to FIG. 16 ).

[0049] In one embodiment, the mobile application client 170 is configured to perform offline operation and delayed synchronization when connectivity between the mobile application client 170 and the mobile application server system 105 is limited or non-existent. Such operation may be referred to as an "offline mode." In the offline mode, the data in the local data storage 265 may include a local cache of data from the mobile application server system 105 while connectivity between the mobile application client 170 and the mobile application server system 105 is limited or non-existent. The data in the local cache may be manipulated by a user of the mobile application client through the view controller 255 while the mobile application client 170 is in the offline mode, and modifications to the data are later synchronized with the server side when connectivity is restored.

[0050] -Example of how to do custom rule scripting- In one embodiment, each step of the computer-implemented methods described herein may be performed by a processor of one or more computing devices (such as processor 1510 as shown and described with reference to FIG. 15) (i) accessing a memory (such as memory 1515 and / or other computing device components as shown and described with reference to FIG. 15), the processor (ii) configured with logic that causes the system to perform the steps of the method (such as custom rule scripting logic 1530 as shown and described with reference to FIG. 15). For example, the processor accesses, reads from, or writes to the memory to perform the steps of the computer-implemented methods 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 or storage / disk of a computing device (such as memory 1515 of computing device 1505, or storage / disk 1535, or remote computer 1565, as shown and described with reference to FIG. 15).

[0051] In one embodiment, each subsequent step of the method is initiated in response to analyzing a received signal or retrieved stored data indicating that the previous step has been performed at least to the extent necessary for the subsequent step to begin. Generally, the received signal or retrieved stored data indicates completion of the previous step.

[0052] FIG. 3 illustrates one embodiment of a method 300 associated with implementing custom validation and business logic (custom rule) scripting. In one embodiment, the method 300 is a computer-implemented method for enabling offline client-side enforcement of custom rules in an offline mode of operation. In one embodiment, the steps of the method 300 are performed by a mobile application server instance 215 (shown and described with reference to FIG. 2 and other figures herein). In one embodiment, the mobile application server instance 215 is implemented by a mobile application server system 105. In one embodiment, the mobile application server system 105 is a dedicated computing device or collection of dedicated computing devices (e.g., computing device 1505) configured with custom rule scripting logic 1530.

[0053] Method 300 may be initiated based on various triggers, such as receiving a signal over the network or analyzing stored data indicating that (i) a user (or administrator) of mobile application server system 105 has initiated method 300, (ii) method 300 has been scheduled to begin at a defined time or time interval, (iii) a mobile application client instance 170 has initiated contact with mobile application server instance 215 and / or mobile application server system 105, or (iv) a mobile application client instance has resumed network connectivity with mobile application server instance 215 and / or mobile application server system 105 after operating in offline mode. Method 300 begins at START block 305 in response to analyzing the received signal or retrieved stored data and determining that the signal or stored data indicates that method 300 should be initiated. Processing proceeds to processing block 310.

[0054] At processing block 310, a processor creates custom rules on the mobile application server for enforcement on the mobile application client.

[0055] In one embodiment, the mobile application client is configured to implement one or more custom rules when operating in an offline mode. For example, the mobile application client may be configured with a scripting engine 250 as shown and described with reference to FIG. 2. The custom rules are configured to be executed by the scripting engine 250. In one embodiment, the processor accepts a set of user inputs describing the operation of the custom rules. The processor stores the set of user inputs in a data structure in the data store 135, for example, in the mobile repository 225. The processor accepts user inputs indicating that the custom rules are satisfactory, such as user inputs indicating that the custom rules should be moved from the sandbox environment to a production environment that configures the mobile client to implement the custom rules. The processor then marks the custom rules in the mobile repository 225 for use in the production environment, thereby creating the custom rules for implementation on the mobile application client.

[0056] In one embodiment, the custom rules are scripts and the mobile application client is configured to execute the scripts (using the scripting engine 250) to implement the custom rules without requiring modifications to the mobile application client build. For example, user input may be a JavaScript script, etc. Contains interpreted programming language scripts.

[0057] 4 illustrates an exemplary script authoring system 400 associated with implementing custom validation and business logic (custom rule) scripting. In one embodiment, the script authoring system 400 is implemented by the mobile application server system 105. As described above, the mobile application server system 105 includes the application composer 220, which includes the rule / script editor 405. In one embodiment, a processor (and other hardware) of the mobile application server 105 executes the rule / script editor 405 to accept inputs that create or modify the script. The resulting script 410 is sent to the data store 135 where it is stored, for example, as part of the mobile repository 225.

[0058] Referring again to FIG. 3, once the processor has thus completed creating the custom rules on the mobile application server for execution on the mobile application client, processing at processing block 310 is complete and processing continues at processing block 315.

[0059] At processing block 315, the processor defines characteristics of the user account for which the mobile application client will enforce the custom rule. In one embodiment, the processor accepts one or more user inputs describing characteristics of the account for which the custom rule is applicable and stores the user inputs in association with the custom rule in a database, for example, in the mobile repository 225. In one embodiment, the characteristics include one or more of: (i) a location, such as a region, country, province or state, city, etc., for which the custom rule is associated with a transaction; and (ii) a business role (e.g., sales representative, business practice supervisor, route operations manager, etc.) for which the user is to be executed and for which the custom rule is associated with a job function or authority. In one embodiment, a default value for the location is "global," indicating applicability to all locations, and the value may be changed to a more specific location in response to user input. For example, the processor may cause a graphical user interface to display a list (e.g., a searchable list) of all available areas that may be assigned to the custom rule and accept a selection of an area. In one embodiment, a default value for the business role is "all personnel," indicating applicability to all users of the system, and the value may be changed to a more specific group of user roles in response to user input. For example, the processor causes a graphical user interface to display a selectable list (which may also be searchable) of all available user roles (i.e., job titles or responsibilities) that can be assigned to the custom rule. The processor parses and records any selections that change the default values. The processor associates the locations and business roles to which the custom rule pertains with the custom rule and records them in the mobile repository 225, e.g., in a common data structure.

[0060] 4, the scripts 410 are associated in the database with a property namespace. For example, some of the scripts 410 are associated with a "domain" namespace 415, while others are associated with a "role" namespace 420. Each script 410 within a namespace 415, 420 is uniquely identified within that namespace. Thus, in one embodiment, the namespace may be striped by domain or other criteria.

[0061] Referring again to FIG. 3, the processor thus completes defining the characteristics of the user account for which the mobile application client will enforce the custom rules. If so, processing at process block 315 is complete and processing proceeds to decision block 320.

[0062] At decision block 320, the processor determines whether a network connection has been established between instances of mobile application clients associated with a particular user. The processor monitors incoming requests (e.g., REST requests) to the web interface server 140 and the configuration service 230 for connections with the mobile application client instances. The processor parses the requests to identify their source and the particular user account with which they are associated. If the processor determines that a network connection has not been established between instances of mobile application clients associated with a particular user (decision block 320: NO), the processor continues to monitor incoming connections, waiting for the establishment of such a connection. In one embodiment, the processor specifically monitors login requests from mobile application clients associated with a particular user account. The association can be based on login credentials provided, where the user account is identified based on one or more of a username and a password. If the processor determines that a network connection has been established between instances of mobile application clients associated with a particular user (decision block 320: YES), processing at decision block 320 is complete and processing continues to processing block 325.

[0063] At processing block 325, the processor determines that the instance of the mobile application client should implement the custom rule based at least in part on a match between the characteristics of the particular user account and the defined characteristics. The processor retrieves records of locations and business roles to which the custom rule is associated from the mobile repository 225. The processor parses the records to identify the locations and business roles to which the custom rule is associated. For example, the processor may extract data indicating that the custom rule should be applied for user accounts associated with sales representatives in California. The processor retrieves records describing the characteristics of the account, such as the user's human resources (HR) records associated with the particular user account. The processor parses the HR (or other account-specific) records to identify the locations and / or business roles assigned to the particular user. For example, the processor may identify that the particular user is a sales representative whose territory is in California. If there is a match between the locations and / or assigned business roles between the records describing the relevance of the custom rule and the characteristics of the particular user account, the processor determines that the instance of the mobile application client should implement the custom rule due to the match. If there is no match in location and / or assigned business roles between the record describing the relevance of the custom rule and the characteristics of the particular user account, the processor determines that the instance of the mobile application client should not implement the custom rule due to the match, although the process may terminate early under this condition.

[0064] Thus, in one embodiment, the characteristics of a user account include one or more of: (i) a geographic region associated with the user account; and (ii) a user role associated with the user account.

[0065] Thus, once the processor has determined that an instance of a mobile application client should implement a custom rule based at least in part on a match between the characteristics of a particular user account and the defined characteristics, processing at processing block 325 is complete and processing continues to processing block 330.

[0066] At process block 330, an instance of the mobile application client is In response to determining that the mobile application client instance should implement the custom rule, the processor sends the custom rule to the mobile application client instance to enable the mobile application client instance to implement the custom rule when the mobile application client instance is operating in offline mode. In one embodiment, the processor retrieves the custom rule from storage in the mobile repository 225. The processor generates a REST request that includes the custom rule as a payload and instructs the mobile application client instance to apply the custom rule to data operations performed locally by the mobile application client instance. The processor sends the REST request from the configuration service 230 (in the mobile application server system 105) to the configuration manager 235 (in the mobile application instance 170) over the network 110 to enable the instance to implement the custom rule when the instance is operating in offline mode.

[0067] In one embodiment, the processor generates a catalog including modified and / or new scripts based on the current update status of the mobile application instance 170. The processor transmits the catalog to the mobile application client instance 170 over the network 110 using Oracle's Content Repository Rest Service, as shown at 425. In response to receiving the custom rules, the mobile application client instance 170 on the mobile device 120 updates the application catalog 430 to a current state, e.g., as a data structure in the file system 245 and / or local data store 265, based on the newly received custom rules (in the catalog download 425). From the updated application catalog 430, in response to the update, the mobile application client instance 170 generates a current active application version 435 executed by the mobile device 120.

[0068] Once the processor has completed sending the custom rules to the instances of the mobile application client in this manner, processing at process block 330 is complete and processing proceeds to END block 335 where process 300 ends.

[0069] - Example of how to operate in offline mode - FIG. 5 illustrates one embodiment of a method 500 associated with implementing custom validation and business logic (custom rule) scripting in an “offline mode” of operation of a mobile application client. In one embodiment, the method 500 is a computer-implemented method for enabling client-side enforcement of custom rules offline in an offline mode of operation. In one embodiment, the steps of the method 500 are performed by a mobile application client instance 170 (shown and described with reference to FIG. 1 and other figures herein). In one embodiment, the mobile application client instance 170 is implemented by a mobile device 120. In one embodiment, the mobile device 120 is a dedicated mobile device (such as the mobile device 1600 shown and described with reference to FIG. 16) configured with custom rule scripting logic 1605. References in the method 500 to a processor may include signal processing and control circuitry 1620.

[0070] The method 500 includes determining whether (i) a mobile application client instance 170 is started or launched on the mobile device 120, (ii) the mobile device 120 has or does not have network connectivity with the mobile application server system 105, (iii) the mobile application client instance 170 is connected to the mobile application server instance 215 and / or the mobile application server system 105, and (iv) the mobile application client instance 170 is connected to the mobile application server instance 215 and / or the mobile application server system 105. The method 500 may be initiated based on various triggers, such as (iv) receiving a communication (e.g., a REST request) from the mobile application server system 105, or (v) receiving a signal over the network or parsing stored data indicating that the mobile application client instance 170 has resumed a network connection with the mobile application server instance 215 and / or the mobile application server system 105 after operating in offline mode. In one embodiment, the method 500 begins in response to the completion of method 300. The method 500 begins at START block 505 in response to parsing the received signal or retrieved stored data and determining that the signal or stored data indicates that the method 500 should be initiated. Processing proceeds to process block 510.

[0071] At processing block 510, the processor monitors network connectivity between the mobile application client instance and the mobile application server instance. In one embodiment, the processor monitors the network connectivity to determine whether the connectivity should be classified as a status of "unavailable" or "offline" or otherwise indicates that there is a lack of connectivity. In one embodiment, the processor of the mobile device 120 detects whether the web interface server 140 is unavailable. For example, the processor may test send to an Internet Protocol (IP) address of the web interface server 140 for a response to determine the network latency between the mobile device 120 and the web interface server 140. The processor then compares the detected network latency to a threshold that indicates that the network connection between the mobile device 120 and the web interface server 140 is slow, bad, or otherwise limited. In another example, the processor may detect that the network is disconnected between the mobile device 120 and the web interface server 140 by test sending to an IP address of the web interface server 140 for a response and determining that no response is received from the server. In another example, the processor may detect low or no availability of the first remote service provider by receiving a message from the first remote service provider and analyzing it as offline or busy. In another example, the processor may access device status information of the mobile device 120 indicating whether there is access to a suitable WI-FI (IEEE 802.11x) signal or a suitable cellular signal to support operation. The monitored data indicating the status of network connectivity is stored, for example, in the local data store 265 or the file system 245, for later processing.Once the processor has completed this monitoring of network connectivity between the mobile application client instance and the mobile application server instance, processing at process block 510 is complete and processing continues to decision block 515 .

[0072] At decision block 515, the processor detects whether there is a lack of network connectivity to the mobile application server. In one embodiment, the monitored data is retrieved from storage and evaluated to determine the state of the connectivity. For example, the monitored data may be compared to a threshold or device status information may be examined to determine whether sufficient network connectivity to the mobile application server exists. If there is no lack of connectivity (processing block 515: NO), processing at decision block 515 ends and processing proceeds to decision block 520. If there is a lack of connectivity (processing block 515: YES), processing at decision block 515 ends and processing proceeds to decision block 525.

[0073] At processing block 525, the processor The processor places the mobile application client instance 170 in offline mode 530. In one embodiment, the processor configures the mobile application client instance 170 to stop attempting to access and manipulate data hosted on the mobile application server system 105. The processor then configures the mobile application client instance 170 to begin accessing and manipulating a local copy of the data locally within the mobile application runtime 240. The processor also configures the mobile application client instance 170 to begin persisting a sequence of changes to the data locally on the mobile device 120 for later synchronization with the server-side data store 135 when the offline mode 530 is exited and interaction with the mobile application server system 105 resumes. This may be referred to as “offline writes” or “deferred write access.” The processor further configures the mobile application client instance 170 to apply the local copy of custom rules to the behavior of the application client instance 170 executed by the mobile device 120 according to the active application version 435. Once the processor has thus completed placing the instance of the mobile application client in offline mode 530, processing at processing block 525 is complete and processing continues to processing block 535.

[0074] Following processing block 525, the mobile application client instance 170 is operating in an offline mode 530. At processing block 535, while the mobile application client instance is operating in the offline mode 530, the processor accepts user input to the instance of the mobile application client that triggers the execution of a custom rule. In one embodiment, the processor analyzes the user input to determine what object was created or modified by the user input and what triggering scripting events (OnCreate, OnFieldValueChange, BeforeSave, and / or AfterSave) occurred due to the action. Based on the trigger event that occurred, the processor searches the custom rules to determine whether there is a custom rule associated with the trigger event for any of the objects created or modified by the user input. The processor identifies whether there is a custom rule script to be executed by the scripting engine. If the search does not return any results, the custom rule script is not executed. If the search returns results that identify one or more custom rule scripts associated with the created / modified object, the corresponding custom rule script will be executed against the associated object. Once the processor has thus completed receiving user input into the instance of the mobile application client that triggers the implementation of the custom rule, processing at process block 535 is complete and processing continues to process block 540.

[0075] At processing block 540, the processor executes all functions of the custom rule locally with the instance of the mobile application client to immediately enforce the custom rule. In one embodiment, the processor retrieves one or more custom rule scripts to be executed from the local data store 265 or the file system 245. (In one embodiment, the custom rule scripts are retrieved from the application catalog 430). The processor then executes the scripting engine 250 to execute the sequenced steps described by each custom rule script. The execution of the scripting engine 250 occurs within the mobile application runtime 240 on the client-side mobile device, eliminating the need for any server-side action to give the custom rule an immediate effect. Note that "immediate" execution of a rule may mean instantaneous execution, but does not necessarily mean so. Rather, Here, the immediate enforcement or effect of custom rules exhibits the inverse of the delay with respect to subsequent synchronization caused by lack of network connectivity to the server-side processing system. The systems and methods herein generally exhibit reasonably real-time performance without excessive delays due to local processing.

[0076] In one embodiment, the GUI presented by an instance of the mobile application client 170 displays the results of a custom rule immediately after receiving the input that triggers the custom rule.

[0077] Thus, once the processor has completed executing all functions of the custom rule locally with the instance of the mobile application client such that the custom rule is immediately implemented, processing at process block 540 is complete and processing continues to decision block 545.

[0078] At decision block 545, the processor retrieves data from the ongoing monitoring process described at process block 510. The processor analyzes the retrieved data to determine whether network connectivity has been restored. If network connectivity has not been restored (decision block 545: NO), processing at decision block 545 is complete and processing remains in offline mode 530 and returns to process block 535 to await subsequent user input. If network connectivity has been restored (decision block 545: YES), processing at decision block 545 is complete and processing proceeds to process block 550.

[0079] At processing block 550, the processor places the instance of the mobile application client 170 in online mode. In one embodiment, the processor then configures the mobile application client instance 170 to stop accessing and manipulating the local copy of the data locally within the mobile application runtime 240. The processor also configures the mobile application client instance 170 to stop persisting new changes for later synchronization. The processor then configures the mobile application client instance 170 to start or resume accessing and manipulating the data hosted on the mobile application server system 105. The processor further configures the mobile application client instance 170 to apply a server-side copy of the custom rules to the operation of the client instance 170 to ensure that the latest version of the custom rules is applied. Once the processor has completed placing the instance of the mobile application client back in online mode in this manner, processing at processing block 550 is complete and processing continues to processing block 555.

[0080] At processing block 555, the processor synchronizes transactions between the mobile application client instance and the mobile application server. In one embodiment, the processor retrieves the sequence of persisted changes to the data from the local data store 265. The processor then transmits the sequence of persisted changes to the data over the network 110 to the web interface server 140 for synchronization with the server-side data store 135. Once the processor has thus completed synchronizing the transactions between the mobile application client instance and the mobile application server, processing at processing block 555 is complete and processing returns to decision block 520.

[0081] At decision block 520, the processor determines whether the mobile application client instance has shut down or is shutting down (or is otherwise terminating). If so (decision block 520: YES), the process proceeds to END block 560 and method 500 ends. If not (decision block 520: NO), the process returns to process block 510 and method 500 resumes monitoring network connectivity.

[0082] -Provide supporting data for client instances- 6 illustrates one embodiment of a method 600 associated with implementing custom validation and business logic (custom rule) scripting with supporting data in an "offline mode" operation of a mobile application client. In one embodiment, the steps of method 600 are performed by a mobile application server instance 215, and more particularly, by configuration service 230 and mobile repository 225 (shown and described with reference to FIG. 2 and other figures herein). In one embodiment, the mobile application server instance 215 is implemented by a mobile application server system 105. In one embodiment, the mobile application server system 105 is a dedicated computing device or collection of dedicated computing devices (e.g., computing device 1505) configured with custom rule scripting logic 1530.

[0083] Method 600 may be initiated based on various triggers, such as, for example, receiving a signal over the network or analyzing stored data indicating that (i) a mobile application client instance 170 has initiated contact with a mobile application server instance 215 and / or mobile application server system 105, or (ii) a mobile application client instance has resumed a network connection with a mobile application server instance 215 and / or mobile application server system 105 after operating in an offline mode. Method 600 begins at START block 605 in response to analyzing the received signal or retrieved stored data and determining that the signal or stored data indicates that method 600 should be initiated. Processing proceeds to process block 610.

[0084] At processing block 610, the processor constructs queries to retrieve supporting data queried during execution of the custom rule from the mobile application database. In one embodiment, the processor parses the custom rule to determine what data sets the custom rule may query. For example, the processor may identify data sets accessed for each query executed by the custom rule. The processor will then generate one or more queries to retrieve those data sets. Thus, once the processor has completed creating queries to retrieve supporting data queried during execution of the custom rule from the mobile application database, processing at processing block 610 is complete and processing continues at processing block 615.

[0085] At processing block 615, the processor executes queries on the mobile application database to obtain supporting data. The processor populates one or more data structures with the retrieved data set and stores the data set for later transmission, for example, in data store 135. Once the processor has completed executing queries on the mobile application database to obtain supporting data in this manner, processing at processing block 615 is complete and processing proceeds to processing block 620.

[0086] At processing block 620, the processor transmits supporting data to the mobile application. The processor retrieves the data set from storage in the data store 135. The processor constructs a message, such as a REST request or catalog download, that includes the data set. The processor then transmits the data set constituting supporting data for operation of the custom rule to the mobile application client instance 170 to support offline operation of the custom rule. Once the processor has completed sending the supporting data to the mobile application client instance in this manner to further enable the mobile application client instance to implement the custom rule when the mobile application client instance is operating in offline mode, processing at processing block 620 is complete and processing proceeds to END block 625 where process 600 ends.

[0087] Thus, for example, if a custom rule requires a credit check for a particular purchase, the processor may parse the custom rule to determine that execution of the custom rule may cause a query to retrieve the credit ratings for the customer. The processor then creates and executes a query to retrieve a data set of all credit ratings for the customer from the data store 135 and transmits it to the client side.

[0088] FIG. 7 illustrates a portion 700 of method 500 including additional parallel method steps associated with providing supporting data for a custom rule during offline operation 530. In one embodiment, the additional steps of method 500 are performed by mobile application client instance 170 (shown and described with reference to FIG. 1 and other figures herein), for example, by mobile device 120 as mobile device 1600 as described above. In FIG. 7, process steps 525, 535, 540 (not shown in FIG. 7), and 545 perform substantially as shown and described with reference to FIG. 5 above. Additionally, once the processor has thus completed receiving user input to the instance of the mobile application client that triggers the implementation of the custom rule, processing at processing block 535 is complete and processing continues to processing block 705 in parallel with processing block 540. In processing block 705, the processor retrieves a portion of the supporting data from local storage to enable the instance of the mobile application client to immediately implement the custom rule. In one embodiment, in the course of locally executing the functionality of a custom rule, the processor executes the queries described by the custom rule script against the supporting data, and the results of the queries are returned to the scripting engine 250 within the mobile application runtime 240 for use in executing the custom rule.

[0089] -Example of updating client-side custom rules- 8 illustrates one embodiment of a method 800 associated with implementing custom validation and business logic (custom rule) scripting, and in particular generating a selective updated set of custom rules for sending to a mobile application client instance 170 based on user account characteristics. In one embodiment, the steps of the method 300 are performed by a mobile application server instance 215, and more particularly, a configuration service 230 and a mobile repository 225 (shown and described with reference to FIG. 2 and other figures herein). In one embodiment, the mobile application server instance 215 is implemented by a mobile application server system 105. In one embodiment, the mobile application server system 105 is a dedicated computing device or collection of dedicated computing devices (such as computing device 1505) configured with custom rule scripting logic 1530.

[0090] Method 800 may be initiated based on a variety of triggers, such as (i) receiving a signal over a network or analyzing stored data indicating, for example, that one or more new custom rules have been created by the completion of process 300; or (ii) receiving one or more custom rules uploaded to mobile application server system 105. In one embodiment, method 800 begins in response to the completion of method 300. Method 800 begins 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 proceeds to process block 810.

[0091] At processing block 810, the processor adds the custom rule to a database of rules associated with the mobile application server. In one embodiment, the processor creates a new entry in the database and writes scripts into fields of the new entry that define the custom rule, any locations to which the custom rule is specifically applicable, and any user roles to which the custom rule is specifically applicable. In one embodiment, this server-side database of rules is a complete list of all custom rules available in the mobile application system. Once the processor has completed adding the custom rule to the database of rules associated with the mobile application server in this manner, processing at processing block 810 is complete and processing proceeds to processing block 815.

[0092] At processing block 815, the processor increments the current version number of the database. In one embodiment, metadata of the database of rules indicates the version of the database. In one embodiment, the processor increments the version number in the metadata in response to each edit to a pre-existing rule or the addition of a newly created rule. Once the processor has completed incrementing the current version number of the database in this manner, processing of processing block 815 is complete and processing proceeds to processing block 820.

[0093] In processing block 820, in response to establishing the connection, the processor compares the current version number of the database with the version number of the database stored by the mobile application client and determines that the current version number exceeds the stored version number. The stored version number indicates the version of the server-side database last accessed by the mobile application client. The current version number of the database indicates the database most recently modified. Note that in practice, the current version number should never be less than the stored version number because the stored version number should only be updated to be equal to the current version number. Only the current version number (for the server-side database of custom rules) is always positively incremented by changes to the contents of the database. In one embodiment, the processor retrieves the current version number from the metadata of the server-side rules database. The processor parses a REST request (e.g., a request to login) from the mobile application client instance 170 to extract the stored version number. A login or other REST request to the mobile application server system 105 should be configured by the mobile application client instance 170 to include the stored version number. The processor then compares the current version number with the stored version number to determine the difference, if any, between them. When the processor thus completes the comparison of the current version number of the database with the version number of the database stored by the mobile application client, the current version number is determined to be 0. If it is determined that the version number exceeds the stored version number, processing at process block 820 is complete and processing continues to decision block 825.

[0094] In decision block 825, the processor determines whether the current version number exceeds the stored version number. If the current version number (from the server side) exceeds the stored version number (from the client side) (decision block 825: YES), processing in decision block 825 is completed and processing proceeds to process block 830. If the current version number (from the server side) does not exceed the stored version number (from the client side) (decision block 825: NO), processing in decision block 825 is completed and processing proceeds to END block 835, where the process 800 ends. Note that this determination is a pre-test to determine whether the stored database may need to be updated. If the stored version number and the current version number match (the current version does not exceed the stored version), there is no need to update the stored version. If the stored version number and the current version number do not match (the current version exceeds the stored version), the stored version may need to be updated, and the processor proceeds to a more detailed process to determine whether there is a true need to update.

[0095] At processing block 830, the processor compares the characteristics of the particular user account with the defined characteristics to find a match. In one embodiment, the processor retrieves and parses the HR (human resources) record associated with the particular user account. The processor extracts the user's role from the HR record. The processor also extracts the areas in which the user is active from the HR record. The processor then queries the database to determine whether any custom rules newer than the stored version match the extracted areas or extracted roles. If so, the processor then retrieves those custom rules and sends them to the mobile application client instance 170 to add or replace the previous version of the custom rules in the stored version, and the stored version number is updated to equal the current version. If there are no custom rules newer than the store that match the extracted areas or roles, the stored version number is simply updated to equal the current version since there are no relevant updates. Once the processor has completed comparing the characteristics of a particular user account to the defined characteristics in this manner and found a match, processing at process block 830 is complete and the process proceeds to END block 835 where process 800 ends.

[0096] Thus, in one embodiment, as part of the mobile application client update or synchronization process that occurs when a user reconnects to the mobile application server system, the mobile application client will download the custom rule scripts associated with the user's area or role within the business organization. Additionally, supporting data for the operation of the custom rule scripts may also be downloaded at the same time, if applicable. In essence, the scripts are bundled with the mobile application update, and only the modified (or new) scripts are included as part of the catalog of scripts provided in the update bundle.

[0097] - Applying rules to objects and events - FIG. 9 illustrates one embodiment of a method 900 associated with implementing custom validation and business logic (custom rule) scripting, and in particular, associating mobile application objects and trigger events with custom rules. In one embodiment, the method 900 further improves upon the step of creating custom rules in the method 300. In one embodiment, the steps of the method 900 are implemented in a mobile application server. The custom rules scripting logic 1530 is executed by a mobile application server instance 215, and more specifically, a mobile application composer 220 (shown and described with reference to FIG. 2 and other figures herein). In one embodiment, the mobile application server instance 215 is realized by a mobile application server system 105. In one embodiment, the mobile application server system 105 is a dedicated computing device or collection of dedicated computing devices (such as computing device 1505) configured with custom rules scripting logic 1530.

[0098] Method 900 may be initiated based on various triggers, such as (i) rule / script editor client 180 accessing a custom rule; (ii) one or more new custom rules being created, e.g., by completion of process 300; (iii) one or more custom rules being uploaded to mobile application server system 105; and (iv) receiving a signal over a network or analyzing stored data indicating the initiation or completion of processing at processing block 310 of method 300. In one embodiment, method 900 begins in response to the completion of method 300. Method 900 begins at START block 905 in response to analyzing a received signal or retrieved stored data and determining that the signal or stored data indicates that method 900 should begin. Processing proceeds to processing block 910.

[0099] At processing block 910, the processor identifies an object of the mobile application client to which the custom rule is to be applied. In one embodiment, the processor accepts a user input indication that the custom rule should be applied to the object. The user input may be provided via the rule / script editor client 180. The processor then records an association between the object and the custom rule in metadata of the object, the custom rule, or both. Processing at processing block 910 is then complete and processing proceeds to processing block 915.

[0100] At processing block 915, the processor selects an event for the object that will trigger the execution of the custom rule. In one embodiment, in response to an indication that a custom rule should be applied to an object, the user is presented, via the rule / script editor client 180, with a set of trigger events from which to choose (OnCreate, OnFieldValueChange, BeforeSave, and AfterSave, as described above). The processor accepts (via the rule / script editor client) a user input selection of the trigger event that will trigger the execution of the rule. The processor then records an association between the object, the custom rule, and the trigger event in metadata for the object, the custom rule, or both. The association can be later analyzed, for example, by the data control module 260 or the scripting engine 250. Processing at processing block 915 is then complete, and processing proceeds to processing block 920.

[0101] At processing block 920, the processor sends the selected trigger event and identifier for the object to the instance of the mobile application client to further enable the instance to implement the custom rule when the instance is operating in offline mode. In one embodiment, the processor generates a REST request that includes the selected trigger event and identifier as a payload. For example, these may be included with the custom rule itself when it is sent to the instance of the mobile application. Processing at processing block 920 is then complete and processing proceeds to END block 925 where process 900 ends.

[0102] -Exemplary Rule / Script Editor GUI- 10 illustrates one embodiment of a method 1000 associated with implementing custom validation and business logic (custom rule) scripting, and in particular with accepting user input to create custom rules. In one embodiment, the steps of method 1000 are performed by a mobile application server instance 215, and more specifically, a mobile application composer 220 (shown and described with reference to FIG. 2 and other figures herein). In one embodiment, the mobile application server instance 215 is implemented by a mobile application server system 105. In one embodiment, the mobile application server system 105 is a dedicated computing device or collection of dedicated computing devices (such as computing device 1505) configured with custom rule scripting logic 1530.

[0103] Method 1000 may be initiated based on a variety of triggers, such as receiving a signal over a network or parsing stored data indicating that rule / script editor client 180 has accessed a custom rule. Method 1000 begins at START block 1005 in response to parsing the received signal or retrieved stored data and determining that the signal or stored data indicates that method 1000 should begin. Processing proceeds to process block 1010.

[0104] At processing block 1010, the processor generates instructions to present a graphical user interface (GUI) for creating one or more custom rules. In one embodiment, the processor generates one or more instructions to generate a web page that includes an instance of the rule / script editor client 180. Note that the generation of instructions to support the rule / script editor client 180 may be a substantially continuous process as a user interacts with the rule / script editor client 180 to effect changes to both the rule / script editor client 180 and the custom rules. Processing at processing block 1010 is then complete and processing proceeds to processing block 1015.

[0105] At processing block 1015, the processor sends instructions to a client computing device associated with the administrator account to cause the GUI to be displayed. In one embodiment, the processor receives a request from the client computing device 115 for the mobile application composer 220. In response, the processor sends instructions to the client computing device 115 to present a rule / script editor 405 graphical user interface for the rule / script editor client 180. This causes the client computing device 115 to display the rule / script editor client 180. Processing at processing block 1015 is then complete and processing proceeds to processing block 1020.

[0106] At processing block 1020, the processor accepts user input received through the GUI to create custom rules. The user may manipulate the custom rules using tools presented as part of the rule / script editor client 180 and its associated GUI. The mobile application composer 220 accepts them and stores them in the mobile repository 225. This process may continue to be repeated continuously while the user interacts with the mobile application composer 220 using the rule / script editor client 180. Processing at processing block 1020 is then complete and processing proceeds to END block 1025 where process 1000 ends.

[0107] As mentioned above, the mobile application composer 220 includes a script editor 405. In one embodiment, the script editor 405 can be accessed through a rule / script editor client 180 running on a client computing device 115. In one embodiment, an administrator or authorized user of the mobile application system will log into the mobile application composer 220, select a sandbox to work in, and navigate to a mobile application setup menu.

[0108] In one embodiment, the steps of method 10 may be performed at least in part by rule / script editor 405. In one embodiment, script editor 405 is a free-form text editor for creating or modifying interpreted programming language scripts, such as JavaScript scripts. In one embodiment, script editor 405 may be a visual editor that allows drag-and-drop assembly of interpreted programming languages.

[0109] In one embodiment, the script editor 405 includes an option to enable or disable client-side script execution. When client-side script execution is enabled, scripts for custom rules, and supporting data for the custom rules, if necessary, are sent to the mobile application client for local storage, for example by the configuration service 230. The client-side enabled custom rules will continue to be applied (enforced) without delay even while the mobile application client is operating in offline mode. When client-side script execution is disabled, neither scripts for custom rules nor supporting data for the custom rules will be sent to the mobile application client for local storage. The client-side disabled custom rules will not continue to be applied while the mobile application client is operating in offline mode and will not be enforced until synchronization after offline mode operation ends and connectivity is restored.

[0110] In one embodiment, the script editor 405 may be operated using a GUI. FIG. 11 shows an example embodiment of a "Create a Script" dialog 1100 for creating a new custom rule script using the script editor 405. The user is presented with three required fields used to define a new script: a script name field 1105, a script description field 1110, and a region assignment search selection field 1115. Note that the default state of the region field 1115 is "All," indicating that the script will operate in all geographic regions. However, it may be desirable to have the script only function in a particular geographic region. Thus, the user may select a geographic region for the script. The script will then only function for users whose geographic region has been selected in the region field 1115, for example, as the user's country preference setting in the user's HR record.

[0111] Scripts may be set to an active or inactive state by a graphical toggle 1120; selecting an active state instructs the sandbox environment (or production environment) to execute the script when the script's trigger conditions are met for the object associated with the script. Selecting an inactive state instructs the sandbox environment (or production environment) to ignore and not execute the script even when its trigger conditions are met. Thus, the active / inactive state controls which scripts are selected for execution at run time. Selecting the Create button 1125 allows the user to initialize the new script in the system and begin editing. Selecting the Cancel button 1130 cancels the new script. The menu closes without creating a script.

[0112] 12 illustrates an example embodiment of a mobile application script editor GUI 1200. In one embodiment, the script editor GUI 1200 is an interface for manipulating the rule / script editor 405 in the application composer 220. In one embodiment, the script creation dialog 1100 can be reached from the script editor GUI 1200. For example, by selecting an object in the (collapsed) mobile application object menu 1205, then selecting one of the trigger events 1210 that will trigger the script. The mobile application object menu 1205 is a list of all available top-level objects in the mobile application system. In the view of the script editor GUI 1200, with the "Opportunity" object already selected, the menu 1205 collapses to show that for the opportunity object, four events may be selected as trigger events for the opportunity object: On Create (triggered when a new record is created in the mobile app), Before Save (triggered before the record is saved), On Field Value Change (triggered when a user changes the value of a field and then taps out of the field), and After Save (triggered after the app saves the record). In one embodiment, these four events are supported for scripting for any object in the mobile application system. Thus, an administrator or authorized user can select an object and see the user interface events associated with the object in order to create a script. This visibility is enabled for all standard, custom, and vertical objects in the mobile application system. Selecting one of the four events, for example the before save event, opens the before save script menu 1215.Selecting the plus "+" button 1220 in the before save scripts menu 1215 opens the script creation dialog 1100. Note that there is a scripts menu for each type of triggering event. In one embodiment, the scripts menu lists all scripts associated with a given object-event combination.

[0113] Once a new script has been initialized or created as described above with respect to FIG. 11, an administrator or authorized user can write and edit the new script in an edit area 1225. The edit area 1225 is a free-form text editor. Changes made in the edit area (or script box) 1225 are persisted to storage, e.g., the mobile repository 225, in response to user input indicating selection of a save button 1230. Sub-features of an object, such as fields and child objects, may be selected using a mobile application object details menu 1235. Areas (including sub-areas) other than the area selected in the area field 1115 of FIG. 11 may be assigned using an assigned areas menu 1240. Restricting custom rule scripts by user role rather than area requires that the restrictions be written in JavaScript script. Roles are searchable in an assigned roles menu 1245 to aid in script writing.

[0114] In one embodiment, a user may create custom functions (also known as utility functions) that are available to all objects in all scripts. To begin creating a utility function, a user may select the plus "+" button 1250 in the utility functions menu 1255. Utility functions may be drafted and edited in the editing area 1225 similar to other scripts described above. By including the letters "_C" in the function name of a utility function, the function is designated as a utility function and is included in the system functions list (described below). If a utility function is added to the system functions list, the function may be edited in the edit area 1225. Once included in the list, the utility functions can be accessed from any custom script. An example of the format of a utility function is as follows:

[0115]

number

[0116] In one embodiment, to aid in the selection of the correct object and field values, the user may type "control+space" (or other key combination) in the edit area 1225, in response to which a list of available objects and fields is displayed. An object or field displayed in the list may be selected, for example, by a mouse click, and the correct value is inserted into the script text in the edit area at the cursor position where "control+space" was typed. Additionally, this feature enables the use of system functions that automatically populate application programming interfaces (APIs) into the script. By typing "control+space" and scrolling down to the "System Functions" section of the list, the user reveals not only system functions created by the user, but also a list of APIs that the user may select and insert into the script. The user may use these APIs to determine the operating system of the host device, the current geographic location of that device (e.g., via the Global Positioning System (GPS)). In one embodiment, these APIs include, but are not limited to, the system "helper" functions and JavaScript wrapper APIs described above with reference to Table 2.

[0117] In one embodiment, a user may select the verify button 1260 to initiate the script verification process. In one embodiment, the processor parses the script configured in the edit area 1225 to perform a JavaScript syntax check. A successful syntax check indicates that the script will be executed (although the executed script may not function as expected due to non-syntactic errors in the script). An unsuccessful syntax check indicates that the script's syntax requires correction. The processor may provide a visual prompt to indicate a possible syntax error. Additionally, in response to selecting the verify button, the processor may further parse the script configured in the edit area 1225 to perform best practice checks.

[0118] In one embodiment, the processor performs these validation checks while applying the standard ESLint Validation Rules (available at https: / / eslint.org / docs / 2.0.0 / rules / ). In one embodiment, a small number of ESLint rules and / or best practices are disabled or enabled with reduced severity to improve the usability of the rules / script editor 405. For example, the following rules and best practices are modified as described: no-irregular-whitespace-no-irregular-outside-strings-and-comments Rules: no whitespace;no-multi-spaces - no multiple spaces allowed;no-space-before-semi - no space before semicolon;no-trailing-spaces - at end of line do not allow trailing whitespace;comma-spacing-enforces spacing before and after a comma;eol-last- enforce new lines at end of file, without multiple empty lines;global-strict-global Requires or does not allow the "use strict" pragma at global scope.

[0119] In one embodiment, the processor further performs validation checks on blacklisted APIs or global objects. These APIs are not allowed to be used in custom rule scripts because in some cases they pose security risks to the mobile application system. In one embodiment, the following APIs and global objects are blacklisted: Console; Alert; Window; Document; System; Promise; XMLHttpRequest; XHR. These objects are blacklisted when the processor They may be rejected or removed by validation. Similarly, trusted APIs may be whitelisted.

[0120] Thus, using a GUI interface to the rules / scripts editor 405, an administrator or authorized user of the mobile application system can write custom JavaScript (registered A user can configure the mobile application system to meet business requirements by writing custom rule scripts. Custom rule scripts may be applied to any top-level object in the mobile application system. Custom rule scripts may be created generally for all objects or groups of objects, or even for specific objects. Custom rule scripts may be configured to trigger events selected by the user. For example, a user can create a script that makes the product field mandatory when a new "Opportunity" object is created in the mobile application system.

[0121] -Example client GUI- 13 illustrates an example client GUI 1300 for a mobile application client instance 170 associated with implementing custom validation and business logic (custom rule) scripting during offline mode operation. The mobile application client instance 170 is operating in offline mode. This is confirmed by a cellular signal indicator 1305 and a WI-FI signal indicator 1310, each of which are not indicating a signal and therefore no network connectivity between the mobile application client instance 170 and the mobile application server system 105.

[0122] The mobile application client instance 170 generating the GUI 1300 is configured in accordance with the systems and methods described herein to execute custom rule scripts locally. For example, the mobile application client instance 170 is configured to execute a custom rule script OnFieldValueChange for the sales stage of an opportunity object. The custom rule script requires a value to be entered into the revenue amount field to advance the sales stage beyond opportunity (stage 2) 1315 to building vision (stage 3) 1320. Without the inventive systems and methods discussed herein, the mobile application client instance 170 would not be able to implement the "revenue field required" validation rule. However, because the application client instance 170 is configured in accordance with the systems and methods described herein (see inset 1330), selecting the building vision button 1335 to change the sales stage field value to 3 while a revenue amount has not been entered results in the validation rule being executed and the change being rejected, as shown in inset 1340.

[0123] FIG. 14 illustrates an example client GUI 1400 for a mobile application client instance 170 associated with implementing custom validation and business logic (custom rules) scripting during offline mode operation. The mobile application client instance 170 is operating in an offline mode. As mentioned above, this is confirmed by the cellular signal indicator 1305 and the WI-FI signal indicator 1310, each of which are not indicating a signal and therefore not indicating network connectivity between the mobile application client instance 170 and the mobile application server system 105.

[0124] The mobile application client instance 170 generating the GUI 1400 is configured in accordance with the systems and methods described herein to execute custom rule scripts locally. For example, the mobile application client instance 170 is configured to execute several custom rule scripts for a purchase order object.

[0125] In the first example, this mobile application client instance is configured to run a custom rule script on OnFieldValueChange. Account Number 1 When 405 is entered into the field, the custom rule script is configured to search and retrieve the account's address information 1410. Note that this data is pre-loaded into the mobile application client instance 170 due to the fact that the custom rule script is configured to run a query against it, supporting data for the account address lookup. Note that this query can be completed immediately without delay in accessing a remote server.

[0126] In the second example, purchase order line 1415 includes a Blue Boar Energy drink as purchase 2. The mobile application client instance 170 then uses both the custom rule script (which executes OnFieldValueChange on the Blue Boar in the item field) to reduce the price according to the rule. The time scope of this promotion is short and would not justify customization and rebuilding of the core application, however the advantages provided by the systems and methods described herein for offline mode customization justify the deployment of custom logic for a simple promotion.

[0127] In a third example, as shown in success message inset 1420 and error 1425, the mobile application client instance is configured to run a custom rule script that performs a credit check in BeforeSave when the total exceeds $700. Credit information about the customer is supporting data that is pre-populated along with the custom script.

[0128] -Further illustrative use cases- In one embodiment, a set of custom rules is applied to an opportunity object. Upon initial creation of the object by a mobile application client operating in offline mode, the mobile application client immediately: (1) (2) enforce the requirement that the "Account" field be filled (Account is a required field); (3) set default values ​​for custom fields - Odds of Win is assigned a list of values ​​of "Low", "Medium" and "High" and Opportunity Type is assigned a list of values ​​of "Transportation", "Contract Logistics" and "Global Projects"; (4) impose a condition that once an opportunity is created with an opportunity type, it cannot be changed - in other words, the opportunity type is "read-only". On field value change by the mobile application client operating in offline mode, the mobile application client may set the following based on the opportunity type: - You can instantly enforce conditional field requirements with multiple layout may include: (a) a "Business Type" field indicating the nature of the opportunity with a list of values ​​"New", "Growth" and "Retention"; (b) a "Site" field describing the general location of the opportunity with a list of values ​​"APAC" (Asia Pacific), "EMEA" (Europe, Middle East and Africa), "NA" (North America), "LATAM" (South America); (c) a "Region" field further breaking down the location of the site with a list of values ​​that depend on the selected value of the site field - for example, the list of values ​​may be a list of countries within that site; (d) a "Vertical Market" field; and (e) a "Bid Received Date" field. Before saving changes to the object by a mobile application client operating in offline mode, the mobile application client may update the required fields. The mobile application client may immediately enforce the requirements for a transportation opportunity (opportunity type = transportation) that the revenue field is required if the sales stage is greater than 2. The mobile application client will disallow the save operation (and present an error message) if any of these requirements fail. This is true even if the mobile application client is operating in offline mode, in which case the changes are not submitted immediately to the mobile application server, but instead are queued for later synchronization.

[0129] In one embodiment, a different set of custom rules is applied to opportunity objects. On initial creation of an object by a mobile application client operating in offline mode, the mobile application client immediately creates an account. The account field may be made mandatory and the mobile client may present an error message in response to an attempt to edit any other field before the account value is provided. On field value change for an opportunity stage by a mobile application client operating in offline mode ,The mobile application client may immediately implement the requirements that (1) the “competitor” field be required when opportunity stage is greater than 2, and (2) the “partner” field be required when opportunity stage is greater than 3.

[0130] In one embodiment, the custom rules are applied to the "Contact" object. On initial creation of the object by a mobile application client operating in offline mode, the mobile application client may It may be immediately required that the account fields are mandatory, and the mobile client may present an error message in response to an attempt to edit any other fields before the account values ​​have been provided.

[0131] In another embodiment, the custom rule is applied to a "contact" object. When an account field value change is set for a contact in a mobile application client operating in offline mode, the mobile application The application client can immediately set the default address field of a contact to the same value as the address field of the account selected for the contact.

[0132] In another embodiment, custom rules are applied to a "lead" (i.e., sales lead) object. After a change to the lead object is saved by a mobile application client operating in offline mode, the mobile application client can immediately create a task and associate the task with both the lead and the user that "owns" the lead (e.g., the user who created the lead).

[0133] In one embodiment, one or more custom rules for the mobile application client's consumer goods configuration may be applied. For example, custom business logic and custom validation expressions may be applied to cart and purchase operations. For example, a mobile application client operating in offline mode may: (1) allow an order to be taken or otherwise restrict order acceptance only if an account credit status is a certain value or not, or the value of some custom field X is >0; (2) allow shopping cart or order submission only if the value of some account custom field Y=true or the value of some custom field X is greater than the value of the order; (3) prohibit the mobile application client from picking up a returned order if the returned product does not qualify for return eligibility - return eligibility may be defined by a custom field; (4) prohibit the use of a credit line as a payment type if the credit line has expired - expired may be a credit (5) enforce a maximum amount per payment type when a payment is made - a payment type is a list of values ​​(check, cash, credit, etc.) for a payment object -; (6) allow cash payments only if the account is eligible for cash payments - a payment object is related to an account object -; (7) automatically apply a Y% discount if the cart total is over X amount; (8) prevent submission of a shopping cart unless a purchase order (PO) number - a customer defined custom field - is populated by a sales agent user of the mobile application client; (9) enforce contract fences to limit negotiations to acceptable ranges, for example, prevent saving of contacts unless shelf share is within the range of 20%-100%.

[0134] Further custom rules for the mobile application client's consumer goods configuration may be applied, such as custom validation rules that consider various pricing rules, allowing pricing for items to vary within an order if different growth tiers or loyalty levels are achieved based on the order contents. For example, the mobile application client may identify a conditional promotion in offline mode without a connection to the mobile application server, such as if at least 50 items X are added to the cart (or purchase order) at list price, and automatically add Z quantity of Y items to the cart at zero price. This type of promotion may be along the lines of "if you add 2 items from group A and 1 item from group B, get a free item C." Thus, if a sales representative using the mobile application client adds at least 2 items from A and 1 item from B, item C will be automatically added to the order (even if the mobile application client is operating in offline mode). If these items are removed, item C will be automatically removed.

[0135] In addition, custom rules for the mobile application client's consumer goods configuration may be applied to further automate shopping cart operations. For example, a mobile application client operating in offline mode may implement a maximum number of promotional items that can be added or applied to a cart. In another example, a mobile application client operating in offline mode may automatically add any items to a list of out-of-stock items and potentially remove them from the cart if the current inventory amount is less than the recommended inventory amount (whether this amount is stored as a value in an account product sort or as a custom attribute in some custom object).

[0136] In addition, custom rules for the mobile application client's consumer goods configuration may be applied for various other validation purposes. For example, to operate in offline mode. A mobile application client may (1) not allow a call to checkout unless a task marked as required is completed or rescheduled; or (2) specify which products or lines of products are allowed to be paid for using a given payment type.

[0137] The above exemplary use cases further illustrate the great flexibility provided by the implementation of custom validation and business logic (custom rule) scripting for mobile applications disclosed herein. Because of the systems and methods described herein, each of these custom rules can be applied immediately even while the mobile application client is operating in an offline mode, i.e., the custom rules can be implemented without delay until the mobile application client comes back online and synchronizes with the mobile application server. Furthermore, the custom rules, when implemented using a REST architecture, are less prone to failure, thus allowing the custom rules to be implemented immediately even while the application is operating in an online mode using REST communication with the mobile application server. Furthermore, the logic for each of these use cases is completely separated from the core mobile application client functionality, allowing for rapid manipulation, deployment, removal, and other management of the custom rules without requiring complex modifications to the mobile application client and / or server for minor (or indeed, major) business logic or validation customizations. For example, the core mobile application does not need to be modified to implement a temporary local promotional offer. Thus, the systems and methods described herein significantly improve both offline and online mode operation of mobile application clients.

[0138] -Example script- For non-limiting and illustrative purposes, some selected exemplary custom rule scripts are presented herein. In one example, a custom rule script is applied to an opportunity object and triggered by the occurrence of an "OnCreate" scripting event. The script implements three custom rules: (1) an account is required; (2) a default value is set for a field (custom field); (a) odds = medium (values ​​to choose from: low, medium, high); (b) opportunity type = server (values ​​to choose from: server, laptop, and software); and (3) the custom field ContractStartDate is required.

[0139] Example script 1:

[0140]

number

[0141] In one example, a custom rule script is applied to an Opportunity object and triggered by the occurrence of a "BeforeSave" scripting event. The script implements a custom rule that a revenue line is required if the status is Open and the sales stage is >2.

[0142] Example script 2:

[0143]

number

[0144]

number

[0145] In one example, a custom rule script is applied to an Opportunity object and is triggered by the occurrence of an "AfterSave" scripting event. The script: Implement a custom rule that creates a task, assigns it to the signing user, and associates it with the newly created opportunity.

[0146] Example script 3:

[0147]

number

[0148] In one example, a custom rule script is applied to a Contract object and triggered by the occurrence of the "OnCreate" scripting event. The script implements a custom rule that makes Account a required field.

[0149] Example Script 4:

[0150]

number

[0151] In one example, a custom rule script is applied to a Contract object and triggered by the occurrence of an "OnFieldValueChange" scripting event. The script implements a custom rule that copies an Account Address to a Contact Address.

[0152] Example Script 4:

[0153]

number

[0154]

number

[0155] -Selected Benefits- The performance of the mobile application system itself is improved in several ways by the systems and methods described herein: (i) the mobile application client can operate with all custom features enabled even when network connectivity to the mobile application server is unavailable; (ii) the implementation of custom rules is instantaneous and not delayed; (iii) invalid data is prevented from entering the mobile application database server by implementing custom rules when invalid data is entered; and (iv) server-side data processing upon synchronization after network connectivity is restored is much more efficient since the custom rules are already applied on the client side and do not need to be executed on the server side during the synchronization operation. One important source of these technical improvements is the advantageous instantaneous implementation of custom rules made possible by the inventive relocation of custom rule actions from server-side execution to non-conventional execution on the client side (e.g., in the scripting engine 250). These technical improvements may also be caused by non-conventional copying of supporting data for custom rules (for all potential custom rule actions) from the server side to local storage on the client side.

[0156] It should be noted that features of the mobile application client's graphical user interface that would necessarily be disabled during offline operation (e.g., automatic display of discounted pricing with custom incentives) are fully enabled in offline operation by implementation of the systems and methods described herein.

[0157] The mobile application system is further improved by eliminating the need to rebuild the client application in response to each new custom rule. Instead, the custom rules are executed agnostic by the mobile application client. This is made possible by an inventive and unconventional configuration of the mobile application client with a common rule execution environment. Thus, the mobile application client can achieve custom functionality without requiring customization of the mobile application client itself. Additionally, mobile application client instances configured for different roles and / or different locations can run the same build or version of the mobile application client. is still executed while allowing it to have separate custom functionality.

[0158] The present invention allows users to seamlessly use the application in offline or online mode, with the same set of validations being performed regardless of network connectivity, thereby allowing users to use the app in the most efficient way. Ensuring that data is validated regardless of online or offline mode also ensures that the data meets contractual requirements and ensures good quality data in the system, which ensures better results in business intelligence and artificial intelligence analysis. Having custom business logic running in the mobile application allows users to perform all aspects of their work from their mobile devices. Having immediate validation instead of delayed validation that occurs later in asynchronous mode provides users with a greatly improved user experience.

[0159] Advantageously, the hardware used to implement the mobile system does not need to be modified to obtain these benefits, noting that it is the inventive operation of the systems and methods described herein that provides the improvements, not the application of computing hardware.

[0160] -Software Modules, CRM, Cloud and Enterprise Implementations- 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 an interpreted programming language, such as a scripting language.

[0161] In a complex system, such instructions are typically arranged into program modules, with each such module performing a particular task, process, function, or operation. The entire set of modules may be controlled or coordinated in their operation by an operating system (OS) or other form of organizational platform.

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

[0163] In one embodiment, the mobile application server system 105 is a computing / data processing system that includes an application or a collection of distributed applications for an enterprise organization. The application and mobile application server system 105 may be configured to operate with or implemented as a cloud-based networking system, a software as a service (SaaS) architecture, or other type of networked computing solution. In one embodiment, the mobile application server system 105 is a centralized server-side application that provides at least the functionality disclosed herein and is accessed by many users by operation of computing devices / terminals that communicate with the mobile application server system 105 (acting as a server) over a computer network.

[0164] -Computing device embodiment- FIG. 15 illustrates an exemplary computing device configured and / or programmed with one or more of the exemplary systems and methods described herein and / or equivalents. The exemplary computing device may be a computer 1500 including a processor 1510, a memory 1515, and input / output ports 1520 operably connected by a bus 1525. In one example, the computer 1500 may include custom rule scripting logic 1530 configured to facilitate custom validation and business logic (custom rule) scripting for mobile application offline mode operation similar to the logic, systems, and methods illustrated and described with reference to FIGS. 1-14. In different examples, the logic 1530 may be implemented in hardware, a non-transitory computer-readable medium having instructions stored thereon, firmware, and / or a combination thereof. Although logic 1530 is shown as a hardware component attached to bus 1525, it should be appreciated that in other embodiments, logic 1530 may be implemented within processor 1510, stored within memory 1515, or stored within disk 1535.

[0165] In one embodiment, the logic 1530 or computer is a means (e.g., structure: hardware, non-transitory computer readable medium, firmware) for performing the actions described. 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.

[0166] The means may be realized, for example, as an ASIC programmed to perform custom validation and business logic (custom rules) scripting for mobile application offline mode operation. The above means may also be realized as stored computer executable instructions that are temporarily stored in memory 1515 and presented to computer 1500 as data 1540 that are then executed by processor 1510.

[0167] The logic 1530 may also provide the means (e.g., hardware, non-transitory computer-readable medium storing executable instructions, firmware) for performing custom validation and business logic (custom rules) scripting for mobile application offline mode operation.

[0168] To outline an exemplary configuration of computer 1500, processor 1510 may be a variety of processors, including dual microprocessors and other multi-processor architectures. Memory 1515 may include volatile 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.

[0169] The storage disk 1535 may be operatively connected to the computer 1500, for example, via an input / output (I / O) interface (e.g., card, device) 1545 and an input / output port 1520. The disk 1535 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. Furthermore, the disk 1535 may be a CD-ROM drive, a CD-R drive, a CD-RW drive, a DVD ROM, etc. The memory 1515 may store, for example, processes 1550 and / or data 1540. The disk 1535 and / or the memory 1515 may store an operating system that controls and allocates resources of the computer 1500.

[0170] Computer 1500 may interact with input / output (I / O) devices via I / O interface 1545 and input / output ports 1520. Input / output devices may be, for example, a keyboard, a microphone, a pointing and selection device, a camera, a video card, a display, a disk 1535, a network device 1555, etc. Input / output ports 1520 may include, for example, serial ports, parallel ports, and USB ports.

[0171] The computer 1500 can operate in a networked environment and thus can be connected to a network device 1555 via the I / O interface 1545 and / or the I / O port 1520. Through the network device 1555, the computer 1500 can interact with a network. Through the network, the computer 1500 can be logically connected to a remote computer. The networks with which the computer 1500 can interact include, but are not limited to, a LAN, a WAN, and other networks.

[0172] -Mobile device embodiment- Referring now to FIG. 16, an exemplary mobile device 1600 configured and / or programmed with one or more of the exemplary systems and methods described herein and / or equivalents is shown. In one example, the mobile device 1600 may include custom rules scripting logic 1605 configured to facilitate data provider agnostic change processing in a mobile client application similar to the logic, systems, and methods shown and described with reference to FIGS. 1-14. The mobile device 1600 may include a cellular antenna 1610. An exemplary embodiment may implement signal processing and / or control circuitry, generally identified in FIG. 16 at 1620. In some implementations, the mobile device 1600 includes a microphone 1630, an audio output 1640 such as a speaker and / or audio output jack, a display 1650, and / or input devices 1660 such as a keypad, a pointing device, a voice activation, and / or other input devices. Signal processing and / or control circuitry 1620 and / or other circuitry (not shown) within the mobile device 1600 may process data, perform coding and / or encryption, perform calculations, format data, and / or perform other cellular phone, tablet, or mobile device functions.

[0173] The mobile device 1600 may communicate with mass data storage 1670, which stores data in a non-volatile manner, such as, for example, in magnetic, optical, and / or solid-state storage devices, including HDD, DVD, and / or SSD. The cellular phone 1600 may be connected to memory 1680, such as RAM, ROM, low latency non-volatile memory, such as flash memory, and / or other suitable electronic data storage. The mobile device 1600 may also support connection to a WLAN via a WLAN network interface 1690. The mobile device 1600 may include a WLAN antenna 1695. In one embodiment, the mobile device 1600 may communicate via the WLAN with a cloud storage system (e.g., data store 135), which stores data in a non-volatile manner. In one embodiment, the exemplary system and method may be implemented using a WLAN network interface 1690, although other configurations are possible.

[0174] -Definitions and other embodiments- In another embodiment, the methods described and / or their equivalents may be implemented using computer-executable instructions. The data-readable / storage medium is configured with stored computer-executable instructions for algorithms / executable applications that, when executed by a machine, cause the machine (and / or associated components) to perform the method. Exemplary machines include, but are not limited to, processors, computers, servers operating in cloud computing systems, servers configured in Software as a Service (SaaS) architectures, smartphones, etc. In one embodiment, a computing device is implemented with one or more executable algorithms configured to perform any of the disclosed methods.

[0175] 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 and configured as an executable algorithm that, when executed by at least a processor of a computing device, is configured to perform the methods.

[0176] For ease of explanation, the illustrated methods are shown and described as a series of algorithmic blocks, but it should be understood that these methods are not limited by the order of the blocks. Some blocks may occur in a different order than shown and described, and / or concurrently with other blocks. Furthermore, an example method may be implemented using fewer than all of the illustrated blocks. The 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.

[0177] The following contains definitions of selected terms used herein. The 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. The examples are not intended to be limiting. Both singular and plural terms may be within the definitions.

[0178] References to "one embodiment," "an embodiment," "an example," "an 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, characteristic, property, element, or limitation. Additionally, repeated use of the phrase "in one embodiment" does not necessarily refer to the same embodiment, but may.

[0179] ASIC: Application Specific Integrated Circuit. CD:Compact disc.

[0180] CD-R: Recordable CD. CD-RW: Rewritable CD.

[0181] DVD: Digital Versatile Disc and / or Digital Video Disc. HTTP: Hypertext Transfer Protocol.

[0182] LAN: Local Area Network. RAM: Random Access Memory.

[0183] DRAM: Dynamic RAM. SRAM: Synchronous RAM.

[0184] ROM: Read-only memory. PROM: Programmable Read-Only.

[0185] EPROM: Erasable PROM. EEPROM: Electrically Erasable PROM.

[0186] RDBMS: Relational Database Management System. SSD: Solid State Drive / Solid State Storage Device SQL: Structured Query Language.

[0187] USB: Universal Serial Bus. XML: Extensible Markup Language.

[0188] WAN: Wide Area Network. As used herein, a "data structure" is an organization of data within a computing system, stored in a memory, storage device, or other computerized system. A data structure may be, for example, a data field, a data file, a data array, a data record, a database, a data table, 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). Other examples of data structures are possible according to other embodiments.

[0189] As used herein, a "computer-readable medium" or a "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. A computer-readable medium 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 tapes, 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 may function. Each type of media, when selected for implementation in an embodiment, may include stored instructions of an algorithm configured to perform one or more of the functions disclosed and / or claimed.

[0190] As used herein, "logic" refers to components implemented using computer or electrical hardware, non-transitory media having stored instructions of an executable application or program module, and / or combinations thereof to perform any of the functions or actions disclosed herein and / or cause functions or actions from another logic, method, and / or system to be performed as disclosed herein. Equivalent logic may include firmware, a microprocessor programmed with an algorithm, discrete logic (e.g., ASIC), at least one circuit, analog circuit, digital circuit, programmed logic device, memory device containing algorithmic instructions, and the like, any of which may be configured to perform one or more of the disclosed functions. In one embodiment, logic may be implemented using a microprocessor that performs one or more of the disclosed functions. A logic circuit may include one or more gates, combinations of gates, or other circuit components configured to perform one or more of the following: Where multiple logics are described, it may be possible to incorporate the multiple logics into one logic. Similarly, where a single logic is described, it may be possible to distribute the single logic among multiple logics. In an embodiment, one or more of these logics are corresponding structures associated with performing the disclosed and / or claimed functions. The selection of which type of logic to implement may be based on desired system conditions 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.

[0191] An "operable connection," or a connection in which entities are "operably connected," is a connection in which signals, physical communications, and / or logical communications may be transmitted and / or received. An operable connection may include physical interfaces, electrical interfaces, and / or data interfaces. 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 to each other directly or through one or more intermediate entities (e.g., processors, operating systems, logic, non-transitory computer-readable media). Logical and / or physical communication channels may be used to form an operable connection.

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

[0193] Although the disclosed embodiments have been shown and described in considerable detail, it is not intended to restrict or in any way limit the scope of the claims to such details. Of course, it is not possible to describe every conceivable combination of components or methodologies for purposes of describing various aspects of the subject matter. Thus, the disclosure is not limited to the specific details or illustrative examples shown and described. Thus, the disclosure is intended to embrace changes, modifications, and variations that fall within the scope of the claims.

[0194] The words "includes" or "including" appear in the detailed description or To the extent that it is used in the claims, it is intended to be inclusive in the same manner as the term "comprising" is interpreted when used as a transition term in the claims.

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

Claims

1. 1. A computer-implemented method for enabling client-side enforcement of custom rules, comprising: creating, on a mobile application server, custom rules for enforcement on a mobile application client, the mobile application client configured to enforce one or more custom rules when operating in an offline mode, the method further comprising: defining characteristics of a user account for which the mobile application client enforces the custom rules; In response to a connection being established between an instance of the mobile application client and the mobile application server for a particular user account, determining that the instance of the mobile application client should implement the custom rule based at least in part on a match between a characteristic of the particular user account and the defined characteristic; and transmitting the custom rule to the instance of the mobile application client to enable the instance to implement the custom rule when the instance is operating in the offline mode.

2. The method further comprises: generating queries to retrieve supporting data from a mobile application database for interrogation during execution of said custom rules; executing the query on the mobile application database to obtain the supporting data; sending the supporting data to the instance of the mobile application client to further enable the instance to implement the custom rules when the instance is operating in an offline mode; in response to detecting a lack of network connectivity to the mobile application server, placing the instance of the mobile application client in the offline mode; While the instance of the mobile application client is operating in the offline mode, (i) accepting user input to the instance of the mobile application client that triggers implementation of the custom rule; 2. The method of claim 1, further comprising: (ii) retrieving a portion of the supporting data from local storage and performing all functions of the custom rule locally by the instance of the mobile application client to enable the instance of the mobile application client to immediately implement the custom rule.

3. The method further comprises: adding the custom rule to a database of rules associated with the mobile application server; incrementing a current version number of said database; responsive to establishing the connection, comparing the current version number of the database to a version number of the database stored by the mobile application client to determine that the current version number exceeds the stored version number; In response to determining that the current version number exceeds the stored version number, the characteristics of the particular user account and the defined version number are compared to find the match. and comparing the determined characteristic with the determined characteristic.

4. 4. The method of claim 1, 2, or 3, wherein the custom rules are scripts, and the mobile application client is configured to execute the scripts to implement the custom rules without requiring modifications to a build of the mobile application client.

5. 4. The method of claim 1, claim 2, or claim 3, wherein the characteristics of the user account include one or more of: (i) a geographic area associated with the user account; and (ii) a user role associated with the user account.

6. The creating of the custom rule further comprises: identifying an object of the mobile application client to which the custom rule applies; selecting an event for the object that will trigger execution of the custom rule; and transmitting the selected event and an identifier for the object to the instance of the mobile application client to further enable the instance to implement the custom rule when the instance is operating in an offline mode.

7. The creating of the custom rule further comprises: generating instructions to present a graphical user interface (GUI) for creating one or more custom rules; sending the instructions to a client computing device associated with an administrator account to cause the client computing device to display the GUI; and accepting user input received via the GUI to create the custom rule.

8. The method of claim 1 , 2 or 3 , wherein a GUI presented by the instance of the mobile application client displays the results of the custom rule immediately after receiving an input that triggers the custom rule.

9. The method of claim 1 , 2 or 3 , wherein the custom rule is one of: (i) a validation rule; and (ii) a business logic rule.

10. 1. A computing system comprising: A processor; a memory operatively connected to the processor; and 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, to cause the computing system to: and causing, on a mobile application server, to create custom rules for execution on a mobile application client, the mobile application client being configured to execute one or more custom rules when operating in an offline mode. The computer-executable instructions, when executed by at least the processor, further cause the computing system to: defining characteristics of a user account for which the mobile application client enforces the custom rules; An instance of the mobile application client for a particular user account. in response to a connection being established between the instance of the mobile application client and the mobile application server, determining that the instance of the mobile application client should implement the custom rule based at least in part on a match between a characteristic of the particular user account and the defined characteristic; A computing system causing the custom rules to be transmitted to the instance of the mobile application client to enable the instance to implement the custom rules when the instance is operating in the offline mode.

11. The non-transitory computer-readable medium, when executed by at least the processor, provides to the computing system: in response to detecting a lack of network connectivity to the mobile application server, causing the instance of the mobile application client to enter the offline mode; While the instance of the mobile application client is operating in the offline mode, (i) accepting user input to the instance of the mobile application client that triggers implementation of the custom rule; 11. The computing system of claim 10, further comprising: (ii) instructions to cause a portion of the supporting data to be retrieved from local storage and all functions of the custom rule to be executed locally by the instance of the mobile application client to immediately implement the custom rule.

12. The non-transitory computer-readable medium, when executed by at least the processor, provides to the computing system: constructing a query to retrieve supporting data from a mobile application database for interrogation during execution of said custom rules; executing the query on the mobile application database to obtain the supporting data; 11. The computing system of claim 10, further comprising instructions to cause the supporting data to be transmitted to the instance of the mobile application client to further enable the instance to implement the custom rules when the instance is operating in an offline mode.

13. The non-transitory computer-readable medium, when executed by at least the processor, provides to the computing system: adding the custom rule to a database of rules associated with the mobile application server; incrementing the current version number of said database; responsive to establishing the connection, comparing the current version number of the database with a version number of the database stored by the mobile application client to determine that the current version number exceeds the stored version number; 11. The computing system of claim 10, further comprising instructions for, in response to determining that the current version number exceeds the stored version number, comparing the characteristics of the particular user account with the defined characteristics to find the match.

14. A non-transitory computer-readable medium storing computer-executable instructions, the computer-executable instructions being executed by at least a processor of a computer , the computer and causing, on a mobile application server, to create custom rules for enforcement on a mobile application client, the mobile application client being configured to enforce one or more custom rules when operating in an offline mode, the computer-executable instructions, when executed by the at least a processor of the computer, further causing the computer to: defining characteristics of a user account for which the mobile application client enforces the custom rules; in response to a connection being established between an instance of the mobile application client and the mobile application server for a particular user account, causing the instance of the mobile application client to determine that the custom rule should be implemented based at least in part on a match between a characteristic of the particular user account and the defined characteristic; A non-transitory computer-readable medium for causing the custom rules to be transmitted to the instance of the mobile application client to enable the instance to implement the custom rules when the instance is operating in the offline mode.

15. Further, when executed by at least the processor, the computer is in response to detecting a lack of network connectivity to the mobile application server, causing the instance of the mobile application client to enter the offline mode; While the instance of the mobile application client is operating in the offline mode, (i) accepting user input to the instance of the mobile application client that triggers implementation of the custom rule; 11. The non-transitory computer-readable medium of claim 10, further comprising instructions for (ii) causing all functions of the custom rule to be executed locally by the instance of the mobile application client to immediately implement the custom rule.

Images