honeymoose
/
OpenSearch
mirror of https://github.com/honeymoose/OpenSearch.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
OpenSearch/watcher/rest-api-spec/api/watcher.execute_watch.json

28 lines
732 B
JSON
Raw Normal View History

This commit contains a major refactoring to some of the core constructs in watcher. - What used to be the `HistoryService` is not named `ExecutionService`. In fact, it always was an execution context and was simply named wrong and place in the wrog place in the code. - A new `execution` package was created, to contain all execution related contsructs which includes the new `ExecutionService`, `WatchExecutionContext`, `WatchExecutor`, `InternalWatchExecutor`. - The `WatchExecutionContext` role in the execution process was extended to also enable it to "control" the execution. "control" in the sence that it can now provide default results to some of the contructs (for example, it can provide a default input and by that skip the execution of the input). Also, it enables simulating actions (more bellow). - There are two implementations now of the `WatchExecutionContext`. A `TriggeredExecutionContext` which is used when the trigger service triggers the execution of a watch. And `ManualExecutionContext` enabling to manually execute a watch. The latter, can be configured such that different phases in the normal executions of the watch can be skipped. This is great for simulating a watch execution, that is, executing a watch without actually fully executing the actions (e.g. create the emails that the email action would have normally send, but without actually sending it). Both of these new context implementations also sit in the new `execution` package. - With the changes described above, the actions now consult the execution context before actually performing their tasks. If the execution context indicates that the action should run in a "simulated" mode, the action will semi execute and return a `Simulated` result. Each action type defines what is "simulated mode" for it. For example, the email action creates the email and renders all its templats but doesn't actually send it, the returned `Email.Simulated` result will contain the email that would have been sent if it was running under normal conditions (non-simulated mode). The `index` action, doesn't actually indexes anything (just creating the index request that would have been executed), and the `webhook` action only creates the HTTP request but doesn't actually send it. - A new `execute` API was introduced that utilizes all of the above and enables to manually execute registered watches. The API provides all the tools to control what actions are simulated and enables skipping the execution of the watch `input` and `condition`. By default it also skip the recording of the execution in the watch history (though this can be enabled if desired). This API is exposed both by the Java `WatcherClient` and via a dedicated REST endpoint. (documentation around this new API was added as well) Closes elastic/elasticsearch#149 Original commit: elastic/x-pack-elasticsearch@ee8fe0490a093faa7b62a8dcd8534cd2c9d30242
2015-04-08 17:56:03 -04:00
{
Change the watch specific actions to reflect that they operate on watches. This change changes the watch specific actions put/get/delete/execute/ack to be watcher.<action>_watch. Original commit: elastic/x-pack-elasticsearch@86a91cb14166bb511d38a277f8f4288df26084ed
2015-04-28 19:08:28 -04:00
"watcher.execute_watch": {
This commit contains a major refactoring to some of the core constructs in watcher. - What used to be the `HistoryService` is not named `ExecutionService`. In fact, it always was an execution context and was simply named wrong and place in the wrog place in the code. - A new `execution` package was created, to contain all execution related contsructs which includes the new `ExecutionService`, `WatchExecutionContext`, `WatchExecutor`, `InternalWatchExecutor`. - The `WatchExecutionContext` role in the execution process was extended to also enable it to "control" the execution. "control" in the sence that it can now provide default results to some of the contructs (for example, it can provide a default input and by that skip the execution of the input). Also, it enables simulating actions (more bellow). - There are two implementations now of the `WatchExecutionContext`. A `TriggeredExecutionContext` which is used when the trigger service triggers the execution of a watch. And `ManualExecutionContext` enabling to manually execute a watch. The latter, can be configured such that different phases in the normal executions of the watch can be skipped. This is great for simulating a watch execution, that is, executing a watch without actually fully executing the actions (e.g. create the emails that the email action would have normally send, but without actually sending it). Both of these new context implementations also sit in the new `execution` package. - With the changes described above, the actions now consult the execution context before actually performing their tasks. If the execution context indicates that the action should run in a "simulated" mode, the action will semi execute and return a `Simulated` result. Each action type defines what is "simulated mode" for it. For example, the email action creates the email and renders all its templats but doesn't actually send it, the returned `Email.Simulated` result will contain the email that would have been sent if it was running under normal conditions (non-simulated mode). The `index` action, doesn't actually indexes anything (just creating the index request that would have been executed), and the `webhook` action only creates the HTTP request but doesn't actually send it. - A new `execute` API was introduced that utilizes all of the above and enables to manually execute registered watches. The API provides all the tools to control what actions are simulated and enables skipping the execution of the watch `input` and `condition`. By default it also skip the recording of the execution in the watch history (though this can be enabled if desired). This API is exposed both by the Java `WatcherClient` and via a dedicated REST endpoint. (documentation around this new API was added as well) Closes elastic/elasticsearch#149 Original commit: elastic/x-pack-elasticsearch@ee8fe0490a093faa7b62a8dcd8534cd2c9d30242
2015-04-08 17:56:03 -04:00
"documentation": "http://www.elastic.co/guide/en/watcher/current/appendix-api-execute-watch.html",
"methods": [ "PUT", "POST" ],
"url": {
"path": "/_watcher/watch/{id}/_execute",
Added inline watch support to _execute API This change allows the specification of a watch inline to the `_execute` API. This watch id will not be persisted to the index and if record_execution is set to true it will result in an error. The internal id `_anonymous_` will be used for the watch id and will be the watch id in the watch record. Original commit: elastic/x-pack-elasticsearch@00e32c383857030367e280bcd44d25711123e709
2015-06-16 09:36:25 -04:00
"paths": [ "/_watcher/watch/{id}/_execute", "/_watcher/watch/_execute" ],
This commit contains a major refactoring to some of the core constructs in watcher. - What used to be the `HistoryService` is not named `ExecutionService`. In fact, it always was an execution context and was simply named wrong and place in the wrog place in the code. - A new `execution` package was created, to contain all execution related contsructs which includes the new `ExecutionService`, `WatchExecutionContext`, `WatchExecutor`, `InternalWatchExecutor`. - The `WatchExecutionContext` role in the execution process was extended to also enable it to "control" the execution. "control" in the sence that it can now provide default results to some of the contructs (for example, it can provide a default input and by that skip the execution of the input). Also, it enables simulating actions (more bellow). - There are two implementations now of the `WatchExecutionContext`. A `TriggeredExecutionContext` which is used when the trigger service triggers the execution of a watch. And `ManualExecutionContext` enabling to manually execute a watch. The latter, can be configured such that different phases in the normal executions of the watch can be skipped. This is great for simulating a watch execution, that is, executing a watch without actually fully executing the actions (e.g. create the emails that the email action would have normally send, but without actually sending it). Both of these new context implementations also sit in the new `execution` package. - With the changes described above, the actions now consult the execution context before actually performing their tasks. If the execution context indicates that the action should run in a "simulated" mode, the action will semi execute and return a `Simulated` result. Each action type defines what is "simulated mode" for it. For example, the email action creates the email and renders all its templats but doesn't actually send it, the returned `Email.Simulated` result will contain the email that would have been sent if it was running under normal conditions (non-simulated mode). The `index` action, doesn't actually indexes anything (just creating the index request that would have been executed), and the `webhook` action only creates the HTTP request but doesn't actually send it. - A new `execute` API was introduced that utilizes all of the above and enables to manually execute registered watches. The API provides all the tools to control what actions are simulated and enables skipping the execution of the watch `input` and `condition`. By default it also skip the recording of the execution in the watch history (though this can be enabled if desired). This API is exposed both by the Java `WatcherClient` and via a dedicated REST endpoint. (documentation around this new API was added as well) Closes elastic/elasticsearch#149 Original commit: elastic/x-pack-elasticsearch@ee8fe0490a093faa7b62a8dcd8534cd2c9d30242
2015-04-08 17:56:03 -04:00
"parts": {
"id": {
"type" : "string",
Added inline watch support to _execute API This change allows the specification of a watch inline to the `_execute` API. This watch id will not be persisted to the index and if record_execution is set to true it will result in an error. The internal id `_anonymous_` will be used for the watch id and will be the watch id in the watch record. Original commit: elastic/x-pack-elasticsearch@00e32c383857030367e280bcd44d25711123e709
2015-06-16 09:36:25 -04:00
"description" : "Watch ID"
This commit contains a major refactoring to some of the core constructs in watcher. - What used to be the `HistoryService` is not named `ExecutionService`. In fact, it always was an execution context and was simply named wrong and place in the wrog place in the code. - A new `execution` package was created, to contain all execution related contsructs which includes the new `ExecutionService`, `WatchExecutionContext`, `WatchExecutor`, `InternalWatchExecutor`. - The `WatchExecutionContext` role in the execution process was extended to also enable it to "control" the execution. "control" in the sence that it can now provide default results to some of the contructs (for example, it can provide a default input and by that skip the execution of the input). Also, it enables simulating actions (more bellow). - There are two implementations now of the `WatchExecutionContext`. A `TriggeredExecutionContext` which is used when the trigger service triggers the execution of a watch. And `ManualExecutionContext` enabling to manually execute a watch. The latter, can be configured such that different phases in the normal executions of the watch can be skipped. This is great for simulating a watch execution, that is, executing a watch without actually fully executing the actions (e.g. create the emails that the email action would have normally send, but without actually sending it). Both of these new context implementations also sit in the new `execution` package. - With the changes described above, the actions now consult the execution context before actually performing their tasks. If the execution context indicates that the action should run in a "simulated" mode, the action will semi execute and return a `Simulated` result. Each action type defines what is "simulated mode" for it. For example, the email action creates the email and renders all its templats but doesn't actually send it, the returned `Email.Simulated` result will contain the email that would have been sent if it was running under normal conditions (non-simulated mode). The `index` action, doesn't actually indexes anything (just creating the index request that would have been executed), and the `webhook` action only creates the HTTP request but doesn't actually send it. - A new `execute` API was introduced that utilizes all of the above and enables to manually execute registered watches. The API provides all the tools to control what actions are simulated and enables skipping the execution of the watch `input` and `condition`. By default it also skip the recording of the execution in the watch history (though this can be enabled if desired). This API is exposed both by the Java `WatcherClient` and via a dedicated REST endpoint. (documentation around this new API was added as well) Closes elastic/elasticsearch#149 Original commit: elastic/x-pack-elasticsearch@ee8fe0490a093faa7b62a8dcd8534cd2c9d30242
2015-04-08 17:56:03 -04:00
}
},
"params": {
Added dynamic variables registry to the execution context This enables different constructs (primarily scripts) to set variables that can be access by subsequent constructs throughout the wathc execution. These variables are scoped to a single execution, that is, they are not persisted across multiple executions of the same watch. Closes elastic/elasticsearch#589 Original commit: elastic/x-pack-elasticsearch@34223d19919c73f1cf6db8a1e027bd9e417a8dff
2015-06-17 14:06:29 -04:00
"debug" : {
"type" : "boolean",
"description" : "indicates whether the watch should execute in debug mode",
"required" : false
}
This commit contains a major refactoring to some of the core constructs in watcher. - What used to be the `HistoryService` is not named `ExecutionService`. In fact, it always was an execution context and was simply named wrong and place in the wrog place in the code. - A new `execution` package was created, to contain all execution related contsructs which includes the new `ExecutionService`, `WatchExecutionContext`, `WatchExecutor`, `InternalWatchExecutor`. - The `WatchExecutionContext` role in the execution process was extended to also enable it to "control" the execution. "control" in the sence that it can now provide default results to some of the contructs (for example, it can provide a default input and by that skip the execution of the input). Also, it enables simulating actions (more bellow). - There are two implementations now of the `WatchExecutionContext`. A `TriggeredExecutionContext` which is used when the trigger service triggers the execution of a watch. And `ManualExecutionContext` enabling to manually execute a watch. The latter, can be configured such that different phases in the normal executions of the watch can be skipped. This is great for simulating a watch execution, that is, executing a watch without actually fully executing the actions (e.g. create the emails that the email action would have normally send, but without actually sending it). Both of these new context implementations also sit in the new `execution` package. - With the changes described above, the actions now consult the execution context before actually performing their tasks. If the execution context indicates that the action should run in a "simulated" mode, the action will semi execute and return a `Simulated` result. Each action type defines what is "simulated mode" for it. For example, the email action creates the email and renders all its templats but doesn't actually send it, the returned `Email.Simulated` result will contain the email that would have been sent if it was running under normal conditions (non-simulated mode). The `index` action, doesn't actually indexes anything (just creating the index request that would have been executed), and the `webhook` action only creates the HTTP request but doesn't actually send it. - A new `execute` API was introduced that utilizes all of the above and enables to manually execute registered watches. The API provides all the tools to control what actions are simulated and enables skipping the execution of the watch `input` and `condition`. By default it also skip the recording of the execution in the watch history (though this can be enabled if desired). This API is exposed both by the Java `WatcherClient` and via a dedicated REST endpoint. (documentation around this new API was added as well) Closes elastic/elasticsearch#149 Original commit: elastic/x-pack-elasticsearch@ee8fe0490a093faa7b62a8dcd8534cd2c9d30242
2015-04-08 17:56:03 -04:00
}
},
"body": {
"description" : "Execution control",
Fix REST execute API call with empty body. Execute with an empty body will now just use the defaults. Add REST test for empty body. Fixes elastic/elasticsearch#217 Original commit: elastic/x-pack-elasticsearch@072cd47250820cd09f1789395f9d820040af296e
2015-04-14 17:04:48 -04:00
"required" : false
This commit contains a major refactoring to some of the core constructs in watcher. - What used to be the `HistoryService` is not named `ExecutionService`. In fact, it always was an execution context and was simply named wrong and place in the wrog place in the code. - A new `execution` package was created, to contain all execution related contsructs which includes the new `ExecutionService`, `WatchExecutionContext`, `WatchExecutor`, `InternalWatchExecutor`. - The `WatchExecutionContext` role in the execution process was extended to also enable it to "control" the execution. "control" in the sence that it can now provide default results to some of the contructs (for example, it can provide a default input and by that skip the execution of the input). Also, it enables simulating actions (more bellow). - There are two implementations now of the `WatchExecutionContext`. A `TriggeredExecutionContext` which is used when the trigger service triggers the execution of a watch. And `ManualExecutionContext` enabling to manually execute a watch. The latter, can be configured such that different phases in the normal executions of the watch can be skipped. This is great for simulating a watch execution, that is, executing a watch without actually fully executing the actions (e.g. create the emails that the email action would have normally send, but without actually sending it). Both of these new context implementations also sit in the new `execution` package. - With the changes described above, the actions now consult the execution context before actually performing their tasks. If the execution context indicates that the action should run in a "simulated" mode, the action will semi execute and return a `Simulated` result. Each action type defines what is "simulated mode" for it. For example, the email action creates the email and renders all its templats but doesn't actually send it, the returned `Email.Simulated` result will contain the email that would have been sent if it was running under normal conditions (non-simulated mode). The `index` action, doesn't actually indexes anything (just creating the index request that would have been executed), and the `webhook` action only creates the HTTP request but doesn't actually send it. - A new `execute` API was introduced that utilizes all of the above and enables to manually execute registered watches. The API provides all the tools to control what actions are simulated and enables skipping the execution of the watch `input` and `condition`. By default it also skip the recording of the execution in the watch history (though this can be enabled if desired). This API is exposed both by the Java `WatcherClient` and via a dedicated REST endpoint. (documentation around this new API was added as well) Closes elastic/elasticsearch#149 Original commit: elastic/x-pack-elasticsearch@ee8fe0490a093faa7b62a8dcd8534cd2c9d30242
2015-04-08 17:56:03 -04:00
}
}
}