OnDemand User Group
Support Forums => OD/WEK & JAVA API => Topic started by: WietzeW on February 10, 2021, 05:00:12 AM
-
We are using CMOD 10.1. In our Java application we use ODWEK API's (10.1.0.6) to archive individual documents in CMOD (OnDemand server version is 10.1.0.5). In the applications we defined a field as Unique Document ID, which is auto-generated (server-side) when a document gets archived. We want to use that ID (as response) so our workflow can retrieve the archived document with the Unique ID. We can verify manually with the OnDemand client that the generation of this ID is successful. However, we would expect the ODHit that is returned by the call to ODFolder.storeDocument(…) to also contain this generated ID. Instead, what we see is that the value for this field is empty (the field exists though). Does someone know if there is a certain logic behind why the returned ODHit is incomplete? Maybe we overlooked some (ODWEK- or server-side) configuration in relation to such fields?
-
I see this in the ODWEK Java docs for 10.5.
NOTE: If the Application Group contains fields for which the value is not provided by this call -for example, 'Unique Id' or 'Hash SHA-256' fields - but rather generated on the server when the document is stored, the ODHit returned by this method will not contain the server generated values. In order to access those values, a new query should be performed.
I don't see that update in the 10.1 ODWEK Javadocs, but it applies to both versions.
-
Yup, this is consistent with my experience -- in order to get the benefits of the new features, you need to reload historical data to get CMOD Unique Document ID's, Document Hashes, and to enable OnDemand Encryption for data at rest.
-JD.
-
To clarify ...
WietzeW is referring to the actual ODHit returned by the storeDocument operation during execution. What is returned there does not contain the server-generated values (refer to the 10.5 Javadocs I mentioned earlier), however, those server generated values exist in the AG row (database) that is stored for that document. A new *query* is required to access those values programmatically after the document is stored.
JD, what you're referring to is legacy data that was added to an AG that didn't have a Unique Id/Doc Hash field when it was stored (although you are correct, legacy rows are not auto-populated with server generated values).
-
Awesome, thanks for the clarification! :)
-JD.
-
oke, so I'll have to use two steps to get the Unique ID
Thanks for your quick answers!
-
As i know the doc-id returned from the API is not unique. Maybe for the moment when you query the document. But if the storage location changes the docid will change.
-
OnDemand now has the ability to create and store a Unique ID with each hit. The is a 36-byte generated and stored at load time. That is what the original question was referring to.
-Thanks
-
Is this unique at all or only within an instance? And is i possible to generate it for old documents if you extend an existing applicationgroup with that field?
-
it's unique. The short answer to the last questions is you can't generate it for historical data without reloading that data.