Some puzzles about TestRepositoryAndRegistry.groovy in xds tutorial

[刘铭]

Hello IPF Developer's

Recently, I have been studying the XDS tutorial project you wrote. When running the test cases, it works very well, but I have some doubts when understanding the ITI43 transaction, which is to retrieve the documents. For example, in this line of code def attachments = retrieveResponse.documents[0].dataHandler.dataSource.attachments, its function is to get the attachment objects from the response, but when I checked the definition of the DataSource class, I found that there is no Attachments property at all. How should I understand this situation?

I am recreating the test cases of the XDS tutorial project in Java, so I am stuck here and cannot proceed further. Please give me some suggestions, I really appreciate your help.

Best Regards

Ming

[Dmytro Rud]

Hi Ming

IPF SOAP components base on Apache CXF, and Apache CXF uses the class org.apache.cxf.attachment.LazyDataSource, where the field "attachments" is defined.

(You can start the unit test in debug mode and see this.)

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+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ipf-user/35607301-5eb6-4769-8396-3a302d80bce7n%40googlegroups.com.

[刘铭]

Thanks for your advice!!! I'm a new comer about Apache CXF, I'll try it ~

[刘铭]

Dear Dmytro

I start the unit test in debug mode and see the class org.apache.cxf.attachment.LazyDataSource .However, I have a question - is it impossible to retrieve the attachments from the RetrievedDocumentSet object in Java? This is because Groovy is a dynamic language and does not perform type checking, so it can dynamically look up the type at runtime. In the example, the DataHandler inside the RetrievedDocumentSet object has a DataSource of type LazyDataSource, which then has an attachments property.

But Java is a strongly-typed language, so you need to define the attachments type upfront, and then try to retrieve the attachments object from the retrieveResponse. However, it seems like you cannot access the attachments this way.

Is my understanding correct?

If I want to achieve the same functionality in Java, how should I write the code? Please give me some suggestions.







Best Regards
Ming

[Dmytro Rud]

You can retrieve document contents using document.getDataHandler().getInputStream(), independently from which implementation classes are being used.

To view this discussion on the web visit https://groups.google.com/d/msgid/ipf-user/8b218151-4fca-42f5-b17c-19fae67b69fcn%40googlegroups.com.

[刘铭]

InputStream inputStream = retrieveResponse.getDocuments().get(0).getDataHandler().getInputStream();
log.warn(IOUtils.toString(inputStream));

then output is a chain of AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

is that correctly ?

[Dmytro Rud]

Yes, for the test, because the test class LargeDataSource provides 70000 A's :-)

To view this discussion on the web visit https://groups.google.com/d/msgid/ipf-user/8d618d4a-a222-43e7-899e-f9f399a0b4b4n%40googlegroups.com.

[刘铭]

Thanks for your help :-)

[刘铭]

Dear Dmytro

Recently, I have been familiarizing myself with the XDS part of the IPF framework you developed. Through learning the XDS tutorial project, I found that I am not familiar with the Apache Camel technology and Groovy language you are using. So, when I develop XDS-related transactions in the future, can I use a pure Java approach and use web service technology? For example, for the ITI-41 transaction, can I implement the documentRepositoryProvideAndRegisterDocumentSetB method in the Iti41PortType interface, and write the specific registration and storage logic there? Is this technical route feasible? Because I am not very familiar with Apache Camel technology. What are the shortcomings of this implementation of the PortType interface approach? And compared to Apache Camel technology, which one has more advantages? Furthermore, if I use the PortType interface implementation technology, how should I configure and trigger the audit? (PS: The documentation only mentions using Apache Camel technology to configure the audit)

My audit configuration is as follows:

ipf:
atna:
audit-queue-class: org.openehealth.ipf.commons.audit.queue.LoggingAuditMessageQueue
auditEnabled: true

Thank you very much for your help.

Best Regards
Ming

[Dmytro Rud]

Hello Ming

Avoiding Groovy and writing everything in Java is not a problem at all.

Application development without Camel would be possible as well (see various JAX-WS tutorials in the internet), but in this case you would have to re-implement some Camel/IPF functionalities by yourself, like the audit trail you already mentioned.  

Best regards

Dmytro

To view this discussion on the web visit https://groups.google.com/d/msgid/ipf-user/fde702f3-0297-4b4e-a546-e801d4a1a05fn%40googlegroups.com.

[刘铭]

Hello Dmytro

Thank you very much for your suggestions. Recently, I have been studying the IPF framework in more depth, but during this process, I have some doubts. I hope you can help me clarify them. (PS: On the server side, I am using the features from the XDS tutorial as the registry and repository. My main doubts are in the consumer.)
Q1: I created a ProvideAndRegisterDocumentSet by imitating the code in SampleData.class, and I found that the associations inside are all of type HasMember. However, some materials I found suggest using AssociationType.SUBMIT_ASSOCIATION. So, when providing and registering documents, what AssociationType should be used between DocEntry and SubmissionSet? If I need to use SUBMIT_ASSOCIATION, how should I create it? When I simply tried to change the type to SUBMIT_ASSOCIATION, I encountered an error: MISSING_ASSOCIATION("Association specifies a targetObject: %s association, but it was not provided").

Q2: Similarly, when I followed the code in SampleData.class, I only created documents and submission sets without creating any associations. However, when I got to the ITI-42 transaction and printed the logs, I found that there was a relationship between the document and submission set in the request body, and their relationship was of type HasMember. I am not clear whether this relationship was created when transforming the ProvideAndRegisterDocumentSetRequest to RegisterDocumentSetRequest.

Q3: Based on the XDS tutorial project, how should I modify it to support basic operations such as appending, transforming, and replacing documents? Or have I misunderstood the endpoints in Iti4142RouteBuilder.groovy, and the XDS tutorial project already implements some operations for appending, transforming, and replacing documents?

Thank you very much for taking the time to answer my questions amidst your busy schedule. Best Regards
Ming

[Thomas Papke]

Hello Ming,

let me will join to that discussion. I have collected some answeres for you:

Q1:
Associaton types are "HAS_Member" for the most of the ihe XDS transactions as seen also in the Spec:
https://profiles.ihe.net/ITI/TF/Volume3/ch-4.1.html#4.1.2
Some profiles like XDS Metadata Update (ITI-57) use other types as well. The urn:ihe:iti:2010:AssociationType:SubmitAssociation you are referring to was used in the past by an (outdated) Metadata update profile version, i don't remember any profile using it now.

Q2:
The IPF Tests are using the "RegisterDocumentSet#supportiveBuilderWith" which perform some actions behind the scene for you (https://github.com/oehf/ipf/blob/master/commons/ihe/xds/src/main/java/org/openehealth/ipf/commons/ihe/xds/core/requests/builder/AbstractSubmissionRequestBuilder.java#L105). If you do not want to have this handling, simply use the "builderWith" instead of the "supportiveBuilderWith".

Q3:
The IHE spec describe the replace Scenario and requirements:
https://profiles.ihe.net/ITI/TF/Volume3/ch-4.2.html#4.2.2.2

Here an example from an XDS Registry project which illustrate the replacement activity that required from the XDS spec.
https://github.com/oehf/xds-registry-to-fhir/blob/main/src/main/java/org/openehealth/app/xdstofhir/registry/register/RegisterDocumentsProcessor.java#L84

(this project also illustrate the usage of certain IPF without groovy)

Best regards,

Thomas

[刘铭]

Hello Thomas

Thank you very much for your help. I will delve into the relevant code based on your suggestions. Without your assistance, I wouldn't be able to proceed with my next steps. 😊
Best regards,
Ming