OpenSearch/docs/reference/ingest/processors/script.asciidoc

104 lines
3.4 KiB
Plaintext
Raw Normal View History

[[script-processor]]
=== Script Processor
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,js]
--------------------------------------------------
PUT _ingest/pipeline/my_index
{
"description": "use index:my_index and type:_doc",
"processors": [
{
"script": {
"source": """
ctx._index = 'my_index';
ctx._type = '_doc';
"""
}
}
]
}
--------------------------------------------------
// CONSOLE
Using the above pipeline, we can attempt to index a document into the `any_index` index.
[source,js]
--------------------------------------------------
PUT any_index/_doc/1?pipeline=my_index
{
"message": "text"
}
--------------------------------------------------
// CONSOLE
// TEST[continued]
The response from the above index request:
[source,js]
--------------------------------------------------
{
"_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.