In Dataminer FR 10.3.7 we're using actions in DOM to execute a script that runs Process Automation on the given DOM instance. When the DOM instance is "active," we have all fields (besides some hidden ones) as read-only. We then use a DOM button/action combo to pass a token through PA. This works on most DOM definitions besides one, resulting in the following error:
The DOM actions are not executing the script before this error occurs. The action itself doesn't set any fields (as far as I can tell) in the DOM Editor:
We have other DOM definitions set up this same way using a script, and they have no issue. If we mark all fields as "ReadOnly = false" while active, the actions work. If we then go back and mark them as ReadOnly again, it will still work. Only after some time passes do the buttons return the issue.
If we call the action from a script/C# code, it will always work. Only from a low-code app does it seem to fail.
Any ideas what could be missing here? Thanks in advance.
*Updated info for answers:
Hi Blake,
Update:
I chatted with Blake offline & found the issue after checking out the SLClientTestTool follow of the connection. It seems that the web form component is adjusting two read-only DateTime values so they are stored as UTC DateTime objects instead of the ones where the 'Kind' is set to 'Unspecified'. This is why we saw the time shift by a few hours & the 'Kind' change to 'UTC'. The DOM manager detects this as a change of a read-only field and generates the error that is seen here. I was not aware that the form component behaves that way, we'll do some further investigation to see how long that has been the case.
Solution: In general, it is always recommended to save any DateTime with the kind set to UTC (e.g. DateTime.UtcNow instead of .Now). That way, applications can reliably convert it to the timezone of choice. The initial DateTime values in Blake's case were set by a driver, adjusting it to use UTC should resolve this.
Original response:
If I recall correctly, when clicking DOM buttons in a form, the DomInstance will be saved. I would expect that the form wouldn't do that in this case, since nothing is edited. Maybe there is a small bug in the form component somewhere that incorrectly changes something small & sends a save when clicking.
You could try to investigate this by either checking the requests sent by the web app in your browser (F12 Developer Menu -> Network Tab). Or you can follow the SLNet connection with the SLClientTestTool (HTML5 App <UserName>). This way, you may see a save being executed where you can compare the values. The SLNet message response should actually contain an error (ReadOnlyFieldsChangedForCurrentStatus) with the ID(s) of the field(s) that was/were changed. (See https://docs.dataminer.services/user-guide/Advanced_Modules/DOM/DOM_objects/DomInstance.html#errors)
I have updated my original response with the conclusions of our investigation.
Thanks for the help again Thomas!
It was a bit easier to follow the browser. When I used the ClientTestTool, there was too much information for me to go through. I’ve attached pictures to the original question that include the information from the browser dev tools.
Whats interesting is I don’t believe it sent anything for the hidden fields. We have some fields (like InstanceId) which are hidden at all states and only configured from a script. Perhaps when it doesn’t receive a value for those it fails? The only thing I still don’t understand is why this only happens on this DOM Definition.
If you’d like, I could send you the output of the ClientTestTool to review.