[Runtime fields] Dedicated UI for data parsing

[sebelga]

We need to build a dedicated UI for parsing a string into fields. This UI needs to be as simple (and "mouse click") as possible. We need to guide our users with very little knowledge of grok and help them write a pattern with confidence.

This work can be split into the following tasks:

• Select the source (the index pattern and the field). This will most often come from the previous app where the user navigated from (and probably passed through query params).
• Parse a string into and object. Once the source is defined (we have the index pattern and the field) we can prepopulate the string to parse with one of the documents (e.g. the message field from the first document of "logs-*" index pattern). This string can still be edited by the user if he wants to.
  • Form with 2 inputs: one to add/edit a string that the user wants to parse and another one to enter a grok pattern.
  • We will use the "preview handler" exposed in [Index pattern field editor] Support "object" runtime fields #98330 and we will provide (1) a sample doc

{
  "message": "the string that the user has entered in the form"
}

and (2) the script we have automatically created for the user

"script": '''
    Map fields = grok('%{grok the user entered}') .extract(doc["message"].value);
    for (Map.Entry field : fields) {
      emit(field.getKey(), field.getValue());
    }
'''

The output of this task is an object that we can feed to the field selector below.

• A field selector. This component will display the fields that have been parsed and provide recommended type for each of them. The user can decide which field(s) he wants to extract.
  The field selector might already be exposed when doing [Index pattern field editor] Support "object" runtime fields #98330.
• Give the option to the user to "Edit the script" (to support advanced data parsing use cases). This will open the current field editor with the object runtime field and the generated script. If the user modifies the script he won't be able to go back to the parsing UI as that UI won't be able to handle custom Painless script logic.
• IN/OUT interface. Define the architecture on how the consuming app will provide parameters to this new UI (index pattern, field to parse...) and how we will expose the generated fields to the consuming app (it might not be necessary to do anything as when the user will return to the consuming app the fields will be fetched again and the new runtime object field will appear)

[elasticmachine]

Pinging @elastic/es-ui (Team:Elasticsearch UI)