UNVERIFIED SOLUTION i
X

VaultID (DOCID) conversion not working (VaultClient API)

Issue

Symptom: While converting the old-style VaultID into the new-style VaultID, I’ve got the following exception:

 

new DocumentEx(“208524357|2010/04/13|4|afp|113597|20100416175336-20100413-94518-8-ffh-afp-fafe1002498011dfb72fa42084ce77b8|0002CF2800018523|2010/04/13|ffhprod”)

 

com.g1.e2.vault.VaultException: neight an old Document ID (10 elements) nor an newer DocumentEx ID (5 elements) for [208524357|2010/04/13|4|afp|113597|20100416175336-20100413-94518-8-ffh-afp-fafe1002498011dfb72fa42084ce77b8|0002CF2800018523|2010/04/13|ffhprod]

 

This old-style VaultID was created by a previous version of the VaultClient.

 

I’m using the VaultClient API 6.1.196. 

Cause

Cause:

 

Notice that noticed that the data seems to be missing a field.

 

The old style DOCID format is like below:

Account | Date | PageCount | Format | Type | Modes | File | Offset | Match | Database -->total 10 fields

 

from the example : [208524357|2010/04/13|4|afp|113597|20100416175336-20100413-94518-8-ffh-afp-fafe1002498011dfb72fa42084ce77b8|0002CF2800018523|2010/04/13|ffhprod]

it has only 9 fields.

 

01. Account = 208524357

02. Date = 2010/04/13

03. PageCount = 4

04. format = afp

05. Type = ?????

06. modes = 113597

07. File = 20100416175336-20100413-94518-8-ffh-afp-fafe1002498011dfb72fa42084ce77b8

08. Offset = 0002CF2800018523

09. Match = 2010/04/13

10. database = ffhprod

 

seems missing the filed of TYPE.

 

In the VaultClient APIs for 5.4/5.5/6.0 (Java API), the method of Document.getDocId() returns the document ID (A|D|PageCount|Fmt|Type|Modes|File|Offset|Match|DB). There are a total of 10 fields for this.

 

The Format is from the PROFILE settings (format=), it cannot be empty; but TYPE is from the JRN file. Sometimes the settings inside JRN for TYPE may be empty/null;

 

If the TYPE is empty, the data will become

"208524357|2010/04/13|4|afp||113597|20100416175336-20100413-94518-8-ffh-afp-fafe1002498011dfb72fa42084ce77b8|0002CF2800018523|2010/04/13|ffhprod".

 

Note that right after "|afp||", there are two "||".

 

Is it possible that after retrieving the Document object and getting theDOCID, you are re-processing the data and removing the extra "|"?

Resolution

UPDATED: September 7, 2017


1) make sure that the data is properly populated.

2) Or, in the case of this customer, they worked around the problem by splitting these old-style DocID's and passing them to the DocumentEx(,,,,,) value by value.

Downloads

  • No Downloads