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

24 lines
552 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 watcher REST API call namespace to be watcher. This change changes the API spec such that all of the watcher APIs are in the `watcher` namespace. Original commit: elastic/x-pack-elasticsearch@f409ab45693994948c07c8de2099706c307305cb
2015-04-28 18:43:05 -04:00
"watcher.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
"documentation": "http://www.elastic.co/guide/en/watcher/current/appendix-api-execute-watch.html",
"methods": [ "PUT", "POST" ],
"url": {
"path": "/_watcher/watch/{id}/_execute",
"paths": [ "/_watcher/watch/{id}/_execute" ],
"parts": {
"id": {
"type" : "string",
"description" : "Watch ID",
"required" : true
}
},
"params": {
}
},
"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
}
}
}