ODWek Java API - recreateHit issues <Resolved>

[ODCoder]

Thanks all for your replies.  I encoded and decided which worked fine, however I’m still getting a permisissions issue.

I will try an app to do the same thing to see if it’s just a web services issue.

[ODCoder]

I've done some work on this and written a simple java application running on the server to replicate the REST API code.  After running it against the same docid, using odHit.getOpenDocId(), the following error occurred:

Code: [Select]


Logging on to localhost...
com.ibm.edms.od.ODException: Unable to restore hit from DocID
        at com.ibm.edms.od.ODFolder.recreateHit(ODFolder.java:2180)
        at com.test.logon.main(logon.java:45)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
        at java.lang.reflect.Method.invoke(Unknown Source)
        at org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader.main(JarRsrcLoa
der.java:58)


Pretty much the same error as I'm getting in the web service.  So to summarize:

Using getOpenDocId -or- getDocId against the Hit object, to retrieve a document ID, then, use the same docid on recreateHit, appears to not work on its own, so I'm guessing I'm either doing something wrong, or I'm missing something?

Any idea's?

[rjrussel]

I would turn on ODWEK trace, rerun your test and then look for more detailed errors there. Report back..... Also, what is the exact version you are running, 10.1.0.?

[ODCoder]

Trace as follows:

Code: [Select]

7392:8532 03/13/2019 16:58:38:158162 FLOW ars3wapi.cpp(7210)Java_com_ibm_edms_od_ArsWWWInterface_apiRecreateHit:Enter session id=5681056
7392:8532 03/13/2019 16:58:38:158162 FLOW ars3wapi.cpp(3234)apiP_OpenFolder:Enter
7392:8532 03/13/2019 16:58:38:158162 FLOW ars3wapi.cpp(1895)apiP_GetStringUTFChars:Enter
7392:8532 03/13/2019 16:58:38:158162 FLOW ars3wapi.cpp(1923)apiP_GetStringUTFChars:Return rc=0
7392:8532 03/13/2019 16:58:38:158162 INFO ars3wapi.cpp(3276)apiP_OpenFolder:Current state Opening Folder=Statements
7392:8532 03/13/2019 16:58:38:158162 FLOW arscsvfl.c(511)CsvOpenFolder:Enter
7392:8532 03/13/2019 16:58:38:158162 FLOW arscsvlg.c(2986)CsvFolderQuery:Enter
7392:8532 03/13/2019 16:58:38:158162 FLOW arscsvlg.c(3016)CsvFolderQuery:Return csv_rc=0,CSV_RC_OKAY csv_msgid=0,CSV_MSG_NO_MESSAGE
7392:8532 03/13/2019 16:58:38:158162 FLOW arscsvfl.c(581)CsvOpenFolder:Return csv_rc=0,CSV_RC_OKAY csv_msgid=0,CSV_MSG_NO_MESSAGE
7392:8532 03/13/2019 16:58:38:158162 FLOW ars3wapi.cpp(3303)apiP_OpenFolder:Return csv_rc=0,CSV_RC_OKAY csv_msgid=0,CSV_MSG_NO_MESSAGE
7392:8532 03/13/2019 16:58:38:158162 FLOW ars3wapi.cpp(1895)apiP_GetStringUTFChars:Enter
7392:8532 03/13/2019 16:58:38:158162 FLOW ars3wapi.cpp(1923)apiP_GetStringUTFChars:Return rc=0
7392:8532 03/13/2019 16:58:38:158162 FLOW ars3wapi.cpp(1941)apiP_RestoreHitFromDocId:Enter
7392:8532 03/13/2019 16:58:38:158162 INFO ars3wapi.cpp(1970)apiP_RestoreHitFromDocId:Current state byte_buffer=O1qom06pSqO5gv1w%2F9T8gU9ffb2EDfSa9cuN8jAO4kHbfueaJ8vOUPzO9C0gQoeuhBNm0bF1ol4kSBqlXJUwsrcoZ0R4S8Ng0fwhAQlgrq6TqOqQKROFxk57gJVLUjvuFWqJlldEIKLDrv9vK1D1OjCP7WtIdsTummIaBw4ZDx%2BPba25Z7b%2FyWWkN9hJ3Q8r4CJlqs8kwIR432IVwxGeLinObmDjbX%2FoIcs2kj%2BOuIEGgXh0AYztI9ayHMjhu2IqXu
7392:8532 03/13/2019 16:58:38:158162 FLOW arscsvht.c(2766)CsvRestoreHitFromDocId:Enter
7392:8532 03/13/2019 16:58:38:158162 FLOW arscsvht.c(1956)CsvMaxDocIdLength:Enter
7392:8532 03/13/2019 16:58:38:158162 FLOW arscsvht.c(1985)CsvMaxDocIdLength:Return len=6046
7392:8532 03/13/2019 16:58:38:158162 FLOW arscsvht.c(2164)CsvP_ICCDecrypt:Enter
7392:8532 03/13/2019 16:58:38:158162 FLOW arscsvht.c(2207)CsvP_ICCDecrypt:Return arccs return code=6,ARCCS_FAILED
7392:8532 03/13/2019 16:58:38:158162 FLOW arscsvht.c(2982)CsvRestoreHitFromDocId:Return pCsvHit=0000000000000000
7392:8532 03/13/2019 16:58:38:158162 FLOW ars3wapi.cpp(1997)apiP_RestoreHitFromDocId:Return
7392:8532 03/13/2019 16:58:38:158162 FLOW ars3wapi.cpp(713)apiP_setReturnCodeAndMessage:Enter
7392:8532 03/13/2019 16:58:38:158162 ERROR ars3wapi.cpp(7423)Java_com_ibm_edms_od_ArsWWWInterface_apiRecreateHit:Current state rtn.RC=9 extId=0 pMsg=Unable to restore hit from DocID
7392:8532 03/13/2019 16:58:38:158162 FLOW ars3wapi.cpp(789)apiP_setReturnCodeAndMessage:Return
7392:8532 03/13/2019 16:58:38:158162 FLOW ars3wapi.cpp(7436)Java_com_ibm_edms_od_ArsWWWInterface_apiRecreateHit:Return session id=5681056 (rc)=1

Possibly a decrypt issue?

[rjrussel]

Yes, that docID looks urlencoded.

[ODCoder]

Yes your right, the rest api was returning url encoded, if I look at the raw json and put that in, it seems to work fine.  So I seemed to have proven the code works, just not in a rest api.

[ODCoder]

I've spent some more time on this.

Since its the same user that's searching and retrieving the document, both types of getDocID work from the java app, neither work from the rest app.

I have also tried URLEncoding and decoding, but that made no difference either.

I can't seem to find a way to turn tracing on with a rest api.  Even turning up tracing on WAS didn't seem to help.  So I have no other clear indication of what is going on, other than:

Code: [Select]

"errorMsg": "Unable to restore hit from DocID",
    "errorId": 9,
    "message": "Unable to restore hit from DocID",
    "localizedMessage": "Unable to restore hit from DocID",

Any idea's would be great.

Thank you!

DB

[rjrussel]

1. If its the same user (connection pool) make sure you use getDocID.
2. The docID should be returned in the response URLEncoded
URLEncoder.encode(odHit.getDocId(), java.nio.charset.StandardCharsets.UTF_8.toString()

3. Whether you need to decode the docID before you call recreateHit depends on how you send the data back to your rest api.

It shouldn't be to hard to do some logging and see how it gets passed in so you can determine whether you need to decode or not.

[ODCoder]

I did all of that, used both GetDoc commands to be sure, encode and decode.

One thing I have noticed is that it appears to add a + where there is a space, before and after encoding.  But even if I strip that out it doesn’t seem to make any difference.

Will keep playing, this shouldn’t be that hard!

[ODCoder]

Hi all,

Thanks for everyone's help, especially RR!

I eventually got there through trial and error.  I'm still unsure exactly why, but URL encoding the original DOCID in the GET that searches the folder, then on the GET that retrieves the document, do not URL decode, and replace any <space> with a + sign, seemed to work.  Again, I'm just not familiar enough with HTTP encoding to understand a straight forward decode didn't work.  Also the removal of the + and the insert of the space is odd.


So a combination of the string manipulation and the getOpenDocId(), appears to be the final solution.

Regards


DB