Testing XDS Registry using XDS Toolkit : org.apache.cxf.interceptor.Fault

90 views
Skip to first unread message

Berg Therosen

unread,
Feb 18, 2017, 6:25:34 AM2/18/17
to ipf-user
Hi All, 


I am new IPF user. I am trying to test XDS Registry using XDS Toolkit. 
I have configured XDS Toolkit like in this image: 

I have received the following response (displayed in XDS Toolkit):
-----------
Section: FindDocuments/XDS Step: FindDocumentsbyObjectRef
Goals:
SOAP Fault: Unexpected element {urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0}AdhocQueryRequest found. Expected {urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0}SubmitObjectsRequest. (stepId=FindDocumentsbyObjectRef)
Message top level element must be AdhocQueryResponse found Fault instead (stepId=FindDocumentsbyObjectRef)
--------

This is content of exception on server side (IPF):
--------
org.apache.cxf.interceptor.Fault: Unexpected element {urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0}AdhocQueryRequest found.   Expected {urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0}SubmitObjectsRequest.
at org.apache.cxf.wsdl.interceptors.DocLiteralInInterceptor.validatePart(DocLiteralInInterceptor.java:281)
at org.apache.cxf.wsdl.interceptors.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:191)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:252)
at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234)
at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208)
at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160)
at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:180)
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:299)
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:218)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:274)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:198)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:108)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:522)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:349)
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:1110)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:785)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1425)
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)
---------

Any help will be appreciated,

Best regards

Dmytro Rud

unread,
Feb 18, 2017, 7:05:51 AM2/18/17
to ipf-...@googlegroups.com
Hi,

URLs must correspond to transactions.  Instead of 5 URLs of ITI-42 and 2 URLs of ITI-41, the list shall include URLs for ITI-42, ITI-61, ITI-18, ITI-57, ITI-51, ITI-43, ITI-41 (in the provided order).

Best regards
Dmytro

--
You received this message because you are subscribed to the Google Groups "ipf-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ipf-user+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Bod

unread,
Feb 19, 2017, 7:24:33 AM2/19/17
to ipf-user
Many thanks Mr. Dmytro,

I have succeeded in running some tests using XDS Toolkit, but I have for most of them the followings error:
(this is for example Test: 11897 - FindDocuments Stored Query, Section : Approved)

Message
Step
DocumentEntry(urn:uuid:67bc843a-95be-456d-9a22-a1606d3d24e4): lid attribute empty or missing XDSRegistryMetadataError DocumentEntry(urn:uuid:67bc843a-95be-456d-9a22-a1606d3d24e4): VersionInfo attribute missing XDSRegistryMetadataError DocumentEntry(urn:uuid:043ec15e-fcbd-4b4a-8f85-c07197356047): lid attribute empty or missing XDSRegistryMetadataError DocumentEntry(urn:uuid:043ec15e-fcbd-4b4a-8f85-c07197356047): VersionInfo attribute missing XDSRegistryMetadataError 

I have found this reply on XDS Toolkit group for a similar issue:

----------------------------
If you check OASIS ebRIM 3.0 section 2.5.1 RegistryObject Attribute Summary you will see that lid and VersionInfo are optional on write (submit) and required on read (query).

With ebRIM it is very dangerous to trust schema alone.  There are a lot of aspects of the spec that are conditionally required.  XML Schema is not capable of capturing this level of detail.

bill

On Wed, Jan 12, 2011 at 8:24 PM, <kde...@axolotl.com> wrote:
Hello, 

I used the XDS toolkit GUI to run the 'No Peer' Connectathon tests in advance of the Connectathon 2011. Specifically I am running the Registry Validations XDS.b_Registry_Do_This_First, XDS.b_Lifecycle and XDS.b_Registry_Folder_Handling. However some steps in all three tests fail due to a validation performed by the toolkit. 

The validation for the second step (query for registered document) of XDS.b_Registry_Do_This_First test fails with the messages: 

SubmissionSet (urn:uuid....): lid attribute empty or missing XDSRegistryMetadataError 
SubmissionSet (urn:uuid....): VersionInfo attribute empty or missing XDSRegistryMetadataError 
DocumentEntry (urn:uuid....): lid attribute empty or missing XDSRegistryMetadataError 
DocumentEntry (urn:uuid....): VersionInfo attribute empty or missing XDSRegistryMetadataError 

I see the additional fail messages in the certain steps of  XDS.b_Registry_Folder_Handling test: 

Folder (urn:uuid....): lid attribute empty or missing XDSRegistryMetadataError
 
Folder (urn:uuid....): VersionInfo attribute empty or missing XDSRegistryMetadataError 

However, I checked the schema for XDS.b (rim.xsd) and these referenced attributes are optional. Also, I was unable to find any additional requirement in the IHE ITI TF v7.0 which mentions that these attributes are required. Am I missing something or is the toolkit GUI requiring more than  what is needed? 

Dmytro Rud

unread,
Feb 19, 2017, 8:57:30 AM2/19/17
to ipf-...@googlegroups.com
Attributes DocumentEntry.logicalId (lid) and DocumentEntry.version (VersionInfo) are defined in the XDS Medatata Update Supplement (http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_XDS_Metadata_Update.pdf), sections 4.2.3.2.31 and 4.2.3.2.32.  They are optional in submissions, but required in query responses.  If you do not support metadata update, you can copy DocumentEntry.entryUUID into the attribute "lid" and use fixed value "1" for the attribute "version".

Best regards
Dmytro

--

Bod

unread,
Feb 20, 2017, 5:53:07 AM2/20/17
to ipf-user
Hi Dmytro,
I am sorry but i am totally lost inside IPF source code. Where I can do such changes ?

Bod

unread,
Feb 20, 2017, 6:03:12 AM2/20/17
to ipf-user
I have made this changes to 

// Put all document entries in the store
from('direct:storeDocEntriesFromRegister')
.splitEntries { it.req.documentEntries }
.processBody { it.entry.logicalUuid = it.entry.entryUuid }
.to('direct:store')

in Iti4142RouteBuilder.groovy

it worked for me but I am not sure if this is the right location for doing such changes ?

Dmytro Rud

unread,
Feb 20, 2017, 6:59:37 AM2/20/17
to ipf-...@googlegroups.com
Yes, this is the right location (for example, folder timestamps are updated in the route 'direct:storeFolders' in the same way).

Best regards
Dmytro

--
Reply all
Reply to author
Forward
0 new messages