But I've opened a case with support because the response I get when attempting to use it (with the access token associated with my Custom API Source in Workplace Search) is:
"error": "Routing Error. The path you have requested is invalid."
I'm curious if anyone else has used the various API's for creating (bulk_create) or updating or removing documents in Custom API Sources?
We use these Custom API Sources extensively. We typically have a logstash pipeline doing the work to pull the data from our custom source and index it in workplace search. In this case, the pipeline uses a jdbc input. And the query for the jdbc input has changed -- not the schema but the number of results it produces. So what I want to do is "purge" the existing documents in the Custom API Source indexes and re-fill them with the proper subset of documents. This way I don't have to completely remove the Custom API source and re-add it, having to, in turn, re-do the Display Settings.
Anyone else ever tried to do such a purge without entirely removing and re-adding the Custom API source?
what I want to do is "purge" the existing documents in the Custom API Source indexes and re-fill them with the proper subset of documents. This way I don't have to completely remove the Custom API source and re-add it, having to, in turn, re-do the Display Settings.
I'm glad to hear that this is what you're using the delete-all-documents API for! This was exactly the usecase we developed it for. It definitely should work as you're expecting it to, so I'd love to help you track down the issue.
This way I don't have to completely remove the Custom API source and re-add it, having to, in turn, re-do the Display Settings.
Actually, you might be interested to note our Create a Content Source API, which allows you to specify your schema and display settings at creation time, and/or our Update a Content Source API, which allows you to modify them after creation time.
I'm skeptical that I've "fat-fingered" the source ID or the bearer token because these are simply copy and past operations... I've redacted them here, obviously, with fake strings, but I've double checked that clicking the button in the UI to do the copy did not miss any characters.
That said, the one thing that might be a little weird about our setup is that we typically hit the API through an F5 that is secured with ssl (while the server behind the F5 where Enterprise Search is hosted, is NOT secured with ssl)... don't know if that would make any difference, but I thought I'd mention it.
If I make the call hitting the https endpoint instead, I get the same failure message, so it makes me think it's something with WPS that's wigging out.
Here is the cURL command I'm using (against version 7.11.1 of the API):
Ah! I think this is your issue. The delete-all-documents API was not present in 7.11.x. Be sure to always check the documentation version that matches the version of Enterprise Search that you are using. See: Custom sources indexing API reference | Workplace Search Guide [7.11] | Elastic does not include the delete-all-documents API. If you do not have a record of all your document IDs (to use the delete-by-id API), you may want to upgrade to at least version 7.13 in order to access the delete-all-documents API. See the 7.13.0 Release Notes.
You may also be interested to know that, coming soon in 7.15.0, we hope to release a Delete Documents by Query API, which will allow you to use a process like:
index all documents from your source
documents become stale
make note of the current time. Re-index all documents from your source (updating/overwriting documents that existed before by using consistent IDs)
use the delete-documents-by-query API to remove documents with an updated_at earlier than the time noted in the previous step.
This will ensure that you have next to no "down time" while you refresh your content source. While this feature isn't available quite yet, I figured I'd make you aware of it if you'll be considering an upgrade anyway.
Thanks, @Sean_Story ! It does. I'm ready to upgrade... this is functionality we need. May end up being a two-step process -- go to 7.14 now and .15 when it becomes available.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.