User-defined Secure Remote Code Execution from No-code Platforms

TECHNICAL FIELD

This disclosure relates to user-defined secure remote code execution from no-code platforms.

BACKGROUND

No-code development platforms allow programmers and non-programmers to create application software via graphical user interfaces as opposed to conventional programming techniques. Thus, no-code platforms enable business technologists and citizen developers of all skill levels to build power applications and workflows for their organizations without the need to write any code. While these no-code platforms are often powerful and expressive, they have limited capabilities. For example, conventional no-code platforms struggle with advanced functionality such as tying into existing code modules of business logic and/or calling external services.

SUMMARY

One aspect of the disclosure provides a method for user-defined secure remote code execution from no-code platforms. The method, when executed by data processing hardware causes the data processing hardware to perform operations. The operations include receiving a trigger interaction indication indicating a first graphical user interaction by a user within a no-code environment. The operations also include, in response to receiving the trigger interaction indication, establishing a trigger condition for an application generated by the no-code environment. The operations include receiving an action interaction indication indicating a second graphical user interaction by the user within the no-code environment. In response to receiving the action interaction indication, the method includes defining an action response for the application when the trigger condition is satisfied. The action response includes a function call calling a function of a script. The script is generated within a low-code environment. The operations include executing the application.

Implementations of the disclosure may include one or more of the following optional features. In some implementations, the second graphical user interaction includes selecting the function of the script from a plurality of functions of the script. In some of these implementations, each script of the plurality of functions is generated within the low-code environment.

In some examples, the operations further include, after receiving the action interaction indication, receiving, from the low-code environment, one or more parameters associated with the function of the script, receiving, from the low-code environment, data type information for at least one of the one or more parameters, and, for each respective parameter of the one or more parameters, querying the user for an expression that, when evaluated, satisfies the respective parameter. In some of these examples, the function call calls the function of the script using an evaluation of the expression for each respective parameter.

Optionally, the application is associated with a first set of permissions, the script is associated with a second set of permissions, and the second set of permissions different than the first set of permissions. The operations may further include determining the second set of permissions, requesting, from the user, approval for the second set of permissions, and receiving, from the user, permissions approval approving the second set of permissions.

In some implementations, while the application is executing, the application determines whether the trigger condition has been satisfied. The application may also, when the trigger condition has been satisfied, call, using the function call, the function of the script and receive, from the function, a result comprising an execution status and a data response. In some implementations, the data response includes a structured data response that includes one or more fields and type information for at least one field of the one or more fields. In some examples, the application, based on the result, calls a second function. While the application is executing, the application may further use the received data response as an input to a process. The application may call the function via an application programming interface (API). Executing the application may include deploying the application for a second user, the second user different than the user.

Another aspect of the disclosure provides a system for providing user-defined secure remote code execution from no-code platforms. The system includes data processing hardware and memory hardware in communication with the data processing hardware. The memory hardware stores instructions that when executed on the data processing hardware cause the data processing hardware to perform operations. The operations include receiving a trigger interaction indication indicating a first graphical user interaction by a user within a no-code environment. The operations also include, in response to receiving the trigger interaction indication, establishing a trigger condition for an application generated by the no-code environment. The operations include receiving an action interaction indication indicating a second graphical user interaction by the user within the no-code environment. In response to receiving the action interaction indication, the method includes defining an action response for the application when the trigger condition is satisfied. The action response includes a function call calling a function of a script. The script is generated within a low-code environment. The operations include executing the application.

This aspect may include one or more of the following optional features. In some implementations, the second graphical user interaction includes selecting the function of the script from a plurality of functions of the script. In some of these implementations, each script of the plurality of functions is generated within the low-code environment.

The details of one or more implementations of the disclosure are set forth in the accompanying drawings and the description below. Other aspects, features, and advantages will be apparent from the description and drawings, and from the claims.

DESCRIPTION OF DRAWINGS

FIG. 1 is a schematic view of an example system for providing user-defined secure remote code execution from no-code platforms.

FIGS. 2A and 2B are schematic views of example user interactions with a no-code environment.

FIGS. 3A-3C are schematic views of additional example user interactions with the no-code environment.

FIGS. 4A and 4B are schematic views of example user interactions for calling a function within the no-code environment.

FIG. 5 is a schematic view of a user interaction to authorize permissions of a script within the no-code environment.

FIG. 6 is a schematic view of exemplary components of the system of FIG. 1.

FIG. 7 is a flowchart providing an example arrangement of operations for a method of providing user-defined secure remote code execution from no-code platforms.

FIG. 8 is a schematic view of an example computing device that may be used to implement the systems and methods described herein.

Like reference symbols in the various drawings indicate like elements.

DETAILED DESCRIPTION

No-code development platforms allow programmers and non-programmers to create application software via graphical user interfaces as opposed to conventional programming techniques. For example, using graphical representations, a no-code environment can allow a user to easily create an “if-this-then-that” automation that triggers on conditional events. Thus, no-code platforms enable business technologists and citizen developers of all skill levels to build power applications and workflows for their organizations without the need to write any code. While these no-code platforms are often powerful and expressive, they have limited capabilities. For example, conventional no-code platforms struggle with advanced functionality such as tying into existing code modules of business logic and/or calling external services.

In contrast to no-code environments, which allow for the programming of applications with no coding whatsoever, low-code environments provide an environment that allows a user the ability to perform some manual coding and scripting while also including visual-based drag and drop elements. That is, low-code environments offer a middle-ground between a no-code environment (i.e., where the user performs no coding) and a pro-code environment (i.e., a traditional fully manual coding environment). Low-code environments are often extensible and offer open application programming interfaces (APIs) to allow interconnectivity and interoperability with other environments.

Implementations herein include systems and methods for user-defined secure remote code execution from a no-code environment. In some examples, a secure remote execution controller allows a user to interact with a no-code environment. In some additional examples, via graphical interactions from the user, the secure remote execution controller establishes a trigger condition for an application generated by the no-code environment. The secure remote execution controller, via additional graphical interactions from the user, defines an action response to the trigger. The action response includes executing a task. For example, the task is sending an email or saving data. In some implementations, the task includes calling a function of a script where the script has been generated via a low-code environment or a pro-code environment. Thus, the secure remote execution module offers a bridge between no-code environments and low-code (or pro-code) environments to provide additional extensibility and automation. Such extensibility enables a wide range of user cases, such as automatically interfacing with a user's calendar to create appointments, reading or writing from an external data source, calling an external machine learning service, etc.

Referring to FIG. 1, in some implementations, a remote code execution system 100 includes a remote system 140 in communication with one or more user devices 10 each associated with a respective user 12 via a network 112. The remote system 140 may be a single computer, multiple computers, or a distributed system (e.g., a cloud environment) having scalable/elastic resources 142 including computing resources 144 (e.g., data processing hardware) and/or storage resources 146 (e.g., memory hardware). A data store 148 (i.e., a remote storage device) may be overlain on the storage resources 146 to allow scalable use of the storage resources 146 by one or more of the clients (e.g., the user device 10) or the computing resources 144.

The remote system 140 is configured to communicate with the user devices 10 via, for example, the network 112. The user device(s) 10 may correspond to any computing device, such as a desktop workstation, a laptop workstation, or a mobile device (i.e., a smart phone). Each user device 10 includes computing resources 18 (e.g., data processing hardware) and/or storage resources 16 (e.g., memory hardware). The data processing hardware 18 executes a graphical user interface (GUI) 14 for display on a screen 15 in communication with the data processing hardware 18.

The remote system 140 executes a secure remote execution controller 150. The remote execution controller 150 includes a no-code backend 160. A first user 12, 12a may communicate with the no-code backend 160 via, for example, a first user device 10, 10a and a no-code frontend 161 provided by the no-code backend 160. For example, the user 12a interacts with the no-code frontend 161 using a first GUI 14, 14a displayed on the screen 15. The combination of the no-code backend 160 and the no-code frontend 161 comprise a no-code environment. As discussed in more detail below, the GUI 14a provided by the no-code backend 160 may be a web-based GUI 14 (e.g., accessed via a web browser) and provides the user 12a with an interactive, visual workspace to build, execute, and publish no-code applications 190. In other examples, the no-code frontend 161 is executed by an application executing on the first user device 10a. The GUI 14a allows the user 12a to drag and drop application routines or sub-routines into an editing area where they may be connected to form an application 190. Notably, the user 12 does not require programming skills to generate the application 190. For example, the user 12a selects one or more trigger conditions 192 (i.e., events such as a row being added to a database) and action responses 194 (e.g., sending a notification) that the application 190 executes in response to a trigger condition 192 being satisfied. The application 190 may interact with data stored at the data store 148. For example, the application 190 may monitor for changes within data stored at the data store 148 for the trigger condition 192 and/or modify data stored at the data store 148 for the action response 194. The user 12a may select a data source for the application 190. For example, the user 12a directs the remote execution controller 150 to one or more data elements (e.g., tables, databases, etc.) stored at the data store 148 when generating the application 190. The application 190 may support many different use cases, such as email automation (e.g., sending customized messages to internal or external users), creating invoices/decks/reports (e.g., generating files at a specified location using templated content), connecting services (e.g., send/return data from external services), and/or scheduling automated data manipulation/logic (e.g., run advanced business logic on data).

In some examples, the remote execution controller 150 receives a trigger interaction indication 20 indicating a graphical user interaction with the GUI 14 by the user 12a via the no-code frontend 161 (i.e., within the no-code environment). In response to receiving the trigger interaction indication 20, the remote execution controller 150 establishes a trigger condition 192 for the application 190 generated by the no-code environment 160, 161. The remote execution controller 150 also receives an action interaction indication 22 indicating another graphical user interaction with the GUI 14 by the user 12a via the no-code frontend 161. In response to receiving the action interaction indication 22, the remote execution controller 150 defines an action response 194 for the application 190 when the trigger condition 192 is satisfied. That is, as described in more detail below, the action response 194 defines a behavior of the application 190 when the trigger condition 192 is satisfied. For example, when the trigger condition 192 is that a value within a table is changed, the action response 194 for the application 190 is to generate a notification to a user 12. The user 12a may publish or otherwise deploy the application 190 (e.g., via an application deployment backend 180 and/or an application deployment frontend 182) such that the remote execution controller 150 executes the application 190.

Referring now to FIG. 2A, a schematic view 200a includes an exemplary GUI 14 displayed on the screen 15 of the first user device 10a when the user 12 is interacting with the no-code frontend 161 provided by the no-code backend 160 to create an application 190. Here, the GUI 14 is split into an event pane 230, a run pane 240, and a settings pane 250. The event pane 230 displays a graphical representation of a configure event user input 220 (i.e., a button). The configure event user input 220 allows the user 12 to configure an event (i.e., a trigger condition 192) for the application 190. The user 12, via a graphical user interaction, sends the trigger interaction indication 20 to the remote execution controller 150. For example, the user 12 selects the configure event user input 220 with a cursor 210 (e.g., via a mouse, keyboard, touchscreen, voice commands, or any other user input). In the example of schematic view 200b (FIG. 2B), the user 12, via interactions with the configure event user input 220 (FIG. 2A), establishes the trigger condition 192. Here, the configure event user input 220 transforms into a trigger identification element 222 that graphically informs the user 12 that the trigger condition 192, in this example, corresponds to when a new information record is created. The remote execution controller 150 automatically generates or populates any code necessary for the application 190 to implement the trigger condition 192 without requiring the user 12 to do any manual programming.

Referring back to FIG. 1, in some implementations, the secure remote execution controller 150 includes a low-code environment that includes a low-code backend 170 and a low-code frontend 172. A second user 12, 12n may communicate with the low-code backend 170 via, for example, a second user device 10, 10b and the low-code frontend 172 provided by the low-code backend 170. For example, the user 12b interacts with the low-code frontend 172 using a second GUI 14, 14b displayed on the screen 15. The combination of the low-code backend 170 and the low-code frontend 172 comprises a low-code environment. Like the first GUI 14a, the second GUI 14b provided by the low-code backend 170 may be a web-based GUI 14 (e.g., accessed via a web browser) and provides the user 12b with an interactive, visual workspace to build, execute, and publish low-code applications, scripts 162, and/or functions 164, 164a-n of the scripts 162. The low-code environment (i.e., the low-code backend 170 and low-code frontend 172) differs from the no-code environment in that the low-code environment provides access to manual coding techniques (e.g., scripts) that allow for more complex and sophisticated behavior with the tradeoff of requiring some knowledge or expertise with the manual coding techniques. In some examples, the low-code environment is instead a pro-code environment (i.e., a traditional coding environment that relies on minimal, if any, visual representations).

The second user 12b, using the low-code environment, authors or generates one or more scripts 162 using a scripting language (e.g., JavaScript, Python, Lua, etc.). Each script 162 includes one or more functions 164. Each function 164 is a block of code designed to perform a particular task. For example, the task includes reading/writing custom data and/or reports to a particular data store, connecting and passing data to external services, and otherwise executing more advanced business logic. Each function 164 is executed when called or invoked. The second user 12b, which may be a different user than the first user 12a (e.g., a user 12 with more experience or skill in manually coding techniques) or the same user 12 as the first user 12a, publishes or otherwise deploys the script 162 via the remote execution controller 150. For example, the application deployment backend 180 exposes the script 162 to external programs and services via the API 650 (FIG. 6). In this way, the scripts 162 authored by the second user 12b are available to any number of applications 190 authored by any number of other users 12. That is, the scripts can be called (i.e., reused) by any number of applications 190.

In some examples, in response to receiving the action interaction indication 22, the no-code backend 160 defines the action response 194 that includes a function call calling a function 164 of a script 162 generated within the low-code environment 170, 172. This configures the application 190, when executing, to call a function 184 authored by user 12b who may be different than the user 12a. Thus, the user 12a may leverage the manually coding expertise of the user 12b to provide additional sophistication to the application 190 without personally needing coding expertise.

Referring now to FIG. 3A, schematic view 300a continues the example illustrated in FIGS. 2A and 2B. Here, the run pane 240 includes an add step indication 310 that, when interacted with by the user 12a (e.g., via the cursor 210) populates the settings pane 250 with options for configuring the access response 194 to the trigger condition(s) 192 illustrated within the event pane 230. In this example, the user 12a provides an interaction indication indicating an interaction with the add step indication 310 (i.e., the “+” user input) that populates the settings pane 250 with options such as a step name text field 320 that allows the user 12a to uniquely name the access response 194 (i.e., the “step” in response to the “event” or trigger condition 192). The settings pane 250 also includes step options 330 that broadly define an action for the action response 194. Here, the options include “Run a Task,” “Branch,” “Wait for Condition,” and “Return Values.”

In this example, the user 12a has selected “Run a Task” which results in the GUI 14a providing additional options further defining the action response 194. Here, the user 12a is offered a task name text field 340 that allows the user 12a to uniquely name a task or operation of the action response 194. The user 12a is also provided with multiple task options 350. Here, the task options 350 include “Send an Email,” “Send an SMS,” “Create New File,” and “Run Script.”

Referring now to FIG. 3B, while it is understood that the step options 330 and the task options 350 may include any number of choices and that the secure remote execution controller 150 may respond accordingly to whichever option the user 12a selects, in this example, the user 12a, after selecting the “Run a Task” step option 330, selects the “Run Script” step option 350. This prompts the GUI 14a to display a step identification element 360 and a select script indication 370. The select script indication 370, as discussed in more detail below, may query the low-code backend 180, the deployment backend 180, or any other service, using the API 650 (FIG. 6), for a list of scripts 162 available to the user 12a.

In this example, as shown in schematic view 300b, the user 12a generates a graphical user interaction (e.g., with the cursor 210) indicating a selection of the select script indication 370. In schematic view 300c (FIG. 3C), in response to receiving the user interaction indication indicating the user 12a selected the “Choose a Script” user input 360, the no-code frontend 161, using the GUI 14a, displays a script selection window 380 listing multiple different scripts 162 for the user 12a to select. Here, the scripts 162 have been split into two different categories: account scripts 162, 162a and team scripts 162, 162b. In this example, account scripts 162a represent scripts 162 associated specifically with an account of the user 12a while the team scripts 162b represent scripts 162 associated with a team of the user 12a. For example, another individual on the same team as the user 12a may publish a script 162 for an entire team that may appear under the team scripts 162b. Many other categorizations of the scripts 162 are possible. In this example, the user 12a selects, via the cursor 210, the account script 162a “Travel Request.” Each script 162 may include a unique name or identifier.

Referring now to FIG. 4A, schematic view 400a includes the GUI 14a from the examples of FIG. 2A-3C. Here, after the user 12a selects the “Travel requests” script 162, the settings pane 250 updates to include selected script information 410. In this example, the selected script information 410 indicates a name of the script selected by the user 12a (FIG. 3C) and provides a link to access the script 162 (e.g., the source code of the selected script 162). The settings pane 250 also includes a function selection section 420 that, in this example, provides a drop-down list of each function 164 provided by the selected script 162 (e.g., retrieved via a query using the API 650 (FIG. 6)). Here, the “Travel requests” script 162 provides three functions 164: “Locate_user,” “Send_request,” and “Approve_req.” In some examples, each function 164 is associated with one or more parameters 430. The no-code backend 160, after the user 12a selects a function 164, may receive, from the low-code backend 170 or the remote execution controller 150, one or more parameters 430 associated with the selected function 164. The remote execution controller 150, when executing the application 190, may call the function 164 (e.g., via a function call generated when the user 12a selects the function 164) using an evaluation of the expression for each respective parameter 430.

Here, the “Locate_user” function 164 is associated with parameters 430 “title” and “uid.” Similarly, the function 164 “Send_request” is associated with the parameters 430 “r_id” and “t_id.” The parameters 430 are values, variables, expressions, etc., that the associated function 164 requires as an input to execute. For example, a function 164 that sends an email may require as an input a first parameter 430 that provides an email address and a second parameter 430 that provides desired text of the email. In the illustrated example, the user 12a selects, via the cursor 210, the “Send_request” function 164 that is associated with parameters 430 “r_id” and “t_id.”

Referring now to FIG. 4B, in some implementations, for each respective parameter 430 associated with the selected function 164, the no-code backend 160 (e.g., via the GUI 14a) queries the user 12a for a value or an expression that, when evaluated, satisfies the respective parameter. Here, schematic view 400b includes the GUI 14a after the user 12a selects the “Send_request” function 164. The function selection section 420 may update to reflect the selected function 164 (e.g., by displaying a unique name associated with the function 164). In some implementations, the settings pane 250 includes a display of each parameter 430 associated with the selected function 164. The GUI 14a may include text boxes or other elements that allow for the user 12a to input values or variables for the application 190 to assign the parameters 430 when calling the function 164. Here, the function 164 “Send_request” includes parameters 430 “r_id” and “t_id” and the settings pane 250 accordingly includes a text box for each parameter 430 to accept user input.

In some implementations, the user 12a provides a constant value (e.g., a numerical value, a string, etc.) for one or more parameters 430. Optionally, the user 12a provides an expression or formula for one or more parameters 430. That is, the user 12a may provide an expression or formula for the application 190 to evaluate prior to calling the function 164. For example, the user 12a provides an expression that retrieves a value from a certain column and a certain row of a table and multiplies the retrieved value by a constant. The user 12a may differentiate between constants and expressions via a predetermined escape character such as an ‘=’ symbol. The user 12a, in some examples, continues to interact with the GUI 14a to add additional trigger conditions 192 and/or action responses 194.

In some implementations, one or more parameters 430 are typed. The type may be implicitly inferred according to various heuristics or explicitly defined (e.g., by the user 12b via the low-code backend 170 or by the user 12a via the no-code backend 160). The typing may apply to the parameters 430 provided to the function 164 and/or any data returned from the function, such as a result 620 (FIG. 6). For example, the no-code backend 160 receives data type information from the low-code backend 170 for one or more of the parameters 430.

Referring back to FIG. 1, in some implementations, the application 190 is associated with a first set of permissions 196, 196a. Optionally, the first set of permissions is equal to or less than permissions associated with the user 12a. That is, the application 190 may only be granted permissions 196a (e.g., to access resources such as restricted data) that the author (i.e., the user 12a) is authorized to provide. For example, when the application 190 is configured to access a table stored at the data store 148 (e.g., the trigger condition 192 is satisfied when a row is added to the table), the application 190 must be authorized to access the table. The application 190 may inherit authorization from the user 12a (i.e., the user 12a authorizes the application 190 to access the table).

In some examples, when the action response 194 includes calling a script 162, the script 162 is associated with a second set of permissions 196, 196b. The second set of permissions 196b may be different from the first set of permissions 196a. For example, the function 164 called by the application 190 may require access to different data that requires different authorization to access. In some implementations, no-code backend 160, after the user 12a selects a function 164 for the application 190 to call, determines the second set of permissions 196b. For example, the no-code backend 160 evaluates the script 162 and/or function 164. As another example, the no-code backend 160 may query the low-code backend 170 or other service to determine the permissions 196 required for the selected function 164 to execute. After determining the second set of permissions 196b, the no-code backend 160 requests, from the user 12a, approval for the second set of permissions 196b.

Referring now to FIG. 5, schematic view 500 includes the GUI 14a after the user 12a selects the “Send_request” function 164. Here, the GUI 14a includes an authorization user input 510. That is, in this example, the no-code backend 160 evaluates the “Send_request” function 164 of the “Travel requests” script 162 and determines that the function 164 requires some level of authorization to execute. The no-code backend 160 requires the user 12a to provide authorization for execution of the function 164 (e.g., via user interaction with the authorization user input 510 using cursor 210) prior to publishing or deploying the application 190. The user 12a must be capable of providing the necessary level of authorization to satisfy the permissions 196 required by the function 164. After the user 12a interacts with the authorization user input 510, the no-code backend 160 receives permissions approval approving the set of permissions 196 associated with the function 164. That is, in some examples, the script 162 must be authorized by the author of the application 190 (i.e., the user 12a) and not the author of the script 162 (i.e., the user 12b) or any user 12 executing the application 190.

In some examples, the no-code backend 160 stores credentials from the user 12a for providing authorization (e.g., via OAuth or other authentication standards) when calling the function 164 during execution of the application 190. The permissions 196b of the function 164 may be a subset of the permissions 196a of the application 190. The permissions 196 required by the function 164 may be dependent upon the values or expressions provided by the user 12a for the parameters 430 associated with the function 164 (e.g., based on the data required to be accessed to evaluate the expressions). In some implementations, the no-code backend 160 (e.g., via the GUI 14a) may require re-authorization when the required permissions 196 for the script 162 and/or function 164 change (e.g., in response to changing the values for the parameters 430). The GUI 14a may provide a list of authorizations needed for each selected function 164.

Referring back to FIG. 1, in some implementations, after the user 12a configures the application 190 (i.e., sets one or more trigger conditions 192 and one or more action responses 194), the user 12a may publish or deploy the application 190 using the deployment backend 180. The deployment backend 180 may execute the application 190 and expose the application 190 via an application deployment frontend 182 to a third user 12, 12c. The third user 12c may be the same or different from the first user 12a and/or the second user 12b. That is, the secure remote execution controller 150 may deploy the application 190 for a user 12 that is different than the user 12 that authored the application 190 and/or the user that authored the script 162. The third user 12c, for example, interacts with the application 190 via a third GUI 14, 14c. The user 12c may perform an action that satisfies the trigger condition 192. For example, when the trigger condition 192 includes adding a row to a table stored at the data store 148, the user 12c may submit a request via the GUI 14c that causes the application 190 (or a different application or service) to add a row to the table.

Referring now to FIG. 6, in some implementations, while the application 190 is executing, the application 190 determines whether the trigger condition 192 is satisfied (e.g., based on interactions from the third user 12c). When the trigger condition 192 is satisfied, the application 190 may call, using a function call 610, one or more functions 164 of a script 162. The function call 610 may include values for the parameters 430 associated with the function 164 called by the function call 610. The deployment backend 180 (or the low-code backend 170) upon receiving the function call 610, executes the function 164 using any included parameters 430. In some examples, prior to execution, the deployment backend 180 ensures the application 190 includes the proper authorization or permissions 196 to allow the function 164 to execute. The authorization may be included in the function call 610. In some examples, after executing, the function 164 returns a result 620 to the application 190. The result 620 includes, for example, an execution status 622 and/or a data response 624.

The execution status 622 indicates a status of the function execution. For example, the execution status 622 indicates to the application 190 whether the function 164 successfully executed or whether the function 164 encountered a failure while executing. The data response 624 may include any data the function 164 is configured to return to the application 190. For example, the function 164 queries a table for a value and returns the value to the application 190. The execution status 622 and/or the data response 624 may be typed. For example, the data response 624 is a structured data response that includes one or more fields and type information for at least one field of the one or more fields.

In some examples, receiving the result 620 satisfies another trigger condition 192 established by the application 190. In this situation, receiving the result 620 results in the application 190 executing another action response 194. The action response 194 may include the execution of any task or automation step. The execution status 622 and/or data response 624 may be passed to subsequent trigger conditions 192 and/or action responses 194 (e.g., tasks). The tasks may include updating data, sending emails or other notifications, or executing another function 164. That is, when the function 164 returns the result 620, the result may trigger the application 190 to call a second function 164. The application 190 may rely on the result 620 for any number of other trigger conditions 192 and/or action responses 194. For example, the application 190, after receiving the result 620, uses the received data response 624 as an input to another internal or external process or function. Put another way, the application 190, after receiving the result 620, may call another automation, such as another “if-this-then-than-that” process (as discussed above) based on or in response to receiving the result 620.

In some examples, the application 190 calls the function 164 via the API 650. The API 650 may serve as an interface between the application 190 and the script 162. The same or different API 650 may also interface the no-code environment 160, 161 and the low-code environment 170, 172. For example, the no-code backend 160 (e.g., when the user 12a is authoring the application 190) communicates with the low-code backend 170 via the API 650 to determine which scripts 162 the user 12a has access to, which functions 164 are available in each script 162, determine what, if any, permissions 196 are required to execute the functions 164, and/or to call the function 164 during execution of the application 190.

Thus, the secure remote execution controller 150 provides user-defined secure remote code execution from no-code platforms. Leveraging the capabilities of both no-code environments and low-code environments, users 12 can design applications 190 that satisfy a number of use cases. For example, applications 190 may automate emails by automatically sending customized messaging to internal or external (to the user's organization) users 12 for notifications and/or automated reports and/or list/mailmerge management. As another example, the applications 190 can create business artifacts by generating files with templated content. For instance, an application 190 can generate slides based on photographs added to a specified storage location. As yet another example, the applications 190 can provide connection between services to allow users 12 to use advanced features or enable integration with external products. The applications may run advanced business logic on specified data. For example, an application 190 saves all new email attachments to a specified location once per day.

FIG. 7 is a flowchart of an exemplary arrangement of operations for a method 700 for providing user-defined secure remote code execution from no-code platforms. The method 700, at operation 702, includes receiving a trigger interaction indication 20 indicating a first graphical user interaction by a user 12a within a no-code environment 160, 161. At operation 704, the method 700 includes, in response to receiving the trigger interaction indication 20, establishing a trigger condition 192 for an application 190 generated by the no-code environment 160, 161. The method 700, at operation 706, includes receiving an action interaction indication 22 indicating a second graphical user interaction by the user 12a within the no-code environment 160, 161. At operation 708, the method 700 includes, in response to receiving the action interaction indication 22, defining an action response 194 for the application 190 when the trigger condition 192 is satisfied. The action response 194 includes a function call calling a function 164 of a script 162 generated within a low-code environment 170, 172. At operation 710, the method 700 includes executing the application 190.

FIG. 8 is a schematic view of an example computing device 800 that may be used to implement the systems and methods described in this document. The computing device 800 is intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The components shown here, their connections and relationships, and their functions, are meant to be exemplary only, and are not meant to limit implementations of the inventions described and/or claimed in this document.

The computing device 800 includes a processor 810, memory 820, a storage device 830, a high-speed interface/controller 840 connecting to the memory 820 and high-speed expansion ports 850, and a low speed interface/controller 860 connecting to a low speed bus 870 and a storage device 830. Each of the components 810, 820, 830, 840, 850, and 860, are interconnected using various busses, and may be mounted on a common motherboard or in other manners as appropriate. The processor 810 can process instructions for execution within the computing device 800, including instructions stored in the memory 820 or on the storage device 830 to display graphical information for a graphical user interface (GUI) on an external input/output device, such as display 880 coupled to high speed interface 840. In other implementations, multiple processors and/or multiple buses may be used, as appropriate, along with multiple memories and types of memory. Also, multiple computing devices 800 may be connected, with each device providing portions of the necessary operations (e.g., as a server bank, a group of blade servers, or a multi-processor system).

The memory 820 stores information non-transitorily within the computing device 800. The memory 820 may be a computer-readable medium, a volatile memory unit(s), or non-volatile memory unit(s). The non-transitory memory 820 may be physical devices used to store programs (e.g., sequences of instructions) or data (e.g., program state information) on a temporary or permanent basis for use by the computing device 800. Examples of non-volatile memory include, but are not limited to, flash memory and read-only memory (ROM)/programmable read-only memory (PROM)/erasable programmable read-only memory (EPROM)/electronically erasable programmable read-only memory (EEPROM) (e.g., typically used for firmware, such as boot programs). Examples of volatile memory include, but are not limited to, random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), phase change memory (PCM) as well as disks or tapes.

The storage device 830 is capable of providing mass storage for the computing device 800. In some implementations, the storage device 830 is a computer-readable medium. In various different implementations, the storage device 830 may be a floppy disk device, a hard disk device, an optical disk device, or a tape device, a flash memory or other similar solid state memory device, or an array of devices, including devices in a storage area network or other configurations. In additional implementations, a computer program product is tangibly embodied in an information carrier. The computer program product contains instructions that, when executed, perform one or more methods, such as those described above. The information carrier is a computer- or machine-readable medium, such as the memory 820, the storage device 830, or memory on processor 810.

The high speed controller 840 manages bandwidth-intensive operations for the computing device 800, while the low speed controller 860 manages lower bandwidth-intensive operations. Such allocation of duties is exemplary only. In some implementations, the high-speed controller 840 is coupled to the memory 820, the display 880 (e.g., through a graphics processor or accelerator), and to the high-speed expansion ports 850, which may accept various expansion cards (not shown). In some implementations, the low-speed controller 860 is coupled to the storage device 830 and a low-speed expansion port 890. The low-speed expansion port 890, which may include various communication ports (e.g., USB, Bluetooth, Ethernet, wireless Ethernet), may be coupled to one or more input/output devices, such as a keyboard, a pointing device, a scanner, or a networking device such as a switch or router, e.g., through a network adapter.

The computing device 800 may be implemented in a number of different forms, as shown in the figure. For example, it may be implemented as a standard server 800a or multiple times in a group of such servers 800a, as a laptop computer 800b, or as part of a rack server system 800c.

Various implementations of the systems and techniques described herein can be realized in digital electronic and/or optical circuitry, integrated circuitry, specially designed ASICs (application specific integrated circuits), computer hardware, firmware, software, and/or combinations thereof. These various implementations can include implementation in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which may be special or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device.

A software application (i.e., a software resource) may refer to computer software that causes a computing device to perform a task. In some examples, a software application may be referred to as an “application,” an “app,” or a “program.” Example applications include, but are not limited to, system diagnostic applications, system management applications, system maintenance applications, word processing applications, spreadsheet applications, messaging applications, media streaming applications, social networking applications, and gaming applications.

These computer programs (also known as programs, software, software applications or code) include machine instructions for a programmable processor, and can be implemented in a high-level procedural and/or object-oriented programming language, and/or in assembly/machine language. As used herein, the terms “machine-readable medium” and “computer-readable medium” refer to any computer program product, non-transitory computer readable medium, apparatus and/or device (e.g., magnetic discs, optical disks, memory, Programmable Logic Devices (PLDs)) used to provide machine instructions and/or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term “machine-readable signal” refers to any signal used to provide machine instructions and/or data to a programmable processor.

The processes and logic flows described in this specification can be performed by one or more programmable processors, also referred to as data processing hardware, executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logic flows can also be performed by special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit). Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read only memory or a random access memory or both. The essential elements of a computer are a processor for performing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto optical disks, or optical disks. However, a computer need not have such devices. Computer readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto optical disks; and CD ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.

To provide for interaction with a user, one or more aspects of the disclosure can be implemented on a computer having a display device, e.g., a CRT (cathode ray tube), LCD (liquid crystal display) monitor, or touch screen for displaying information to the user and optionally a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer. Other kinds of devices can be used to provide interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input. In addition, a computer can interact with a user by sending documents to and receiving documents from a device that is used by the user; for example, by sending web pages to a web browser on a user's client device in response to requests received from the web browser.

A number of implementations have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the disclosure. Accordingly, other implementations are within the scope of the following claims.

User-defined Secure Remote Code Execution from No-code Platforms

Information

Publication Number

Date Filed

Date Published

Inventors

Original Assignees

CPC

International Classifications

Abstract

Description

Claims