Unable to restore hit from DocID

[jeffs42885]

Hey all,

I am working with a CMOD/P8 federated system, and there are a few documents that when I try to retrieve via ICN, the applet viewer opens and I am given the error message "Unable to restore hit from DocID".

I can open the hit up VIA thick client, and it successfully opens. I also see no errors corresponding in the system log.. There also appears to be no database errors or anything like that either.

Has anyone encountered this before?

[Alessandro Perucchi]

Well, I might have a idea why it might happen...

Just tell me if the scenario seems what you have:

• You have federated some documents from CMOD to P8
• You can see them without problems
• Now you have changed some document indexes in CMOD that are already federated in P8
• Now you cannot open the documents that you have changed the indexes in CMOD from P8, and you receive the message 'Unable to restore hit from DocID'

If yes, then that's because P8 stores the exact Doc ID from CMOD at the moment of the federation, and after that the index of the document must NEVER change, otherwise you cannot retrieve the document from P8 anymore.

If that the scenario that you have or is it something else?

Kind regards,
Alessandro

[jeffs42885]

You hit the nail on the head.

I did not know that making a change to the application level // indexes would impact federation. I believe that the client did make changes to the indexes after I originally set them up.

[jeffs42885]

Well, I might have a idea why it might happen...

Just tell me if the scenario seems what you have:

• You have federated some documents from CMOD to P8
• You can see them without problems
• Now you have changed some document indexes in CMOD that are already federated in P8
• Now you cannot open the documents that you have changed the indexes in CMOD from P8, and you receive the message 'Unable to restore hit from DocID'

If yes, then that's because P8 stores the exact Doc ID from CMOD at the moment of the federation, and after that the index of the document must NEVER change, otherwise you cannot retrieve the document from P8 anymore.

If that the scenario that you have or is it something else?

Kind regards,
Alessandro

By any chance, do you have documentation on this handy? I looked through the 9.0 doc and I can't find it.

[jeffs42885]

update: I copied the index information from another application, waited a few minutes..and attempted to get the document VIA P8. The hit came up while other hits came up showing the error message.

Any more suggestions ?

[jeffs42885]

Just an update that if you are using CFS-OD and make ANY changes to the application, the link between CMOD and P8 gets broken. The customer was making changes to the application level and in some cases recreating the application, Thus, recreating the ID. I did not know that federation services had any relationship at an app level.

[Alessandro Perucchi]

Sorry... I was busy... The problem is that there are not many documents available on that subject :-/

But I can confirm that any changes in CMOD are really not well digested by CFS-OD...

If they do what I think they do... then the link is something to do with the internal doc id from CMOD... and if that the case, then you'll have a lot of internal definition of objects in CMOD, like the internal ID for the AG and APP and also the table where the row is located in CMOD.
And this is not something that should be stored somewhere, because of the changes that can be done, you can break the link between this internal doc id, and the actual index.

This is only speculation... I have really no idea how CFS-OD works internally... but I really really hope they didn't use the internal CMOD doc_id... because if that's the case... then ... the link can be broken easily with any changes...

-
Alessandro

[jeffs42885]

It's actually kinda scary! Because in doing my own unit testing, changing a trigger, broke the link!