REPRESENTATION AND ANALYSIS OF WORKFLOWS USING ABSTRACT SYNTAX TREES
A workflow for an operational process may be defined using a functional programming language. A computer system may parse the workflow to generate an abstract syntax tree, which may include states of the workflow and transitions from one workflow state to another. The computer system may generate code paths from the abstract syntax tree representing sequences of execution. Reflection on the workflow may be performed using the abstract syntax tree and code paths to allow intelligent decision-making.
This application is a continuation of U.S. application Ser. No. 16/421,686, filed May 54, 2019, which claims the benefit of U.S. Provisional Patent Application No. 62/676,240, filed May 24, 2018, which are hereby incorporated by reference in their entirety.
FIELD OF THE INVENTIONThe present invention relates to the use of abstract syntax trees to represent workflows and to analyze said workflows.
BACKGROUNDThe background description provided here is for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description that may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure.
Workflows can be used to represent operations in a wide variety of industries from logistics to software development. A workflow helps organize information about processes and allows analysis and reasoning about the processes. Existing methods of representing workflows have several major disadvantages.
One method of representing workflows is not formalize them as state machines and instead describe the workflows ad hoc in software code. Automated analysis of the workflow is generally not possible in this case. Analysis would have to be designed separately for each use case.
Other methods of representing workflows are to represent the workflow as state machines but without full encodings of the transitions between states. Although the basic states of the workflow may be known, the transitions are not identified with precision, and it is not possible to determine the free and bound variables involved in a state machine transition. Because of the lack of transition information, limited analysis can be performed automatically on these workflows.
Another existing method of representing workflows is to do so with a non-code format, such as Extensible Markup Language (XML). States may be represented in the non-code format, but the use of a non-code language significantly limits the expressive power of transition functions. While some systems may allow writing custom functions as transitions, the custom functions are opaque and cannot be automatically analyzed in the same process as the state functions. It cannot be automatically determined what operations the custom functions perform, what variables they depend on, and other features.
It would be desirable to develop a more effective representation of workflows using abstract syntax trees that allows more effective reasoning and analysis of the workflows.
SUMMARY OF THE INVENTIONEmbodiments of the invention relate to representing workflows using abstract syntax trees. The abstract syntax tree may be used for various forms of reflection and analysis of the workflow in a seamless manner.
One embodiment relates to a method for building an abstract syntax tree and code paths. A computer file may be provided representing a workflow in a functional programming language. A computer system may parse the file, identify workflow states, and generate state transition functions that specify transitions from one workflow state to another workflow state. The computer system may generate an abstract syntax tree from the workflow states and transition functions. From the abstract syntax tree, the computer system may generate code paths representing sequences of execution. The workflow may be executed as code, and the code paths updated as new input values are bound to input variables of functions.
The code paths may be used for reflection and analysis about what code paths are available or what actions can be performed. Moreover, historical data may be provide from past runs of the workflow to allow the system to automatically choose optimal actions to perform.
In this specification, reference is made in detail to specific embodiments of the invention. Some of the embodiments or their aspects are illustrated in the drawings.
For clarity in explanation, the invention has been described with reference to specific embodiments, however it should be understood that the invention is not limited to the described embodiments. On the contrary, the invention covers alternatives, modifications, and equivalents as may be included within its scope as defined by any patent claims. The following embodiments of the invention are set forth without any loss of generality to, and without imposing limitations on, the claimed invention. In the following description, specific details are set forth in order to provide a thorough understanding of the present invention. The present invention may be practiced without some or all of these specific details. In addition, well known features may not have been described in detail to avoid unnecessarily obscuring the invention.
In addition, it should be understood that steps of the exemplary methods set forth in this exemplary patent can be performed in different orders than the order presented in this specification. Furthermore, some steps of the exemplary methods may be performed in parallel rather than being performed sequentially. Also, the steps of the exemplary methods may be performed in a network environment in which some steps are performed by different computers in the networked environment.
Embodiments herein relate to representing a workflow in an abstract syntax tree. An operator may define the workflow in a programming language, such as a functional programming language. Functional programming languages are programming languages that treat computer programs as the evaluation of mathematical functions and avoids state changes and side effects. Side effects refer to the storage of data and causing of effects other than the return of data from a function. Functional languages that may be used herein include Lisp, Scheme, Haskell, Erlang, OCaml, and others. Alternatively, an operator may define a workflow using a visual interface, and a computer program may translate the visually defined workflow into a programming language.
In step 102, the computer system parses the file comprising the instructions representing the workflow. During parsing, the file may be tokenized into tokens. The computer system may iterate over the tokens and operate on them.
In step 103, during parsing, the computer system may identify one or more workflow states from the file. States define a state of the workflow after functions or operations have been performed. During parsing, the computer system may also generate one or more state transition functions that specify the transitions from one workflow state to another workflow state.
State transition functions may be pure functions in the form S1->A->C1->R<Option(S2*C2)>. Each state transition function takes as input a source state S1, an action A, and context data C1 and returns a new state S2 and updated context C2 with the result value wrapped inside a container of type R. A state transition function may output the empty set if no transition is possible. State transitions may be thought of as actions, whose output depends on the current state and context.
Pure functions have two properties. First, they always evaluate to the same return value given the same argument value(s). The function result value cannot depend on any hidden information or state that may change while program execution proceeds or between different executions of the program, nor can it depend on any external input from I/O devices. Second, the evaluation of the function does not cause any semantically observable side effect or output; in other words, there are no mutations of mutable objects or output to I/O devices.
In step 104, the computer system generates an abstract syntax tree based on the workflow states and the one or more state transition functions. An abstract syntax tree may be represented in the same functional programming language as the workflow or in other programming languages. Classes and structs may be used as data structures for representing the abstract syntax tree.
Transitions may be defined not just for particular actions but may also include other information, such as the employee performing the action or other parameters related to the action. In one embodiment, different transitions may be provided from a state for different employees performing the action, such as “Charles picks up the soda from the shelf” or “Anne picks up the soda from the shelf.” Alternatively, a single transition may be provided with different context information that may be provided to identify the employee performing the action.
In one embodiment, other parameters related to the action may be represented with different transitions, such as providing a first transition from a state for finding soda in warehouse A and a second transition from said state for finding soda in warehouse B. Alternatively, a single transition may be provided with different context information that may be provided to specify the different parameters such as the identity of the warehouse.
Providing different transitions, or different context, for employees or other parameters allows tracking and analyzing the workflow according to performance by the employees or based on the other parameters. For example, the employee or other parameters may affect the success probability of successfully completing the transition and the time it takes to complete the transition in the workflow. Some employees may perform more successfully or more quickly at certain tasks in the workflow than others. Moreover, other variables, such as the identity of the warehouse, may also affect the success rate and time taken.
Once a workflow has been represented as an abstract syntax tree, the workflow can reflect upon itself and various operations may be automatically performed, such as automatically finding the most efficient path from a source state to a desired target state. Artificial intelligence may be applied to the abstract syntax tree to determine optimal paths or actions to take.
Two potential types of code paths may exist, depending on whether a function branches or not due to control flow statements such as IF/THEN/ELSE statements. If a function has no control flow statements that evaluate to a jump instruction based on a condition, such as IF/THEN/ELSE statements, for loops, while loops, and ternary operators, then only one code path exists, which includes all the statements within the function. If a function has control flow statements, then the computer system forks and generates a code path for each conditional path based on each condition outcome. The number of code paths generated depends on the number of control flow statements within the abstract syntax tree.
The result of the code path generation is a set of code paths having a target state and one or more conditions that must be true for a transition to occur to the target state, where each condition may depend on one or more input variables of the source state, action, and context (S1, A, C1). If a condition does not depend on any input variable, then the condition can be evaluated to a constant during code path generation and eliminated. The code path generation process 302 need only occur once during runtime so long as the underlying code and abstract syntax tree do not change.
In step 303, one or more steps of the workflow may be performed. Some steps of the workflow may be automatically completed by the computer system, such as assigning a task to a human worker or charging a credit card. Others may require human input or interaction, such as waiting to receive an order from an e-commerce website or payment information from a customer. Still others may require input from sensors or other computer systems in the environment, for example a confirmation from a sensor or computer system that a product was picked up in a warehouse or sent out for delivery. The workflow may naturally pause at points where human input or input from sensors or other computer systems is needed and resume when the appropriate input is received.
In step 304, additional inputs may be determined, such as from the execution of the workflow, from environmental sensors, or from user inputs. The input values may be used to update the code paths. The input variables in the code paths may be replaced with the input values (in other words, input values are bound to the input variables) and re-evaluation may be performed on the code paths. For example, some conditions on the code paths that had been unknown may now be determined to be true or false based on the new input values.
In step 305, the workflow may be analyzed by using the code paths and the abstract syntax tree. In one form of reflection on the abstract syntax tree, a source state may be provided, and the computer system may determine all potential code paths from the source state to a target state and the required conditions that must be met for each code path to reach the desired target state. In another from of reflection, a source state may be provided and, optionally, context data. The computer system may filter the potential actions available to determine which actions may be performed from the source state based on the context and the code paths from the source state.
In some embodiments, analysis of the workflow may be performed to influence choices made by the system in progressing in the workflow. When presented with an option of a plurality of actions to perform in the workflow, the computer system may use determinations of potential code paths and actions to perform, as well as their likelihood of success, likely time to completion, and other metrics to select an action from the plurality of actions to perform. The computer system may select appropriate actions to optimize probability of success and time to completion.
The process ends when the workflow completes at step 306.
In step 401, the computer system may store tracked information about prior iterations of the workflow. For example, the computer system may store information about whether the workflow was successful or unsuccessful and how long it took to complete the workflow. A database may be provided, and the computer system may store in the database information about success rates and completion time. In some embodiments, the database may store information per transition to identify the past historical success rate of that transition and the time to complete that transition. The historical information may be provided as averages, means, medians, modes, or other statistical information or metrics.
In step 402, the workflow may be run and one or more code paths of the workflow may be updated during runtime. The time to completion and success of each action may be monitored and then updated in the database. At some point during execution, a fork may be reached at a state where a plurality of actions are available and the computer system must decide which action to perform (step 403).
In step 404, the tracked historical information may be retrieved from the database to analyze historical information about the available actions. The computer system may compute a predicted success rate or time to completion to transition from the present state to a target state for each of the available actions by using the stored information about the success rate or time to completion for each transition on the code path involving the action from the present state to the target state.
In step 405, an action may be selected from the available actions based on the predicted success rate or time to completion.
In some embodiments, the computer system may use historical information or past configuration to determine when the workflow has reached an exceptional situation and send an alert to an operator.
In additional embodiments, a computer system may be used to generate a user interface from the abstract syntax tree and code paths. The computer system iterates over the states of the abstract syntax tree and code paths and determines the states at which user input is required. The computer system then automatically generates a user interface with user interface elements to receive the user input identified in the workflow. The user interface is then presented at the appropriate times in the workflow with the user interface elements for receiving the necessary user input. The user interface may automatically disappear at steps of the workflow where user input is not required.
The terminology used herein is for the purpose of describing particular aspects only and is not intended to be limiting of the disclosure. As used herein, the singular forms “a,” “an,” and “the” are intended to comprise the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
While the invention has been particularly shown and described with reference to specific embodiments thereof, it should be understood that changes in the form and details of the disclosed embodiments may be made without departing from the scope of the invention. Although various advantages, aspects, and objects of the present invention have been discussed herein with reference to various embodiments, it will be understood that the scope of the invention should not be limited by reference to such advantages, aspects, and objects. Rather, the scope of the invention should be determined with reference to patent claims.
Claims
1. (canceled)
2. A method, comprising:
- providing a file comprising computer instructions representing a workflow in a functional programming language;
- parsing the file to identify workflow states;
- generating an abstract syntax tree based on the workflow states and one or more transitions between the workflow states;
- building, from the abstract syntax tree, one or more code paths, each code path representing a potential sequence of execution in the workflow;
- receiving one or more new input values for the workflow; and
- iteratively executing the workflow and updating the one or more code paths based on the new input values.
3. The method of claim 2, wherein the file defines the workflow using one or more recursive function calls that have no side effects.
4. The method of claim 2, further comprising:
- generating one or more state transition functions that specify the transitions between the workflow states,
- wherein the transitions are based on an action and a context, and
- wherein generating the abstract syntax tree is further based on the one or more state transition functions.
5. The method of claim 4, wherein the one or more state transition functions are pure functions that have no side effects.
6. The method of claim 2, wherein the abstract syntax tree is represented in the same functional programming language as the file representing the workflow.
7. The method of claim 2, further comprising:
- providing a source state and a target state; and
- determining one or more code paths and required conditions to reach the target state from the source state.
8. The method of claim 2, further comprising:
- providing a source state and a context; and
- determining a set of actions that may be performed in the source state based on the context and the one or more code paths.
9. The method of claim 2, further comprising:
- providing one or more environmental sensors,
- wherein the new input values comprise one or more inputs from the environment sensors.
10. The method of claim 2, further comprising:
- storing information about the success rate of transitions between states in the abstract syntax tree, where the transitions are associated with actions;
- iteratively executing the workflow and updating the one or more code paths until a first state is reached where a plurality of actions are available;
- computing a predicted success rate to transition from the first state to a second state for each of the plurality of available actions by using the stored information about the success rate of transitions for each transition on the code path involving the action from the first state to the second state; and
- selecting an action from the plurality of actions based on the predicted success rates.
11. The method of claim 2, further comprising:
- storing information about the time for transitions between states in the abstract syntax tree, where the transitions are associated with actions;
- iteratively executing the workflow and updating the one or more code paths until a first state is reached where a plurality of actions are available;
- computing a predicted time to transition from the first state to a second state for each of the plurality of available actions by using the stored information about the time to transition for each transition on the code path involving the action from the first state to the second state; and
- selecting an action from the plurality of actions based on the predicted times.
12. A non-transitory computer-readable medium, the non-transitory computer-readable medium comprising instructions for:
- providing a file comprising computer instructions representing a workflow in a functional programming language;
- parsing the file to identify workflow states;
- generating an abstract syntax tree based on the workflow states and one or more transitions between the workflow states;
- building, from the abstract syntax tree, one or more code paths, each code path representing a potential sequence of execution in the workflow;
- receiving one or more new input values for the workflow; and
- iteratively executing the workflow and updating the one or more code paths based on the new input values.
13. The non-transitory computer-readable medium of claim 12, further comprising instructions for:
- automatically generating, based on the abstract syntax tree, a user interface to receive the one or more new input values for the workflow as user inputs.
14. The non-transitory computer-readable medium of claim 12, further comprising instructions for:
- generating one or more state transition functions that specify the transitions between the workflow states,
- wherein the transitions are based on an action and a context, and
- wherein generating the abstract syntax tree is further based on the one or more state transition functions.
15. The non-transitory computer-readable medium of claim 12, wherein the abstract syntax tree is represented in the same functional programming language as the file representing the workflow.
16. The non-transitory computer-readable medium of claim 12, further comprising instructions for:
- providing a source state and a target state; and
- determining one or more code paths and required conditions to reach the target state from the source state.
17. The non-transitory computer-readable medium of claim 12, further comprising instructions for:
- providing a source state and a context; and
- determining a set of actions that may be performed in the source state based on the context and the one or more code paths.
18. The non-transitory computer-readable medium of claim 12, further comprising instructions for:
- providing one or more environmental sensors,
- wherein the new input values comprise one or more inputs from the environment sensors.
19. The non-transitory computer-readable medium of claim 12, further comprising instructions for:
- storing information about the success rate of transitions between states in the abstract syntax tree, where the transitions are associated with actions;
- iteratively executing the workflow and updating the one or more code paths until a first state is reached where a plurality of actions are available;
- computing a predicted success rate to transition from the first state to a second state for each of the plurality of available actions by using the stored information about the success rate of transitions for each transition on the code path involving the action from the first state to the second state; and
- selecting an action from the plurality of actions based on the predicted success rates.
20. The non-transitory computer-readable medium of claim 12, further comprising instructions for:
- storing information about the time for transitions between states in the abstract syntax tree, where the transitions are associated with actions;
- iteratively executing the workflow and updating the one or more code paths until a first state is reached where a plurality of actions are available; and
- computing a predicted time to transition from the first state to a second state for each of the plurality of available actions by using the stored information about the time to transition for each transition on the code path involving the action from the first state to the second state;
- selecting an action from the plurality of actions based on the predicted times.
21. The non-transitory computer-readable medium of claim 12, further comprising instructions for:
- identifying the workflow states from the file representing the workflow.
Type: Application
Filed: Jan 17, 2022
Publication Date: May 5, 2022
Inventor: Tejas Viswanath (San Francisco, CA)
Application Number: 17/577,366