Closed locnguyenx closed 8 years ago
Moqui automatically sends a mapping for each DataDocument type to ElasticSearch (see EntityDataDocument.makeElasticSearchMapping()) to specify which fields are numeric, etc.
I tested the current code in an application that uses it (a commercial one I'm working on), with data in place and all, and it is running fine. Did you make any changes to the Moqui or Mantle code? You can call the ElasticSearch REST interface to get the mapping for the doc in question to make sure it is as expected, and otherwise go through general debugging. If you'd like me to look into this further please submit (as a gist or simple code here) something I can run to reproduce the issue.
I'll leave this open for now, though I'm not seeing any issue calling this service.
I don't touch moqui nor mantle-usl except the MantleDocumentInventoryData.xml, uncomment DataFeed setting as below:
<!-- DataFeed -->
<!-- uncomment this to enable the feed and index data for these documents:-->
<moqui.entity.feed.DataFeed dataFeedId="MantleInventorySearch" dataFeedTypeEnumId="DTFDTP_RT_PUSH"
feedName="Mantle Inventory Search" feedReceiveServiceName="org.moqui.impl.EntityServices.index#DataDocuments">
<documents dataDocumentId="MantleInventoryAsset"/>
<documents dataDocumentId="MantleInventoryOrderItem"/>
<documents dataDocumentId="MantleInventoryRunConsume"/>
<documents dataDocumentId="MantleInventoryRunProduce"/>
<documents dataDocumentId="MantleInventoryProdEstimate"/>
</moqui.entity.feed.DataFeed>
I check this inventory document data using screen in Tool component and it's okay. For example, this an OderItem get from Tool's Document Search:
{
"_entity": "orderItems",
"orderId": "100100",
"orderItemSeqId": "02",
"orderPartSeqId": "02",
"productId": "DEMO_3_1",
"orderQuantity": "3E+1",
"placedDate": "2016-02-18T00:55:02.289Z",
"facilityId": "ORG_ZIZI_RETAIL_WH",
"partStatusId": "OrderPlaced",
"vendorPartyId": "ORG_ZIZI_CORP",
"vendorRoles": [
{
"vendorRoleTypeId": "OrgInternal"
}
],
"reservations": [
{
"assetId": "100051",
"quantityReserved": "3E+1",
"quantityNotAvailable": "3E+1",
"quantityNotIssued": "3E+1",
"reservedDate": "2016-02-18T00:55:02.581Z"
}
]
}
However, when using Aggregation (I clone the service get#InventoryProjectedInfo and modify the field path, as mentioned in the first post), the value I got from field "quantityReserved" is "3e"
For more information, I can't get output for Order Reservation fields with existing code of service get#InventoryProjectedInfo. https://github.com/moqui/mantle-usl/blob/master/service/mantle/product/InventoryReportServices.xml#L93 Then I copy it and change line #93-95 with my ones:
quantityReservedSum: [sum: [field:'reservations.quantityReserved']],
quantityNotAvailableSum: [sum: [field:'reservations.quantityNotAvailable']],
quantityNotIssuedSum: [sum: [field:'reservations.quantityNotIssued']]
I get Elastic exception with this modified code.
Thank you for the additional detail. Looks like I wasn't seeing the issue because the field names for these were wrong! After fixing those the error shows up and it is caused by incomplete mappings being sent to ElasticSearch. There was a bug in the EntityDataDocument.makeElasticSearchMapping() method that is fixed in moqui-framework commit #2749d21 (in a forked repo I'm working on, will be in the main repo soon). This was a funny bug... there is a Map key for ElasticSearch called 'properties' but if you use the dot syntax in Groovy it calls the getProperties() method which Groovy adds to all objects by default. Ugh.
BTW, you can see what ElasticSearch has for mappings with something like:
curl -XGET 'http://localhost:9200/default__mantle_inventory/_mapping?pretty=true'
The changes to get#InventoryProjectedInfo service are in commit #3545076 (currently in a forked repo, will be merged soon).
I've tried the service get#InventoryProjectedInfo and find that some sum aggregation fields have no data, i.e all reservations sub fields. Related data documents already exists (checked using System's DataDocument search) Trying use the full field path like it:
then I got the output for that fields but also an exception from ElasticSearch because of not numeric data type. I wonder if this service is not fully implemented yet, or there's something wrong with Elastic.