PM
Peter Murray
Mon, Oct 12, 2015 8:19 PM
I think I've gotten all of the CSpace configuration and UI changes behind me. Just a few things left to clean up. I'm concentrating on data loading now. I figured it would be best to get started with the example in Imports Service Home at the "Example Request" heading. I saved the XML for the persons authority records to a file and ran the curl command
:
$ curl -X POST https://cspace.vagrant/cspace-services/imports
-i -u admin@museumofman.org:Administrator
-H "Content-Type: application/xml"
-T authority-request.xtml
Initially the error response I got back said "Could not process import payload. Check XML markup for not-well-formed errors, elements not matching import schema, etc." and this was logged on the cspace-services.log file:
ERROR [...] [org.collectionspace.services.imports.TemplateExpander:492] ERROR calling expandXmlPayloadToDirjava.lang.IllegalArgumentException: Malformed refName for Authority (too few tokens)
So I removed the "<personauthorities_common:refName>" element in the XML file and tried again. The response I got back (with prettified XML) was:
HTTP/1.1 100 Continue
HTTP/1.1 200 OK
Date: Mon, 12 Oct 2015 20:05:02 GMT
Server: Apache-Coyote/1.1
Strict-Transport-Security: max-age=15768000
Content-Type: application/xml
Content-Length: 998
Set-Cookie: JSESSIONID=9EB6F3E6A8679B82E55B8E742CA331E9; Path=/cspace-services/; HttpOnly
Vary: Accept-Encoding
<?xml version="1.0" encoding="UTF-8"?>
<import>
<msg>SUCCESS</msg>
<importedRecords>
<importedRecord>
<doctype>Personauthority</doctype>
<csid>c955a218-6fea-44bd-9dfe-1e7804be7ac5</csid>
</importedRecord>
<importedRecord>
<doctype>Personauthority</doctype>
<csid>11111111-2222-3333-4444-123456789012</csid>
</importedRecord>
</importedRecords>
<status>Success</status>
<totalRecordsImported>2</totalRecordsImported>
<numRecordsImportedByDocType>
<numRecordsImported>
<docType>Personauthority</docType>
<numRecords>2</numRecords>
</numRecordsImported>
</numRecordsImportedByDocType>
<report>READ: /home/vagrant/cspace-tomcat/apache-tomcat-7.0.57/temp/imports-2086091545258611644/Personauthorities/11111111-2222-3333-4444-123456789012/document.xml/Personauthorities/11111111-2222-3333-4444-123456789012READ: /home/vagrant/cspace-tomcat/apache-tomcat-7.0.57/temp/imports-2086091545258611644/Personauthorities/c955a218-6fea-44bd-9dfe-1e7804be7ac5/document.xml/Personauthorities/c955a218-6fea-44bd-9dfe-1e7804be7ac5</report>
</import>
...which looks like a successful import, BUT this is in cspace-services.log:
WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no ID for document, won't add org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@74ae85f4
WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no ID for document, won't add org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@3f4d7382
...AND the document doesn't seem to be in the database. Based on the csid
I would expect these URLs to work:
https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=c955a218-6fea-44bd-9dfe-1e7804be7ac5&vocab=person
https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=11111111-2222-3333-4444-123456789012&vocab=person
...because the documents can't be found (also from cspace-services.log):
ERROR [...] [org.collectionspace.services.nuxeo.client.java.RepositoryJavaClientImpl:1303] Could not find document with CSID=c955a218-6fea-44bd-9dfe-1e7804be7ac5. Caught exception:Failed to get document /sdmom-domain/Workspaces/Persons/c955a218-6fea-44bd-9dfe-1e7804be7ac5
ERROR [...] [org.collectionspace.services.nuxeo.client.java.RepositoryJavaClientImpl:1303] Could not find document with CSID=11111111-2222-3333-4444-123456789012. Caught exception:Failed to get document /sdmom-domain/Workspaces/Persons/11111111-2222-3333-4444-123456789012
... and the records don't show up in a search. I feel like I'm missing something here, but I can't quite put my finger on it. Suggestions?
Peter
Peter Murray
Dev/Ops Lead and Project Manager
Cherry Hill Company
I think I've gotten all of the CSpace configuration and UI changes behind me. Just a few things left to clean up. I'm concentrating on data loading now. I figured it would be best to get started with the example in [Imports Service Home](https://wiki.collectionspace.org/display/collectionspace/Imports+Service+Home) at the "Example Request" heading. I saved the XML for the persons authority records to a file and ran the `curl command`:
$ curl -X POST https://cspace.vagrant/cspace-services/imports \
-i -u admin@museumofman.org:Administrator \
-H "Content-Type: application/xml" \
-T authority-request.xtml
Initially the error response I got back said "Could not process import payload. Check XML markup for not-well-formed errors, elements not matching import schema, etc." and this was logged on the cspace-services.log file:
ERROR [...] [org.collectionspace.services.imports.TemplateExpander:492] ERROR calling expandXmlPayloadToDirjava.lang.IllegalArgumentException: Malformed refName for Authority (too few tokens)
So I removed the "<personauthorities_common:refName>" element in the XML file and tried again. The response I got back (with prettified XML) was:
HTTP/1.1 100 Continue
HTTP/1.1 200 OK
Date: Mon, 12 Oct 2015 20:05:02 GMT
Server: Apache-Coyote/1.1
Strict-Transport-Security: max-age=15768000
Content-Type: application/xml
Content-Length: 998
Set-Cookie: JSESSIONID=9EB6F3E6A8679B82E55B8E742CA331E9; Path=/cspace-services/; HttpOnly
Vary: Accept-Encoding
<?xml version="1.0" encoding="UTF-8"?>
<import>
<msg>SUCCESS</msg>
<importedRecords>
<importedRecord>
<doctype>Personauthority</doctype>
<csid>c955a218-6fea-44bd-9dfe-1e7804be7ac5</csid>
</importedRecord>
<importedRecord>
<doctype>Personauthority</doctype>
<csid>11111111-2222-3333-4444-123456789012</csid>
</importedRecord>
</importedRecords>
<status>Success</status>
<totalRecordsImported>2</totalRecordsImported>
<numRecordsImportedByDocType>
<numRecordsImported>
<docType>Personauthority</docType>
<numRecords>2</numRecords>
</numRecordsImported>
</numRecordsImportedByDocType>
<report>READ: /home/vagrant/cspace-tomcat/apache-tomcat-7.0.57/temp/imports-2086091545258611644/Personauthorities/11111111-2222-3333-4444-123456789012/document.xml/Personauthorities/11111111-2222-3333-4444-123456789012READ: /home/vagrant/cspace-tomcat/apache-tomcat-7.0.57/temp/imports-2086091545258611644/Personauthorities/c955a218-6fea-44bd-9dfe-1e7804be7ac5/document.xml/Personauthorities/c955a218-6fea-44bd-9dfe-1e7804be7ac5</report>
</import>
...which looks like a successful import, BUT this is in cspace-services.log:
WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no ID for document, won't add org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@74ae85f4
WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no ID for document, won't add org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@3f4d7382
...AND the document doesn't seem to be in the database. Based on the `csid` I would expect these URLs to work:
https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=c955a218-6fea-44bd-9dfe-1e7804be7ac5&vocab=person
https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=11111111-2222-3333-4444-123456789012&vocab=person
...because the documents can't be found (also from cspace-services.log):
ERROR [...] [org.collectionspace.services.nuxeo.client.java.RepositoryJavaClientImpl:1303] Could not find document with CSID=c955a218-6fea-44bd-9dfe-1e7804be7ac5. Caught exception:Failed to get document /sdmom-domain/Workspaces/Persons/c955a218-6fea-44bd-9dfe-1e7804be7ac5
ERROR [...] [org.collectionspace.services.nuxeo.client.java.RepositoryJavaClientImpl:1303] Could not find document with CSID=11111111-2222-3333-4444-123456789012. Caught exception:Failed to get document /sdmom-domain/Workspaces/Persons/11111111-2222-3333-4444-123456789012
... and the records don't show up in a search. I feel like I'm missing something here, but I can't quite put my finger on it. Suggestions?
Peter
--
Peter Murray
Dev/Ops Lead and Project Manager
Cherry Hill Company
AR
Aron Roberts
Mon, Oct 12, 2015 9:52 PM
At a brief and superficial glance, it seems possible the refName values,
in that example on the Imports Service Home page might be obsolete.
The RefName page (https://wiki.collectionspace.org/display/DOC/RefName)
gives this example, for importing a person authority record:
urn:cspace:core.collectionspace.org:personauthorities:name(localPersonVocabulary)'Local
Person Vocabulary'
Note that unlike the example on the Imports Service Home page, that
example includes a 'name' component. (As well, the URL in this example also
reflects the tenant domain name, which is current practice, IIRC.) Contrast
the (presumably correct) example above with this one, from the imports page:
urn:cspace:collectionspace.org:Personauthorities(perfTestPersons)'Perf
Test Person Auth'
Perhaps try putting back the "<personauthorities_common:refName>" element
and using the RefName page's example (the first one above) - tweaked as
needed to reflect the Museum of Man's values - and see if the import works?
This might or might not be relevant, but it's what first comes to mind.
On Mon, Oct 12, 2015 at 1:19 PM, Peter Murray pmurray@chillco.com wrote:
I think I've gotten all of the CSpace configuration and UI changes behind
me. Just a few things left to clean up. I'm concentrating on data loading
now. I figured it would be best to get started with the example in
Imports Service Home
at the "Example Request" heading. I saved the XML for the persons
authority records to a file and ran the curl command
:
$ curl -X POST https://cspace.vagrant/cspace-services/imports
-i -u admin@museumofman.org:Administrator
-H "Content-Type: application/xml"
-T authority-request.xtml
Initially the error response I got back said "Could not process import
payload. Check XML markup for not-well-formed errors, elements not matching
import schema, etc." and this was logged on the cspace-services.log file:
ERROR [...] [org.collectionspace.services.imports.TemplateExpander:492]
ERROR calling expandXmlPayloadToDirjava.lang.IllegalArgumentException:
Malformed refName for Authority (too few tokens)
So I removed the "<personauthorities_common:refName>" element in the XML
file and tried again. The response I got back (with prettified XML) was:
HTTP/1.1 100 Continue
HTTP/1.1 200 OK
Date: Mon, 12 Oct 2015 20:05:02 GMT
Server: Apache-Coyote/1.1
Strict-Transport-Security: max-age=15768000
Content-Type: application/xml
Content-Length: 998
Set-Cookie: JSESSIONID=9EB6F3E6A8679B82E55B8E742CA331E9;
Path=/cspace-services/; HttpOnly
Vary: Accept-Encoding
<?xml version="1.0" encoding="UTF-8"?>
<import>
<msg>SUCCESS</msg>
<importedRecords>
<importedRecord>
<doctype>Personauthority</doctype>
<csid>c955a218-6fea-44bd-9dfe-1e7804be7ac5</csid>
</importedRecord>
<importedRecord>
<doctype>Personauthority</doctype>
<csid>11111111-2222-3333-4444-123456789012</csid>
</importedRecord>
</importedRecords>
<status>Success</status>
<totalRecordsImported>2</totalRecordsImported>
<numRecordsImportedByDocType>
<numRecordsImported>
<docType>Personauthority</docType>
<numRecords>2</numRecords>
</numRecordsImported>
</numRecordsImportedByDocType>
<report>READ:
/home/vagrant/cspace-tomcat/apache-tomcat-7.0.57/temp/imports-2086091545258611644/Personauthorities/11111111-2222-3333-4444-123456789012/document.xml/Personauthorities/11111111-2222-3333-4444-123456789012READ:
/home/vagrant/cspace-tomcat/apache-tomcat-7.0.57/temp/imports-2086091545258611644/Personauthorities/c955a218-6fea-44bd-9dfe-1e7804be7ac5/document.xml/Personauthorities/c955a218-6fea-44bd-9dfe-1e7804be7ac5</report>
</import>
...which looks like a successful import, BUT this is in
cspace-services.log:
WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no ID
for document, won't add
org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@74ae85f4
WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no ID
for document, won't add
org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@3f4d7382
...AND the document doesn't seem to be in the database. Based on the
csid
I would expect these URLs to work:
https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=c955a218-6fea-44bd-9dfe-1e7804be7ac5&vocab=person
https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=11111111-2222-3333-4444-123456789012&vocab=person
...because the documents can't be found (also from cspace-services.log):
ERROR [...]
[org.collectionspace.services.nuxeo.client.java.RepositoryJavaClientImpl:1303]
Could not find document with CSID=c955a218-6fea-44bd-9dfe-1e7804be7ac5.
Caught exception:Failed to get document
/sdmom-domain/Workspaces/Persons/c955a218-6fea-44bd-9dfe-1e7804be7ac5
ERROR [...]
[org.collectionspace.services.nuxeo.client.java.RepositoryJavaClientImpl:1303]
Could not find document with CSID=11111111-2222-3333-4444-123456789012.
Caught exception:Failed to get document
/sdmom-domain/Workspaces/Persons/11111111-2222-3333-4444-123456789012
... and the records don't show up in a search. I feel like I'm missing
something here, but I can't quite put my finger on it. Suggestions?
Peter
Peter Murray
Dev/Ops Lead and Project Manager
Cherry Hill Company
Talk mailing list
Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
At a brief and superficial glance, it seems possible the refName values,
in that example on the Imports Service Home page might be obsolete.
The RefName page (https://wiki.collectionspace.org/display/DOC/RefName)
gives this example, for importing a person authority record:
urn:cspace:core.collectionspace.org:personauthorities:name(localPersonVocabulary)'Local
Person Vocabulary'
Note that unlike the example on the Imports Service Home page, that
example includes a 'name' component. (As well, the URL in this example also
reflects the tenant domain name, which is current practice, IIRC.) Contrast
the (presumably correct) example above with this one, from the imports page:
urn:cspace:collectionspace.org:Personauthorities(perfTestPersons)'Perf
Test Person Auth'
Perhaps try putting back the "<personauthorities_common:refName>" element
and using the RefName page's example (the first one above) - tweaked as
needed to reflect the Museum of Man's values - and see if the import works?
This might or might not be relevant, but it's what first comes to mind.
On Mon, Oct 12, 2015 at 1:19 PM, Peter Murray <pmurray@chillco.com> wrote:
> I think I've gotten all of the CSpace configuration and UI changes behind
> me. Just a few things left to clean up. I'm concentrating on data loading
> now. I figured it would be best to get started with the example in
> [Imports Service Home](
> https://wiki.collectionspace.org/display/collectionspace/Imports+Service+Home)
> at the "Example Request" heading. I saved the XML for the persons
> authority records to a file and ran the `curl command`:
>
> $ curl -X POST https://cspace.vagrant/cspace-services/imports \
> -i -u admin@museumofman.org:Administrator \
> -H "Content-Type: application/xml" \
> -T authority-request.xtml
>
> Initially the error response I got back said "Could not process import
> payload. Check XML markup for not-well-formed errors, elements not matching
> import schema, etc." and this was logged on the cspace-services.log file:
>
> ERROR [...] [org.collectionspace.services.imports.TemplateExpander:492]
> ERROR calling expandXmlPayloadToDirjava.lang.IllegalArgumentException:
> Malformed refName for Authority (too few tokens)
>
> So I removed the "<personauthorities_common:refName>" element in the XML
> file and tried again. The response I got back (with prettified XML) was:
>
> HTTP/1.1 100 Continue
>
> HTTP/1.1 200 OK
> Date: Mon, 12 Oct 2015 20:05:02 GMT
> Server: Apache-Coyote/1.1
> Strict-Transport-Security: max-age=15768000
> Content-Type: application/xml
> Content-Length: 998
> Set-Cookie: JSESSIONID=9EB6F3E6A8679B82E55B8E742CA331E9;
> Path=/cspace-services/; HttpOnly
> Vary: Accept-Encoding
>
> <?xml version="1.0" encoding="UTF-8"?>
> <import>
> <msg>SUCCESS</msg>
> <importedRecords>
> <importedRecord>
> <doctype>Personauthority</doctype>
> <csid>c955a218-6fea-44bd-9dfe-1e7804be7ac5</csid>
> </importedRecord>
> <importedRecord>
> <doctype>Personauthority</doctype>
> <csid>11111111-2222-3333-4444-123456789012</csid>
> </importedRecord>
> </importedRecords>
> <status>Success</status>
> <totalRecordsImported>2</totalRecordsImported>
> <numRecordsImportedByDocType>
> <numRecordsImported>
> <docType>Personauthority</docType>
> <numRecords>2</numRecords>
> </numRecordsImported>
> </numRecordsImportedByDocType>
> <report>READ:
> /home/vagrant/cspace-tomcat/apache-tomcat-7.0.57/temp/imports-2086091545258611644/Personauthorities/11111111-2222-3333-4444-123456789012/document.xml/Personauthorities/11111111-2222-3333-4444-123456789012READ:
> /home/vagrant/cspace-tomcat/apache-tomcat-7.0.57/temp/imports-2086091545258611644/Personauthorities/c955a218-6fea-44bd-9dfe-1e7804be7ac5/document.xml/Personauthorities/c955a218-6fea-44bd-9dfe-1e7804be7ac5</report>
> </import>
>
>
> ...which looks like a successful import, BUT this is in
> cspace-services.log:
>
> WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no ID
> for document, won't add
> org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@74ae85f4
> WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no ID
> for document, won't add
> org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@3f4d7382
>
>
> ...AND the document doesn't seem to be in the database. Based on the
> `csid` I would expect these URLs to work:
>
>
> https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=c955a218-6fea-44bd-9dfe-1e7804be7ac5&vocab=person
>
> https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=11111111-2222-3333-4444-123456789012&vocab=person
>
> ...because the documents can't be found (also from cspace-services.log):
>
> ERROR [...]
> [org.collectionspace.services.nuxeo.client.java.RepositoryJavaClientImpl:1303]
> Could not find document with CSID=c955a218-6fea-44bd-9dfe-1e7804be7ac5.
> Caught exception:Failed to get document
> /sdmom-domain/Workspaces/Persons/c955a218-6fea-44bd-9dfe-1e7804be7ac5
> ERROR [...]
> [org.collectionspace.services.nuxeo.client.java.RepositoryJavaClientImpl:1303]
> Could not find document with CSID=11111111-2222-3333-4444-123456789012.
> Caught exception:Failed to get document
> /sdmom-domain/Workspaces/Persons/11111111-2222-3333-4444-123456789012
>
>
> ... and the records don't show up in a search. I feel like I'm missing
> something here, but I can't quite put my finger on it. Suggestions?
>
>
> Peter
> --
> Peter Murray
> Dev/Ops Lead and Project Manager
> Cherry Hill Company
>
>
> _______________________________________________
> Talk mailing list
> Talk@lists.collectionspace.org
>
> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
>
PM
Peter Murray
Tue, Oct 13, 2015 3:14 PM
On Oct 12, 2015, at 5:52 PM, Aron Roberts aron@socrates.berkeley.edu wrote:
At a brief and superficial glance, it seems possible the refName values, in that example on the Imports Service Home page might be obsolete.
The RefName page (https://wiki.collectionspace.org/display/DOC/RefName https://wiki.collectionspace.org/display/DOC/RefName) gives this example, for importing a person authority record:
urn:cspace:core.collectionspace.org:personauthorities:name(localPersonVocabulary)'Local Person Vocabulary'
Note that unlike the example on the Imports Service Home page, that example includes a 'name' component. (As well, the URL in this example also reflects the tenant domain name, which is current practice, IIRC.) Contrast the (presumably correct) example above with this one, from the imports page:
urn:cspace:collectionspace.org:Personauthorities(perfTestPersons)'Perf Test Person Auth'
Perhaps try putting back the "<personauthorities_common:refName>" element and using the RefName page's example (the first one above) - tweaked as needed to reflect the Museum of Man's values - and see if the import works?
This might or might not be relevant, but it's what first comes to mind.
On Mon, Oct 12, 2015 at 1:19 PM, Peter Murray <pmurray@chillco.com mailto:pmurray@chillco.com> wrote:
I think I've gotten all of the CSpace configuration and UI changes behind me. Just a few things left to clean up. I'm concentrating on data loading now. I figured it would be best to get started with the example in [Imports Service Home](https://wiki.collectionspace.org/display/collectionspace/Imports+Service+Home https://wiki.collectionspace.org/display/collectionspace/Imports+Service+Home) at the "Example Request" heading. I saved the XML for the persons authority records to a file and ran the curl command
:
$ curl -X POST https://cspace.vagrant/cspace-services/imports https://cspace.vagrant/cspace-services/imports
-i -u admin@museumofman.org:Administrator
-H "Content-Type: application/xml"
-T authority-request.xtml
Initially the error response I got back said "Could not process import payload. Check XML markup for not-well-formed errors, elements not matching import schema, etc." and this was logged on the cspace-services.log file:
ERROR [...] [org.collectionspace.services.imports.TemplateExpander:492] ERROR calling expandXmlPayloadToDirjava.lang.IllegalArgumentException: Malformed refName for Authority (too few tokens)
So I removed the "<personauthorities_common:refName>" element in the XML file and tried again. The response I got back (with prettified XML) was:
HTTP/1.1 100 Continue
HTTP/1.1 200 OK
Date: Mon, 12 Oct 2015 20:05:02 GMT
Server: Apache-Coyote/1.1
Strict-Transport-Security: max-age=15768000
Content-Type: application/xml
Content-Length: 998
Set-Cookie: JSESSIONID=9EB6F3E6A8679B82E55B8E742CA331E9; Path=/cspace-services/; HttpOnly
Vary: Accept-Encoding
<?xml version="1.0" encoding="UTF-8"?>
<import>
<msg>SUCCESS</msg>
<importedRecords>
<importedRecord>
<doctype>Personauthority</doctype>
<csid>c955a218-6fea-44bd-9dfe-1e7804be7ac5</csid>
</importedRecord>
<importedRecord>
<doctype>Personauthority</doctype>
<csid>11111111-2222-3333-4444-123456789012</csid>
</importedRecord>
</importedRecords>
<status>Success</status>
<totalRecordsImported>2</totalRecordsImported>
<numRecordsImportedByDocType>
<numRecordsImported>
<docType>Personauthority</docType>
<numRecords>2</numRecords>
</numRecordsImported>
</numRecordsImportedByDocType>
<report>READ: /home/vagrant/cspace-tomcat/apache-tomcat-7.0.57/temp/imports-2086091545258611644/Personauthorities/11111111-2222-3333-4444-123456789012/document.xml/Personauthorities/11111111-2222-3333-4444-123456789012READ: /home/vagrant/cspace-tomcat/apache-tomcat-7.0.57/temp/imports-2086091545258611644/Personauthorities/c955a218-6fea-44bd-9dfe-1e7804be7ac5/document.xml/Personauthorities/c955a218-6fea-44bd-9dfe-1e7804be7ac5</report>
</import>
...which looks like a successful import, BUT this is in cspace-services.log:
WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no ID for document, won't add org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@74ae85f4
WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no ID for document, won't add org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@3f4d7382
...AND the document doesn't seem to be in the database. Based on the csid
I would expect these URLs to work:
https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=c955a218-6fea-44bd-9dfe-1e7804be7ac5&vocab=person https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=c955a218-6fea-44bd-9dfe-1e7804be7ac5&vocab=person
https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=11111111-2222-3333-4444-123456789012&vocab=person https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=11111111-2222-3333-4444-123456789012&vocab=person
...because the documents can't be found (also from cspace-services.log):
ERROR [...] [org.collectionspace.services.nuxeo.client.java.RepositoryJavaClientImpl:1303] Could not find document with CSID=c955a218-6fea-44bd-9dfe-1e7804be7ac5. Caught exception:Failed to get document /sdmom-domain/Workspaces/Persons/c955a218-6fea-44bd-9dfe-1e7804be7ac5
ERROR [...] [org.collectionspace.services.nuxeo.client.java.RepositoryJavaClientImpl:1303] Could not find document with CSID=11111111-2222-3333-4444-123456789012. Caught exception:Failed to get document /sdmom-domain/Workspaces/Persons/11111111-2222-3333-4444-123456789012
... and the records don't show up in a search. I feel like I'm missing something here, but I can't quite put my finger on it. Suggestions?
Peter
--
Peter Murray
Dev/Ops Lead and Project Manager
Cherry Hill Company
I'm no further along, but I think I understand the pieces a little better. I put the 'refName' element back in and changed the text of the element to match what I think is our "Local Names" persons authority. I haven't modified the instances of the person authority, so it is using the one defined in base-authority-person.xml (https://github.com/collectionspace/application/blob/v4.2/tomcat-main/src/main/resources/defaults/base-authority-person.xml#L42-L46 <https://github.com/collectionspace/application/blob/v4.2/tomcat-main/src/main/resources/defaults/base-authority-person.xml#L42-L46>). My request document looks like this:
https://gist.github.com/dltj/cacd7dbf011e58d4aa33#file-authority-request-xml <https://gist.github.com/dltj/cacd7dbf011e58d4aa33#file-authority-request-xml>
The response from CSpace looks like this:
https://gist.github.com/dltj/cacd7dbf011e58d4aa33#file-post-body-xml <https://gist.github.com/dltj/cacd7dbf011e58d4aa33#file-post-body-xml>
...and I went looking for the document referenced in the CSpace response; it looks like this:
https://gist.github.com/dltj/cacd7dbf011e58d4aa33#file-11111111-2222-3333-4444-123456789012-document-xml <https://gist.github.com/dltj/cacd7dbf011e58d4aa33#file-11111111-2222-3333-4444-123456789012-document-xml>
When I look for the record in the UI (https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=11111111-2222-3333-4444-123456789012&vocab=person <https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=11111111-2222-3333-4444-123456789012&vocab=person>), it is not there. The only thing in the logs continues to be these warnings in cspace-services.log:
WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no ID for document, won't add org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@7192126e
WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no ID for document, won't add org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@78598d48
The 'catalina.out' file also has these two lines, along with log lines that state the request directory and the document directory are being created in $CATALINA_HOME/temp
I have a feeling that there is still something missing in the import request document, but I can't put my finger on it.
Peter
> On Oct 12, 2015, at 5:52 PM, Aron Roberts <aron@socrates.berkeley.edu> wrote:
>
> At a brief and superficial glance, it seems possible the refName values, in that example on the Imports Service Home page might be obsolete.
>
> The RefName page (https://wiki.collectionspace.org/display/DOC/RefName <https://wiki.collectionspace.org/display/DOC/RefName>) gives this example, for importing a person authority record:
>
> urn:cspace:core.collectionspace.org:personauthorities:name(localPersonVocabulary)'Local Person Vocabulary'
>
> Note that unlike the example on the Imports Service Home page, that example includes a 'name' component. (As well, the URL in this example also reflects the tenant domain name, which is current practice, IIRC.) Contrast the (presumably correct) example above with this one, from the imports page:
>
> urn:cspace:collectionspace.org:Personauthorities(perfTestPersons)'Perf Test Person Auth'
>
> Perhaps try putting back the "<personauthorities_common:refName>" element and using the RefName page's example (the first one above) - tweaked as needed to reflect the Museum of Man's values - and see if the import works?
>
> This might or might not be relevant, but it's what first comes to mind.
>
> On Mon, Oct 12, 2015 at 1:19 PM, Peter Murray <pmurray@chillco.com <mailto:pmurray@chillco.com>> wrote:
> I think I've gotten all of the CSpace configuration and UI changes behind me. Just a few things left to clean up. I'm concentrating on data loading now. I figured it would be best to get started with the example in [Imports Service Home](https://wiki.collectionspace.org/display/collectionspace/Imports+Service+Home <https://wiki.collectionspace.org/display/collectionspace/Imports+Service+Home>) at the "Example Request" heading. I saved the XML for the persons authority records to a file and ran the `curl command`:
>
> $ curl -X POST https://cspace.vagrant/cspace-services/imports <https://cspace.vagrant/cspace-services/imports> \
> -i -u admin@museumofman.org:Administrator \
> -H "Content-Type: application/xml" \
> -T authority-request.xtml
>
> Initially the error response I got back said "Could not process import payload. Check XML markup for not-well-formed errors, elements not matching import schema, etc." and this was logged on the cspace-services.log file:
>
> ERROR [...] [org.collectionspace.services.imports.TemplateExpander:492] ERROR calling expandXmlPayloadToDirjava.lang.IllegalArgumentException: Malformed refName for Authority (too few tokens)
>
> So I removed the "<personauthorities_common:refName>" element in the XML file and tried again. The response I got back (with prettified XML) was:
>
> HTTP/1.1 100 Continue
>
> HTTP/1.1 200 OK
> Date: Mon, 12 Oct 2015 20:05:02 GMT
> Server: Apache-Coyote/1.1
> Strict-Transport-Security: max-age=15768000
> Content-Type: application/xml
> Content-Length: 998
> Set-Cookie: JSESSIONID=9EB6F3E6A8679B82E55B8E742CA331E9; Path=/cspace-services/; HttpOnly
> Vary: Accept-Encoding
>
> <?xml version="1.0" encoding="UTF-8"?>
> <import>
> <msg>SUCCESS</msg>
> <importedRecords>
> <importedRecord>
> <doctype>Personauthority</doctype>
> <csid>c955a218-6fea-44bd-9dfe-1e7804be7ac5</csid>
> </importedRecord>
> <importedRecord>
> <doctype>Personauthority</doctype>
> <csid>11111111-2222-3333-4444-123456789012</csid>
> </importedRecord>
> </importedRecords>
> <status>Success</status>
> <totalRecordsImported>2</totalRecordsImported>
> <numRecordsImportedByDocType>
> <numRecordsImported>
> <docType>Personauthority</docType>
> <numRecords>2</numRecords>
> </numRecordsImported>
> </numRecordsImportedByDocType>
> <report>READ: /home/vagrant/cspace-tomcat/apache-tomcat-7.0.57/temp/imports-2086091545258611644/Personauthorities/11111111-2222-3333-4444-123456789012/document.xml/Personauthorities/11111111-2222-3333-4444-123456789012READ: /home/vagrant/cspace-tomcat/apache-tomcat-7.0.57/temp/imports-2086091545258611644/Personauthorities/c955a218-6fea-44bd-9dfe-1e7804be7ac5/document.xml/Personauthorities/c955a218-6fea-44bd-9dfe-1e7804be7ac5</report>
> </import>
>
>
> ...which looks like a successful import, BUT this is in cspace-services.log:
>
> WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no ID for document, won't add org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@74ae85f4
> WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no ID for document, won't add org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@3f4d7382
>
>
> ...AND the document doesn't seem to be in the database. Based on the `csid` I would expect these URLs to work:
>
> https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=c955a218-6fea-44bd-9dfe-1e7804be7ac5&vocab=person <https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=c955a218-6fea-44bd-9dfe-1e7804be7ac5&vocab=person>
> https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=11111111-2222-3333-4444-123456789012&vocab=person <https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=11111111-2222-3333-4444-123456789012&vocab=person>
>
> ...because the documents can't be found (also from cspace-services.log):
>
> ERROR [...] [org.collectionspace.services.nuxeo.client.java.RepositoryJavaClientImpl:1303] Could not find document with CSID=c955a218-6fea-44bd-9dfe-1e7804be7ac5. Caught exception:Failed to get document /sdmom-domain/Workspaces/Persons/c955a218-6fea-44bd-9dfe-1e7804be7ac5
> ERROR [...] [org.collectionspace.services.nuxeo.client.java.RepositoryJavaClientImpl:1303] Could not find document with CSID=11111111-2222-3333-4444-123456789012. Caught exception:Failed to get document /sdmom-domain/Workspaces/Persons/11111111-2222-3333-4444-123456789012
>
>
> ... and the records don't show up in a search. I feel like I'm missing something here, but I can't quite put my finger on it. Suggestions?
>
>
> Peter
--
Peter Murray
Dev/Ops Lead and Project Manager
Cherry Hill Company
JB
John B. LOWE
Tue, Oct 13, 2015 3:47 PM
Peter,
There are a number of different "styles" or "dialects" of XML that will
work with the IMPORT service, it was interesting to see yours.
I had a quick look and I noticed your IMPORT document
(authority-request.xml) seems to have two instances of the <
personauthorities_common:shortIdentifier> element and I'm not sure how that
can possibly work.
For comparison, I created a gist with 2 Person Authority records and 2
Relations records of the sort we used for the Hearst Museum ("PAHMA") a few
years ago. (For reasons I won't get into here, the examples do not use the
"sparse payload" approach -- they have lots of empty fields.)
https://gist.github.com/jblowe/2a99906195667c27a725
But hopefully they will give you the flavor of "our" dialect of IMPORT
xml...
Good hunting!
John
On Tue, Oct 13, 2015 at 8:14 AM, Peter Murray pmurray@chillco.com wrote:
I'm no further along, but I think I understand the pieces a little
better. I put the 'refName' element back in and changed the text of the
element to match what I think is our "Local Names" persons authority. I
haven't modified the instances of the person authority, so it is using the
one defined in base-authority-person.xml (
https://github.com/collectionspace/application/blob/v4.2/tomcat-main/src/main/resources/defaults/base-authority-person.xml#L42-L46).
My request document looks like this:
https://gist.github.com/dltj/cacd7dbf011e58d4aa33#file-authority-request-xml
The response from CSpace looks like this:
https://gist.github.com/dltj/cacd7dbf011e58d4aa33#file-post-body-xml
...and I went looking for the document referenced in the CSpace response;
it looks like this:
https://gist.github.com/dltj/cacd7dbf011e58d4aa33#file-11111111-2222-3333-4444-123456789012-document-xml
When I look for the record in the UI (
https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=11111111-2222-3333-4444-123456789012&vocab=person),
it is not there. The only thing in the logs continues to be these warnings
in cspace-services.log:
WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no ID
for document, won't add
org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@7192126e
WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no ID
for document, won't add
org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@78598d48
The 'catalina.out' file also has these two lines, along with log lines
that state the request directory and the document directory are being
created in $CATALINA_HOME/temp
I have a feeling that there is still something missing in the import
request document, but I can't put my finger on it.
Peter
On Oct 12, 2015, at 5:52 PM, Aron Roberts aron@socrates.berkeley.edu
wrote:
At a brief and superficial glance, it seems possible the refName values,
in that example on the Imports Service Home page might be obsolete.
The RefName page (https://wiki.collectionspace.org/display/DOC/RefName)
gives this example, for importing a person authority record:
urn:cspace:core.collectionspace.org:personauthorities:name(localPersonVocabulary)'Local
Person Vocabulary'
Note that unlike the example on the Imports Service Home page, that
example includes a 'name' component. (As well, the URL in this example also
reflects the tenant domain name, which is current practice, IIRC.) Contrast
the (presumably correct) example above with this one, from the imports page:
urn:cspace:collectionspace.org:Personauthorities(perfTestPersons)'Perf
Test Person Auth'
Perhaps try putting back the "<personauthorities_common:refName>"
element and using the RefName page's example (the first one above) -
tweaked as needed to reflect the Museum of Man's values - and see if the
import works?
This might or might not be relevant, but it's what first comes to mind.
On Mon, Oct 12, 2015 at 1:19 PM, Peter Murray pmurray@chillco.com wrote:
I think I've gotten all of the CSpace configuration and UI changes behind
me. Just a few things left to clean up. I'm concentrating on data loading
now. I figured it would be best to get started with the example in
Imports Service Home
at the "Example Request" heading. I saved the XML for the persons
authority records to a file and ran the curl command
:
$ curl -X POST https://cspace.vagrant/cspace-services/imports
-i -u admin@museumofman.org:Administrator
-H "Content-Type: application/xml"
-T authority-request.xtml
Initially the error response I got back said "Could not process import
payload. Check XML markup for not-well-formed errors, elements not matching
import schema, etc." and this was logged on the cspace-services.log file:
ERROR [...] [org.collectionspace.services.imports.TemplateExpander:492]
ERROR calling expandXmlPayloadToDirjava.lang.IllegalArgumentException:
Malformed refName for Authority (too few tokens)
So I removed the "<personauthorities_common:refName>" element in the XML
file and tried again. The response I got back (with prettified XML) was:
HTTP/1.1 100 Continue
HTTP/1.1 200 OK
Date: Mon, 12 Oct 2015 20:05:02 GMT
Server: Apache-Coyote/1.1
Strict-Transport-Security: max-age=15768000
Content-Type: application/xml
Content-Length: 998
Set-Cookie: JSESSIONID=9EB6F3E6A8679B82E55B8E742CA331E9;
Path=/cspace-services/; HttpOnly
Vary: Accept-Encoding
<?xml version="1.0" encoding="UTF-8"?>
<import>
<msg>SUCCESS</msg>
<importedRecords>
<importedRecord>
<doctype>Personauthority</doctype>
<csid>c955a218-6fea-44bd-9dfe-1e7804be7ac5</csid>
</importedRecord>
<importedRecord>
<doctype>Personauthority</doctype>
<csid>11111111-2222-3333-4444-123456789012</csid>
</importedRecord>
</importedRecords>
<status>Success</status>
<totalRecordsImported>2</totalRecordsImported>
<numRecordsImportedByDocType>
<numRecordsImported>
<docType>Personauthority</docType>
<numRecords>2</numRecords>
</numRecordsImported>
</numRecordsImportedByDocType>
<report>READ:
/home/vagrant/cspace-tomcat/apache-tomcat-7.0.57/temp/imports-2086091545258611644/Personauthorities/11111111-2222-3333-4444-123456789012/document.xml/Personauthorities/11111111-2222-3333-4444-123456789012READ:
/home/vagrant/cspace-tomcat/apache-tomcat-7.0.57/temp/imports-2086091545258611644/Personauthorities/c955a218-6fea-44bd-9dfe-1e7804be7ac5/document.xml/Personauthorities/c955a218-6fea-44bd-9dfe-1e7804be7ac5</report>
</import>
...which looks like a successful import, BUT this is in
cspace-services.log:
WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no ID
for document, won't add
org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@74ae85f4
WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no ID
for document, won't add
org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@3f4d7382
...AND the document doesn't seem to be in the database. Based on the
csid
I would expect these URLs to work:
https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=c955a218-6fea-44bd-9dfe-1e7804be7ac5&vocab=person
https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=11111111-2222-3333-4444-123456789012&vocab=person
...because the documents can't be found (also from cspace-services.log):
ERROR [...]
[org.collectionspace.services.nuxeo.client.java.RepositoryJavaClientImpl:1303]
Could not find document with CSID=c955a218-6fea-44bd-9dfe-1e7804be7ac5.
Caught exception:Failed to get document
/sdmom-domain/Workspaces/Persons/c955a218-6fea-44bd-9dfe-1e7804be7ac5
ERROR [...]
[org.collectionspace.services.nuxeo.client.java.RepositoryJavaClientImpl:1303]
Could not find document with CSID=11111111-2222-3333-4444-123456789012.
Caught exception:Failed to get document
/sdmom-domain/Workspaces/Persons/11111111-2222-3333-4444-123456789012
... and the records don't show up in a search. I feel like I'm missing
something here, but I can't quite put my finger on it. Suggestions?
Peter
Peter,
There are a number of different "styles" or "dialects" of XML that will
work with the IMPORT service, it was interesting to see yours.
I had a quick look and I noticed your IMPORT document
(authority-request.xml) seems to have two instances of the <
personauthorities_common:shortIdentifier> element and I'm not sure how that
can possibly work.
For comparison, I created a gist with 2 Person Authority records and 2
Relations records of the sort we used for the Hearst Museum ("PAHMA") a few
years ago. (For reasons I won't get into here, the examples do not use the
"sparse payload" approach -- they have lots of empty fields.)
https://gist.github.com/jblowe/2a99906195667c27a725
But hopefully they will give you the flavor of "our" dialect of IMPORT
xml...
Good hunting!
John
On Tue, Oct 13, 2015 at 8:14 AM, Peter Murray <pmurray@chillco.com> wrote:
> I'm no further along, but I think I understand the pieces a little
> better. I put the 'refName' element back in and changed the text of the
> element to match what I think is our "Local Names" persons authority. I
> haven't modified the instances of the person authority, so it is using the
> one defined in base-authority-person.xml (
> https://github.com/collectionspace/application/blob/v4.2/tomcat-main/src/main/resources/defaults/base-authority-person.xml#L42-L46).
> My request document looks like this:
>
>
> https://gist.github.com/dltj/cacd7dbf011e58d4aa33#file-authority-request-xml
>
> The response from CSpace looks like this:
>
> https://gist.github.com/dltj/cacd7dbf011e58d4aa33#file-post-body-xml
>
> ...and I went looking for the document referenced in the CSpace response;
> it looks like this:
>
>
> https://gist.github.com/dltj/cacd7dbf011e58d4aa33#file-11111111-2222-3333-4444-123456789012-document-xml
>
> When I look for the record in the UI (
> https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=11111111-2222-3333-4444-123456789012&vocab=person),
> it is not there. The only thing in the logs continues to be these warnings
> in cspace-services.log:
>
> WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no ID
> for document, won't add
> org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@7192126e
> WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no ID
> for document, won't add
> org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@78598d48
>
> The 'catalina.out' file also has these two lines, along with log lines
> that state the request directory and the document directory are being
> created in $CATALINA_HOME/temp
>
> I have a feeling that there is still something missing in the import
> request document, but I can't put my finger on it.
>
>
> Peter
>
> On Oct 12, 2015, at 5:52 PM, Aron Roberts <aron@socrates.berkeley.edu>
> wrote:
>
> At a brief and superficial glance, it seems possible the refName values,
> in that example on the Imports Service Home page might be obsolete.
>
> The RefName page (https://wiki.collectionspace.org/display/DOC/RefName)
> gives this example, for importing a person authority record:
>
> urn:cspace:core.collectionspace.org:personauthorities:name(localPersonVocabulary)'Local
> Person Vocabulary'
>
> Note that unlike the example on the Imports Service Home page, that
> example includes a 'name' component. (As well, the URL in this example also
> reflects the tenant domain name, which is current practice, IIRC.) Contrast
> the (presumably correct) example above with this one, from the imports page:
>
> urn:cspace:collectionspace.org:Personauthorities(perfTestPersons)'Perf
> Test Person Auth'
>
> Perhaps try putting back the "<personauthorities_common:refName>"
> element and using the RefName page's example (the first one above) -
> tweaked as needed to reflect the Museum of Man's values - and see if the
> import works?
>
> This might or might not be relevant, but it's what first comes to mind.
>
> On Mon, Oct 12, 2015 at 1:19 PM, Peter Murray <pmurray@chillco.com> wrote:
>
>> I think I've gotten all of the CSpace configuration and UI changes behind
>> me. Just a few things left to clean up. I'm concentrating on data loading
>> now. I figured it would be best to get started with the example in
>> [Imports Service Home](
>> https://wiki.collectionspace.org/display/collectionspace/Imports+Service+Home)
>> at the "Example Request" heading. I saved the XML for the persons
>> authority records to a file and ran the `curl command`:
>>
>> $ curl -X POST https://cspace.vagrant/cspace-services/imports \
>> -i -u admin@museumofman.org:Administrator \
>> -H "Content-Type: application/xml" \
>> -T authority-request.xtml
>>
>> Initially the error response I got back said "Could not process import
>> payload. Check XML markup for not-well-formed errors, elements not matching
>> import schema, etc." and this was logged on the cspace-services.log file:
>>
>> ERROR [...] [org.collectionspace.services.imports.TemplateExpander:492]
>> ERROR calling expandXmlPayloadToDirjava.lang.IllegalArgumentException:
>> Malformed refName for Authority (too few tokens)
>>
>> So I removed the "<personauthorities_common:refName>" element in the XML
>> file and tried again. The response I got back (with prettified XML) was:
>>
>> HTTP/1.1 100 Continue
>>
>> HTTP/1.1 200 OK
>> Date: Mon, 12 Oct 2015 20:05:02 GMT
>> Server: Apache-Coyote/1.1
>> Strict-Transport-Security: max-age=15768000
>> Content-Type: application/xml
>> Content-Length: 998
>> Set-Cookie: JSESSIONID=9EB6F3E6A8679B82E55B8E742CA331E9;
>> Path=/cspace-services/; HttpOnly
>> Vary: Accept-Encoding
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <import>
>> <msg>SUCCESS</msg>
>> <importedRecords>
>> <importedRecord>
>> <doctype>Personauthority</doctype>
>> <csid>c955a218-6fea-44bd-9dfe-1e7804be7ac5</csid>
>> </importedRecord>
>> <importedRecord>
>> <doctype>Personauthority</doctype>
>> <csid>11111111-2222-3333-4444-123456789012</csid>
>> </importedRecord>
>> </importedRecords>
>> <status>Success</status>
>> <totalRecordsImported>2</totalRecordsImported>
>> <numRecordsImportedByDocType>
>> <numRecordsImported>
>> <docType>Personauthority</docType>
>> <numRecords>2</numRecords>
>> </numRecordsImported>
>> </numRecordsImportedByDocType>
>> <report>READ:
>> /home/vagrant/cspace-tomcat/apache-tomcat-7.0.57/temp/imports-2086091545258611644/Personauthorities/11111111-2222-3333-4444-123456789012/document.xml/Personauthorities/11111111-2222-3333-4444-123456789012READ:
>> /home/vagrant/cspace-tomcat/apache-tomcat-7.0.57/temp/imports-2086091545258611644/Personauthorities/c955a218-6fea-44bd-9dfe-1e7804be7ac5/document.xml/Personauthorities/c955a218-6fea-44bd-9dfe-1e7804be7ac5</report>
>> </import>
>>
>>
>> ...which looks like a successful import, BUT this is in
>> cspace-services.log:
>>
>> WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no ID
>> for document, won't add
>> org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@74ae85f4
>> WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no ID
>> for document, won't add
>> org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@3f4d7382
>>
>>
>> ...AND the document doesn't seem to be in the database. Based on the
>> `csid` I would expect these URLs to work:
>>
>>
>> https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=c955a218-6fea-44bd-9dfe-1e7804be7ac5&vocab=person
>>
>> https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=11111111-2222-3333-4444-123456789012&vocab=person
>>
>> ...because the documents can't be found (also from cspace-services.log):
>>
>> ERROR [...]
>> [org.collectionspace.services.nuxeo.client.java.RepositoryJavaClientImpl:1303]
>> Could not find document with CSID=c955a218-6fea-44bd-9dfe-1e7804be7ac5.
>> Caught exception:Failed to get document
>> /sdmom-domain/Workspaces/Persons/c955a218-6fea-44bd-9dfe-1e7804be7ac5
>> ERROR [...]
>> [org.collectionspace.services.nuxeo.client.java.RepositoryJavaClientImpl:1303]
>> Could not find document with CSID=11111111-2222-3333-4444-123456789012.
>> Caught exception:Failed to get document
>> /sdmom-domain/Workspaces/Persons/11111111-2222-3333-4444-123456789012
>>
>>
>> ... and the records don't show up in a search. I feel like I'm missing
>> something here, but I can't quite put my finger on it. Suggestions?
>>
>>
>> Peter
>
>
> --
> Peter Murray
> Dev/Ops Lead and Project Manager
> Cherry Hill Company
>
>
>
>
> _______________________________________________
> Talk mailing list
> Talk@lists.collectionspace.org
>
> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
>
>
PM
Peter Murray
Tue, Oct 13, 2015 6:32 PM
Thank you, John -- I hope that will be helpful. One thing I noticed right off the bat is the service
and type
attributes on the import
element:
<import service="Persons" type="Person" CSID="75d9ceef-5ee5-4afe-93da-16cf34700427">
versus
<import seq="2" service="Personauthorities" type="Personauthority" CSID="11111111-2222-3333-4444-123456789012">
I'm not quite sure what the difference between "Persons" and "Personauthorities" is, but there are indeed two different service bindings in my tenant bindings file (reading from https://wiki.collectionspace.org/display/collectionspace/Imports+Service+Home#ImportsServiceHome-Howtofindtheserviceandtypevalues. https://wiki.collectionspace.org/display/collectionspace/Imports+Service+Home#ImportsServiceHome-Howtofindtheserviceandtypevalues. -- which itself seems outdated because I didn't find the file where the documentation says the file would be).
Another difference is in the record structure itself. I think you might be on an older version of CSpace because in my persons_common schema the Display Name is in a repeated group and has a slightly different element name:
<persons_common:displayName>G. D. Baron [Ute]</persons_common:displayName>
versus
<persons_common:personTermGroupList>
<persons_common:personTermGroup>
<persons_common:termDisplayName>Perf Test Person Auth ${docID}</persons_common:termDisplayName>
</persons_common:personTermGroup>
</persons_common:personTermGroupList>
I found the latter by looking at what a record looks like in its raw form and comparing it with the documentation. Unfortunately, these changes don't seem to be enough to get the record imported in the right form.
Peter
On Oct 13, 2015, at 11:47 AM, John B. LOWE jblowe@berkeley.edu wrote:
Peter,
There are a number of different "styles" or "dialects" of XML that will work with the IMPORT service, it was interesting to see yours.
I had a quick look and I noticed your IMPORT document (authority-request.xml) seems to have two instances of the <personauthorities_common:shortIdentifier> element and I'm not sure how that can possibly work.
For comparison, I created a gist with 2 Person Authority records and 2 Relations records of the sort we used for the Hearst Museum ("PAHMA") a few years ago. (For reasons I won't get into here, the examples do not use the "sparse payload" approach -- they have lots of empty fields.)
https://gist.github.com/jblowe/2a99906195667c27a725 https://gist.github.com/jblowe/2a99906195667c27a725
But hopefully they will give you the flavor of "our" dialect of IMPORT xml...
Good hunting!
John
On Tue, Oct 13, 2015 at 8:14 AM, Peter Murray <pmurray@chillco.com mailto:pmurray@chillco.com> wrote:
I'm no further along, but I think I understand the pieces a little better. I put the 'refName' element back in and changed the text of the element to match what I think is our "Local Names" persons authority. I haven't modified the instances of the person authority, so it is using the one defined in base-authority-person.xml (https://github.com/collectionspace/application/blob/v4.2/tomcat-main/src/main/resources/defaults/base-authority-person.xml#L42-L46 https://github.com/collectionspace/application/blob/v4.2/tomcat-main/src/main/resources/defaults/base-authority-person.xml#L42-L46). My request document looks like this:
https://gist.github.com/dltj/cacd7dbf011e58d4aa33#file-authority-request-xml https://gist.github.com/dltj/cacd7dbf011e58d4aa33#file-authority-request-xml
The response from CSpace looks like this:
https://gist.github.com/dltj/cacd7dbf011e58d4aa33#file-post-body-xml https://gist.github.com/dltj/cacd7dbf011e58d4aa33#file-post-body-xml
...and I went looking for the document referenced in the CSpace response; it looks like this:
https://gist.github.com/dltj/cacd7dbf011e58d4aa33#file-11111111-2222-3333-4444-123456789012-document-xml https://gist.github.com/dltj/cacd7dbf011e58d4aa33#file-11111111-2222-3333-4444-123456789012-document-xml
When I look for the record in the UI (https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=11111111-2222-3333-4444-123456789012&vocab=person https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=11111111-2222-3333-4444-123456789012&vocab=person), it is not there. The only thing in the logs continues to be these warnings in cspace-services.log:
WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no ID for document, won't add org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@7192126e
WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no ID for document, won't add org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@78598d48
The 'catalina.out' file also has these two lines, along with log lines that state the request directory and the document directory are being created in $CATALINA_HOME/temp
I have a feeling that there is still something missing in the import request document, but I can't put my finger on it.
Peter
On Oct 12, 2015, at 5:52 PM, Aron Roberts <aron@socrates.berkeley.edu mailto:aron@socrates.berkeley.edu> wrote:
At a brief and superficial glance, it seems possible the refName values, in that example on the Imports Service Home page might be obsolete.
The RefName page (https://wiki.collectionspace.org/display/DOC/RefName https://wiki.collectionspace.org/display/DOC/RefName) gives this example, for importing a person authority record:
urn:cspace:core.collectionspace.org:personauthorities:name(localPersonVocabulary)'Local Person Vocabulary'
Note that unlike the example on the Imports Service Home page, that example includes a 'name' component. (As well, the URL in this example also reflects the tenant domain name, which is current practice, IIRC.) Contrast the (presumably correct) example above with this one, from the imports page:
urn:cspace:collectionspace.org:Personauthorities(perfTestPersons)'Perf Test Person Auth'
Perhaps try putting back the "<personauthorities_common:refName>" element and using the RefName page's example (the first one above) - tweaked as needed to reflect the Museum of Man's values - and see if the import works?
This might or might not be relevant, but it's what first comes to mind.
On Mon, Oct 12, 2015 at 1:19 PM, Peter Murray <pmurray@chillco.com mailto:pmurray@chillco.com> wrote:
I think I've gotten all of the CSpace configuration and UI changes behind me. Just a few things left to clean up. I'm concentrating on data loading now. I figured it would be best to get started with the example in [Imports Service Home](https://wiki.collectionspace.org/display/collectionspace/Imports+Service+Home https://wiki.collectionspace.org/display/collectionspace/Imports+Service+Home) at the "Example Request" heading. I saved the XML for the persons authority records to a file and ran the curl command
:
$ curl -X POST https://cspace.vagrant/cspace-services/imports https://cspace.vagrant/cspace-services/imports
-i -u admin@museumofman.org:Administrator
-H "Content-Type: application/xml"
-T authority-request.xtml
Initially the error response I got back said "Could not process import payload. Check XML markup for not-well-formed errors, elements not matching import schema, etc." and this was logged on the cspace-services.log file:
ERROR [...] [org.collectionspace.services.imports.TemplateExpander:492] ERROR calling expandXmlPayloadToDirjava.lang.IllegalArgumentException: Malformed refName for Authority (too few tokens)
So I removed the "<personauthorities_common:refName>" element in the XML file and tried again. The response I got back (with prettified XML) was:
HTTP/1.1 100 Continue
HTTP/1.1 200 OK
Date: Mon, 12 Oct 2015 20:05:02 GMT
Server: Apache-Coyote/1.1
Strict-Transport-Security: max-age=15768000
Content-Type: application/xml
Content-Length: 998
Set-Cookie: JSESSIONID=9EB6F3E6A8679B82E55B8E742CA331E9; Path=/cspace-services/; HttpOnly
Vary: Accept-Encoding
<?xml version="1.0" encoding="UTF-8"?>
<import>
<msg>SUCCESS</msg>
<importedRecords>
<importedRecord>
<doctype>Personauthority</doctype>
<csid>c955a218-6fea-44bd-9dfe-1e7804be7ac5</csid>
</importedRecord>
<importedRecord>
<doctype>Personauthority</doctype>
<csid>11111111-2222-3333-4444-123456789012</csid>
</importedRecord>
</importedRecords>
<status>Success</status>
<totalRecordsImported>2</totalRecordsImported>
<numRecordsImportedByDocType>
<numRecordsImported>
<docType>Personauthority</docType>
<numRecords>2</numRecords>
</numRecordsImported>
</numRecordsImportedByDocType>
<report>READ: /home/vagrant/cspace-tomcat/apache-tomcat-7.0.57/temp/imports-2086091545258611644/Personauthorities/11111111-2222-3333-4444-123456789012/document.xml/Personauthorities/11111111-2222-3333-4444-123456789012READ: /home/vagrant/cspace-tomcat/apache-tomcat-7.0.57/temp/imports-2086091545258611644/Personauthorities/c955a218-6fea-44bd-9dfe-1e7804be7ac5/document.xml/Personauthorities/c955a218-6fea-44bd-9dfe-1e7804be7ac5</report>
</import>
...which looks like a successful import, BUT this is in cspace-services.log:
WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no ID for document, won't add org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@74ae85f4
WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no ID for document, won't add org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@3f4d7382
...AND the document doesn't seem to be in the database. Based on the csid
I would expect these URLs to work:
https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=c955a218-6fea-44bd-9dfe-1e7804be7ac5&vocab=person https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=c955a218-6fea-44bd-9dfe-1e7804be7ac5&vocab=person
https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=11111111-2222-3333-4444-123456789012&vocab=person https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=11111111-2222-3333-4444-123456789012&vocab=person
...because the documents can't be found (also from cspace-services.log):
ERROR [...] [org.collectionspace.services.nuxeo.client.java.RepositoryJavaClientImpl:1303] Could not find document with CSID=c955a218-6fea-44bd-9dfe-1e7804be7ac5. Caught exception:Failed to get document /sdmom-domain/Workspaces/Persons/c955a218-6fea-44bd-9dfe-1e7804be7ac5
ERROR [...] [org.collectionspace.services.nuxeo.client.java.RepositoryJavaClientImpl:1303] Could not find document with CSID=11111111-2222-3333-4444-123456789012. Caught exception:Failed to get document /sdmom-domain/Workspaces/Persons/11111111-2222-3333-4444-123456789012
... and the records don't show up in a search. I feel like I'm missing something here, but I can't quite put my finger on it. Suggestions?
Peter
--
Peter Murray
Dev/Ops Lead and Project Manager
Cherry Hill Company
Thank you, John -- I hope that will be helpful. One thing I noticed right off the bat is the `service` and `type` attributes on the `import` element:
<import service="Persons" type="Person" CSID="75d9ceef-5ee5-4afe-93da-16cf34700427">
versus
<import seq="2" service="Personauthorities" type="Personauthority" CSID="11111111-2222-3333-4444-123456789012">
I'm not quite sure what the difference between "Persons" and "Personauthorities" is, but there are indeed two different service bindings in my tenant bindings file (reading from https://wiki.collectionspace.org/display/collectionspace/Imports+Service+Home#ImportsServiceHome-Howtofindtheserviceandtypevalues. <https://wiki.collectionspace.org/display/collectionspace/Imports+Service+Home#ImportsServiceHome-Howtofindtheserviceandtypevalues.> -- which itself seems outdated because I didn't find the file where the documentation says the file would be).
Another difference is in the record structure itself. I think you might be on an older version of CSpace because in my persons_common schema the Display Name is in a repeated group and has a slightly different element name:
<persons_common:displayName>G. D. Baron [Ute]</persons_common:displayName>
versus
<persons_common:personTermGroupList>
<persons_common:personTermGroup>
<persons_common:termDisplayName>Perf Test Person Auth ${docID}</persons_common:termDisplayName>
</persons_common:personTermGroup>
</persons_common:personTermGroupList>
I found the latter by looking at what a record looks like in its raw form and comparing it with the documentation. Unfortunately, these changes don't seem to be enough to get the record imported in the right form.
Peter
> On Oct 13, 2015, at 11:47 AM, John B. LOWE <jblowe@berkeley.edu> wrote:
>
> Peter,
>
> There are a number of different "styles" or "dialects" of XML that will work with the IMPORT service, it was interesting to see yours.
>
> I had a quick look and I noticed your IMPORT document (authority-request.xml) seems to have two instances of the <personauthorities_common:shortIdentifier> element and I'm not sure how that can possibly work.
>
> For comparison, I created a gist with 2 Person Authority records and 2 Relations records of the sort we used for the Hearst Museum ("PAHMA") a few years ago. (For reasons I won't get into here, the examples do not use the "sparse payload" approach -- they have lots of empty fields.)
>
> https://gist.github.com/jblowe/2a99906195667c27a725 <https://gist.github.com/jblowe/2a99906195667c27a725>
>
> But hopefully they will give you the flavor of "our" dialect of IMPORT xml...
>
> Good hunting!
>
> John
>
> On Tue, Oct 13, 2015 at 8:14 AM, Peter Murray <pmurray@chillco.com <mailto:pmurray@chillco.com>> wrote:
> I'm no further along, but I think I understand the pieces a little better. I put the 'refName' element back in and changed the text of the element to match what I think is our "Local Names" persons authority. I haven't modified the instances of the person authority, so it is using the one defined in base-authority-person.xml (https://github.com/collectionspace/application/blob/v4.2/tomcat-main/src/main/resources/defaults/base-authority-person.xml#L42-L46 <https://github.com/collectionspace/application/blob/v4.2/tomcat-main/src/main/resources/defaults/base-authority-person.xml#L42-L46>). My request document looks like this:
>
> https://gist.github.com/dltj/cacd7dbf011e58d4aa33#file-authority-request-xml <https://gist.github.com/dltj/cacd7dbf011e58d4aa33#file-authority-request-xml>
>
> The response from CSpace looks like this:
>
> https://gist.github.com/dltj/cacd7dbf011e58d4aa33#file-post-body-xml <https://gist.github.com/dltj/cacd7dbf011e58d4aa33#file-post-body-xml>
>
> ...and I went looking for the document referenced in the CSpace response; it looks like this:
>
> https://gist.github.com/dltj/cacd7dbf011e58d4aa33#file-11111111-2222-3333-4444-123456789012-document-xml <https://gist.github.com/dltj/cacd7dbf011e58d4aa33#file-11111111-2222-3333-4444-123456789012-document-xml>
>
> When I look for the record in the UI (https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=11111111-2222-3333-4444-123456789012&vocab=person <https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=11111111-2222-3333-4444-123456789012&vocab=person>), it is not there. The only thing in the logs continues to be these warnings in cspace-services.log:
>
> WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no ID for document, won't add org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@7192126e
> WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no ID for document, won't add org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@78598d48
>
> The 'catalina.out' file also has these two lines, along with log lines that state the request directory and the document directory are being created in $CATALINA_HOME/temp
>
> I have a feeling that there is still something missing in the import request document, but I can't put my finger on it.
>
>
> Peter
>
>> On Oct 12, 2015, at 5:52 PM, Aron Roberts <aron@socrates.berkeley.edu <mailto:aron@socrates.berkeley.edu>> wrote:
>>
>> At a brief and superficial glance, it seems possible the refName values, in that example on the Imports Service Home page might be obsolete.
>>
>> The RefName page (https://wiki.collectionspace.org/display/DOC/RefName <https://wiki.collectionspace.org/display/DOC/RefName>) gives this example, for importing a person authority record:
>>
>> urn:cspace:core.collectionspace.org:personauthorities:name(localPersonVocabulary)'Local Person Vocabulary'
>>
>> Note that unlike the example on the Imports Service Home page, that example includes a 'name' component. (As well, the URL in this example also reflects the tenant domain name, which is current practice, IIRC.) Contrast the (presumably correct) example above with this one, from the imports page:
>>
>> urn:cspace:collectionspace.org:Personauthorities(perfTestPersons)'Perf Test Person Auth'
>>
>> Perhaps try putting back the "<personauthorities_common:refName>" element and using the RefName page's example (the first one above) - tweaked as needed to reflect the Museum of Man's values - and see if the import works?
>>
>> This might or might not be relevant, but it's what first comes to mind.
>>
>> On Mon, Oct 12, 2015 at 1:19 PM, Peter Murray <pmurray@chillco.com <mailto:pmurray@chillco.com>> wrote:
>> I think I've gotten all of the CSpace configuration and UI changes behind me. Just a few things left to clean up. I'm concentrating on data loading now. I figured it would be best to get started with the example in [Imports Service Home](https://wiki.collectionspace.org/display/collectionspace/Imports+Service+Home <https://wiki.collectionspace.org/display/collectionspace/Imports+Service+Home>) at the "Example Request" heading. I saved the XML for the persons authority records to a file and ran the `curl command`:
>>
>> $ curl -X POST https://cspace.vagrant/cspace-services/imports <https://cspace.vagrant/cspace-services/imports> \
>> -i -u admin@museumofman.org:Administrator \
>> -H "Content-Type: application/xml" \
>> -T authority-request.xtml
>>
>> Initially the error response I got back said "Could not process import payload. Check XML markup for not-well-formed errors, elements not matching import schema, etc." and this was logged on the cspace-services.log file:
>>
>> ERROR [...] [org.collectionspace.services.imports.TemplateExpander:492] ERROR calling expandXmlPayloadToDirjava.lang.IllegalArgumentException: Malformed refName for Authority (too few tokens)
>>
>> So I removed the "<personauthorities_common:refName>" element in the XML file and tried again. The response I got back (with prettified XML) was:
>>
>> HTTP/1.1 100 Continue
>>
>> HTTP/1.1 200 OK
>> Date: Mon, 12 Oct 2015 20:05:02 GMT
>> Server: Apache-Coyote/1.1
>> Strict-Transport-Security: max-age=15768000
>> Content-Type: application/xml
>> Content-Length: 998
>> Set-Cookie: JSESSIONID=9EB6F3E6A8679B82E55B8E742CA331E9; Path=/cspace-services/; HttpOnly
>> Vary: Accept-Encoding
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <import>
>> <msg>SUCCESS</msg>
>> <importedRecords>
>> <importedRecord>
>> <doctype>Personauthority</doctype>
>> <csid>c955a218-6fea-44bd-9dfe-1e7804be7ac5</csid>
>> </importedRecord>
>> <importedRecord>
>> <doctype>Personauthority</doctype>
>> <csid>11111111-2222-3333-4444-123456789012</csid>
>> </importedRecord>
>> </importedRecords>
>> <status>Success</status>
>> <totalRecordsImported>2</totalRecordsImported>
>> <numRecordsImportedByDocType>
>> <numRecordsImported>
>> <docType>Personauthority</docType>
>> <numRecords>2</numRecords>
>> </numRecordsImported>
>> </numRecordsImportedByDocType>
>> <report>READ: /home/vagrant/cspace-tomcat/apache-tomcat-7.0.57/temp/imports-2086091545258611644/Personauthorities/11111111-2222-3333-4444-123456789012/document.xml/Personauthorities/11111111-2222-3333-4444-123456789012READ: /home/vagrant/cspace-tomcat/apache-tomcat-7.0.57/temp/imports-2086091545258611644/Personauthorities/c955a218-6fea-44bd-9dfe-1e7804be7ac5/document.xml/Personauthorities/c955a218-6fea-44bd-9dfe-1e7804be7ac5</report>
>> </import>
>>
>>
>> ...which looks like a successful import, BUT this is in cspace-services.log:
>>
>> WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no ID for document, won't add org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@74ae85f4
>> WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no ID for document, won't add org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@3f4d7382
>>
>>
>> ...AND the document doesn't seem to be in the database. Based on the `csid` I would expect these URLs to work:
>>
>> https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=c955a218-6fea-44bd-9dfe-1e7804be7ac5&vocab=person <https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=c955a218-6fea-44bd-9dfe-1e7804be7ac5&vocab=person>
>> https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=11111111-2222-3333-4444-123456789012&vocab=person <https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=11111111-2222-3333-4444-123456789012&vocab=person>
>>
>> ...because the documents can't be found (also from cspace-services.log):
>>
>> ERROR [...] [org.collectionspace.services.nuxeo.client.java.RepositoryJavaClientImpl:1303] Could not find document with CSID=c955a218-6fea-44bd-9dfe-1e7804be7ac5. Caught exception:Failed to get document /sdmom-domain/Workspaces/Persons/c955a218-6fea-44bd-9dfe-1e7804be7ac5
>> ERROR [...] [org.collectionspace.services.nuxeo.client.java.RepositoryJavaClientImpl:1303] Could not find document with CSID=11111111-2222-3333-4444-123456789012. Caught exception:Failed to get document /sdmom-domain/Workspaces/Persons/11111111-2222-3333-4444-123456789012
>>
>>
>> ... and the records don't show up in a search. I feel like I'm missing something here, but I can't quite put my finger on it. Suggestions?
>>
>>
>> Peter
--
Peter Murray
Dev/Ops Lead and Project Manager
Cherry Hill Company
PM
Peter Murray
Tue, Oct 13, 2015 8:40 PM
I've updated the Gist (https://gist.github.com/dltj/cacd7dbf011e58d4aa33) with the latest version of what I'm trying, but I know this doesn't work because it wrecks my Nuxeo database (forcing a flush and rebuild).
The request I'm making is: https://gist.github.com/dltj/cacd7dbf011e58d4aa33/5ee596d5ec3dfa86cdddab84c7dd58c82cb9cd9a#file-authority-request-xml
The response body to the POST request is: https://gist.github.com/dltj/cacd7dbf011e58d4aa33/5ee596d5ec3dfa86cdddab84c7dd58c82cb9cd9a#file-post-body-xml
The file created in the $CATALINA_HOME/temp directory is: https://gist.github.com/dltj/cacd7dbf011e58d4aa33/5ee596d5ec3dfa86cdddab84c7dd58c82cb9cd9a#file-catalina_home_temp_-_request-xml
Although the post body says "<msg>SUCCESS</msg>" I cannot find the record in the database using the CSpace web UI. In fact, when I try to search for all "Person" record types, I'm getting an error in Catalina.out (https://gist.github.com/dltj/cacd7dbf011e58d4aa33/5ee596d5ec3dfa86cdddab84c7dd58c82cb9cd9a#file-catalina-out).
John's message (http://lists.collectionspace.org/pipermail/talk_lists.collectionspace.org/2015-October/002217.html) with his Gist (https://gist.github.com/jblowe/2a99906195667c27a725) were helpful, but judging from the schema differences SDMoM's version of CSpace does not match PAHMA's. (In particular, my "Display Name" is in nested XML tags (personTermGroupList.personTermGroup.termDisplayName) and PAHMA's is at the top level (displayName).) I'm also wondering if the documentation (https://wiki.collectionspace.org/display/collectionspace/Imports+Service+Home) is out of date because its examples don't include this hierarchy either. Either that or I'm chasing the wrong schema.
So I'm left with these questions:
-
What is the difference between the 'service="Persons"' endpoint and the 'service="Personauthorities"' endpoint? Both appear in my tenant bindings file.
-
What does a valid Person import request for CSpace 4.2 look like? The documentation suggests the test file in the code repo should work (https://github.com/collectionspace/services/blob/master/services/imports/service/src/test/resources/requests/authority-request.xml), but it doesn't. If I try to import the first record there (changing just the RefName tag to match the SDMoM configuration), I get:
ERROR calling expandXmlPayloadToDirjava.lang.IllegalArgumentException: Malformed refName for Authority (too few tokens)
If I change the RefName to be a URN that points to a specific item in a vocabulary, the record seems to import ('<msg>SUCCESS</msg>') but it cannot be found in the CSpace web UI.
Peter
Peter Murray
Dev/Ops Lead and Project Manager
Cherry Hill Company
I've updated the Gist (https://gist.github.com/dltj/cacd7dbf011e58d4aa33) with the latest version of what I'm trying, but I know this doesn't work because it wrecks my Nuxeo database (forcing a flush and rebuild).
The request I'm making is: https://gist.github.com/dltj/cacd7dbf011e58d4aa33/5ee596d5ec3dfa86cdddab84c7dd58c82cb9cd9a#file-authority-request-xml
The response body to the POST request is: https://gist.github.com/dltj/cacd7dbf011e58d4aa33/5ee596d5ec3dfa86cdddab84c7dd58c82cb9cd9a#file-post-body-xml
The file created in the $CATALINA_HOME/temp directory is: https://gist.github.com/dltj/cacd7dbf011e58d4aa33/5ee596d5ec3dfa86cdddab84c7dd58c82cb9cd9a#file-catalina_home_temp_-_request-xml
Although the post body says "<msg>SUCCESS</msg>" I cannot find the record in the database using the CSpace web UI. In fact, when I try to search for all "Person" record types, I'm getting an error in Catalina.out (https://gist.github.com/dltj/cacd7dbf011e58d4aa33/5ee596d5ec3dfa86cdddab84c7dd58c82cb9cd9a#file-catalina-out).
John's message (http://lists.collectionspace.org/pipermail/talk_lists.collectionspace.org/2015-October/002217.html) with his Gist (https://gist.github.com/jblowe/2a99906195667c27a725) were helpful, but judging from the schema differences SDMoM's version of CSpace does not match PAHMA's. (In particular, my "Display Name" is in nested XML tags (personTermGroupList.personTermGroup.termDisplayName) and PAHMA's is at the top level (displayName).) I'm also wondering if the documentation (https://wiki.collectionspace.org/display/collectionspace/Imports+Service+Home) is out of date because its examples don't include this hierarchy either. Either that or I'm chasing the wrong schema.
So I'm left with these questions:
* What is the difference between the 'service="Persons"' endpoint and the 'service="Personauthorities"' endpoint? Both appear in my tenant bindings file.
* What does a valid Person import request for CSpace 4.2 look like? The documentation suggests the test file in the code repo should work (https://github.com/collectionspace/services/blob/master/services/imports/service/src/test/resources/requests/authority-request.xml), but it doesn't. If I try to import the first record there (changing just the RefName tag to match the SDMoM configuration), I get:
ERROR calling expandXmlPayloadToDirjava.lang.IllegalArgumentException: Malformed refName for Authority (too few tokens)
If I change the RefName to be a URN that points to a specific item in a vocabulary, the record seems to import ('<msg>SUCCESS</msg>') but it cannot be found in the CSpace web UI.
Peter
--
Peter Murray
Dev/Ops Lead and Project Manager
Cherry Hill Company
AR
Aron Roberts
Tue, Oct 13, 2015 8:45 PM
I'm not quite sure what the difference between "Persons" and
"Personauthorities" is, but there are indeed two different service bindings
in my tenant bindings file
True. Personauthorities are authorities for (aka controlled lists of)
person terms. Persons are individual terms ("items") in those lists. The
former can be conceived of as a container or bucket, for holding terms
related to a particular category of persons, and the latter as those person
terms that fill it.
If a specific person authority doesn't yet exist, you'd need to create it
before you could add terms to it. In the default configuration of
CollectionSpace's demonstration 'core' and 'lifesci' tenants, at least one
sample person authority is created, as specified in config files in the
Application layer, via the process of visiting the URL for initializing
authorities. Your own tenant's authorities might differ from those in the
sample tenants.
It might be helpful to start out with a different import, in part because
this one doesn't introduce any of the potential complexities regarding
authorities and authority items. Does the Object Exit example in that
Imports Service Home document work when you try it, for starters?
https://wiki.collectionspace.org/display/DOC/Imports+Service+Home#ImportsServiceHome-ExampleRequest
That is, if you copy that XML snippet to a different file and use 'curl'
with a command pretty much identical to the one you used for
personauthorities?
On Tue, Oct 13, 2015 at 11:32 AM, Peter Murray pmurray@chillco.com wrote:
Thank you, John -- I hope that will be helpful. One thing I noticed right
off the bat is the service
and type
attributes on the import
element:
<import service="Persons" type="Person" CSID="
75d9ceef-5ee5-4afe-93da-16cf34700427">
versus
<import seq="2" service="Personauthorities" type="Personauthority" CSID="
11111111-2222-3333-4444-123456789012">
I'm not quite sure what the difference between "Persons" and
"Personauthorities" is, but there are indeed two different service bindings
in my tenant bindings file (reading from
https://wiki.collectionspace.org/display/collectionspace/Imports+Service+Home#ImportsServiceHome-Howtofindtheserviceandtypevalues. --
which itself seems outdated because I didn't find the file where the
documentation says the file would be).
Another difference is in the record structure itself. I think you might
be on an older version of CSpace because in my persons_common schema the
Display Name is in a repeated group and has a slightly different element
name:
<persons_common:displayName>G. D. Baron [Ute]</persons_common:displayName>
versus
<persons_common:personTermGroupList><persons_common:personTermGroup> <
persons_common:termDisplayName>Perf Test Person Auth ${docID}</
persons_common:termDisplayName></persons_common:personTermGroup></
persons_common:personTermGroupList>
I found the latter by looking at what a record looks like in its raw form
and comparing it with the documentation. Unfortunately, these changes
don't seem to be enough to get the record imported in the right form.
Peter
On Oct 13, 2015, at 11:47 AM, John B. LOWE jblowe@berkeley.edu wrote:
Peter,
There are a number of different "styles" or "dialects" of XML that will
work with the IMPORT service, it was interesting to see yours.
I had a quick look and I noticed your IMPORT document
(authority-request.xml) seems to have two instances of the <
personauthorities_common:shortIdentifier> element and I'm not sure how
that can possibly work.
For comparison, I created a gist with 2 Person Authority records and 2
Relations records of the sort we used for the Hearst Museum ("PAHMA") a few
years ago. (For reasons I won't get into here, the examples do not use the
"sparse payload" approach -- they have lots of empty fields.)
https://gist.github.com/jblowe/2a99906195667c27a725
But hopefully they will give you the flavor of "our" dialect of IMPORT
xml...
Good hunting!
John
On Tue, Oct 13, 2015 at 8:14 AM, Peter Murray pmurray@chillco.com wrote:
I'm no further along, but I think I understand the pieces a little
better. I put the 'refName' element back in and changed the text of the
element to match what I think is our "Local Names" persons authority. I
haven't modified the instances of the person authority, so it is using the
one defined in base-authority-person.xml (
https://github.com/collectionspace/application/blob/v4.2/tomcat-main/src/main/resources/defaults/base-authority-person.xml#L42-L46).
My request document looks like this:
https://gist.github.com/dltj/cacd7dbf011e58d4aa33#file-authority-request-xml
The response from CSpace looks like this:
https://gist.github.com/dltj/cacd7dbf011e58d4aa33#file-post-body-xml
...and I went looking for the document referenced in the CSpace response;
it looks like this:
https://gist.github.com/dltj/cacd7dbf011e58d4aa33#file-11111111-2222-3333-4444-123456789012-document-xml
When I look for the record in the UI (
https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=11111111-2222-3333-4444-123456789012&vocab=person),
it is not there. The only thing in the logs continues to be these warnings
in cspace-services.log:
WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no ID
for document, won't add
org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@7192126e
WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no ID
for document, won't add
org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@78598d48
The 'catalina.out' file also has these two lines, along with log lines
that state the request directory and the document directory are being
created in $CATALINA_HOME/temp
I have a feeling that there is still something missing in the import
request document, but I can't put my finger on it.
Peter
On Oct 12, 2015, at 5:52 PM, Aron Roberts aron@socrates.berkeley.edu
wrote:
At a brief and superficial glance, it seems possible the refName
values, in that example on the Imports Service Home page might be obsolete.
The RefName page (https://wiki.collectionspace.org/display/DOC/RefName)
gives this example, for importing a person authority record:
urn:cspace:core.collectionspace.org:personauthorities:name(localPersonVocabulary)'Local
Person Vocabulary'
Note that unlike the example on the Imports Service Home page, that
example includes a 'name' component. (As well, the URL in this example also
reflects the tenant domain name, which is current practice, IIRC.) Contrast
the (presumably correct) example above with this one, from the imports page:
urn:cspace:collectionspace.org:Personauthorities(perfTestPersons)'Perf
Test Person Auth'
Perhaps try putting back the "<personauthorities_common:refName>"
element and using the RefName page's example (the first one above) -
tweaked as needed to reflect the Museum of Man's values - and see if the
import works?
This might or might not be relevant, but it's what first comes to mind.
On Mon, Oct 12, 2015 at 1:19 PM, Peter Murray pmurray@chillco.com
wrote:
I think I've gotten all of the CSpace configuration and UI changes
behind me. Just a few things left to clean up. I'm concentrating on data
loading now. I figured it would be best to get started with the example in
Imports Service Home
at the "Example Request" heading. I saved the XML for the persons
authority records to a file and ran the curl command
:
$ curl -X POST https://cspace.vagrant/cspace-services/imports
-i -u admin@museumofman.org:Administrator
-H "Content-Type: application/xml"
-T authority-request.xtml
Initially the error response I got back said "Could not process import
payload. Check XML markup for not-well-formed errors, elements not matching
import schema, etc." and this was logged on the cspace-services.log file:
ERROR [...]
[org.collectionspace.services.imports.TemplateExpander:492] ERROR calling
expandXmlPayloadToDirjava.lang.IllegalArgumentException: Malformed refName
for Authority (too few tokens)
So I removed the "<personauthorities_common:refName>" element in the XML
file and tried again. The response I got back (with prettified XML) was:
HTTP/1.1 100 Continue
HTTP/1.1 200 OK
Date: Mon, 12 Oct 2015 20:05:02 GMT
Server: Apache-Coyote/1.1
Strict-Transport-Security: max-age=15768000
Content-Type: application/xml
Content-Length: 998
Set-Cookie: JSESSIONID=9EB6F3E6A8679B82E55B8E742CA331E9;
Path=/cspace-services/; HttpOnly
Vary: Accept-Encoding
<?xml version="1.0" encoding="UTF-8"?>
<import>
<msg>SUCCESS</msg>
<importedRecords>
<importedRecord>
<doctype>Personauthority</doctype>
<csid>c955a218-6fea-44bd-9dfe-1e7804be7ac5</csid>
</importedRecord>
<importedRecord>
<doctype>Personauthority</doctype>
<csid>11111111-2222-3333-4444-123456789012</csid>
</importedRecord>
</importedRecords>
<status>Success</status>
<totalRecordsImported>2</totalRecordsImported>
<numRecordsImportedByDocType>
<numRecordsImported>
<docType>Personauthority</docType>
<numRecords>2</numRecords>
</numRecordsImported>
</numRecordsImportedByDocType>
<report>READ:
/home/vagrant/cspace-tomcat/apache-tomcat-7.0.57/temp/imports-2086091545258611644/Personauthorities/11111111-2222-3333-4444-123456789012/document.xml/Personauthorities/11111111-2222-3333-4444-123456789012READ:
/home/vagrant/cspace-tomcat/apache-tomcat-7.0.57/temp/imports-2086091545258611644/Personauthorities/c955a218-6fea-44bd-9dfe-1e7804be7ac5/document.xml/Personauthorities/c955a218-6fea-44bd-9dfe-1e7804be7ac5</report>
</import>
...which looks like a successful import, BUT this is in
cspace-services.log:
WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no
ID for document, won't add
org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@74ae85f4
WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no
ID for document, won't add
org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@3f4d7382
...AND the document doesn't seem to be in the database. Based on the
csid
I would expect these URLs to work:
https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=c955a218-6fea-44bd-9dfe-1e7804be7ac5&vocab=person
https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=11111111-2222-3333-4444-123456789012&vocab=person
...because the documents can't be found (also from cspace-services.log):
ERROR [...]
[org.collectionspace.services.nuxeo.client.java.RepositoryJavaClientImpl:1303]
Could not find document with CSID=c955a218-6fea-44bd-9dfe-1e7804be7ac5.
Caught exception:Failed to get document
/sdmom-domain/Workspaces/Persons/c955a218-6fea-44bd-9dfe-1e7804be7ac5
ERROR [...]
[org.collectionspace.services.nuxeo.client.java.RepositoryJavaClientImpl:1303]
Could not find document with CSID=11111111-2222-3333-4444-123456789012.
Caught exception:Failed to get document
/sdmom-domain/Workspaces/Persons/11111111-2222-3333-4444-123456789012
... and the records don't show up in a search. I feel like I'm missing
something here, but I can't quite put my finger on it. Suggestions?
Peter
Peter writes:
> I'm not quite sure what the difference between "Persons" and
"Personauthorities" is, but there are indeed two different service bindings
in my tenant bindings file
True. Personauthorities are authorities for (aka controlled lists of)
person terms. Persons are individual terms ("items") in those lists. The
former can be conceived of as a container or bucket, for holding terms
related to a particular category of persons, and the latter as those person
terms that fill it.
If a specific person authority doesn't yet exist, you'd need to create it
before you could add terms to it. In the default configuration of
CollectionSpace's demonstration 'core' and 'lifesci' tenants, at least one
sample person authority is created, as specified in config files in the
Application layer, via the process of visiting the URL for initializing
authorities. Your own tenant's authorities might differ from those in the
sample tenants.
It might be helpful to start out with a different import, in part because
this one doesn't introduce any of the potential complexities regarding
authorities and authority items. Does the Object Exit example in that
Imports Service Home document work when you try it, for starters?
https://wiki.collectionspace.org/display/DOC/Imports+Service+Home#ImportsServiceHome-ExampleRequest
That is, if you copy that XML snippet to a different file and use 'curl'
with a command pretty much identical to the one you used for
personauthorities?
On Tue, Oct 13, 2015 at 11:32 AM, Peter Murray <pmurray@chillco.com> wrote:
> Thank you, John -- I hope that will be helpful. One thing I noticed right
> off the bat is the `service` and `type` attributes on the `import` element:
>
> <import service="Persons" type="Person" CSID="
> 75d9ceef-5ee5-4afe-93da-16cf34700427">
>
> versus
>
> <import seq="2" service="Personauthorities" type="Personauthority" CSID="
> 11111111-2222-3333-4444-123456789012">
> I'm not quite sure what the difference between "Persons" and
> "Personauthorities" is, but there are indeed two different service bindings
> in my tenant bindings file (reading from
> https://wiki.collectionspace.org/display/collectionspace/Imports+Service+Home#ImportsServiceHome-Howtofindtheserviceandtypevalues. --
> which itself seems outdated because I didn't find the file where the
> documentation says the file would be).
>
> Another difference is in the record structure itself. I think you might
> be on an older version of CSpace because in my persons_common schema the
> Display Name is in a repeated group and has a slightly different element
> name:
>
> <persons_common:displayName>G. D. Baron [Ute]</persons_common:displayName>
>
> versus
>
>
> <persons_common:personTermGroupList><persons_common:personTermGroup> <
> persons_common:termDisplayName>Perf Test Person Auth ${docID}</
> persons_common:termDisplayName></persons_common:personTermGroup></
> persons_common:personTermGroupList>
> I found the latter by looking at what a record looks like in its raw form
> and comparing it with the documentation. Unfortunately, these changes
> don't seem to be enough to get the record imported in the right form.
>
>
> Peter
>
>
> On Oct 13, 2015, at 11:47 AM, John B. LOWE <jblowe@berkeley.edu> wrote:
>
> Peter,
>
> There are a number of different "styles" or "dialects" of XML that will
> work with the IMPORT service, it was interesting to see yours.
>
> I had a quick look and I noticed your IMPORT document
> (authority-request.xml) seems to have two instances of the <
> personauthorities_common:shortIdentifier> element and I'm not sure how
> that can possibly work.
>
> For comparison, I created a gist with 2 Person Authority records and 2
> Relations records of the sort we used for the Hearst Museum ("PAHMA") a few
> years ago. (For reasons I won't get into here, the examples do not use the
> "sparse payload" approach -- they have lots of empty fields.)
>
> https://gist.github.com/jblowe/2a99906195667c27a725
>
> But hopefully they will give you the flavor of "our" dialect of IMPORT
> xml...
>
> Good hunting!
>
> John
>
> On Tue, Oct 13, 2015 at 8:14 AM, Peter Murray <pmurray@chillco.com> wrote:
>
>> I'm no further along, but I think I understand the pieces a little
>> better. I put the 'refName' element back in and changed the text of the
>> element to match what I think is our "Local Names" persons authority. I
>> haven't modified the instances of the person authority, so it is using the
>> one defined in base-authority-person.xml (
>> https://github.com/collectionspace/application/blob/v4.2/tomcat-main/src/main/resources/defaults/base-authority-person.xml#L42-L46).
>> My request document looks like this:
>>
>>
>> https://gist.github.com/dltj/cacd7dbf011e58d4aa33#file-authority-request-xml
>>
>> The response from CSpace looks like this:
>>
>> https://gist.github.com/dltj/cacd7dbf011e58d4aa33#file-post-body-xml
>>
>> ...and I went looking for the document referenced in the CSpace response;
>> it looks like this:
>>
>>
>> https://gist.github.com/dltj/cacd7dbf011e58d4aa33#file-11111111-2222-3333-4444-123456789012-document-xml
>>
>> When I look for the record in the UI (
>> https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=11111111-2222-3333-4444-123456789012&vocab=person),
>> it is not there. The only thing in the logs continues to be these warnings
>> in cspace-services.log:
>>
>> WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no ID
>> for document, won't add
>> org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@7192126e
>> WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no ID
>> for document, won't add
>> org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@78598d48
>>
>> The 'catalina.out' file also has these two lines, along with log lines
>> that state the request directory and the document directory are being
>> created in $CATALINA_HOME/temp
>>
>> I have a feeling that there is still something missing in the import
>> request document, but I can't put my finger on it.
>>
>>
>> Peter
>>
>> On Oct 12, 2015, at 5:52 PM, Aron Roberts <aron@socrates.berkeley.edu>
>> wrote:
>>
>> At a brief and superficial glance, it seems possible the refName
>> values, in that example on the Imports Service Home page might be obsolete.
>>
>> The RefName page (https://wiki.collectionspace.org/display/DOC/RefName)
>> gives this example, for importing a person authority record:
>>
>> urn:cspace:core.collectionspace.org:personauthorities:name(localPersonVocabulary)'Local
>> Person Vocabulary'
>>
>> Note that unlike the example on the Imports Service Home page, that
>> example includes a 'name' component. (As well, the URL in this example also
>> reflects the tenant domain name, which is current practice, IIRC.) Contrast
>> the (presumably correct) example above with this one, from the imports page:
>>
>> urn:cspace:collectionspace.org:Personauthorities(perfTestPersons)'Perf
>> Test Person Auth'
>>
>> Perhaps try putting back the "<personauthorities_common:refName>"
>> element and using the RefName page's example (the first one above) -
>> tweaked as needed to reflect the Museum of Man's values - and see if the
>> import works?
>>
>> This might or might not be relevant, but it's what first comes to mind.
>>
>> On Mon, Oct 12, 2015 at 1:19 PM, Peter Murray <pmurray@chillco.com>
>> wrote:
>>
>>> I think I've gotten all of the CSpace configuration and UI changes
>>> behind me. Just a few things left to clean up. I'm concentrating on data
>>> loading now. I figured it would be best to get started with the example in
>>> [Imports Service Home](
>>> https://wiki.collectionspace.org/display/collectionspace/Imports+Service+Home)
>>> at the "Example Request" heading. I saved the XML for the persons
>>> authority records to a file and ran the `curl command`:
>>>
>>> $ curl -X POST https://cspace.vagrant/cspace-services/imports \
>>> -i -u admin@museumofman.org:Administrator \
>>> -H "Content-Type: application/xml" \
>>> -T authority-request.xtml
>>>
>>> Initially the error response I got back said "Could not process import
>>> payload. Check XML markup for not-well-formed errors, elements not matching
>>> import schema, etc." and this was logged on the cspace-services.log file:
>>>
>>> ERROR [...]
>>> [org.collectionspace.services.imports.TemplateExpander:492] ERROR calling
>>> expandXmlPayloadToDirjava.lang.IllegalArgumentException: Malformed refName
>>> for Authority (too few tokens)
>>>
>>> So I removed the "<personauthorities_common:refName>" element in the XML
>>> file and tried again. The response I got back (with prettified XML) was:
>>>
>>> HTTP/1.1 100 Continue
>>>
>>> HTTP/1.1 200 OK
>>> Date: Mon, 12 Oct 2015 20:05:02 GMT
>>> Server: Apache-Coyote/1.1
>>> Strict-Transport-Security: max-age=15768000
>>> Content-Type: application/xml
>>> Content-Length: 998
>>> Set-Cookie: JSESSIONID=9EB6F3E6A8679B82E55B8E742CA331E9;
>>> Path=/cspace-services/; HttpOnly
>>> Vary: Accept-Encoding
>>>
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <import>
>>> <msg>SUCCESS</msg>
>>> <importedRecords>
>>> <importedRecord>
>>> <doctype>Personauthority</doctype>
>>> <csid>c955a218-6fea-44bd-9dfe-1e7804be7ac5</csid>
>>> </importedRecord>
>>> <importedRecord>
>>> <doctype>Personauthority</doctype>
>>> <csid>11111111-2222-3333-4444-123456789012</csid>
>>> </importedRecord>
>>> </importedRecords>
>>> <status>Success</status>
>>> <totalRecordsImported>2</totalRecordsImported>
>>> <numRecordsImportedByDocType>
>>> <numRecordsImported>
>>> <docType>Personauthority</docType>
>>> <numRecords>2</numRecords>
>>> </numRecordsImported>
>>> </numRecordsImportedByDocType>
>>> <report>READ:
>>> /home/vagrant/cspace-tomcat/apache-tomcat-7.0.57/temp/imports-2086091545258611644/Personauthorities/11111111-2222-3333-4444-123456789012/document.xml/Personauthorities/11111111-2222-3333-4444-123456789012READ:
>>> /home/vagrant/cspace-tomcat/apache-tomcat-7.0.57/temp/imports-2086091545258611644/Personauthorities/c955a218-6fea-44bd-9dfe-1e7804be7ac5/document.xml/Personauthorities/c955a218-6fea-44bd-9dfe-1e7804be7ac5</report>
>>> </import>
>>>
>>>
>>> ...which looks like a successful import, BUT this is in
>>> cspace-services.log:
>>>
>>> WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no
>>> ID for document, won't add
>>> org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@74ae85f4
>>> WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no
>>> ID for document, won't add
>>> org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@3f4d7382
>>>
>>>
>>> ...AND the document doesn't seem to be in the database. Based on the
>>> `csid` I would expect these URLs to work:
>>>
>>>
>>> https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=c955a218-6fea-44bd-9dfe-1e7804be7ac5&vocab=person
>>>
>>> https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=11111111-2222-3333-4444-123456789012&vocab=person
>>>
>>> ...because the documents can't be found (also from cspace-services.log):
>>>
>>> ERROR [...]
>>> [org.collectionspace.services.nuxeo.client.java.RepositoryJavaClientImpl:1303]
>>> Could not find document with CSID=c955a218-6fea-44bd-9dfe-1e7804be7ac5.
>>> Caught exception:Failed to get document
>>> /sdmom-domain/Workspaces/Persons/c955a218-6fea-44bd-9dfe-1e7804be7ac5
>>> ERROR [...]
>>> [org.collectionspace.services.nuxeo.client.java.RepositoryJavaClientImpl:1303]
>>> Could not find document with CSID=11111111-2222-3333-4444-123456789012.
>>> Caught exception:Failed to get document
>>> /sdmom-domain/Workspaces/Persons/11111111-2222-3333-4444-123456789012
>>>
>>>
>>> ... and the records don't show up in a search. I feel like I'm missing
>>> something here, but I can't quite put my finger on it. Suggestions?
>>>
>>>
>>> Peter
>>
>>
> --
> Peter Murray
> Dev/Ops Lead and Project Manager
> Cherry Hill Company
>
>
>
>
> _______________________________________________
> Talk mailing list
> Talk@lists.collectionspace.org
>
> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
>
>
AR
Aron Roberts
Tue, Oct 13, 2015 8:49 PM
http://lists.collectionspace.org/pipermail/talk_lists.collectionspace.org/2015-October/002217.html)
with his Gist (https://gist.github.com/jblowe/2a99906195667c27a725) were
helpful, but judging from the schema differences SDMoM's version of CSpace
does not match PAHMA's. (In particular, my "Display Name" is in nested XML
tags (personTermGroupList.personTermGroup.termDisplayName) and PAHMA's is
at the top level (displayName).) I'm also wondering if the documentation (
https://wiki.collectionspace.org/display/collectionspace/Imports+Service+Home)
is out of date because its examples don't include this hierarchy either.
Either that or I'm chasing the wrong schema.
Excellent sleuthing and you're right on track, Peter. The person authority
schema doesn't include a nested display name, but the person schema does.
(That's because the names of persons may include multiple, alternate forms
- e.g. such as "Mark Twain", "Samuel L. Clemens", and "Samuel Langhorne
Clemens" - while the buckets or containers into which you put a set of
related person terms will generally have only one name; e.g. "Local
Persons", "Authors", "Creators", etc..)
On Tue, Oct 13, 2015 at 1:40 PM, Peter Murray pmurray@chillco.com wrote:
> John's message (
http://lists.collectionspace.org/pipermail/talk_lists.collectionspace.org/2015-October/002217.html)
with his Gist (https://gist.github.com/jblowe/2a99906195667c27a725) were
helpful, but judging from the schema differences SDMoM's version of CSpace
does not match PAHMA's. (In particular, my "Display Name" is in nested XML
tags (personTermGroupList.personTermGroup.termDisplayName) and PAHMA's is
at the top level (displayName).) I'm also wondering if the documentation (
https://wiki.collectionspace.org/display/collectionspace/Imports+Service+Home)
is out of date because its examples don't include this hierarchy either.
Either that or I'm chasing the wrong schema.
Excellent sleuthing and you're right on track, Peter. The person authority
schema doesn't include a nested display name, but the person schema does.
(That's because the names of persons may include multiple, alternate forms
- e.g. such as "Mark Twain", "Samuel L. Clemens", and "Samuel Langhorne
Clemens" - while the buckets or containers into which you put a set of
related person terms will generally have only one name; e.g. "Local
Persons", "Authors", "Creators", etc..)
On Tue, Oct 13, 2015 at 1:40 PM, Peter Murray <pmurray@chillco.com> wrote:
> I've updated the Gist (https://gist.github.com/dltj/cacd7dbf011e58d4aa33)
> with the latest version of what I'm trying, but I know this doesn't work
> because it wrecks my Nuxeo database (forcing a flush and rebuild).
>
> The request I'm making is:
> https://gist.github.com/dltj/cacd7dbf011e58d4aa33/5ee596d5ec3dfa86cdddab84c7dd58c82cb9cd9a#file-authority-request-xml
>
> The response body to the POST request is:
> https://gist.github.com/dltj/cacd7dbf011e58d4aa33/5ee596d5ec3dfa86cdddab84c7dd58c82cb9cd9a#file-post-body-xml
>
> The file created in the $CATALINA_HOME/temp directory is:
> https://gist.github.com/dltj/cacd7dbf011e58d4aa33/5ee596d5ec3dfa86cdddab84c7dd58c82cb9cd9a#file-catalina_home_temp_-_request-xml
>
> Although the post body says "<msg>SUCCESS</msg>" I cannot find the record
> in the database using the CSpace web UI. In fact, when I try to search for
> all "Person" record types, I'm getting an error in Catalina.out (
> https://gist.github.com/dltj/cacd7dbf011e58d4aa33/5ee596d5ec3dfa86cdddab84c7dd58c82cb9cd9a#file-catalina-out
> ).
>
> John's message (
> http://lists.collectionspace.org/pipermail/talk_lists.collectionspace.org/2015-October/002217.html)
> with his Gist (https://gist.github.com/jblowe/2a99906195667c27a725) were
> helpful, but judging from the schema differences SDMoM's version of CSpace
> does not match PAHMA's. (In particular, my "Display Name" is in nested XML
> tags (personTermGroupList.personTermGroup.termDisplayName) and PAHMA's is
> at the top level (displayName).) I'm also wondering if the documentation (
> https://wiki.collectionspace.org/display/collectionspace/Imports+Service+Home)
> is out of date because its examples don't include this hierarchy either.
> Either that or I'm chasing the wrong schema.
>
> So I'm left with these questions:
>
> * What is the difference between the 'service="Persons"' endpoint and the
> 'service="Personauthorities"' endpoint? Both appear in my tenant bindings
> file.
>
> * What does a valid Person import request for CSpace 4.2 look like? The
> documentation suggests the test file in the code repo should work (
> https://github.com/collectionspace/services/blob/master/services/imports/service/src/test/resources/requests/authority-request.xml),
> but it doesn't. If I try to import the first record there (changing just
> the RefName tag to match the SDMoM configuration), I get:
>
> ERROR calling expandXmlPayloadToDirjava.lang.IllegalArgumentException:
> Malformed refName for Authority (too few tokens)
>
> If I change the RefName to be a URN that points to a specific item in a
> vocabulary, the record seems to import ('<msg>SUCCESS</msg>') but it cannot
> be found in the CSpace web UI.
>
>
> Peter
> --
> Peter Murray
> Dev/Ops Lead and Project Manager
> Cherry Hill Company
>
>
>
> _______________________________________________
> Talk mailing list
> Talk@lists.collectionspace.org
>
> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
>
RL
Ray Lee
Tue, Oct 13, 2015 8:54 PM
Peter,
The examples are indeed out of date. In older versions of cspace
displayName was a top-level field, but now it is in the repeating group.
To follow up on Aron's reply, the field that connects a person to a
personauthority is persons_common:inAuthority. You must set that to the
csid of the personauthority in which the person item should reside (e.g.
Local vs. ULAN). That could explain why your record isn't appearing.
Ray
On Tue, Oct 13, 2015 at 1:45 PM, Aron Roberts aron@socrates.berkeley.edu
wrote:
I'm not quite sure what the difference between "Persons" and
"Personauthorities" is, but there are indeed two different service bindings
in my tenant bindings file
True. Personauthorities are authorities for (aka controlled lists of)
person terms. Persons are individual terms ("items") in those lists. The
former can be conceived of as a container or bucket, for holding terms
related to a particular category of persons, and the latter as those person
terms that fill it.
If a specific person authority doesn't yet exist, you'd need to create it
before you could add terms to it. In the default configuration of
CollectionSpace's demonstration 'core' and 'lifesci' tenants, at least one
sample person authority is created, as specified in config files in the
Application layer, via the process of visiting the URL for initializing
authorities. Your own tenant's authorities might differ from those in the
sample tenants.
It might be helpful to start out with a different import, in part because
this one doesn't introduce any of the potential complexities regarding
authorities and authority items. Does the Object Exit example in that
Imports Service Home document work when you try it, for starters?
https://wiki.collectionspace.org/display/DOC/Imports+Service+Home#ImportsServiceHome-ExampleRequest
That is, if you copy that XML snippet to a different file and use 'curl'
with a command pretty much identical to the one you used for
personauthorities?
On Tue, Oct 13, 2015 at 11:32 AM, Peter Murray pmurray@chillco.com
wrote:
Thank you, John -- I hope that will be helpful. One thing I noticed
right off the bat is the service
and type
attributes on the import
element:
<import service="Persons" type="Person" CSID="
75d9ceef-5ee5-4afe-93da-16cf34700427">
versus
<import seq="2" service="Personauthorities" type="Personauthority" CSID="
11111111-2222-3333-4444-123456789012">
I'm not quite sure what the difference between "Persons" and
"Personauthorities" is, but there are indeed two different service bindings
in my tenant bindings file (reading from
https://wiki.collectionspace.org/display/collectionspace/Imports+Service+Home#ImportsServiceHome-Howtofindtheserviceandtypevalues. --
which itself seems outdated because I didn't find the file where the
documentation says the file would be).
Another difference is in the record structure itself. I think you might
be on an older version of CSpace because in my persons_common schema the
Display Name is in a repeated group and has a slightly different element
name:
<persons_common:displayName>G. D. Baron [Ute]</persons_common:displayName
versus
<persons_common:personTermGroupList><persons_common:personTermGroup> <
persons_common:termDisplayName>Perf Test Person Auth ${docID}</
persons_common:termDisplayName></persons_common:personTermGroup></
persons_common:personTermGroupList>
I found the latter by looking at what a record looks like in its raw form
and comparing it with the documentation. Unfortunately, these changes
don't seem to be enough to get the record imported in the right form.
Peter
On Oct 13, 2015, at 11:47 AM, John B. LOWE jblowe@berkeley.edu wrote:
Peter,
There are a number of different "styles" or "dialects" of XML that will
work with the IMPORT service, it was interesting to see yours.
I had a quick look and I noticed your IMPORT document
(authority-request.xml) seems to have two instances of the <
personauthorities_common:shortIdentifier> element and I'm not sure how
that can possibly work.
For comparison, I created a gist with 2 Person Authority records and 2
Relations records of the sort we used for the Hearst Museum ("PAHMA") a few
years ago. (For reasons I won't get into here, the examples do not use the
"sparse payload" approach -- they have lots of empty fields.)
https://gist.github.com/jblowe/2a99906195667c27a725
But hopefully they will give you the flavor of "our" dialect of IMPORT
xml...
Good hunting!
John
On Tue, Oct 13, 2015 at 8:14 AM, Peter Murray pmurray@chillco.com
wrote:
I'm no further along, but I think I understand the pieces a little
better. I put the 'refName' element back in and changed the text of the
element to match what I think is our "Local Names" persons authority. I
haven't modified the instances of the person authority, so it is using the
one defined in base-authority-person.xml (
https://github.com/collectionspace/application/blob/v4.2/tomcat-main/src/main/resources/defaults/base-authority-person.xml#L42-L46).
My request document looks like this:
https://gist.github.com/dltj/cacd7dbf011e58d4aa33#file-authority-request-xml
The response from CSpace looks like this:
https://gist.github.com/dltj/cacd7dbf011e58d4aa33#file-post-body-xml
...and I went looking for the document referenced in the CSpace
response; it looks like this:
https://gist.github.com/dltj/cacd7dbf011e58d4aa33#file-11111111-2222-3333-4444-123456789012-document-xml
When I look for the record in the UI (
https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=11111111-2222-3333-4444-123456789012&vocab=person),
it is not there. The only thing in the logs continues to be these warnings
in cspace-services.log:
WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no
ID for document, won't add
org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@7192126e
WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no
ID for document, won't add
org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@78598d48
The 'catalina.out' file also has these two lines, along with log lines
that state the request directory and the document directory are being
created in $CATALINA_HOME/temp
I have a feeling that there is still something missing in the import
request document, but I can't put my finger on it.
Peter
On Oct 12, 2015, at 5:52 PM, Aron Roberts aron@socrates.berkeley.edu
wrote:
At a brief and superficial glance, it seems possible the refName
values, in that example on the Imports Service Home page might be obsolete.
The RefName page (https://wiki.collectionspace.org/display/DOC/RefName)
gives this example, for importing a person authority record:
urn:cspace:core.collectionspace.org:personauthorities:name(localPersonVocabulary)'Local
Person Vocabulary'
Note that unlike the example on the Imports Service Home page, that
example includes a 'name' component. (As well, the URL in this example also
reflects the tenant domain name, which is current practice, IIRC.) Contrast
the (presumably correct) example above with this one, from the imports page:
urn:cspace:collectionspace.org:Personauthorities(perfTestPersons)'Perf
Test Person Auth'
Perhaps try putting back the "<personauthorities_common:refName>"
element and using the RefName page's example (the first one above) -
tweaked as needed to reflect the Museum of Man's values - and see if the
import works?
This might or might not be relevant, but it's what first comes to mind.
On Mon, Oct 12, 2015 at 1:19 PM, Peter Murray pmurray@chillco.com
wrote:
I think I've gotten all of the CSpace configuration and UI changes
behind me. Just a few things left to clean up. I'm concentrating on data
loading now. I figured it would be best to get started with the example in
Imports Service Home
at the "Example Request" heading. I saved the XML for the persons
authority records to a file and ran the curl command
:
$ curl -X POST https://cspace.vagrant/cspace-services/imports
-i -u admin@museumofman.org:Administrator
-H "Content-Type: application/xml"
-T authority-request.xtml
Initially the error response I got back said "Could not process import
payload. Check XML markup for not-well-formed errors, elements not matching
import schema, etc." and this was logged on the cspace-services.log file:
ERROR [...]
[org.collectionspace.services.imports.TemplateExpander:492] ERROR calling
expandXmlPayloadToDirjava.lang.IllegalArgumentException: Malformed refName
for Authority (too few tokens)
So I removed the "<personauthorities_common:refName>" element in the
XML file and tried again. The response I got back (with prettified XML)
was:
HTTP/1.1 100 Continue
HTTP/1.1 200 OK
Date: Mon, 12 Oct 2015 20:05:02 GMT
Server: Apache-Coyote/1.1
Strict-Transport-Security: max-age=15768000
Content-Type: application/xml
Content-Length: 998
Set-Cookie: JSESSIONID=9EB6F3E6A8679B82E55B8E742CA331E9;
Path=/cspace-services/; HttpOnly
Vary: Accept-Encoding
<?xml version="1.0" encoding="UTF-8"?>
<import>
<msg>SUCCESS</msg>
<importedRecords>
<importedRecord>
<doctype>Personauthority</doctype>
<csid>c955a218-6fea-44bd-9dfe-1e7804be7ac5</csid>
</importedRecord>
<importedRecord>
<doctype>Personauthority</doctype>
<csid>11111111-2222-3333-4444-123456789012</csid>
</importedRecord>
</importedRecords>
<status>Success</status>
<totalRecordsImported>2</totalRecordsImported>
<numRecordsImportedByDocType>
<numRecordsImported>
<docType>Personauthority</docType>
<numRecords>2</numRecords>
</numRecordsImported>
</numRecordsImportedByDocType>
<report>READ:
/home/vagrant/cspace-tomcat/apache-tomcat-7.0.57/temp/imports-2086091545258611644/Personauthorities/11111111-2222-3333-4444-123456789012/document.xml/Personauthorities/11111111-2222-3333-4444-123456789012READ:
/home/vagrant/cspace-tomcat/apache-tomcat-7.0.57/temp/imports-2086091545258611644/Personauthorities/c955a218-6fea-44bd-9dfe-1e7804be7ac5/document.xml/Personauthorities/c955a218-6fea-44bd-9dfe-1e7804be7ac5</report>
</import>
...which looks like a successful import, BUT this is in
cspace-services.log:
WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no
ID for document, won't add
org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@74ae85f4
WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no
ID for document, won't add
org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@3f4d7382
...AND the document doesn't seem to be in the database. Based on the
csid
I would expect these URLs to work:
https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=c955a218-6fea-44bd-9dfe-1e7804be7ac5&vocab=person
https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=11111111-2222-3333-4444-123456789012&vocab=person
...because the documents can't be found (also from cspace-services.log):
ERROR [...]
[org.collectionspace.services.nuxeo.client.java.RepositoryJavaClientImpl:1303]
Could not find document with CSID=c955a218-6fea-44bd-9dfe-1e7804be7ac5.
Caught exception:Failed to get document
/sdmom-domain/Workspaces/Persons/c955a218-6fea-44bd-9dfe-1e7804be7ac5
ERROR [...]
[org.collectionspace.services.nuxeo.client.java.RepositoryJavaClientImpl:1303]
Could not find document with CSID=11111111-2222-3333-4444-123456789012.
Caught exception:Failed to get document
/sdmom-domain/Workspaces/Persons/11111111-2222-3333-4444-123456789012
... and the records don't show up in a search. I feel like I'm missing
something here, but I can't quite put my finger on it. Suggestions?
Peter
Peter,
The examples are indeed out of date. In older versions of cspace
displayName was a top-level field, but now it is in the repeating group.
To follow up on Aron's reply, the field that connects a person to a
personauthority is persons_common:inAuthority. You must set that to the
csid of the personauthority in which the person item should reside (e.g.
Local vs. ULAN). That could explain why your record isn't appearing.
Ray
On Tue, Oct 13, 2015 at 1:45 PM, Aron Roberts <aron@socrates.berkeley.edu>
wrote:
> Peter writes:
> > I'm not quite sure what the difference between "Persons" and
> "Personauthorities" is, but there are indeed two different service bindings
> in my tenant bindings file
>
> True. Personauthorities are authorities for (aka controlled lists of)
> person terms. Persons are individual terms ("items") in those lists. The
> former can be conceived of as a container or bucket, for holding terms
> related to a particular category of persons, and the latter as those person
> terms that fill it.
>
> If a specific person authority doesn't yet exist, you'd need to create it
> before you could add terms to it. In the default configuration of
> CollectionSpace's demonstration 'core' and 'lifesci' tenants, at least one
> sample person authority is created, as specified in config files in the
> Application layer, via the process of visiting the URL for initializing
> authorities. Your own tenant's authorities might differ from those in the
> sample tenants.
>
> It might be helpful to start out with a different import, in part because
> this one doesn't introduce any of the potential complexities regarding
> authorities and authority items. Does the Object Exit example in that
> Imports Service Home document work when you try it, for starters?
>
>
> https://wiki.collectionspace.org/display/DOC/Imports+Service+Home#ImportsServiceHome-ExampleRequest
>
> That is, if you copy that XML snippet to a different file and use 'curl'
> with a command pretty much identical to the one you used for
> personauthorities?
>
>
>
> On Tue, Oct 13, 2015 at 11:32 AM, Peter Murray <pmurray@chillco.com>
> wrote:
>
>> Thank you, John -- I hope that will be helpful. One thing I noticed
>> right off the bat is the `service` and `type` attributes on the `import`
>> element:
>>
>> <import service="Persons" type="Person" CSID="
>> 75d9ceef-5ee5-4afe-93da-16cf34700427">
>>
>> versus
>>
>> <import seq="2" service="Personauthorities" type="Personauthority" CSID="
>> 11111111-2222-3333-4444-123456789012">
>> I'm not quite sure what the difference between "Persons" and
>> "Personauthorities" is, but there are indeed two different service bindings
>> in my tenant bindings file (reading from
>> https://wiki.collectionspace.org/display/collectionspace/Imports+Service+Home#ImportsServiceHome-Howtofindtheserviceandtypevalues. --
>> which itself seems outdated because I didn't find the file where the
>> documentation says the file would be).
>>
>> Another difference is in the record structure itself. I think you might
>> be on an older version of CSpace because in my persons_common schema the
>> Display Name is in a repeated group and has a slightly different element
>> name:
>>
>> <persons_common:displayName>G. D. Baron [Ute]</persons_common:displayName
>> >
>>
>> versus
>>
>>
>> <persons_common:personTermGroupList><persons_common:personTermGroup> <
>> persons_common:termDisplayName>Perf Test Person Auth ${docID}</
>> persons_common:termDisplayName></persons_common:personTermGroup></
>> persons_common:personTermGroupList>
>> I found the latter by looking at what a record looks like in its raw form
>> and comparing it with the documentation. Unfortunately, these changes
>> don't seem to be enough to get the record imported in the right form.
>>
>>
>> Peter
>>
>>
>> On Oct 13, 2015, at 11:47 AM, John B. LOWE <jblowe@berkeley.edu> wrote:
>>
>> Peter,
>>
>> There are a number of different "styles" or "dialects" of XML that will
>> work with the IMPORT service, it was interesting to see yours.
>>
>> I had a quick look and I noticed your IMPORT document
>> (authority-request.xml) seems to have two instances of the <
>> personauthorities_common:shortIdentifier> element and I'm not sure how
>> that can possibly work.
>>
>> For comparison, I created a gist with 2 Person Authority records and 2
>> Relations records of the sort we used for the Hearst Museum ("PAHMA") a few
>> years ago. (For reasons I won't get into here, the examples do not use the
>> "sparse payload" approach -- they have lots of empty fields.)
>>
>> https://gist.github.com/jblowe/2a99906195667c27a725
>>
>> But hopefully they will give you the flavor of "our" dialect of IMPORT
>> xml...
>>
>> Good hunting!
>>
>> John
>>
>> On Tue, Oct 13, 2015 at 8:14 AM, Peter Murray <pmurray@chillco.com>
>> wrote:
>>
>>> I'm no further along, but I think I understand the pieces a little
>>> better. I put the 'refName' element back in and changed the text of the
>>> element to match what I think is our "Local Names" persons authority. I
>>> haven't modified the instances of the person authority, so it is using the
>>> one defined in base-authority-person.xml (
>>> https://github.com/collectionspace/application/blob/v4.2/tomcat-main/src/main/resources/defaults/base-authority-person.xml#L42-L46).
>>> My request document looks like this:
>>>
>>>
>>> https://gist.github.com/dltj/cacd7dbf011e58d4aa33#file-authority-request-xml
>>>
>>> The response from CSpace looks like this:
>>>
>>> https://gist.github.com/dltj/cacd7dbf011e58d4aa33#file-post-body-xml
>>>
>>> ...and I went looking for the document referenced in the CSpace
>>> response; it looks like this:
>>>
>>>
>>> https://gist.github.com/dltj/cacd7dbf011e58d4aa33#file-11111111-2222-3333-4444-123456789012-document-xml
>>>
>>> When I look for the record in the UI (
>>> https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=11111111-2222-3333-4444-123456789012&vocab=person),
>>> it is not there. The only thing in the logs continues to be these warnings
>>> in cspace-services.log:
>>>
>>> WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no
>>> ID for document, won't add
>>> org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@7192126e
>>> WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no
>>> ID for document, won't add
>>> org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@78598d48
>>>
>>> The 'catalina.out' file also has these two lines, along with log lines
>>> that state the request directory and the document directory are being
>>> created in $CATALINA_HOME/temp
>>>
>>> I have a feeling that there is still something missing in the import
>>> request document, but I can't put my finger on it.
>>>
>>>
>>> Peter
>>>
>>> On Oct 12, 2015, at 5:52 PM, Aron Roberts <aron@socrates.berkeley.edu>
>>> wrote:
>>>
>>> At a brief and superficial glance, it seems possible the refName
>>> values, in that example on the Imports Service Home page might be obsolete.
>>>
>>> The RefName page (https://wiki.collectionspace.org/display/DOC/RefName)
>>> gives this example, for importing a person authority record:
>>>
>>> urn:cspace:core.collectionspace.org:personauthorities:name(localPersonVocabulary)'Local
>>> Person Vocabulary'
>>>
>>> Note that unlike the example on the Imports Service Home page, that
>>> example includes a 'name' component. (As well, the URL in this example also
>>> reflects the tenant domain name, which is current practice, IIRC.) Contrast
>>> the (presumably correct) example above with this one, from the imports page:
>>>
>>> urn:cspace:collectionspace.org:Personauthorities(perfTestPersons)'Perf
>>> Test Person Auth'
>>>
>>> Perhaps try putting back the "<personauthorities_common:refName>"
>>> element and using the RefName page's example (the first one above) -
>>> tweaked as needed to reflect the Museum of Man's values - and see if the
>>> import works?
>>>
>>> This might or might not be relevant, but it's what first comes to mind.
>>>
>>> On Mon, Oct 12, 2015 at 1:19 PM, Peter Murray <pmurray@chillco.com>
>>> wrote:
>>>
>>>> I think I've gotten all of the CSpace configuration and UI changes
>>>> behind me. Just a few things left to clean up. I'm concentrating on data
>>>> loading now. I figured it would be best to get started with the example in
>>>> [Imports Service Home](
>>>> https://wiki.collectionspace.org/display/collectionspace/Imports+Service+Home)
>>>> at the "Example Request" heading. I saved the XML for the persons
>>>> authority records to a file and ran the `curl command`:
>>>>
>>>> $ curl -X POST https://cspace.vagrant/cspace-services/imports \
>>>> -i -u admin@museumofman.org:Administrator \
>>>> -H "Content-Type: application/xml" \
>>>> -T authority-request.xtml
>>>>
>>>> Initially the error response I got back said "Could not process import
>>>> payload. Check XML markup for not-well-formed errors, elements not matching
>>>> import schema, etc." and this was logged on the cspace-services.log file:
>>>>
>>>> ERROR [...]
>>>> [org.collectionspace.services.imports.TemplateExpander:492] ERROR calling
>>>> expandXmlPayloadToDirjava.lang.IllegalArgumentException: Malformed refName
>>>> for Authority (too few tokens)
>>>>
>>>> So I removed the "<personauthorities_common:refName>" element in the
>>>> XML file and tried again. The response I got back (with prettified XML)
>>>> was:
>>>>
>>>> HTTP/1.1 100 Continue
>>>>
>>>> HTTP/1.1 200 OK
>>>> Date: Mon, 12 Oct 2015 20:05:02 GMT
>>>> Server: Apache-Coyote/1.1
>>>> Strict-Transport-Security: max-age=15768000
>>>> Content-Type: application/xml
>>>> Content-Length: 998
>>>> Set-Cookie: JSESSIONID=9EB6F3E6A8679B82E55B8E742CA331E9;
>>>> Path=/cspace-services/; HttpOnly
>>>> Vary: Accept-Encoding
>>>>
>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>> <import>
>>>> <msg>SUCCESS</msg>
>>>> <importedRecords>
>>>> <importedRecord>
>>>> <doctype>Personauthority</doctype>
>>>> <csid>c955a218-6fea-44bd-9dfe-1e7804be7ac5</csid>
>>>> </importedRecord>
>>>> <importedRecord>
>>>> <doctype>Personauthority</doctype>
>>>> <csid>11111111-2222-3333-4444-123456789012</csid>
>>>> </importedRecord>
>>>> </importedRecords>
>>>> <status>Success</status>
>>>> <totalRecordsImported>2</totalRecordsImported>
>>>> <numRecordsImportedByDocType>
>>>> <numRecordsImported>
>>>> <docType>Personauthority</docType>
>>>> <numRecords>2</numRecords>
>>>> </numRecordsImported>
>>>> </numRecordsImportedByDocType>
>>>> <report>READ:
>>>> /home/vagrant/cspace-tomcat/apache-tomcat-7.0.57/temp/imports-2086091545258611644/Personauthorities/11111111-2222-3333-4444-123456789012/document.xml/Personauthorities/11111111-2222-3333-4444-123456789012READ:
>>>> /home/vagrant/cspace-tomcat/apache-tomcat-7.0.57/temp/imports-2086091545258611644/Personauthorities/c955a218-6fea-44bd-9dfe-1e7804be7ac5/document.xml/Personauthorities/c955a218-6fea-44bd-9dfe-1e7804be7ac5</report>
>>>> </import>
>>>>
>>>>
>>>> ...which looks like a successful import, BUT this is in
>>>> cspace-services.log:
>>>>
>>>> WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no
>>>> ID for document, won't add
>>>> org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@74ae85f4
>>>> WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no
>>>> ID for document, won't add
>>>> org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@3f4d7382
>>>>
>>>>
>>>> ...AND the document doesn't seem to be in the database. Based on the
>>>> `csid` I would expect these URLs to work:
>>>>
>>>>
>>>> https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=c955a218-6fea-44bd-9dfe-1e7804be7ac5&vocab=person
>>>>
>>>> https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=11111111-2222-3333-4444-123456789012&vocab=person
>>>>
>>>> ...because the documents can't be found (also from cspace-services.log):
>>>>
>>>> ERROR [...]
>>>> [org.collectionspace.services.nuxeo.client.java.RepositoryJavaClientImpl:1303]
>>>> Could not find document with CSID=c955a218-6fea-44bd-9dfe-1e7804be7ac5.
>>>> Caught exception:Failed to get document
>>>> /sdmom-domain/Workspaces/Persons/c955a218-6fea-44bd-9dfe-1e7804be7ac5
>>>> ERROR [...]
>>>> [org.collectionspace.services.nuxeo.client.java.RepositoryJavaClientImpl:1303]
>>>> Could not find document with CSID=11111111-2222-3333-4444-123456789012.
>>>> Caught exception:Failed to get document
>>>> /sdmom-domain/Workspaces/Persons/11111111-2222-3333-4444-123456789012
>>>>
>>>>
>>>> ... and the records don't show up in a search. I feel like I'm missing
>>>> something here, but I can't quite put my finger on it. Suggestions?
>>>>
>>>>
>>>> Peter
>>>
>>>
>> --
>> Peter Murray
>> Dev/Ops Lead and Project Manager
>> Cherry Hill Company
>>
>>
>>
>>
>> _______________________________________________
>> Talk mailing list
>> Talk@lists.collectionspace.org
>>
>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
>>
>>
>
> _______________________________________________
> Talk mailing list
> Talk@lists.collectionspace.org
>
> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
>
>
JB
John B. LOWE
Tue, Oct 13, 2015 9:05 PM
Peter,
Yes, sorry, Ray and Aron picked up on my out-of-date example, apologies for
the confusion.
But perhaps it has teased out some of the things that are needed to make
your stuff work, in which case it might still be called "useful" :-/
John
On Tue, Oct 13, 2015 at 1:54 PM, Ray Lee rhlee@berkeley.edu wrote:
Peter,
The examples are indeed out of date. In older versions of cspace
displayName was a top-level field, but now it is in the repeating group.
To follow up on Aron's reply, the field that connects a person to a
personauthority is persons_common:inAuthority. You must set that to the
csid of the personauthority in which the person item should reside (e.g.
Local vs. ULAN). That could explain why your record isn't appearing.
Ray
On Tue, Oct 13, 2015 at 1:45 PM, Aron Roberts aron@socrates.berkeley.edu
wrote:
I'm not quite sure what the difference between "Persons" and
"Personauthorities" is, but there are indeed two different service bindings
in my tenant bindings file
True. Personauthorities are authorities for (aka controlled lists of)
person terms. Persons are individual terms ("items") in those lists. The
former can be conceived of as a container or bucket, for holding terms
related to a particular category of persons, and the latter as those person
terms that fill it.
If a specific person authority doesn't yet exist, you'd need to create it
before you could add terms to it. In the default configuration of
CollectionSpace's demonstration 'core' and 'lifesci' tenants, at least one
sample person authority is created, as specified in config files in the
Application layer, via the process of visiting the URL for initializing
authorities. Your own tenant's authorities might differ from those in the
sample tenants.
It might be helpful to start out with a different import, in part because
this one doesn't introduce any of the potential complexities regarding
authorities and authority items. Does the Object Exit example in that
Imports Service Home document work when you try it, for starters?
https://wiki.collectionspace.org/display/DOC/Imports+Service+Home#ImportsServiceHome-ExampleRequest
That is, if you copy that XML snippet to a different file and use 'curl'
with a command pretty much identical to the one you used for
personauthorities?
On Tue, Oct 13, 2015 at 11:32 AM, Peter Murray pmurray@chillco.com
wrote:
Thank you, John -- I hope that will be helpful. One thing I noticed
right off the bat is the service
and type
attributes on the import
element:
<import service="Persons" type="Person" CSID="
75d9ceef-5ee5-4afe-93da-16cf34700427">
versus
<import seq="2" service="Personauthorities" type="Personauthority" CSID=
"11111111-2222-3333-4444-123456789012">
I'm not quite sure what the difference between "Persons" and
"Personauthorities" is, but there are indeed two different service bindings
in my tenant bindings file (reading from
https://wiki.collectionspace.org/display/collectionspace/Imports+Service+Home#ImportsServiceHome-Howtofindtheserviceandtypevalues. --
which itself seems outdated because I didn't find the file where the
documentation says the file would be).
Another difference is in the record structure itself. I think you might
be on an older version of CSpace because in my persons_common schema the
Display Name is in a repeated group and has a slightly different element
name:
<persons_common:displayName>G. D. Baron [Ute]</persons_common:
displayName>
versus
<persons_common:personTermGroupList><persons_common:personTermGroup> <
persons_common:termDisplayName>Perf Test Person Auth ${docID}</
persons_common:termDisplayName></persons_common:personTermGroup></
persons_common:personTermGroupList>
I found the latter by looking at what a record looks like in its raw
form and comparing it with the documentation. Unfortunately, these changes
don't seem to be enough to get the record imported in the right form.
Peter
On Oct 13, 2015, at 11:47 AM, John B. LOWE jblowe@berkeley.edu wrote:
Peter,
There are a number of different "styles" or "dialects" of XML that will
work with the IMPORT service, it was interesting to see yours.
I had a quick look and I noticed your IMPORT document
(authority-request.xml) seems to have two instances of the <
personauthorities_common:shortIdentifier> element and I'm not sure how
that can possibly work.
For comparison, I created a gist with 2 Person Authority records and 2
Relations records of the sort we used for the Hearst Museum ("PAHMA") a few
years ago. (For reasons I won't get into here, the examples do not use the
"sparse payload" approach -- they have lots of empty fields.)
https://gist.github.com/jblowe/2a99906195667c27a725
But hopefully they will give you the flavor of "our" dialect of IMPORT
xml...
Good hunting!
John
On Tue, Oct 13, 2015 at 8:14 AM, Peter Murray pmurray@chillco.com
wrote:
I'm no further along, but I think I understand the pieces a little
better. I put the 'refName' element back in and changed the text of the
element to match what I think is our "Local Names" persons authority. I
haven't modified the instances of the person authority, so it is using the
one defined in base-authority-person.xml (
https://github.com/collectionspace/application/blob/v4.2/tomcat-main/src/main/resources/defaults/base-authority-person.xml#L42-L46).
My request document looks like this:
https://gist.github.com/dltj/cacd7dbf011e58d4aa33#file-authority-request-xml
The response from CSpace looks like this:
https://gist.github.com/dltj/cacd7dbf011e58d4aa33#file-post-body-xml
...and I went looking for the document referenced in the CSpace
response; it looks like this:
https://gist.github.com/dltj/cacd7dbf011e58d4aa33#file-11111111-2222-3333-4444-123456789012-document-xml
When I look for the record in the UI (
https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=11111111-2222-3333-4444-123456789012&vocab=person),
it is not there. The only thing in the logs continues to be these warnings
in cspace-services.log:
WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no
ID for document, won't add
org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@7192126e
WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no
ID for document, won't add
org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@78598d48
The 'catalina.out' file also has these two lines, along with log lines
that state the request directory and the document directory are being
created in $CATALINA_HOME/temp
I have a feeling that there is still something missing in the import
request document, but I can't put my finger on it.
Peter
On Oct 12, 2015, at 5:52 PM, Aron Roberts aron@socrates.berkeley.edu
wrote:
At a brief and superficial glance, it seems possible the refName
values, in that example on the Imports Service Home page might be obsolete.
The RefName page (
https://wiki.collectionspace.org/display/DOC/RefName) gives this
example, for importing a person authority record:
urn:cspace:core.collectionspace.org:personauthorities:name(localPersonVocabulary)'Local
Person Vocabulary'
Note that unlike the example on the Imports Service Home page, that
example includes a 'name' component. (As well, the URL in this example also
reflects the tenant domain name, which is current practice, IIRC.) Contrast
the (presumably correct) example above with this one, from the imports page:
urn:cspace:collectionspace.org:Personauthorities(perfTestPersons)'Perf
Test Person Auth'
Perhaps try putting back the "<personauthorities_common:refName>"
element and using the RefName page's example (the first one above) -
tweaked as needed to reflect the Museum of Man's values - and see if the
import works?
This might or might not be relevant, but it's what first comes to
mind.
On Mon, Oct 12, 2015 at 1:19 PM, Peter Murray pmurray@chillco.com
wrote:
I think I've gotten all of the CSpace configuration and UI changes
behind me. Just a few things left to clean up. I'm concentrating on data
loading now. I figured it would be best to get started with the example in
Imports Service Home
at the "Example Request" heading. I saved the XML for the persons
authority records to a file and ran the curl command
:
$ curl -X POST https://cspace.vagrant/cspace-services/imports
-i -u admin@museumofman.org:Administrator
-H "Content-Type: application/xml"
-T authority-request.xtml
Initially the error response I got back said "Could not process import
payload. Check XML markup for not-well-formed errors, elements not matching
import schema, etc." and this was logged on the cspace-services.log file:
ERROR [...]
[org.collectionspace.services.imports.TemplateExpander:492] ERROR calling
expandXmlPayloadToDirjava.lang.IllegalArgumentException: Malformed refName
for Authority (too few tokens)
So I removed the "<personauthorities_common:refName>" element in the
XML file and tried again. The response I got back (with prettified XML)
was:
HTTP/1.1 100 Continue
HTTP/1.1 200 OK
Date: Mon, 12 Oct 2015 20:05:02 GMT
Server: Apache-Coyote/1.1
Strict-Transport-Security: max-age=15768000
Content-Type: application/xml
Content-Length: 998
Set-Cookie: JSESSIONID=9EB6F3E6A8679B82E55B8E742CA331E9;
Path=/cspace-services/; HttpOnly
Vary: Accept-Encoding
<?xml version="1.0" encoding="UTF-8"?>
<import>
<msg>SUCCESS</msg>
<importedRecords>
<importedRecord>
<doctype>Personauthority</doctype>
<csid>c955a218-6fea-44bd-9dfe-1e7804be7ac5</csid>
</importedRecord>
<importedRecord>
<doctype>Personauthority</doctype>
<csid>11111111-2222-3333-4444-123456789012</csid>
</importedRecord>
</importedRecords>
<status>Success</status>
<totalRecordsImported>2</totalRecordsImported>
<numRecordsImportedByDocType>
<numRecordsImported>
<docType>Personauthority</docType>
<numRecords>2</numRecords>
</numRecordsImported>
</numRecordsImportedByDocType>
<report>READ:
/home/vagrant/cspace-tomcat/apache-tomcat-7.0.57/temp/imports-2086091545258611644/Personauthorities/11111111-2222-3333-4444-123456789012/document.xml/Personauthorities/11111111-2222-3333-4444-123456789012READ:
/home/vagrant/cspace-tomcat/apache-tomcat-7.0.57/temp/imports-2086091545258611644/Personauthorities/c955a218-6fea-44bd-9dfe-1e7804be7ac5/document.xml/Personauthorities/c955a218-6fea-44bd-9dfe-1e7804be7ac5</report>
</import>
...which looks like a successful import, BUT this is in
cspace-services.log:
WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no
ID for document, won't add
org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@74ae85f4
WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no
ID for document, won't add
org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@3f4d7382
...AND the document doesn't seem to be in the database. Based on the
csid
I would expect these URLs to work:
https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=c955a218-6fea-44bd-9dfe-1e7804be7ac5&vocab=person
https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=11111111-2222-3333-4444-123456789012&vocab=person
...because the documents can't be found (also from
cspace-services.log):
ERROR [...]
[org.collectionspace.services.nuxeo.client.java.RepositoryJavaClientImpl:1303]
Could not find document with CSID=c955a218-6fea-44bd-9dfe-1e7804be7ac5.
Caught exception:Failed to get document
/sdmom-domain/Workspaces/Persons/c955a218-6fea-44bd-9dfe-1e7804be7ac5
ERROR [...]
[org.collectionspace.services.nuxeo.client.java.RepositoryJavaClientImpl:1303]
Could not find document with CSID=11111111-2222-3333-4444-123456789012.
Caught exception:Failed to get document
/sdmom-domain/Workspaces/Persons/11111111-2222-3333-4444-123456789012
... and the records don't show up in a search. I feel like I'm
missing something here, but I can't quite put my finger on it. Suggestions?
Peter
Peter,
Yes, sorry, Ray and Aron picked up on my out-of-date example, apologies for
the confusion.
But perhaps it has teased out some of the things that are needed to make
your stuff work, in which case it might still be called "useful" :-/
John
On Tue, Oct 13, 2015 at 1:54 PM, Ray Lee <rhlee@berkeley.edu> wrote:
> Peter,
> The examples are indeed out of date. In older versions of cspace
> displayName was a top-level field, but now it is in the repeating group.
>
> To follow up on Aron's reply, the field that connects a person to a
> personauthority is persons_common:inAuthority. You must set that to the
> csid of the personauthority in which the person item should reside (e.g.
> Local vs. ULAN). That could explain why your record isn't appearing.
>
> Ray
>
>
>
> On Tue, Oct 13, 2015 at 1:45 PM, Aron Roberts <aron@socrates.berkeley.edu>
> wrote:
>
>> Peter writes:
>> > I'm not quite sure what the difference between "Persons" and
>> "Personauthorities" is, but there are indeed two different service bindings
>> in my tenant bindings file
>>
>> True. Personauthorities are authorities for (aka controlled lists of)
>> person terms. Persons are individual terms ("items") in those lists. The
>> former can be conceived of as a container or bucket, for holding terms
>> related to a particular category of persons, and the latter as those person
>> terms that fill it.
>>
>> If a specific person authority doesn't yet exist, you'd need to create it
>> before you could add terms to it. In the default configuration of
>> CollectionSpace's demonstration 'core' and 'lifesci' tenants, at least one
>> sample person authority is created, as specified in config files in the
>> Application layer, via the process of visiting the URL for initializing
>> authorities. Your own tenant's authorities might differ from those in the
>> sample tenants.
>>
>> It might be helpful to start out with a different import, in part because
>> this one doesn't introduce any of the potential complexities regarding
>> authorities and authority items. Does the Object Exit example in that
>> Imports Service Home document work when you try it, for starters?
>>
>>
>> https://wiki.collectionspace.org/display/DOC/Imports+Service+Home#ImportsServiceHome-ExampleRequest
>>
>> That is, if you copy that XML snippet to a different file and use 'curl'
>> with a command pretty much identical to the one you used for
>> personauthorities?
>>
>>
>>
>> On Tue, Oct 13, 2015 at 11:32 AM, Peter Murray <pmurray@chillco.com>
>> wrote:
>>
>>> Thank you, John -- I hope that will be helpful. One thing I noticed
>>> right off the bat is the `service` and `type` attributes on the `import`
>>> element:
>>>
>>> <import service="Persons" type="Person" CSID="
>>> 75d9ceef-5ee5-4afe-93da-16cf34700427">
>>>
>>> versus
>>>
>>> <import seq="2" service="Personauthorities" type="Personauthority" CSID=
>>> "11111111-2222-3333-4444-123456789012">
>>> I'm not quite sure what the difference between "Persons" and
>>> "Personauthorities" is, but there are indeed two different service bindings
>>> in my tenant bindings file (reading from
>>> https://wiki.collectionspace.org/display/collectionspace/Imports+Service+Home#ImportsServiceHome-Howtofindtheserviceandtypevalues. --
>>> which itself seems outdated because I didn't find the file where the
>>> documentation says the file would be).
>>>
>>> Another difference is in the record structure itself. I think you might
>>> be on an older version of CSpace because in my persons_common schema the
>>> Display Name is in a repeated group and has a slightly different element
>>> name:
>>>
>>> <persons_common:displayName>G. D. Baron [Ute]</persons_common:
>>> displayName>
>>>
>>> versus
>>>
>>>
>>> <persons_common:personTermGroupList><persons_common:personTermGroup> <
>>> persons_common:termDisplayName>Perf Test Person Auth ${docID}</
>>> persons_common:termDisplayName></persons_common:personTermGroup></
>>> persons_common:personTermGroupList>
>>> I found the latter by looking at what a record looks like in its raw
>>> form and comparing it with the documentation. Unfortunately, these changes
>>> don't seem to be enough to get the record imported in the right form.
>>>
>>>
>>> Peter
>>>
>>>
>>> On Oct 13, 2015, at 11:47 AM, John B. LOWE <jblowe@berkeley.edu> wrote:
>>>
>>> Peter,
>>>
>>> There are a number of different "styles" or "dialects" of XML that will
>>> work with the IMPORT service, it was interesting to see yours.
>>>
>>> I had a quick look and I noticed your IMPORT document
>>> (authority-request.xml) seems to have two instances of the <
>>> personauthorities_common:shortIdentifier> element and I'm not sure how
>>> that can possibly work.
>>>
>>> For comparison, I created a gist with 2 Person Authority records and 2
>>> Relations records of the sort we used for the Hearst Museum ("PAHMA") a few
>>> years ago. (For reasons I won't get into here, the examples do not use the
>>> "sparse payload" approach -- they have lots of empty fields.)
>>>
>>> https://gist.github.com/jblowe/2a99906195667c27a725
>>>
>>> But hopefully they will give you the flavor of "our" dialect of IMPORT
>>> xml...
>>>
>>> Good hunting!
>>>
>>> John
>>>
>>> On Tue, Oct 13, 2015 at 8:14 AM, Peter Murray <pmurray@chillco.com>
>>> wrote:
>>>
>>>> I'm no further along, but I think I understand the pieces a little
>>>> better. I put the 'refName' element back in and changed the text of the
>>>> element to match what I think is our "Local Names" persons authority. I
>>>> haven't modified the instances of the person authority, so it is using the
>>>> one defined in base-authority-person.xml (
>>>> https://github.com/collectionspace/application/blob/v4.2/tomcat-main/src/main/resources/defaults/base-authority-person.xml#L42-L46).
>>>> My request document looks like this:
>>>>
>>>>
>>>> https://gist.github.com/dltj/cacd7dbf011e58d4aa33#file-authority-request-xml
>>>>
>>>> The response from CSpace looks like this:
>>>>
>>>> https://gist.github.com/dltj/cacd7dbf011e58d4aa33#file-post-body-xml
>>>>
>>>> ...and I went looking for the document referenced in the CSpace
>>>> response; it looks like this:
>>>>
>>>>
>>>> https://gist.github.com/dltj/cacd7dbf011e58d4aa33#file-11111111-2222-3333-4444-123456789012-document-xml
>>>>
>>>> When I look for the record in the UI (
>>>> https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=11111111-2222-3333-4444-123456789012&vocab=person),
>>>> it is not there. The only thing in the logs continues to be these warnings
>>>> in cspace-services.log:
>>>>
>>>> WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no
>>>> ID for document, won't add
>>>> org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@7192126e
>>>> WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no
>>>> ID for document, won't add
>>>> org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@78598d48
>>>>
>>>> The 'catalina.out' file also has these two lines, along with log lines
>>>> that state the request directory and the document directory are being
>>>> created in $CATALINA_HOME/temp
>>>>
>>>> I have a feeling that there is still something missing in the import
>>>> request document, but I can't put my finger on it.
>>>>
>>>>
>>>> Peter
>>>>
>>>> On Oct 12, 2015, at 5:52 PM, Aron Roberts <aron@socrates.berkeley.edu>
>>>> wrote:
>>>>
>>>> At a brief and superficial glance, it seems possible the refName
>>>> values, in that example on the Imports Service Home page might be obsolete.
>>>>
>>>> The RefName page (
>>>> https://wiki.collectionspace.org/display/DOC/RefName) gives this
>>>> example, for importing a person authority record:
>>>>
>>>> urn:cspace:core.collectionspace.org:personauthorities:name(localPersonVocabulary)'Local
>>>> Person Vocabulary'
>>>>
>>>> Note that unlike the example on the Imports Service Home page, that
>>>> example includes a 'name' component. (As well, the URL in this example also
>>>> reflects the tenant domain name, which is current practice, IIRC.) Contrast
>>>> the (presumably correct) example above with this one, from the imports page:
>>>>
>>>> urn:cspace:collectionspace.org:Personauthorities(perfTestPersons)'Perf
>>>> Test Person Auth'
>>>>
>>>> Perhaps try putting back the "<personauthorities_common:refName>"
>>>> element and using the RefName page's example (the first one above) -
>>>> tweaked as needed to reflect the Museum of Man's values - and see if the
>>>> import works?
>>>>
>>>> This might or might not be relevant, but it's what first comes to
>>>> mind.
>>>>
>>>> On Mon, Oct 12, 2015 at 1:19 PM, Peter Murray <pmurray@chillco.com>
>>>> wrote:
>>>>
>>>>> I think I've gotten all of the CSpace configuration and UI changes
>>>>> behind me. Just a few things left to clean up. I'm concentrating on data
>>>>> loading now. I figured it would be best to get started with the example in
>>>>> [Imports Service Home](
>>>>> https://wiki.collectionspace.org/display/collectionspace/Imports+Service+Home)
>>>>> at the "Example Request" heading. I saved the XML for the persons
>>>>> authority records to a file and ran the `curl command`:
>>>>>
>>>>> $ curl -X POST https://cspace.vagrant/cspace-services/imports \
>>>>> -i -u admin@museumofman.org:Administrator \
>>>>> -H "Content-Type: application/xml" \
>>>>> -T authority-request.xtml
>>>>>
>>>>> Initially the error response I got back said "Could not process import
>>>>> payload. Check XML markup for not-well-formed errors, elements not matching
>>>>> import schema, etc." and this was logged on the cspace-services.log file:
>>>>>
>>>>> ERROR [...]
>>>>> [org.collectionspace.services.imports.TemplateExpander:492] ERROR calling
>>>>> expandXmlPayloadToDirjava.lang.IllegalArgumentException: Malformed refName
>>>>> for Authority (too few tokens)
>>>>>
>>>>> So I removed the "<personauthorities_common:refName>" element in the
>>>>> XML file and tried again. The response I got back (with prettified XML)
>>>>> was:
>>>>>
>>>>> HTTP/1.1 100 Continue
>>>>>
>>>>> HTTP/1.1 200 OK
>>>>> Date: Mon, 12 Oct 2015 20:05:02 GMT
>>>>> Server: Apache-Coyote/1.1
>>>>> Strict-Transport-Security: max-age=15768000
>>>>> Content-Type: application/xml
>>>>> Content-Length: 998
>>>>> Set-Cookie: JSESSIONID=9EB6F3E6A8679B82E55B8E742CA331E9;
>>>>> Path=/cspace-services/; HttpOnly
>>>>> Vary: Accept-Encoding
>>>>>
>>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>>> <import>
>>>>> <msg>SUCCESS</msg>
>>>>> <importedRecords>
>>>>> <importedRecord>
>>>>> <doctype>Personauthority</doctype>
>>>>> <csid>c955a218-6fea-44bd-9dfe-1e7804be7ac5</csid>
>>>>> </importedRecord>
>>>>> <importedRecord>
>>>>> <doctype>Personauthority</doctype>
>>>>> <csid>11111111-2222-3333-4444-123456789012</csid>
>>>>> </importedRecord>
>>>>> </importedRecords>
>>>>> <status>Success</status>
>>>>> <totalRecordsImported>2</totalRecordsImported>
>>>>> <numRecordsImportedByDocType>
>>>>> <numRecordsImported>
>>>>> <docType>Personauthority</docType>
>>>>> <numRecords>2</numRecords>
>>>>> </numRecordsImported>
>>>>> </numRecordsImportedByDocType>
>>>>> <report>READ:
>>>>> /home/vagrant/cspace-tomcat/apache-tomcat-7.0.57/temp/imports-2086091545258611644/Personauthorities/11111111-2222-3333-4444-123456789012/document.xml/Personauthorities/11111111-2222-3333-4444-123456789012READ:
>>>>> /home/vagrant/cspace-tomcat/apache-tomcat-7.0.57/temp/imports-2086091545258611644/Personauthorities/c955a218-6fea-44bd-9dfe-1e7804be7ac5/document.xml/Personauthorities/c955a218-6fea-44bd-9dfe-1e7804be7ac5</report>
>>>>> </import>
>>>>>
>>>>>
>>>>> ...which looks like a successful import, BUT this is in
>>>>> cspace-services.log:
>>>>>
>>>>> WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no
>>>>> ID for document, won't add
>>>>> org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@74ae85f4
>>>>> WARN [...] [org.nuxeo.ecm.core.io.impl.AbstractDocumentReader:57] no
>>>>> ID for document, won't add
>>>>> org.nuxeo.ecm.core.io.impl.ExportedDocumentImpl@3f4d7382
>>>>>
>>>>>
>>>>> ...AND the document doesn't seem to be in the database. Based on the
>>>>> `csid` I would expect these URLs to work:
>>>>>
>>>>>
>>>>> https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=c955a218-6fea-44bd-9dfe-1e7804be7ac5&vocab=person
>>>>>
>>>>> https://cspace.vagrant/collectionspace/ui/sdmom/html/person.html?csid=11111111-2222-3333-4444-123456789012&vocab=person
>>>>>
>>>>> ...because the documents can't be found (also from
>>>>> cspace-services.log):
>>>>>
>>>>> ERROR [...]
>>>>> [org.collectionspace.services.nuxeo.client.java.RepositoryJavaClientImpl:1303]
>>>>> Could not find document with CSID=c955a218-6fea-44bd-9dfe-1e7804be7ac5.
>>>>> Caught exception:Failed to get document
>>>>> /sdmom-domain/Workspaces/Persons/c955a218-6fea-44bd-9dfe-1e7804be7ac5
>>>>> ERROR [...]
>>>>> [org.collectionspace.services.nuxeo.client.java.RepositoryJavaClientImpl:1303]
>>>>> Could not find document with CSID=11111111-2222-3333-4444-123456789012.
>>>>> Caught exception:Failed to get document
>>>>> /sdmom-domain/Workspaces/Persons/11111111-2222-3333-4444-123456789012
>>>>>
>>>>>
>>>>> ... and the records don't show up in a search. I feel like I'm
>>>>> missing something here, but I can't quite put my finger on it. Suggestions?
>>>>>
>>>>>
>>>>> Peter
>>>>
>>>>
>>> --
>>> Peter Murray
>>> Dev/Ops Lead and Project Manager
>>> Cherry Hill Company
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Talk mailing list
>>> Talk@lists.collectionspace.org
>>>
>>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
>>>
>>>
>>
>> _______________________________________________
>> Talk mailing list
>> Talk@lists.collectionspace.org
>>
>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
>>
>>
>
> _______________________________________________
> Talk mailing list
> Talk@lists.collectionspace.org
>
> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
>
>