A system for custom validation and scripting for mobile applications

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 everyday work functions. For example, sales representatives conducting store visits can use their mobile devices to take orders or record other information, and technicians can use their mobile devices to perform service management tasks. Mobile application solution vendors may offer solutions to which customers want 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, 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 including defining characteristics of a user account for which the mobile application client will enforce the custom rule; determining, in response to establishing a connection between an instance of the mobile application client for a particular user account and the mobile application server, 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 implement the custom rule when 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 execution of the custom rule 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 implement the custom rule when the instance is operating in an offline mode; placing the instance of the mobile application client in the offline mode in response to detecting a lack of network connectivity to the mobile application server; 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 rule; 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 a custom rule, 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 implement the custom rule when the instance is operating in offline mode.

[0009] In one embodiment, in a computer-implemented method for enabling client-side enforcement of custom rules, creating the custom rules 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 display the GUI, and accepting user input received via the GUI to create the custom rules.

[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 after 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 the method implemented by the data, 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, the computer-executable instructions, when executed by at least the processor, causing the computing system to create, on a mobile application server, custom rules 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, when executed by at least the processor, further 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 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, enabling the instance to implement the custom rule when 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 functionality of the custom rule to be performed locally by the instance of the mobile application client, thereby immediately implementing the custom rule.

[0014] In one embodiment, the computing system, the non-transitory computer-readable medium further comprises instructions that, when executed by at least the processor, cause the computing system to formulate 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 send 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 the characteristic of the particular user account to be compared with the defined characteristic 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, on a mobile application server, custom rules 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, when executed by at least the processor of the computer, further cause the computer to define characteristics of a user account for which the mobile application client will implement the custom rules; 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, enabling the instance to implement the custom rule when 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 functionality of the custom rule to be performed locally by the instance of the mobile application client, thereby immediately implementing 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 explanation 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. [Figure 2] 1 illustrates one embodiment of a mobile application runtime environment associated with implementing custom validation and business logic (custom rules) scripting. [Figure 3]1 illustrates one embodiment of a method associated with implementing custom validation and business logic (custom rules) scripting. [Figure 4] FIG. 1 illustrates an exemplary script authoring system associated with implementing custom validation and business logic (custom rules) scripting. [Figure 5] 1 illustrates one embodiment of a method 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 method 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] 10 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 implementing 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 the script editor. [Figure 12] 1 illustrates an example embodiment of a mobile application script editor GUI. [Figure 13] 1 illustrates an exemplary 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 exemplary 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 exemplary 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 INVENTION

[0020] Detailed Description Described herein are systems and methods for custom validations and scripts for mobile applications that can be executed in the mobile application regardless of whether the mobile application is running in online or offline mode. Oracle® CX Mobile Applications Platform Mobile application systems such as, but 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 such as scalability, login and security, application updates, application user interfaces, and / or user experience patterns, in addition to the development of horizontal mobile applications ("general purpose" applications designed to be used by many different types of users and businesses) and vertical mobile applications ("vertical mobile applications" built to provide specific functionality and processes unique to a particular user or business). It may be provided for both "purpose-built" applications.

[0021] Business entities may implement mobile applications to enhance business productivity. Mobile applications targeting various business objectives, such as customer relationship management (CRM), are offered by many vendors and may 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 desire to extend or modify mobile applications to address business situations unique to their organization, personnel, geography, customers, or other aspects. Accordingly, some mobile applications may be customized to include custom business logic and / or validations that are 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.” While mobile applications, such as those implemented on the Oracle® CX platform, may be customized to some extent by, for example, adding new standard and / or custom objects, customizing page layouts, configuring saved searches, and managing application settings, 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 the required validation, leading to downstream impacts with inaccurate data.

[0023] Often, business users work in areas with no or poor network connectivity, during which time their mobile devices 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 custom business logic and validations are implemented on the server side of a mobile application, loss of network connectivity may block the mobile client's access to these custom rules and may also block 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 perform transactions with minimal validations native to (i.e., included in) the mobile application client, but custom validations and business logic are not applied or enforced until data is synchronized from the mobile application to the server.

[0024] For example, a salesperson may use a mobile application with the mobile application operating in offline mode during the day. As the salesperson visits their respective stores, they sell various promotional items and / or enter 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 being performed in offline mode has a contractually binding effect (such as taking an order at a store), it is important that all validations be performed at the time such a transaction is performed. In another example, if a transaction being performed in offline mode includes a promotional discount (enforced by custom business logic), that discount should be reflected in the order total. By the time the sales rep returns to the distribution center, it is too late to perform any custom business logic or custom validation enforcement.

[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 that 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 enable 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 enable data validation at transaction execution time, ensuring that data meets any or all contract requirements regardless of network connectivity status. The systems and methods described herein improve data validation in mobile applications. Validated data also ensures good quality data input into the system, which in turn ensures better results in business intelligence and artificial intelligence systems that utilize the input data. The systems and methods described herein also enable 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 enable immediate validation, instead of validation that occurs later in asynchronous mode. Immediate validation provides users with a greatly improved user experience and usability of mobile applications.

[0027] -Example environment for custom rules for mobile apps- 1 illustrates one 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 by a network 110 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). There may be many mobile devices 120 connected to the mobile application server system 105. In one embodiment, most users of a mobile application will have a dedicated mobile device 120, so 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. 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 rule scripting module 150, which 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 mobile application client instance 173, a second mobile device 124 is configured with mobile application client instance 174, and a third mobile device 126 is configured with mobile application client instance 175. Two mobile devices 125 are configured with mobile application client instance 2 175, and an 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 devices 115 are 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 them may be referred to as "clients." Depending on the computing services they provide, 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 material 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 / material 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 the 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 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 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 rule 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 the 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, mobile application client 170 is a client application for accessing and manipulating data stored in data store 135 in association with the functionality provided by mobile application module 145. For example, mobile application client 170 may be a client application for an enterprise sales and service tool that hosts data on data store 135. In one embodiment, mobile application client 170 is an Oracle® CX mobile client, and the mobile application server system hosts the Oracle® CX cloud service. Client App The application may be downloaded from a third-party mobile application distributor, 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 view 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 server-side 205 and client-side 210 components.

[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 or 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 created 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. When 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 data operations on the mobile application server 105 by generating application programming interface (API) requests to one or more data providers (such as REST data providers or XML data providers) of the web interface server 140 in conjunction with the configuration manager 235 or other network interface module. In one embodiment, the requests are remote data exchanged between the mobile application client 170 and the web interface server 140 using JavaScript Object Notation (JSON) as the data exchange format. 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, which 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 behavior of the mobile application executed by the data control module 260. The custom rule execution engine 250 then executes the script to enforce the custom rule in conjunction with the behavior 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 GraalJS engine may include a JavaScript execution engine such as GraalJS (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). Furthermore, 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, custom rule execution 215 may include an expression language execution engine. In another embodiment, custom rule execution engine 215 includes an Apache Groovy execution engine. Good too.

[0045] Note that the scripting engine 250 may also implement 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 the execution of custom rules by the scripting engine 250. Exemplary custom rules that may be implemented client-side include: (1) conditionally making a field required 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 a certain upcoming date is greater than "today," checking that Revenue = Quantity * Amount - Discount, or checking 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 a field or based on validation actions performed on a field. and (5) automatically populating fields based on formulas expressed in scripts; (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; and (7) disabling server-side scripts for transactions running on a mobile application client.

[0048] In one embodiment, local data store 265 may be included in mass data storage 1670 or memory 1680 of mobile device 1600 (as shown and described with reference to FIG. 16 ). Mobile application client 170 may store data from mobile application server system 105 (e.g., retrieved from data store 135) in local data storage 265. Data in local data storage 265 may be manipulated by a user of mobile application client 170 through view controller 255. In one embodiment, view controller 255 controls the presentation of a graphical user interface (GUI) for mobile client application 170, for example, using display 1650 and input device 1660 (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 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 offline mode, and modifications to the data are later synchronized with the server side when connectivity is restored.

[0050] -Example of how to script custom rules- 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 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 method steps (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 computer-implemented method steps described herein. These steps may include (i) retrieving any necessary information, (ii) calculating, determining, generating, classifying, or otherwise creating any data, and (iii) storing any calculated, determined, generated, classified, or otherwise created data. References to storage or storing refer to storage as data structures 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] 3 illustrates one embodiment of a method 300 associated with implementing custom validation and business logic (custom rule) scripting. In one embodiment, 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 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, mobile application server instance 215 is implemented by mobile application server system 105. In one embodiment, 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 specified 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 begin. 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 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, a processor accepts a set of user inputs that describe the behavior 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 that indicate that the custom rules are satisfactory, such as user inputs that indicate 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 scripting engine 250) to implement the custom rules without requiring modifications to the build of the mobile application client. For example, user input can be a JavaScript script, 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 to create or modify a 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 implementation on the mobile application client, processing at processing block 310 is complete and processing continues at processing block 315.

[0059] In 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 associates the user inputs with the custom rule and stores them in a database, for example, in mobile repository 225. In one embodiment, the characteristics include one or more of: (i) a location, such as a region, country, province or state, or city, to which the custom rule is associated with the transaction; and (ii) a business role (e.g., sales representative, business practice supervisor, route operations manager, etc.) to which the user is executing the custom rule and whose job function or authority the custom rule is associated. In one embodiment, the default value for location is “global,” indicating applicability to all locations, and this 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 regions that can be assigned to the custom rule and accept selection of a region. In one embodiment, the default value for business role is “all employees,” indicating applicability to all users of the system, and this value may be changed to a more specific group of user roles in response to user input. For example, the processor may cause a graphical user interface to display a selectable (and possibly searchable) list of all available user roles (i.e., job titles or responsibilities) that can be assigned to a custom rule. The processor may parse and record any selections that change the default values. The processor may associate the location and business role to which the custom rule pertains with the custom rule and record them in the mobile repository 225, e.g., in a common data structure.

[0060] 4, scripts 410 are associated in the database with a property namespace. For example, some of the scripts 410 are associated with a "region" namespace 415, and 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, namespaces may be striped by region 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 custom rules. If so, processing at process block 315 is complete and processing continues 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 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 provided login credentials, where the user account is identified based on one or more of a username and 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 from the mobile repository 225 the records of the locations and business roles to which the custom rule is associated. 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 apply 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 the locations and / or assigned business roles match 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 the location and / or assigned business roles do not match 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, and 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 custom rule should be implemented, 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® Content Repository Rest Services, 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, for example, 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 instance 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 offline mode operation - 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, method 500 is a computer-implemented method for enabling offline client-side enforcement of custom rules in offline mode operation. In one embodiment, the steps of 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, mobile application client instance 170 is implemented by a mobile device 120. In one embodiment, mobile device 120 is a dedicated mobile device (such as mobile device 1600 shown and described with reference to FIG. 16) configured with custom rule scripting logic 1605. References to a processor in method 500 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, and (iii) 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 indicating that the mobile application client instance 170 has resumed network connectivity with the mobile application server instance 215 and / or the mobile application server system 105 after operating in offline mode, or analyzing stored data indicating that. In one embodiment, the method 500 begins in response to the completion of the method 300. The method 500 begins at START block 505 in response to analyzing 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 processing 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 network connectivity to determine whether connectivity should be classified as an “unavailable” or “offline” status, or otherwise indicates 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 the 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, poor, 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 testing the 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 saved for later processing, for example, in the local data store 265 or the file system 245.Once the processor has completed monitoring network connectivity between the mobile application client instance and the mobile application server instance in this manner, 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, monitored data is retrieved from storage and evaluated to determine the status of the connection. 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 that 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 offline mode 530 ends 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 at processing block 535.

[0074] Following processing block 525, the mobile application client instance 170 is operating in offline mode 530. At processing block 535, while the mobile application client instance is operating in offline mode 530, the processor accepts user input to the mobile application client instance, which 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 event (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 identifying one or more custom rule scripts associated with the created / modified objects, the corresponding custom rule script will be executed for the associated objects. 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 at processing 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 implement 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 perform the ordered 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, but does not necessarily, imply instantaneous execution. Rather, Here, the immediate implementation or effect of custom rules exhibits the opposite 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 the 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 processing 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 mobile application client 170 in online mode. In one embodiment, the processor then configures mobile application client instance 170 to stop accessing and manipulating the local copy of the data locally within mobile application runtime 240. The processor also configures mobile application client instance 170 to stop persisting new changes for later synchronization. The processor then configures mobile application client instance 170 to start or resume accessing and manipulating data hosted on mobile application server system 105. The processor further configures mobile application client instance 170 to apply a server-side copy of the custom rules to the operation of client instance 170 to ensure that the latest version of the custom rules is applied. Once the processor has completed placing the instance of 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 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] -Providing 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, mobile application server instance 215 is implemented by mobile application server system 105. In one embodiment, 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 network connectivity with a mobile application server instance 215 and / or mobile application server system 105 after operating in 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 processing block 610.

[0084] At processing block 610, the processor constructs queries to retrieve supporting data from the mobile application database to be queried during execution of the custom rule. In one embodiment, the processor analyzes the custom rule to determine what data sets the custom rule may query. For example, the processor may identify the 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 constructing queries to retrieve supporting data from the mobile application database to be queried during execution of the custom rule, 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 sets and stores the data sets 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 the supporting data to the mobile application. The processor retrieves the dataset from storage in data store 135. The processor constructs a message, such as a REST request or catalog download, that includes the dataset. The processor then transmits the dataset, comprising supporting data for operation of the custom rule, to 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 analyze the custom rule and determine that execution of the custom rule may cause a query to retrieve the credit rating for the customer. The processor then creates and executes a query to retrieve a data set of all credit ratings for the customer from data store 135 and transmits it to the client side.

[0088] FIG. 7 illustrates a portion 700 of method 500 that includes 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), e.g., 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 above with reference to FIG. 5. Additionally, once the processor has thus completed receiving user input to the instance of the mobile application client that triggers 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 method 300 are performed by a mobile application server instance 215, and more particularly, by 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 (e.g., computing device 1505) configured with custom rule scripting logic 1530.

[0090] Method 800 may be initiated based on various triggers, such as (i) the completion of process 300, resulting in the creation of one or more new custom rules; or (ii) receiving a signal over a network or analyzing stored data indicating that one or more custom rules have been 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 fills in fields of the new entry with script that defines 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 continues to processing block 815.

[0092] At processing block 815, the processor increments the current version number of the database. In one embodiment, metadata in the rules database 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 continues 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 equal 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 database contents. In one embodiment, the processor retrieves the current version number from the metadata of the server-side rule database. The processor parses a REST request (e.g., a request to log in) 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. Once the processor has completed this 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. 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] At 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 at decision block 825 is complete, 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 at decision block 825 is complete, and processing proceeds to END block 835, where process 800 ends. Note that this determination is a preliminary 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 more detailed processing 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 any previous versions 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 because there are no relevant updates. Once the processor has completed this comparison of the characteristics of the particular user account with the defined characteristics 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, if applicable, may also be downloaded at the same time. In essence, scripts are bundled with the mobile application update, and only 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 - 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 refines the step of creating custom rules in the method 300. In one embodiment, the steps of the method 900 are performed by the mobile application server. The custom rules scripting logic 1530 is executed by a mobile application server instance 215, 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 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, for example, by completing 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 start or completion of processing in 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 applies. 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 rule / script editor client 180. The processor then records the association between the object and the custom rule in the 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 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) the user-input selection of the trigger event that will trigger the execution of the rule. The processor then records the association between the object, the custom rule, and the trigger event in the metadata of the object, the custom rule, or both. The association can be later analyzed, for example, by data control module 260 or scripting engine 250. Processing at processing block 915 then completes, and processing continues 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 the custom rule 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] -Example 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, 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 (e.g., computing device 1505) configured with custom rule scripting logic 1530.

[0103] Method 1000 may be initiated based on various triggers, such as receiving a signal over a network or analyzing stored data indicating that rule / script editor client 180 has accessed a custom rule. Method 1000 begins at START block 1005 in response to analyzing a 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 rule / script editor client 180. Note that generating instructions to support rule / script editor client 180 may be a substantially continuous process as a user interacts with rule / script editor client 180 to effect changes to both rule / script editor client 180 and 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 to the mobile application composer 220. In response, the processor sends instructions to the client computing device 115 to present the 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 then completes, and processing continues 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 repeat 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 the rule / script editor client 180 running on the 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 the 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. These 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. These 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 a synchronization after offline mode operation ends and connectivity is restored.

[0110] In one embodiment, script editor 405 may be operated using a GUI. FIG. 11 shows one example embodiment of a "Create a Script" dialog 1100 for creating a new custom rule script using 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 region field 1115 is "All," indicating that the script will operate in all geographic regions. However, it may be desirable for the script to function only in a particular geographic region. Thus, the user can select a geographic region for the script. The script will then only work for users whose geographic region is selected in 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 runtime. By selecting the Create button 1125, the user can initialize a new script in the system and begin editing. By selecting the Cancel button 1130, the new script is canceled. The menu closes without creating a script.

[0112] 12 shows an example embodiment of a mobile application script editor GUI 1200. In one embodiment, the script editor GUI 1200 is an interface for operating 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, and 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, collapses menu 1205 to show that four events may be selected as trigger events for that 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 view 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 trigger event. In one embodiment, the scripts menu lists all scripts associated with a given object-event combination.

[0113] Once a new script is initialized or created as described above with respect to FIG. 11 , an administrator or authorized user can write and edit the new script in edit area 1225. Edit area 1225 is a free-form text editor. Changes made in edit area (or script box) 1225 are persisted to storage, e.g., mobile repository 225, in response to user input indicating selection of save button 1230. Sub-features of an object, such as fields and child objects, can be selected using mobile application object details menu 1235. Areas (including sub-areas) other than the area selected in area field 1115 of FIG. 11 may be assigned using 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 assigned roles menu 1245 to assist with 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 characters "_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 is automatically added to the system functions list. Once included in the list, utility functions can be accessed from any custom script. An example of the format of a utility function is:

[0115]

number

[0116] In one embodiment, to assist in selecting the correct object and field values, the user may type "control+space" (or other key combination) within the editing 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 within the editing 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 a script. By typing "control+space" and scrolling down to the "System Functions" section of the list, the user reveals not only user-created system functions, but also a list of APIs that the user may select and insert into the script. The user can use these APIs to determine the host device's operating system, the device's current geographic location (e.g., via the Global Positioning System (GPS)), and so on. 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 validate button 1260 to begin the script validation process. In one embodiment, the processor parses the script configured in the edit area 1225 and performs a JavaScript syntax check. A successful syntax check indicates that the script will execute (although the executed script may not function as expected due to non-syntactical 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 validate button, the processor may further parse the script configured in the edit area 1225 and 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 few 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 whitespace outside strings and comments Rules: no-spaces - no multiple spaces allowed; no-space-before-semi - no space before semicolons; no-trailing-spaces - end of line do not allow trailing whitespace; comma-spacing- enforce spacing before and after a comma; eol-last- Enforce new lines at end of file, without multiple empty lines;global-strict-global Requires or disallows the "use strict" pragma in 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 a security risk 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) rules that enforce validations and rules both online and offline. By writing Salesforce.com trademark (TM) scripts, users can configure the mobile application system to meet business requirements. 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 required when a new "Opportunity" object is created in the mobile application system.

[0121] -Example client GUI- 13 illustrates an exemplary 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 indicates no 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 GUI 1300 is configured in accordance with the systems and methods described herein to locally execute custom rule scripts. For example, this mobile application client instance 170 is configured to execute a custom rule script, OnFieldValueChange, for the sales stage of an opportunity object. This custom rule script requires a value to be entered in the revenue amount field to advance the sales stage beyond opportunity (stage 2) 1315 to construction 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 construction 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 offline mode. As noted above, this is confirmed by the cellular signal indicator 1305 and the Wi-Fi signal indicator 1310, each of which indicates no signal and therefore no 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 locally execute custom rule scripts. 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 look up and retrieve that account's address information 1410. Note that this data is supporting data for account address lookup that 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. Note that this query can be completed immediately without delay for accessing a remote server.

[0126] In the second example, purchase order line 1415 includes a Blue Boar Energy drink in purchase 2. The mobile application client instance 170 uses both a custom rule script (which executes an OnFieldValueChange in the Blue Boar in the item field) to reduce the price according to the rule. The time horizon for this promotion is short and would not justify customizing and rebuilding 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 at BeforeSave when the total exceeds $700. Credit information about the customer is supporting data that is pre-populated along with the custom script.

[0128] -More illustrative use cases- In one embodiment, a set of custom rules is applied to opportunity objects. Upon initial creation of an 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 in (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 a certain opportunity type, it cannot be changed - in other words, the opportunity type is "read-only". When a field value change is made by a mobile application client operating in offline mode, the mobile application client will - Allows you to instantly enforce conditional field requirements and allows multiple For example, if the opportunity type is transportation, the required fields include an operations start date field. In another example, if the opportunity type is contract logistics, the required fields are: (a) a "Business Type" field that indicates the nature of the opportunity with a list of values ​​"New," "Growth," and "Retention"; (b) a "Site" field that describes the general location of the opportunity with a list of values: "APAC" (Asia Pacific), "EMEA" (Europe, Middle East, and Africa), "NA" (North America), and "LATAM" (South America); (c) a "Territory" field that further subdivides 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 an object by a mobile application client operating in offline mode, the mobile application The mobile application client can immediately enforce the requirements for transportation opportunities (opportunity type = transportation) that the revenue field is required if the sales stage is greater than 2. The mobile application client will prohibit 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 changes are not immediately submitted 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. Upon 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 required, 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. When a field value for an opportunity stage is changed 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 the opportunity stage is greater than 2, and (2) the “partner” field be required when the opportunity stage is greater than 3.

[0130] In one embodiment, the custom rules are applied to the "contact" object. Upon initial creation of the object by a mobile application client operating in offline mode, the mobile application client may apply the account field. The account value may be immediately required to be a required field, and the mobile client may present an error message in response to an attempt to edit any other field before the account value has been provided.

[0131] In another embodiment, the custom rule is applied to the "contact" object. When an account field value is set for a contact in a mobile application client operating in offline mode (on field value change), the mobile application The application client can immediately set the default address field of the 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 saving changes to the lead object 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 who "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 only if an account credit status is a certain value or not, or if the value of some custom field X is >0, or otherwise impose restrictions on order acceptance; (2) allow a 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 retrieving 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 is expired - expiration 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 shopping cart submission unless a purchase order (PO) number - a customer-defined custom field - is populated by a sales agent user in the mobile application client; (9) Implement contractual barriers to limit negotiations within acceptable limits, for example, prevent contact information from being saved unless shelf share is within a range of 20% to 100%.

[0134] Additional 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 when at least 50 items X are added to a cart (or purchase order) at list price, and automatically add a quantity of Y items in Z quantities to the cart at zero price. This type of promotion may be along the lines of "If you add two items from group A and one item from group B, get a free item C." Thus, if a sales representative using the mobile application client adds at least two items from A and one item from B, item C will be automatically added to the order (even when the mobile application client is operating in offline mode). If these items are removed, item C will be automatically removed.

[0135] Additionally, 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 to or applied to a single 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] Additionally, custom rules for the mobile application client's consumer goods configuration may be applied for various other validation purposes, such as operating 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 product lines are allowed to be paid for using a given payment type.

[0137] The above example use cases further demonstrate 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 offline mode; that is, the custom rules can be implemented without delay until the mobile application client returns online and synchronizes with the mobile application server. Furthermore, custom rules, when implemented using a REST architecture, are less prone to failure, thus allowing custom rules to be implemented immediately, even while the application is operating in online mode using REST communication with the mobile application server. Furthermore, the logic for each of these use cases is completely separate from the core mobile application client functionality, allowing for rapid manipulation, deployment, removal, and other management of 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 promotion. 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, several 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) fields (custom fields) have default values; (a) odds = medium (values ​​to select from: low, medium, high); (b) opportunity type = server (values ​​to select 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. Implement a custom rule that creates a task, assigns it to the user who signed it, 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 immediate 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 because custom rules are already applied on the client side and do not need to be executed on the server side during synchronization operations. One important source of these technical improvements is the advantageous immediate implementation of custom rules made possible by the present invention's relocation of custom rule actions from server-side execution to non-conventional client-side execution (e.g., in scripting engine 250). These technical improvements may also be caused by the non-conventional copying of supporting data for custom rules (for all potential custom rule actions) from the server side to client-side local storage.

[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 implementing 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 agnostically 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. Furthermore, mobile application client instances configured for different roles and / or different locations can run on the same build or version of the mobile application client. is still running while allowing for separate custom functionality.

[0158] The present invention allows users to seamlessly use applications 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 manner. Ensuring that data is validated regardless of online or offline mode also ensures that 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 mobile applications 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 significantly improved user experience.

[0159] Advantageously, the hardware used to implement the mobile system need not 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 interpreted programming languages, such as scripting languages.

[0161] In complex systems, 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 on a non-transitory computer-readable medium. The modules are configured with stored software instructions that, when executed by at least a processor accessing 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 in conjunction 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 through 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- 15 illustrates an exemplary computing device configured and / or programmed with one or more of the example systems and methods described herein and / or equivalents. The exemplary computing device may be a computer 1500 including a processor 1510, a memory 1515, and input / output ports 1520 operatively 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 rules) scripting for mobile application offline mode operation similar to the logic, systems, and methods shown 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, logic 1530 or a computer is a means (e.g., structure: hardware, non-transitory computer-readable medium, firmware) for performing the described actions. In some embodiments, the computing device may be a server operating in a cloud computing system, a server configured in a Software as a Service (SaaS) architecture, a smartphone, a laptop, a tablet computing device, etc.

[0166] The means may be realized, for example, as an ASIC programmed to perform custom validation and business logic (custom rule) 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 means (e.g., hardware, non-transitory computer-readable media storing executable instructions, firmware) for performing custom validation and business logic (custom rule) 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 memory and / or non-volatile memory. Non-volatile memory may include, for example, ROM, PROM, etc. Volatile memory may include, for example, RAM, SRAM, DRAM, etc.

[0169] Storage disk 1535 may be operatively connected to computer 1500, for example, via input / output (I / O) interface (e.g., card, device) 1545 and input / output port 1520. Disk 1535 may be, for example, a magnetic disk drive, solid-state disk drive, floppy disk drive, tape drive, Zip drive, flash memory card, memory stick, etc. Additionally, disk 1535 may be a CD-ROM drive, CD-R drive, CD-RW drive, DVD ROM, etc. Memory 1515 may store, for example, processes 1550 and / or data 1540. Disk 1535 and / or memory 1515 may store an operating system that controls and allocates resources of 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 example systems and methods described herein and / or equivalents is illustrated. In one example, the mobile device 1600 may include custom rule 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 at 1620 in FIG. 16 . 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, pointing device, voice activation, and / or other input device. Signal processing and / or control circuitry 1620 and / or other circuitry (not shown) within 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 nonvolatile manner, such as, for example, in magnetic, optical, and / or solid-state storage devices, including HDDs, DVDs, and / or SSDs. The cellular phone 1600 may be connected to memory 1680, such as RAM, ROM, low-latency nonvolatile memory such as flash memory, and / or other suitable electronic data storage. The mobile device 1600 may also support connectivity with 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 nonvolatile manner. In one embodiment, the exemplary system and method may be implemented using the WLAN network interface 1690, although other configurations are possible.

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

[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, the computer instructions 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, example methods may be implemented using fewer than all of the illustrated blocks. 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 term and may be used to implement it. The examples are not intended to be limiting. Both singular and plural terms may be found 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. Furthermore, 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 ROM.

[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 memory, storage, 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, "computer-readable medium" or "computer storage medium" refers to a non-transitory medium that stores instructions and / or data that, when executed, are configured to perform one or more of the disclosed functions. In some embodiments, data may function as instructions. Computer-readable 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 tape, other magnetic media, application-specific integrated circuits (ASICs), programmable logic devices, compact disks (CDs), other optical media, random access memory (RAM), read-only memory (ROM), memory chips or cards, memory sticks, solid-state storage devices (SSDs), flash drives, and other media with which a computer, processor, or other electronic device can function. Each type of media, when selected for implementation in an embodiment, may include stored instructions of an algorithm configured to perform one or more of the disclosed and / or claimed functions.

[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 another logic, method, and / or system to perform a function or action 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, etc., 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 implements 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 functions: (a) a logic circuit configured to implement a logic function; (b) a logic circuit configured to implement a logic function; (c) a logic circuit configured to implement a logic function; (d) a logic circuit configured to implement a logic function; (e) a logic circuit configured to implement a logic function; (f) a logic circuit configured to implement a logic function; (g) a logic circuit configured to implement a logic function; (h) a logic circuit configured to implement a logic function; (i) a logic circuit configured to implement a logic function; (ii) a logic circuit configured to implement a logic function; (iii) a logic circuit configured to implement a logic function; (iv) a logic circuit configured to implement a logic function; (v) a logic circuit configured to implement a logic function; (vi) a logic circuit configured to implement a logic function; (vii) a logic circuit configured to implement a logic function; (v ...

[0191] An "operable connection," or a connection through which entities are "operably connected," is a connection through which signals, physical communications, and / or logical communications may be sent and / or received. An operable connection may include 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 people, one or more computers or other devices, or a combination thereof.

[0193] While 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. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing various aspects of the subject matter. Accordingly, the disclosure is not limited to the specific details or illustrative examples shown and described. Accordingly, 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 transitional term in the claims.

[0195] To the extent 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 applicant intends to indicate "A or B only, but not both," the term "A or B only, but not both" would be used. Thus, the use of the term "or" herein is inclusive, not exclusive.

Claims

1. 1. A computer-implemented method comprising: storing a custom rule script in a mobile application client, the custom rule script describing custom rules that extend the behavior of the mobile application client to validate data entered into the mobile application client, the method further comprising: While the mobile application client is in offline mode, accepting user input via the mobile application client to create or modify an object; determining that the custom rule script is associated with a trigger event resulting from the user input to create or modify the object; and immediately executing the custom rule script upon occurrence of the trigger event to validate the user input, the custom rule script being executed before the user input is used to create or modify the object, the method further comprising: synchronizing the objects created or modified by the validated user input with a mobile application server when the mobile application client is in online mode; Before entering the offline mode, analyzing the custom rule script to identify data sets accessed by queries in the custom rule script; loading the data set into the mobile application client; The computer-implemented method, wherein immediately executing the custom rule script to validate the user input further includes executing the custom rule script to complete the query by using the data set at the mobile application client.

2. The computer-implemented method may further comprise, prior to storing the custom rule script in the mobile application client: creating, on the mobile application server, the custom rule script describing the custom rules for execution against transactions executed on the mobile application client, the custom rule script being written in an interpreted programming language, and the mobile application client, when operating in the offline mode, is configured to implement the custom rule script by executing the custom rule script using a script execution engine of the mobile application client, the computer-implemented method further comprising, prior to storing the custom rule script on the mobile application client: and defining, on the mobile application server, characteristics of a user account for which the mobile application client will implement the custom rule script, the characteristics describing (i) a geographic location for which the custom rule applies to a transaction, or (ii) a business role for which the custom rule applies, the computer-implemented method further comprising, prior to storing the custom rule script on the mobile application client: in response to a connection being established between the mobile application client and the mobile application server for a particular user account; identifying whether the particular user account has the characteristic; the mobile application server determining that the mobile application client should implement the custom rule script based at least in part on the particular user account having the characteristic; 2. The computer-implemented method of claim 1, further comprising: in response to determining that the mobile application client should implement the custom rule script, transmitting the custom rule script from the mobile application server to the mobile application client to enable the mobile application client to implement the custom rule script during transaction execution when the mobile application client is operating in the offline mode.

3. 2. The computer-implemented method of claim 1, wherein the custom rule script is written in an interpreted programming language, the method further comprising executing the custom rule script in a script execution engine of the mobile application client when operating in the offline mode.

4. 4. The computer-implemented method of claim 1, further comprising implementing custom functionality for a first role or location using the custom rule script that is different from functionality for a second role or location on one build of the mobile application client.

5. 5. The computer-implemented method of claim 1, further comprising: executing the custom rule script with the mobile application client operating in the offline mode to conditionally make a field of the object required, conditionally make the field of the object read-only, conditionally show or hide the field of the object in a graphical user interface, or conditionally show or hide the field of the object in a graphical user interface in response to a condition being met.

6. 6. The computer-implemented method of claim 1, further comprising displaying results of the custom rule script in a graphical user interface of the mobile application client in response to the user input while the mobile application client is operating in the offline mode.

7. 1. A computing system comprising: a processor; a memory operatively connected to the processor; a non-transitory computer-readable medium operatively connected to the processor and the memory and storing computer-executable instructions, the computer-executable instructions, when executed by at least the processor, causing the computing system to: and storing a custom rule script in a mobile application client, the custom rule script describing custom rules that extend the operation of the mobile application client to validate data input to the mobile application client, the computer-executable instructions further, when executed by at least the processor, causing the computing system to: causing the mobile application client to enter an offline mode; causing the custom rule script to be executed to validate user input via the mobile application client to create or modify an object while the mobile application client is in the offline mode, the custom rule script being executed by the mobile application client prior to creating or modifying the object with the user input; and the computer-executable instructions, when executed by at least the processor, further cause the computing system to: When the mobile application client is in online mode, synchronizing the objects created or modified by the validated user input with a mobile application server; Before entering the offline mode, identifying a data set accessed by a query in the custom rule script; loading the data set into the mobile application client; Implementing the custom rule script to validate the user input includes executing the custom rule script to complete the query by using the data set at the mobile application client.

8. The non-transitory computer-readable medium further includes, when executed by at least the processor, causing the computing system to, before storing the custom rule script in the mobile application client: and instructions to cause the custom rule script to be created on the mobile application server, the custom rule script being written in an interpreted programming language, and the mobile application client, when operating in the offline mode, is configured to implement the custom rule script by executing the custom rule script using a script execution engine of the mobile application client, the non-transitory computer-readable medium further comprising, when executed by at least the processor, causing the computing system to, before storing the custom rule script in the mobile application client: defining, on the mobile application server, characteristics of a user account under which the mobile application client will implement the custom rule script; in response to a connection being established between the mobile application client and the mobile application server for a particular user account; Identifying whether the particular user account has the characteristic; causing the mobile application server to determine that the mobile application client should implement the custom rule script based at least in part on the particular user account having the characteristic; 10. The computing system of claim 7, further comprising instructions that, in response to determining that the mobile application client should implement the custom rule script, cause the mobile application server to transmit the custom rule script to the mobile application client, and enable the mobile application client to implement the custom rule script to validate the data during transaction execution when the mobile application client is operating in the offline mode.

9. 9. The computing system of claim 7 or 8, further comprising a mobile device, wherein the non-transitory computer-readable medium further includes instructions that, when executed by at least the processor, cause the computing system to execute the mobile application client on the mobile device.

10. 10. The computing system of claim 7, wherein the computing system is a mobile device, and the non-transitory computer-readable medium further includes instructions that, when executed by at least the processor, cause the mobile device to execute the mobile application client.

11. 8. The computing system of claim 7, wherein the custom rule script is written in an interpreted programming language, and the computer-executable instructions that cause the computing system to implement the custom rule script further cause the computing system, when operating in the offline mode, to execute the custom rule script using a script execution engine of the mobile application client.

12. The non-transitory computer-readable medium, when executed, further causes the computing system to: determining that a trigger event occurs due to the user input; 12. The computing system of claim 7, further comprising instructions for searching a set of custom rules to identify the custom rule script associated with the trigger event for the object.

13. A program comprising computer executable instructions, which when executed by at least a processor of a computer, cause the computer to perform the method of any one of claims 1 to 6.

Images