System and method for workflow application programming interfaces (APIS)

This application is a continuation-in-part of U.S. patent application Ser. No. 17/301,055, filed Mar. 23, 2021, and entitled, “SYSTEM AND METHOD FOR WORKFLOW APPLICATION PROGRAMMING INTERFACES (APIS),” which is a continuation of U.S. patent application Ser. No. 16/133,438, filed Sep. 17, 2018 (now U.S. Pat. No. 10,970,048 issued on Apr. 6, 2021), and entitled, “SYSTEM AND METHOD FOR WORKFLOW APPLICATION PROGRAMMING INTERFACES (APIS),” each of which is herein incorporated by reference in its entirety for all purposes.

The present disclosure relates generally to workflows and, more particularly, to custom workflow Application Programming Interfaces (APIs).

This section is intended to introduce the reader to various aspects of art that may be related to various aspects of the present disclosure, which are described and/or claimed below. This discussion is believed to be helpful in providing the reader with background information to facilitate a better understanding of the various aspects of the present disclosure. Accordingly, it should be understood that these statements are to be read in this light, and not as admissions of prior art.

Cloud computing relates to the sharing of computing resources that are generally accessed via the Internet. In particular, a cloud computing infrastructure allows users, such as individuals and/or enterprises, to access a shared pool of computing resources, such as servers, storage devices, networks, applications, and/or other computing based services. By doing so, users are able to access computing resources on demand that are located at remote locations, which resources may be used to perform a variety computing functions (e.g., storing and/or processing large quantities of computing data). For enterprise and other organization users, cloud computing provides flexibility in accessing cloud computing resources without accruing large up-front costs, such as purchasing expensive network equipment or investing large amounts of time in establishing a private network infrastructure. Instead, by utilizing cloud computing resources, users are able redirect their resources to focus on their enterprise's core functions.

Within the context of cloud computing solutions for data repositories, users may be asked to deal with ever increasing amounts of data, e.g., including certain date-based information stored in the data repositories. In fact, the amount of cloud-based and date-based data collected and stored in today's cloud computing solutions, such as cloud-based repositories, may be orders of magnitude greater than what was historically collected and stored. Users tasked with automating and/or troubleshooting enterprise, IT, and/or other organization-related functions (e.g., incident tracking and/or help desk-related functions) navigate ever increasing amounts of date-based data to properly and efficiently perform their job functions. In certain embodiments, cloned data repositories may be created. With this in mind, the following embodiments are directed to improving the manner in which information workflows in certain data repositories may be automated, including cloned data repository information workflows.

A summary of certain embodiments disclosed herein is set forth below. It should be understood that these aspects are presented merely to provide the reader with a brief summary of these certain embodiments and that these aspects are not intended to limit the scope of this disclosure. Indeed, this disclosure may encompass a variety of aspects that may not be set forth below.

Information Technology (IT) networks may include a number of computing devices, server systems, databases, and the like that generate, collect, and store information. As increasing amounts of data representing vast resources become available, it becomes increasingly difficult to analyze the data, interact with the data, and/or provide reports for the data. The current embodiments enable systems and methods that may create information flows (e.g., workflows) executable in one or more instances or clones by using certain application programming interfaces (APIs). The creation of information flows may be performed by users that are not programmers or information technology personnel. For example, in certain embodiments, software tools may be used that visually present a flow of information, e.g. a flow chart view, and that enable a user to graphically manipulate the “flow” to perform desired processing, as further described below. That is, rather than entering computer code by typing text, for example, the software tools may enable the user to “draw” a flow chart which may then be executed. Accordingly, written computer code, such as Java, JavaScript, and so on, may be avoided and visual flows used instead.

The flows may include “sub-flows”, “Actions”, and “Steps”, as further described below. The techniques described herein may provide for both server side as well as front-end “Flow APIs” that are suitable for executing the flows, sub-flows, Actions, and/or Steps. In some embodiments, the Flow APIs may enable asynchronous execution. That is, the flows, sub-flows, Actions, and/or Steps may execute in an asynchronous or non-blocking manner, thus other work may be performed, resulting in improvements in efficiency and in the utilization of resources. The Flow APIs may also provide for enhanced security, for example, by using access control lists (ACLs) to verify permissions. By providing for more efficient and secure reuse of flows, sub-flows, Actions, and Steps, the Flow APIs may thus enable improved data processing and use across a larger organizational spectrum.

One or more specific embodiments will be described below. In an effort to provide a concise description of these embodiments, not all features of an actual implementation are described in the specification. It should be appreciated that in the development of any such actual implementation, as in any engineering or design project, numerous implementation-specific decisions must be made to achieve the developers' specific goals, such as compliance with system-related and enterprise-related constraints, which may vary from one implementation to another. Moreover, it should be appreciated that such a development effort might be complex and time consuming, but would nevertheless be a routine undertaking of design, fabrication, and manufacture for those of ordinary skill having the benefit of this disclosure.

One or more specific embodiments will be described below. In an effort to provide a concise description of these embodiments, not all features of an actual implementation are described in the specification. It should be appreciated that in the development of any such actual implementation, as in any engineering or design project, numerous implementation-specific decisions must be made to achieve the developers' specific goals, such as compliance with system-related and enterprise-related constraints, which may vary from one implementation to another. Moreover, it should be appreciated that such a development effort might be complex and time consuming, but would nevertheless be a routine undertaking of design, fabrication, and manufacture for those of ordinary skill having the benefit of this disclosure.

As used herein, the term “computing system” refers to an electronic computing device that includes, but is not limited to a computer, virtual machine, virtual container, host, server, laptop, and/or mobile device, or to a plurality of electronic computing devices working together to perform the function described as being performed on or by the computing system. As used herein, the term “medium” refers to one or more non-transitory, computer-readable physical media that together store the contents described as being stored thereon. Embodiments may include non-volatile secondary storage, read-only memory (ROM), and/or random-access memory (RAM). As used herein, the term “application” refers to one or more computing modules, programs, processes, workloads, threads and/or a set of computing instructions executed by a computing system. Example embodiments of an application include software modules, software objects, software instances and/or other types of executable code.

As used herein, the term “flow” may refer to data processing of information (e.g., database records) that may be presented to a user in a flow chart-like view. A flow may have inputs but may not have an output. A flow may include one or more “sub-flows” and/or one or more “Actions.” The flow may also include “triggers” and control logic. A “sub-flow” as used herein may refer to data processing of information (e.g., database records) also presented to the user in a flow chart-like view. Unlike the flow, a sub-flow may have both inputs and outputs. A sub-flow may additionally contain Actions, triggers, control logic and/or other sub-flows. A “trigger” may be “fired” or turned on by a change in certain conditions, such as a change in one or more database records. The trigger may also be “fired” or otherwise turned on via a schedule, e.g., daily, weekly, monthly schedule. “Action” as used herein may include one or more “Steps.” Steps may be self-contained code, such as scripts (e.g., Java, JavaScript code) provided by the manufacturer of the software tools used to create the flows, sub-flows, and the like. Steps may also be provided by users and any other entity. As used herein, the terms “flow objects” may refer to flows, sub-flows, Actions, and Steps.

Present embodiments are directed to enabling the reuse of flow objects via APIs. The APIs that may call and work with the flow objects may be referred to herein as with the term “Flow” APIs. The Flow APIs may include a back-end (e.g., server-side) API and a front-end (e.g., client-side API). The server-side API may include scriptable object(s) which may act as an API interface for all server-side code, e.g., server-side scripting code. The front-end API may enable front-end computing systems, such as web browsers, to use an implementation, such as a REST (Representational State Transfer) implementation of the Flow APIs, thus providing an easier to use client for end-user access through a REST service. As referred to herein, “REST” may include a web-based Remote Process Call (RPC) system based on the work (e.g., Ph.D. thesis) of Roy Fielding. It is to be noted that in other embodiments any RPC system may be used, including Simple Object Access Protocol (SOAP)-based systems, JavaScript Object Notation (JSON)-based systems, XML-based systems, and so on. The Flow APIs may also provide for asynchronous execution of flow objects, for example, via push style delivery of outputs as further described below.

1 FIG. 1 FIG. 1 FIG. 1 FIG. 10 10 12 14 16 16 12 12 18 12 20 20 20 16 20 22 20 16 12 24 16 12 12 With the preceding in mind, the following figures relate to various types of generalized system architectures or configurations that may be employed to provide services to an organization accessing a cloud-platform, such as may be embodied in a multi-instance or multi-tenant framework on which the present approaches may be employed. Correspondingly, these system and platform examples may also relate to systems and platforms on which the techniques discussed herein may be implemented or otherwise utilized. Turning now to, a schematic diagram of an embodiment of a cloud computing systemin which embodiments of the present disclosure may operate, is illustrated. The cloud computing systemmay include a client network, a network(e.g., the Internet), and a cloud-based platform. In some implementations, the cloud-based platformmay be a configuration management database (CMDB) platform. In one embodiment, the client networkmay be a local private network, such as local area network (LAN) that includes a variety of network devices that include, but are not limited to, switches, servers, and routers. In another embodiment, the client networkrepresents an enterprise network that could include one or more LANs, virtual networks, data centers, and/or other remote networks. As shown in, the client networkis able to connect to one or more client devicesA,B, andC so that the client devices are able to communicate with each other and/or with the network hosting the platform. The client devicesmay be computing systems and/or other types of computing devices generally referred to as Internet of Things (IoT) devices that access cloud computing services, for example, via a web browser application or via an edge devicethat may act as a gateway between the client devicesand the platform.also illustrates that the client networkincludes a management, instrumentation, and discovery (MID) serverthat facilitates communication of data between the network hosting the platform, other external applications, data sources, and services, and the client network. Although not specifically illustrated in, the client networkmay also include a connecting network device (e.g., a gateway or router) or a combination of devices that implement a customer firewall or intrusion protection system.

1 FIG. 1 FIG. 12 14 20 16 14 14 14 14 14 For the illustrated embodiment,illustrates that client networkis coupled to the network, which may include one or more computing networks, such as other LANs, wide area networks (WAN), the Internet, and/or other remote networks, in order to transfer data between the client devicesand the network hosting the platform. Each of the computing networks within networkmay contain wired and/or wireless programmable devices that operate in the electrical and/or optical domain. For example, networkmay include wireless networks, such as cellular networks (e.g., Global System for Mobile Communications (GSM) based cellular network), WiFi® networks (WIFI is a registered trademark owned by Wi-Fi Alliance Corporation), and/or other suitable radio-based networks. The networkmay also employ any number of network communication protocols, such as Transmission Control Protocol (TCP) and Internet Protocol (IP). Although not explicitly shown in, networkmay include a variety of network devices, such as servers, routers, network switches, and/or other network hardware devices configured to transport data over the network.

1 FIG. 16 20 12 14 16 20 12 16 20 16 18 18 26 26 26 In, the network hosting the platformmay be a remote network (e.g., a cloud network) that is able to communicate with the client devicesvia the client networkand network. The network hosting the platformprovides additional computing resources to the client devicesand/or the client network. For example, by utilizing the network hosting the platform, users of the client devicesare able to build and execute applications for various enterprise, IT, and/or other organization-related functions. In one embodiment, the network hosting the platformis implemented on the one or more data centers, where each data center could correspond to a different geographic location. Each of the data centersincludes a plurality of virtual servers(also referred to herein as application nodes, application servers, virtual server instances, application instances, or application server instances), where each virtual servercan be implemented on a physical computing system, such as a single electronic computing device (e.g., a single physical hardware server) or across multiple-computing devices (e.g., multiple physical hardware servers). Examples of virtual serversinclude, but are not limited to a web server (e.g., a unitary Apache installation), an application server (e.g., unitary Java® Virtual Machine), and/or a database server, e.g., a unitary MySQL® catalog (MySQL® is a registered trademark owned by MySQL AB A COMPANY).

26 26 26 The virtual serversmay store or access a variety of data, including data that may have date-based information. For example, manufacturing data, financial data, farming data, company operations data, accounting data, and so on, may be include date-based information specifying one or more points in time associated with the data. Indeed, dates of manufacture, dates of sale, dates of incidents, expiration dates, scheduled dates, and so on, may be stored in the virtual servers. The virtual serversmay then use the techniques described herein to provide for one or more calendars for data having-based information, including custom calendars.

16 18 18 26 26 16 2 FIG. To utilize computing resources within the platform, network operators may choose to configure the data centersusing a variety of computing infrastructures. In one embodiment, one or more of the data centersare configured using a multi-instance cloud architecture to provide every customer its own unique customer instance or instances. For example, a multi-instance cloud architecture could provide each customer instance with its own dedicated application server and dedicated database server. In other examples, the multi-instance cloud architecture could deploy a single physical or virtual serverand/or other combinations of physical and/or virtual servers, such as one or more dedicated web servers, one or more dedicated application servers, and one or more database servers, for each customer instance. In a multi-instance cloud architecture, multiple customer instances could be installed on one or more respective hardware servers, where each customer instance is allocated certain portions of the physical server resources, such as computing memory, storage, and processing power. By doing so, each customer instance has its own unique software stack that provides the benefit of data isolation, relatively less downtime for customers to access the platform, and customer-driven upgrade schedules. An example of implementing a customer instance within a multi-instance cloud architecture will be discussed in more detail below with reference to.

2 FIG. 2 FIG. 2 FIG. 2 FIG. 100 100 12 14 18 18 102 102 26 26 26 26 26 104 104 26 26 26 26 104 104 102 100 102 26 26 26 26 104 104 is a schematic diagram of an embodiment of a multi-instance cloud architecturewhere embodiments of the present disclosure may operate.illustrates that the multi-instance cloud architectureincludes the client networkand the networkthat connect to two (e.g., paired) data centersA andB that may be geographically separated from one another. Usingas an example, network environment and service provider cloud infrastructure client instance(also referred to herein as a simply client instance) is associated with (e.g., supported and enabled by) dedicated virtual servers(e.g., virtual serversA,B,C, andD) and dedicated database servers (e.g., virtual database serversA andB). Stated another way, the virtual serversA,B,C,D and virtual database serversA,B are not shared with other client instances but are specific to the respective client instance. Other embodiments of the multi-instance cloud architecturecould include other types of dedicated virtual servers, such as a web server. For example, the client instancecould be associated with (e.g., supported and enabled by) the dedicated virtual serversA,B,C,D, dedicated virtual database serversA,B, and additional dedicated virtual web servers (not shown in).

102 26 26 26 26 104 104 18 18 18 18 18 18 26 26 104 102 18 18 18 102 18 102 18 26 26 104 104 104 2 FIG. In the depicted example, to facilitate availability of the client instance, the virtual serversA,B,C,D and virtual database serversA,B are allocated to two different data centersA,B, where one of the data centersacts as a backup data center. In reference to, data centerA acts as a primary data centerA that includes a primary pair of virtual serversA,B and the primary virtual database serverA associated with the client instance, and data centerB acts as a secondary data centerB to back up the primary data centerA for the client instance. To back up the primary data centerA for the client instance, the secondary data centerB includes a secondary pair of virtual serversC,D and a secondary virtual database serverB. The primary virtual database serverA is able to replicate data to the secondary virtual database serverB.

2 FIG. 2 FIG. 104 104 18 18 18 18 18 102 18 26 26 104 102 26 26 104 As shown in, the primary virtual database serverA may replicate data to the secondary virtual database serverB using, e.g., a Master-Master MySQL Binlog replication operation. The replication of data between data could be implemented by performing full backups weekly and daily incremental backups in both data centersA,B. Having both a primary data centerA and secondary data centerB allows data traffic that typically travels to the primary data centerA for the client instanceto be diverted to the second data centerB during a failure and/or maintenance scenario. Usingas an example, if the virtual serversA,B and/or primary virtual database serverA fails and/or is under maintenance, data traffic for client instancescan be diverted to the secondary virtual serversC,D and the secondary virtual database server instanceB for processing.

104 104 106 106 108 110 108 110 108 110 108 110 In the depicted embodiment, a database server, such as the serversA and/orB, may each include a flow data processing system. That is, the flow data processing systemmay enable the creation of flow objects and then provide access (e.g. execution, status checks, and retrieval of outputs) of the flow objects via a front-end Flow APIand a back-end Flow API. The techniques described herein may allow the creation of custom flow objects and then the subsequent execution, status check, and receipt of output from the flow objects via the front-end Flow APIand the back-end Flow API. The front-end Flow APImay be provided for use by front-end clients, such as web browsers, mobile apps (e.g., smart phone apps), and the like. The back-end Flow APImay be provided for use by back-end clients that may be under the supervision, for example, of an information technology (IT) group. By providing for the front-end Flow APIand the back-end Flow API, the techniques described herein may enable a more efficient and useful reuse of flow objects, as further described herein.

1 2 FIGS.and 1 2 FIGS.and 1 FIG. 2 FIG. 1 2 FIGS.and 10 100 16 16 26 26 26 26 104 104 Althoughillustrate specific embodiments of a cloud computing systemand a multi-instance cloud architecture, respectively, the disclosure is not limited to the specific embodiments illustrated in. For instance, althoughillustrates that the platformis implemented using data centers, other embodiments of the platformare not limited to data centers and can utilize other types of remote network infrastructures. Moreover, other embodiments of the present disclosure may combine one or more different virtual servers into a single virtual server. Usingas an example, the virtual serversA,B,C,D and virtual database serversA,B may be combined into a single virtual server. The use and discussion ofare only examples to facilitate ease of description and explanation of discrete or functional concepts and are not intended to limit the disclosure to the specific examples illustrated therein.

1 2 FIGS.and As may be appreciated, the respective architectures and frameworks discussed with respect toincorporate computing systems of various types (e.g., servers, workstations, client devices, laptops, tablet computers, cellular telephones, and so forth) throughout. For the sake of completeness, a brief, high level overview of components typically found in such systems is provided. As may be appreciated, the present overview is intended to merely provide a high-level, generalized view of components typical in such computing systems and should not be viewed as limiting in terms of components discussed or omitted from discussion.

3 FIG. 3 FIG. 3 FIG. With this in mind, and by way of background, it may be appreciated that the present approach may be implemented using one or more processor-based systems such as shown in. Likewise, applications and/or databases utilized in the present approach stored, employed, and/or maintained on such processor-based systems. As may be appreciated, such systems as shown inmay be present in a distributed computing environment, a networked environment, or other multi-computer platform or architecture. Likewise, systems such as that shown in, may be used in supporting or communicating with one or more virtual environments or computational instances on which the present approach may be implemented.

3 FIG. 3 FIG. 200 200 202 204 206 208 210 212 214 With this in mind, an example computer system may include some or all of the computer components depicted in.generally illustrates a block diagram of example components of a computing systemand their potential interconnections or communication paths, such as along one or more busses. As illustrated, the computing systemmay include various hardware components such as, but not limited to, one or more processors, one or more busses, memory, input devices, a power source, a network interface, a user interface, and/or other computer components useful in performing the functions described herein.

202 206 202 206 The one or more processorsmay include one or more microprocessors capable of performing instructions stored in the memory. Additionally or alternatively, the one or more processorsmay include application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), and/or other devices designed to perform some or all of the functions discussed herein without calling instructions from the memory.

204 200 206 206 208 202 208 210 200 212 212 214 202 214 1 FIG. With respect to other components, the one or more bussesincludes suitable electrical channels to provide data and/or power between the various components of the computing system. The memorymay include any tangible, non-transitory, and computer-readable storage media. Although shown as a single block in, the memorycan be implemented using multiple physical units of the same or different types in one or more physical locations. The input devicescorrespond to structures to input data and/or commands to the one or more processor. For example, the input devicesmay include a mouse, touchpad, touchscreen, keyboard and the like. The power sourcecan be any suitable source for power of the various components of the computing device, such as line power and/or a battery source. The network interfaceincludes one or more transceivers capable of communicating with other devices over one or more networks (e.g., a communication channel). The network interfacemay provide a wired network interface or a wireless network interface. A user interfacemay include a display that is configured to display text or images transferred to it from the one or more processors. In addition and/or alternative to the display, the user interfacemay include other devices for interfacing with a user, such as lights (e.g., LEDs), speakers, and the like.

4 FIG. 106 300 300 108 110 106 26 104 106 302 302 302 300 301 300 300 Turning now to, the figure is a block diagram illustrating an embodiment of the flow data processing systemsuitable for creating flow objectsand for accessing the flow objectsvia the front-end Flow APIand the back-end Flow API. It is to be understood that the flow data processing systemdepicted is an example only and may be included in or implemented using one or more of the virtual servers, the virtual DB servers, or a combination thereof. In the depicted embodiment, the flow data processing systemincludes a flow designer system, e.g., a visual information flow creation tool. The flow designer systemmay provide for visual programming via natural languages as opposed to entering text representative of a computer program. The flow designer systemmay include executable code or computer instructions suitable for creating, managing, accessing, and/or editing the flow objects. In the depicted embodiment, a single flowis shown in the flow objects. It is to be understood that more than one flow may be provided in the flow objects.

301 304 104 304 304 300 306 308 310 312 The flowmay include a triggerwhich may be “fired” or otherwise turned on by certain changed condition, such as a change in one or more records stored in a database (e.g., stored in the virtual DB servers). The triggermay additionally be “fired” periodically, for example, as part of a schedule (e.g., hourly schedule, daily schedule, weekly schedule, monthly schedule, and so on). The triggermay thus be used to initiate execution of other flow objects, such as sub-flow, Action, Action, and sub-flow.

304 306 306 306 306 308 308 314 316 308 314 316 302 302 314 316 In the depicted embodiment, the triggerinitiates execution of the sub-flow. The sub-flowmay include Actions, control logic (e.g., Boolean logic, branching logic, termination logic), other sub-flows, and so on. The sub-flowmay additionally take in inputs and provide outputs. For example, output of the sub-flowmay be used as input to the Action. The Actionmay use the inputs provided to execute Steps,. The Actionmay also include control logic. As mentioned earlier, Steps, such as the Steps,, and may be self-contained code, such as scripts (e.g., Java, JavaScript code) provided by the manufacturer of the flow designer system. As an example, the flow and/or action designer system(s)may be provided by ServiceNow™ Inc., of Santa Clara, California, U.S.A., under the name Flow Designer™. The Steps,may be additionally or alternatively provided by other third parties and/or coded by certain users, such as IT users.

26 104 310 308 310 318 320 320 312 312 301 301 Steps may include any number of functionality, such as requesting approval from other users of the servers,, creating records in a database table, editing the record in the database table, deleting the records in the database table, creating server tasks, logging messages, looking up database information, notifying of certain events (e.g., incidents, change requests, problems, changes to user records), executing scripts, such as JavaScript, sending REST web service requests, sending email, waiting for a condition to occur, and so on. Actionmay execute following Action. In turn, Actionmay include Steps,, and upon completion of Step, sub-flowmay be executed. Once sub-flowfinishes execution, the flowfinishes. As noted earlier, the flows, such as the flow, may not have outputs.

322 20 324 26 104 322 300 108 300 110 108 110 The flows may be executable from external clients, such as a front-end client(e.g., executable via device) and a back-end client(e.g., executable via serversand/or). More specifically, the front-end clientmay interface with the flow objectsvia the front-end Flow APIand the back-end client may interface with the flow objectsvia the back-end Flow API. Each API,may include three or more function types as follows:

326 326 300 108 110 Function 1) Call Action/Sub-flow/Flow (Inputs: Object ID, Array of input Arguments)—Output: ExecutionID. This API function type executes a desired Action, sub-flow, or flow, and uses a list of inputs, including the flow object's identification (ID), and an array of input arguments. The array of input arguments may include numeric values, text, characters, Unicode, and so on. Once executed, the Call Action/Sub-flow/Flow API may result in an asynchronous execution of the given Action, sub-flow, or flow. In certain embodiments, the response of the asynchronous execution may be provided by an asynchronous message bus (AMB) system. For example, the AMB systemmay be in charge of managing the delivery of the response of the asynchronous execution of the flow objectsand interacting with the APIs,based on the asynchronous execution. Outputs for the Call Action/Sub-flow/Flow may include a “handle” or unique identifier (e.g., ExecutionID) uniquely identifying the executing Action, sub-flow, and/or flow. As used herein, Function 1 types may include Call Action ( . . . ), Call Sub-flow ( . . . ), and Call Flow ( . . . ).Function 2) Check Action/Sub-flow/Flow Execution Status (Inputs: ExecutionID)—Output: Execution status. This API function type may be provided to derive the current status of the executing Action, sub-flow, and/or flow. For example, given an input such as the previously received ExecutionID (e.g., received via the Call Action/Sub-flow/Flow API described above), the Check Action/Sub-flow/Flow API may then return an execution status, such as “executing”, “execution completed”, and so on. As used herein, Function 2 types may include Check Action ( . . . ), Check Sub-flow ( . . . ), and Check Flow ( . . . ).Function 3) Retrieve Action/Sub-flow/Flow Outputs (Inputs: ExecutionID)—Output: Array of output Arguments. This API function may be used to retrieve outputs of the previously executed Call API. That is, once the Call API is completed, the Retrieve API may then be called, using the ExecutionID previously described, to retrieve any outputs of the Call API. As used herein, Function 3 types may include Retrieve Action ( . . . ), Retrieve Sub-flow ( . . . ), and Retrieve Flow ( . . . ).

108 110 108 326 328 328 322 324 300 326 328 106 106 300 108 110 300 302 5 FIG. As previously noted, each of the three API function types listed above may be provided for the front-end APIand/or for the back-end API. However, some changes may be made. For example, in certain embodiments, the front-end APImay be using a REST implementation, as further described below in, and may also use the AMB. Likewise access control lists (ACLs)may be used to provide for certain secure data processing. For example, the ACLsmay be queried to verify that the clientsand/orhave proper authorization to execute the different Flow APIs for certain flow objects. It is to be understood that the AMBand the ACLsmay in certain embodiments, be disposed in systems outside of the flow data processing systembut may then operatively coupled to the flow data processing system. By using the three API function types listed above, the techniques described herein may provide for improved execution and reuse of the flow objects. Indeed, any computing system may use the APIs,to use flow objects, such as flows, Actions, sub-flows, steps, and the like, which may have been created via the flow designer tool.

5 FIG. 400 300 301 400 302 301 402 400 300 108 110 is a screenshot depicting an embodiment of a graphical user interface (GUI)suitable for inputting certain flow objectsinto a flow, such as the flow. The GUImay be included in the flow and/or action designer systemand used to create the flow. In the depicted embodiment, a graphical flow viewof a flow is shown. Indeed, the GUImay be used to create and edit any number of graphical flow views that may then be executed as flow objectsvia the front-end Flow APIand/or the back-end Flow API.

402 404 404 406 406 408 410 410 414 302 300 300 322 324 In the depicted embodiment, the graphical flow viewmay start execution via a trigger. More specifically, if a certain user record is updated, then the triggermay “fire” and execute Action. The Actionmay then retrieve a set of tasks assigned to the updated user that have an open state. The retrieved tasks may then be further process via a “Do . . . Until” control logic. More specifically, a Do logicmay execute one or more Actions, such as Action, until the “Until” control logichas its conditions met. More sub-flows and/or Actions may be added, for example, via the “+” control. As shown, natural language and visual composition via the flow designermay be used to enable the creation of executable flow objects. The flow objectsmay then be reused by the front-end clientand/or the back-end client.

6 FIG. 450 108 452 452 322 454 108 452 456 454 454 458 460 108 460 462 464 Turning now to, the figure is an interaction overview diagram illustrating embodiments of interactionsbetween certain components of the front-end Flow APIand a client-side code implementation. In the depicted embodiment, the client-side code(e.g., JavaScript code) may be executable, for example, via a web browser of the front end client, and may interact with a script client API(e.g., JavaScript client) included in the front-end Flow API. For example, the client-side codemay executea call to the Call Action function of the Flow API (e.g., Function 1 above) included in the script client API. In turn, the script client APImay executea Flow API REST Service requestalso included in the front-end Flow API. The Flow API REST Service requestmay then dispatchthe request to a processing engine.

464 462 300 464 466 326 452 468 452 326 466 452 300 452 454 300 300 The processing enginemay process the dispatchto execute the chosen flow object(s), such as by executing an Action. The processing enginemay execute the Action asynchronously, e.g., in a background thread. When the Action's processing is complete, the AMBmay notify the client-side codevia a callback. More specifically, a callback function included in the client-side codemay be executed by the AMBonce the processing completes. The client-side codemay then execute, for example, the Retrieve Flow API (e.g., Function 3 above) to get results from execution of the flow object(s). It is to be noted that the client-side codeand the script client APImay be implemented in a number of computer languages in addition to or alternative to JavaScript. It is also to be understood that while the depicted figure shows Actions as the executable flow object, other embodiments may use other flow objects, such as flows and/or sub-flows.

7 FIG. 500 110 502 502 324 26 104 502 504 110 502 506 504 504 508 464 is an interaction overview diagram illustrating embodiments of interactionsbetween certain components of the back-end Flow APIand a server-side code. The server-side codemay be executable by the back-end client, for example, via the serversand/or. The server-side codemay interact with a scriptable objectincluded in the back-end Flow API. For example, the server-side codemay executea call to the Call Flow API (e.g., Function 1) included in the scriptable object. In turn, the scriptable objectmay then dispatchcall to the processing engine.

464 508 300 510 464 502 512 110 510 502 514 502 The processing enginemay process the dispatchto execute the chosen flow object(s), such as by executing an Action and then returningan ExecutionID representative of a “handle” or “pointer” to the Action being executed. The processing enginemay execute the Action asynchronously, such as via a background thread. In the depicted embodiment, the server-side codemay then executethe Check Action Execution Status API (e.g., Function 2) included in the back-end Flow API, for example, by using the returnedExecutionID as input to the Check Action Execution Status API. That is, the server-side codemay check the status of execution to see if the Action has completed execution. A returnedstatus may inform the server-side codethat the Action has not completed execution.

502 516 110 510 516 502 520 110 510 522 502 504 502 504 Accordingly, the server-side codemay wait and then again executethe Check Action Execution Status API (e.g., Function 2) included in the back-end Flow API, for example, by using the returnedExecutionID. A returnedstatus may now inform the server-side codethat the Action has completed execution. To receive the outputs of the Action's execution, the server-side code may then executethe Retrieve Action Outputs API (e.g., Function 3) included in the back-end Flow API, for example, by using the returnedExecutionID. The Retrieve Action Outputs API may then returnan array of output arguments derived by executing the Action. In certain embodiments, the server-side codeand/or the scriptable objectmay be implemented for execution via Rhino, a JavaScript engine written fully in Java and managed by the Mozilla Foundation. In other embodiments, the server-side codeand/or the scriptable objectmay be implemented in Java, Python, C, C++, and so on, executable by a variety of back-end engines.

8 FIG. 600 300 600 202 206 600 106 600 602 300 302 602 300 is a flowchart of an embodiment of a processthat may be used to create custom flow objects, such as flows, sub-flows, and Actions, which may then be reused. The processmay be implemented as computer instructions or code executable via the processor(s)and stored in the memory. The process, for example, may be executed via the flow data processing system. In the illustrated embodiment, the processmay create (block) one or more flow objects. For example, the flow designer systemmay be used to create (block) the one or more flow objects.

600 604 300 108 110 108 300 300 300 606 322 110 300 300 300 608 324 The processmay then provide an interface (block) for the flow objects. In the depicted example, two interfaces are provided. A first interface may include the front-end Flow APIs, and a second interface may include the back-end Flow APIs. As mentioned above, the front-end Flow APIsmay interface with the flow objectsto execute the objects, check the status of execution of the objects, and to retrieve results (block) to the front-end client. Likewise, the back-end Flow APIsmay interface with the flow objectsto execute the objects, check the status of execution of the objects, and to retrieve results (block) to the back-end client.

9 FIG. 700 110 702 702 324 26 104 702 704 110 702 706 704 504 708 464 706 702 702 702 704 702 704 is an interaction overview diagram illustrating embodiments of “fire and forget” interactionsbetween certain components of the back-end Flow APIand a server-side code. The server-side codemay be executable by the back-end client, for example, via the serversand/or. The server-side codemay interact with a scriptable objectincluded in the back-end Flow API. For example, the server-side codemay executea call to the Call Flow API (e.g., Function 1) included in the scriptable object. In turn, the scriptable objectmay then dispatchthe call to the processing engine. Because of the “fire and forget” nature of processing, after the executionthe server-side codemay continue execution without, for example, waiting for results. As mentioned earlier, the server-side codemay then periodically check for execution status and then retrieve results when execution of the API call is completed. In certain embodiments, the server-side codeand/or the scriptable objectmay be implemented for execution via Rhino, a JavaScript engine written fully in Java and managed by the Mozilla Foundation. In other embodiments, the server-side codeand/or the scriptable objectmay be implemented in Java, Python, C, C++, and so on, executable by a variety of back-end engines.

10 FIG. 800 110 802 802 324 26 104 802 804 110 802 806 804 804 808 464 806 804 464 is an interaction overview diagram illustrating embodiments of synchronous interactionsbetween certain components of the back-end Flow APIand a server-side code. The server-side codemay be executable by the back-end client, for example, via the serversand/or. The server-side codemay interact with a scriptable objectincluded in the back-end Flow API. For example, the server-side codemay executea call to the Call Flow API (e.g., Function 1) included in the scriptable object. In turn, the scriptable objectmay then executethe call to the processing engine. Because of the synchronous nature of processing, after the execution, the scriptable objectmay wait for results from the processing engine.

464 808 806 802 804 804 810 802 802 804 802 804 10 FIG. The processing enginemay then returnresults from the executionof the call. Likewise, the server-side codemay also wait for results from the scriptable object. Accordingly, the scriptable objectmay returnresults to the server-side codethat was waiting. Accordingly, both asynchronous and synchronous processing may be provided, with the synchronous example shown in. In certain embodiments, the server-side codeand/or the scriptable objectmay be implemented for execution via Rhino, a JavaScript engine written fully in Java and managed by the Mozilla Foundation. In other embodiments, the server-side codeand/or the scriptable objectmay be implemented in Java, Python, C, C++, and so on, executable by a variety of back-end engines.

The specific embodiments described above have been shown by way of example, and it should be understood that these embodiments may be susceptible to various modifications and alternative forms. It should be further understood that the claims are not intended to be limited to the particular forms disclosed, but rather to cover all modifications, equivalents, and alternatives falling within the spirit and scope of this disclosure.

The techniques presented and claimed herein are referenced and applied to material objects and concrete examples of a practical nature that demonstrably improve the present technical field and, as such, are not abstract, intangible or purely theoretical. Further, if any claims appended to the end of this specification contain one or more elements designated as “means for [perform]ing [a function] . . . ” or “step for [perform]ing [a function] . . . ”, it is intended that such elements are to be interpreted under 35 U.S.C. 112(f). However, for any claims containing elements designated in any other manner, it is intended that such elements are not to be interpreted under 35 U.S.C. 112(f).