Endpoints are JavaScript scripts. To add a new endpoint, just need a script to run when that endpoint is invoked (and some configuration to control it). Using the vast array of JavaScript modules available for NodeJS, it's possible to make the endpoints for any propose.
Note |
---|
Endpoints only respond to PUT, POST, GET and DELETE requests. Data for the request should be sent in the message body as json and the content type of the request should be set to application/json. |
In the folder server/endpoints
can be found all the endpoints available which can be use as reference for the new endpoint. Make sure you have the following requirements:
server/endpoints
src/app/shared/services/api.service.ts
needs to be updated with a new function which will point to the new endpoint. All endpoint configuration and scripts are held on disk in the endpoints directory under the installation directory. There is a directory for each endpoint so, for instance, the search endpoint (as shipped) can be found in the endpoints/search directory.
In this directory, you'll find an endpoint.json file. This is the main configuration file for the endpoint and holds its properties.
The endpoint.json file for the search endpoint is shown below:
Code Block | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
module.exports = { endpoint: 'search', enabled: true, description: 'Default search endpoint', processing: [ [ { label: 'search', engine: 'elastic', scripts: [ { script: 'scripts/search', config: { default_index: { compositeSearchFields: { content: 1.0, title: 1.0, url: 1.0 }, suggest: { field: 'title', candidates: 3, gram_size: 3, mode: 'always' }, security: { aclField: 'acls' }, dateField: 'lastModified', filters: {}, fetch: { excludes: ['cleandescriptionsearch'] }, parsed_options: { extendedOperators: true, customOperators: true, wildcards: true } } } } ] } ] ] } |
Reading down the file, you can see the following:
server/engines
script - The path of the script
default_index - This will be the configuration use as default in case a configuration with the name of the index doesn't exist
compositeSearchFields:- This is the list of fields where qpl will generate the query within the boosting value.
suggest - This is the configuration of elastic search for the suggestion feature.
security - Security properties applicable for the search
dateField - Date field used for the advanced search form
When a request is received on an endpoint, it triggers the executions of scripts associated with the endpoint (and configured in the endpoint.json file described above). Multiple scripts can be run, sequentially or in parallel, with the results of one script available to the next. Once all scripts have been run, the result is returned to the caller. This flexible processing allows for a number of scenarios, including making multiple searches with merged results to be handled.
See here for detailed information on endpoint processing.
Configuring engines allows the Enterprise Search server to talk to search engines. It is designed to be used with QPL for JavaScript.
When connecting to search engines, it's likely that whilst you might have a certain number of endpoints, there will not typically be a one to one correspondence to the search engines used. For example, in the shipped configuration, both the search and typeahead endpoints use the same search engine configuration.
Engine configurations are held in the engines directory under the installation directory. Each engine configuration is held in its own json file, for example elastic.json.
An example configuration (for Elasticsearch) is shown below:
Code Block | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
{ "id": "elastic", "enabled": true, "implementation": "qpl-elastic", /* QPL JS Engine specific version */ "config": { "server": "http://localhost:9200", "version": 6, "serverAuth": "http://user:password@localhost:9200" } } |
Reading through the file you'll see:
If you need to connect more than one engine of the same type, you'll simply have two engine configurations with different ids using the same implementation but different configurations. You'll then use the appropriate id in the appropriate script configuration.
When an endpoint that has an engine configured is called, the SEIA server first loads the script referenced in the implementation and calls new on it, passing the configuration, to get a reference. This reference will then be passed to the processing scripts, where its methods may be called to access engine functionality.