Hi All,
I have configured a field descriptor as a String type (Img 1).
However, when I try to write a string value to it (using low-code app), I get the below error (Img 2).
When I write an Int or long value, it is written to the DOM instance correctly.
Img 1
Img 2
Logging from DOM Manager:
2023/03/14 07:51:15.510|SLNet.exe|DomInstanceStorage|ERR|0|314|Skyline.DataMiner.Net.Apps.Utils.FailedSyncWriteException: Failed to write some objects. Should be written: 1. Exception SLDataGateway.API.Types.Exceptions.RepositoryException: System.Exception: Invalid NEST response built from a successful low level call on POST: /dms-active-cdominstance_feedbookings/_bulk
at SLDataGateway.Types.FileOffload.SwitchoverRouter`1.TryAction(Action`1 action, String actionName)
at SLDataGateway.Types.Storage.Queue.Writers.SimpleWriter`1.DoWork()
at SLDataGateway.API.Repositories.DataSetRepository`1.Upsert(IEnumerable`1 items, IUpsertTrackerConfiguration trackerConfiguration)
at Skyline.DataMiner.Net.Apps.Utils.CustomDataRepositoryStorage`2.InnerWrite(List`1 objects) ---> SLDataGateway.API.Types.Exceptions.RepositoryException: System.Exception: Invalid NEST response built from a successful low level call on POST: /dms-active-cdominstance_feedbookings/_bulk
at SLDataGateway.Types.FileOffload.SwitchoverRouter`1.TryAction(Action`1 action, String actionName)
at SLDataGateway.Types.Storage.Queue.Writers.SimpleWriter`1.DoWork()
at SLDataGateway.API.Repositories.DataSetRepository`1.Upsert(IEnumerable`1 items, IUpsertTrackerConfiguration trackerConfiguration)
at Skyline.DataMiner.Net.Apps.Utils.CustomDataRepositoryStorage`2.InnerWrite(List`1 objects)
--- End of inner exception stack trace ---
Please advise what could be causing this behaviour and if there is an alternative to re-creating a new field descriptor.
Thank you in advance.
Hi Rajesh,
Can you try removing this FieldDescriptor and adding it again? (Same name & type) It will have a different ID (which will hopefully not lead to too much extra work for you).
The DomInstance data is stored in Elasticsearch. Each value is indexed in there with the FieldDescriptor as a key. It could happen that Elasticsearch has the incorrect type defined for this key.
You can check it by sending a GET request to one of the Elasticsearch nodes. It should look something like this: "http://localhost:9200/dms-cdominstance_feedbookings/_mapping". (You can just copy and paste this in the URL bar of a browser as well.)
This should output a JSON which contains the field mapping for this alias. You can do a search on the FieldDesciptorID and you should see something like this.
If you see any other type (date, boolean, long) then it would seem that a FieldDescriptor has already been defined once in this manager that had this different type. It is not trivial to alter this manually, so using a different FieldDescriptor with a different ID is recommended.
Thanks for confirming. In the documentation you can find a list of the properties that can be updated on the FieldDescriptors: https://docs.dataminer.services/user-guide/Advanced_Modules/DOM/DOM_objects/DOM_SectionDefinition.html#requirements. When updating any other property (like the type), an error wil be returned. This mechanism will unfortunatly not stop you from deleting a FieldDescriptor and adding it again in another request with another type. This would then result in the issue you were having. There is no checking mechanism available in the pipelines because there is no standardized way to define your DOM configuration that would allow this yet. It would however indeed be nice if this was the case in the future. To conclude, changing the type of an existing FieldDescriptor is not allowed. You will have to create a new one with another ID.
Thank you Tomas. The information adds more clarity to the situation.
Thank you for sharing more information to identify the cause Thomas.
The field descriptor is indeed defined as a long in Elastic. This was probably due to the field descriptor being created as type long initially.
“69539dbf-f193-40e0-b33d-47d10b30ca28”: {
“properties”: {
“$type”: {
“type”: “keyword”
},
“$value”: {
“type”: “long”
}
}
},
If that is the expected behaviour, would that mean for any type of change to a DOM field descriptor, the ideal way to change is to re-create the descriptor?
Additionally, is there anything in the pipeline to remedy this current situation? – this is because these changes cause overhead when a subsequent component is utilizing DOM, in my case, a low-code app.
Should there be a couple of changes, it can add some significant efforts in changing minor portions of the DOM definitions.