105 lines
3.4 KiB
Plaintext
105 lines
3.4 KiB
Plaintext
[[script-processor]]
|
|
=== Script processor
|
|
++++
|
|
<titleabbrev>Script</titleabbrev>
|
|
++++
|
|
|
|
Allows inline and stored scripts to be executed within ingest pipelines.
|
|
|
|
See <<modules-scripting-using, How to use scripts>> to learn more about writing scripts. The Script Processor
|
|
leverages caching of compiled scripts for improved performance. Since the
|
|
script specified within the processor is potentially re-compiled per document, it is important
|
|
to understand how script caching works. To learn more about
|
|
caching see <<modules-scripting-using-caching, Script Caching>>.
|
|
|
|
[[script-options]]
|
|
.Script Options
|
|
[options="header"]
|
|
|======
|
|
| Name | Required | Default | Description
|
|
| `lang` | no | "painless" | The scripting language
|
|
| `id` | no | - | The stored script id to refer to
|
|
| `source` | no | - | An inline script to be executed
|
|
| `params` | no | - | Script Parameters
|
|
include::common-options.asciidoc[]
|
|
|======
|
|
|
|
One of `id` or `source` options must be provided in order to properly reference a script to execute.
|
|
|
|
You can access the current ingest document from within the script context by using the `ctx` variable.
|
|
|
|
The following example sets a new field called `field_a_plus_b_times_c` to be the sum of two existing
|
|
numeric fields `field_a` and `field_b` multiplied by the parameter param_c:
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
{
|
|
"script": {
|
|
"lang": "painless",
|
|
"source": "ctx.field_a_plus_b_times_c = (ctx.field_a + ctx.field_b) * params.param_c",
|
|
"params": {
|
|
"param_c": 10
|
|
}
|
|
}
|
|
}
|
|
--------------------------------------------------
|
|
// NOTCONSOLE
|
|
|
|
It is possible to use the Script Processor to manipulate document metadata like `_index` and `_type` during
|
|
ingestion. Here is an example of an Ingest Pipeline that renames the index and type to `my-index` no matter what
|
|
was provided in the original index request:
|
|
|
|
[source,console]
|
|
--------------------------------------------------
|
|
PUT _ingest/pipeline/my-index
|
|
{
|
|
"description": "use index:my-index",
|
|
"processors": [
|
|
{
|
|
"script": {
|
|
"source": """
|
|
ctx._index = 'my-index';
|
|
ctx._type = '_doc';
|
|
"""
|
|
}
|
|
}
|
|
]
|
|
}
|
|
--------------------------------------------------
|
|
|
|
Using the above pipeline, we can attempt to index a document into the `any-index` index.
|
|
|
|
[source,console]
|
|
--------------------------------------------------
|
|
PUT any-index/_doc/1?pipeline=my-index
|
|
{
|
|
"message": "text"
|
|
}
|
|
--------------------------------------------------
|
|
// TEST[continued]
|
|
|
|
The response from the above index request:
|
|
|
|
[source,console-result]
|
|
--------------------------------------------------
|
|
{
|
|
"_index": "my-index",
|
|
"_type": "_doc",
|
|
"_id": "1",
|
|
"_version": 1,
|
|
"result": "created",
|
|
"_shards": {
|
|
"total": 2,
|
|
"successful": 1,
|
|
"failed": 0
|
|
},
|
|
"_seq_no": 89,
|
|
"_primary_term": 1,
|
|
}
|
|
--------------------------------------------------
|
|
// TESTRESPONSE[s/"_seq_no": \d+/"_seq_no" : $body._seq_no/ s/"_primary_term" : 1/"_primary_term" : $body._primary_term/]
|
|
|
|
In the above response, you can see that our document was actually indexed into `my-index` instead of
|
|
`any-index`. This type of manipulation is often convenient in pipelines that have various branches of transformation,
|
|
and depending on the progress made, indexed into different indices.
|