Resolves#206433
Added optional `exposeConfig` field to the `preconfiguredActionSchema`
to allow return the configuration for the pre-configured connectors,
which set this value as `true`.
This change is completely backward compatible, because this field is
optional and all the connectors, which don't have the value will remain
to work the same way as before the change (won't return the config).
Changed get and getAll methods of the ActionsClient to reflect opt-in
config based on the set `exposeConfig` value.
This PR:
- updates navigation instructions to accommodate for the navigation
changes related to solution views.
- updates instructions for adding sample data to rely on the
integrations page instead of the home page, that only exists with the
classic solution view
- updates references to the home page to avoid confusing users using one
of the new solution views
Closes: https://github.com/elastic/platform-docs-team/issues/529
Closes: https://github.com/elastic/platform-docs-team/issues/540
## Summary
Jira Cloud and Datacenter work using the same API urls. In this PR we
remove the calls to the capabilities API which was being used to know
the API url we needed to hit
To test it:
- Create Jira Cloud and Datacenter connectors
- Test all use cases related to them
Related to https://github.com/elastic/kibana/issues/189017
## Research Work
**getCapabilities, createIncident and getIncident** are always the same,
therefore ignored for the rest of this document
- getCapabilities: `/rest/capabilities`
- createIncident: `/rest/api/2/issue`
- getIncident: `/rest/api/2/issue`
## API links
- Cloud:
https://developer.atlassian.com/cloud/jira/platform/rest/v2/intro/#version
- DC: https://docs.atlassian.com/software/jira/docs/api/REST/9.17.0/
### Expected API urls based on the API links
- Get issue types
- Cloud: `GET /rest/api/2/issue/createmeta/{projectIdOrKey}/issuetypes`
- DC:`GET /rest/api/2/issue/createmeta/{projectIdOrKey}/issuetypes`
- Get fields by issue type
- Cloud: `GET
/rest/api/2/issue/createmeta/{projectIdOrKey}/issuetypes/{issueTypeId}`
- DC:
`GET /rest/api/2/issue/createmeta/{projectIdOrKey}/issuetypes/{issueTypeId}`
### API we hit
- Get issue types
- Cloud `GET
/rest/api/2/issue/createmeta?projectKeys=ROC&expand=projects.issuetypes.fields`
(variable name we are using is `getIssueTypesOldAPIURL`)
- DC `GET /rest/api/2/issue/createmeta/RES/issuetypes` (variable name is
`getIssueTypesUrl`)
- Get fields by issue type
- Cloud `GET
/rest/api/2/issue/createmeta?projectKeys=ROC&issuetypeIds={issueTypeId}&expand=projects.issuetypes.fields`
(variable name is `getIssueTypeFieldsOldAPIURL`)
- DC `GET /rest/api/2/issue/createmeta/RES/issuetypes/{issueTypeId}`
(variable name is `getIssueTypeFieldsUrl`)
#### Analysed use cases to retrieve API urls we hit
- created a case with JIRA Cloud as Connector
- did a connector test with JIRA Cloud as connector
- created a case with JIRA DC as connector
- did a connector test with JIRA DC as connector
### Conclusions
- We are not using the right endpoints for Cloud, we should update them
to use the same endpoints.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Christos Nasikas <christos.nasikas@elastic.co>
Co-authored-by: adcoelho <antonio.coelho@elastic.co>
Co-authored-by: Antonio <antoniodcoelho@gmail.com>
Co-authored-by: Lisa Cawley <lcawley@elastic.co>
## Summary
Resolves https://github.com/elastic/kibana/issues/188043
This PR adds new connector which is define integration with Elastic
Inference Endpoint via [Inference
APIs](https://www.elastic.co/guide/en/elasticsearch/reference/current/inference-apis.html)
The lifecycle of the Inference Endpoint are managed by the connector
registered handlers:
- `preSaveHook` -
[create](https://www.elastic.co/guide/en/elasticsearch/reference/current/put-inference-api.html)
new Inference Endpoint in the connector create mode (`isEdit === false`)
and
[delete](https://www.elastic.co/guide/en/elasticsearch/reference/current/delete-inference-api.html)+[create](https://www.elastic.co/guide/en/elasticsearch/reference/current/put-inference-api.html)
in the connector edit mode (`isEdit === true`)
- `postSaveHook` - check if the connector SO was created/updated and if
not removes Inference Endpoint from preSaveHook
- `postDeleteHook` -
[delete](https://www.elastic.co/guide/en/elasticsearch/reference/current/delete-inference-api.html)
Inference Endpoint if connector was deleted.
In the Kibana Stack Management Connectors, its represented with the new
card (Technical preview badge):
<img width="1261" alt="Screenshot 2024-09-27 at 2 11 12 PM"
src="https://github.com/user-attachments/assets/dcbcce1f-06e7-4d08-8b77-0ba4105354f8">
To simplify the future integration with AI Assistants, the Connector
consists from the two main UI parts: provider selector and required
provider settings, which will be always displayed
<img width="862" alt="Screenshot 2024-10-07 at 7 59 09 AM"
src="https://github.com/user-attachments/assets/87bae493-c642-479e-b28f-6150354608dd">
and Additional options, which contains optional provider settings and
Task Type configuration:
<img width="861" alt="Screenshot 2024-10-07 at 8 00 15 AM"
src="https://github.com/user-attachments/assets/2341c034-6198-4731-8ce7-e22e6c6fb20f">
subActions corresponds to the different taskTypes Inference API
supports. Each of the task type has its own Inference Perform params.
Currently added:
- completion & completionStream
- rerank
- text_embedding
- sparse_embedding
Follow up work:
1. Collapse/expand Additional options, when the connector flyout/modal
has AI Assistant as a context (path through the extending context
implementation on the connector framework level)
2. Add support for additional params for Completion subAction to be able
to path functions
3. Add support for tokens usage Dashboard, when inference API will
include the used tokens count in the response
4. Add functionality and UX for migration from existing specific AI
connectors to the Inference connector with proper provider and
completion task
5. Integrate Connector with the AI Assistants
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: István Zoltán Szabó <istvan.szabo@elastic.co>
Co-authored-by: Liam Thompson <32779855+leemthompo@users.noreply.github.com>
Co-authored-by: Steph Milovic <stephanie.milovic@elastic.co>
## Summary
Adds reference documentation about the Obs AI Assistant connector
(requested in #181282)
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
~This PR still needs work (tests, mainly), so keeping it in draft for
now, but feel free to take it for a spin.~
Implements Bedrock support, specifically for the Claude models.
Architecturally, this introduces LLM adapters: one for OpenAI (which is
what we already have), and one for Bedrock/Claude. The Bedrock/Claude
adapter does the following things:
- parses data from a SerDe (an AWS concept IIUC) stream using
`@smithy/eventstream-serde-node`.
- Converts function requests and results into XML and back (to some
extent)
- some slight changes to existing functionality to achieve _some_ kind
of baseline performance with Bedrock + Claude.
Generally, GPT seems better at implicit tasks. Claude needs explicit
tasks, otherwise it will take things too literally. For instance, I had
to use a function for generating a title because Claude was too eager to
add explanations. For the `classify_esql` function, I had to add extra
instructions to stop it from requesting information that is not there.
It is prone to generating invalid XML.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
