Extending a dataDocuments definition

Technical Questions
1

I would like to include some additional fields from WorkEffort in the MantleTask data document definition. Is it possible to extend? For example, something like this:

    <dataDocuments dataDocumentId="MantleTask" indexName="mantle" documentName="Task"
            primaryEntityName="mantle.work.effort.WorkEffort" documentTitle="${name}">
        <fields fieldSeqId="100" fieldPath="estimatedCompletionDate"/>
    </dataDocuments>
1 Like
2

In the spirit of attempting to answer my own question, I loaded the xml snippet above using Tools → Data Import. Then I deleted the mantle_task index through the command line with this command:

curl -XDELETE "http://localhost:9200/mantle_task"

For reference, you can list all the indexes using this command:

curl -XGET "http://localhost:9200/_cat/indices?v"

After deleting the index I created a new task, the index was recreated, and the new field is there. I assume you could also recreate the index using System → Feed Index

3

I’m not entirely sure what your question is here. It seems like you already figured out how to add fields to a data document, and add them to an open/elastic search index.

For future reference:

A Data Document is assembled from database records into a JSON document or a Java nested Map/List representation of the document.

https://moqui.org/m/docs/framework/Data+and+Resources/Data+Document

Data Documents are loaded through database records (like this), so adding another Data Document Field should be as easy as adding the data in a data load file and loading it.

Then you can load the index with this:

Also for dealing with Elastic/Open Search, I suggest using https://elasticvue.com/ because it’s a nice gui interface.

1 Like
4

Hi Michael, just a quick question regarding you reference to Elasticvue. Have you (or anybody else) been using OpenSearch Dashboards? From a quick search I find it should be not only a replacement for Kibana, but also offer some management tasks, which seems to be like Elasticvue. Does it make sense to choose one over the other, or perhaps use both for different tasks?

5

I haven’t been using it. I’ve set it up a couple times. I’m going to set it up soon though.

I’ve only ever used Elasticvue as a browser extension for local development, and would not suggest it for anything else (although perhaps you could). OpenSearch Dashboards is what I’m planning on setting up soon for metrics and indicators for my application.

If you give me a bit more information about what your requirements are, I can help you come up with a better solution.

6

I am looking for some way to oversee the opensearch cluster connected to moqui, mostly for housekeeping, status check, etc. For instance, if some filesystem goes above the high-water-mark the index gets marked as read-only and you would need to re-enable read-write status to it manually after solving the free space problem (without need to restarting opensearch), maybe to check out some performance issues and evaluate the need to assign more resources (another opensearch instance, more memory or CPU, etc).

7

For that, I would probably build a Moqui admin screen that gets some of that information, and allows for any custom logic and data display that you need. It’s very easy to setup once you know Moqui. For the high-water mark, and status, I would use: CAT nodes operation - OpenSearch documentation. Then send an email or whatever through Moqui for various alerts, and if needed hook into a cloud API for assigning more resources. The reason why I think that that is a good way to go is because it looks like you’re already going to have a Moqui server, it seems like you’re going to need to run custom logic, and I’m not sure how well either of those applications would handle custom logic without some know how.