krasserm / ipf Goto Github PK

Currently the FlowManager can be used only from Groovy routes. It would be great if we can use it from Java routes as well. Currently a lot of initialization happens in Flow_ProcessorDefinition classes for the correct working for flow management functionality. Just using Flow_Processor classes in Java routes doesn't seem to work.

Home community ID in ITI-18 Get* requests should be placed into and read from the XML attribute "home" instead of the "$homeCommunityId" ebXML slot --- this is prescribed by the IHE ITI FT, Vol. 2a, Sections 3.18.4.1.2.3.7.* as well as in the XCA Supplement.

ATNA auditing should be adapter appropriately.

When a HL7v2 producer with activated interactive message continuation support gets the last data fragment, it should automatically send a cancel message to the server --- simply to be polite. This feature is already implemented in Hl7v3-based components and controlled by the "autoCancel" endpoint URI parameter --- now should it be "backported" :) to HL7v2.

Even though the code indicates that only 100 flows are deleted in a loop, I got an memory-related exception (Derby 10.4.1.2):

org.springframework.jdbc.UncategorizedSQLException: Hibernate operation: could not execute query; uncategorized SQLException for SQL [select this_.C_
4968 ID as C1_0_0_, this_.C_ACK_COUNT_EXPECTED as C2_0_0_, this_.C_APPLICATION as C3_0_0_, this_.C_CREATION_TIME as C4_0_0_, this_.C_DERIVED_STATUS as C5_
4968 0_0_, this_.FLOW_MESSAGE_ID as FLOW9_0_0_, this_.C_PACKET as C6_0_0_, this_.C_REPLAY_COUNT as C7_0_0_, this_.C_REPLAY_TIME as C8_0_0_ from PLATFORM.T
4968 FLOW this where this_.C_CREATION_TIME<? and this_.C_APPLICATION=? order by this_.C_CREATION_TIME asc]; SQL state [XJ001]; error code [0]; Java exce
4968 ption: 'GC overhead limit exceeded: java.lang.OutOfMemoryError'.; nested exception is java.sql.SQLException: Java exception: 'GC overhead limit excee
4968 ded: java.lang.OutOfMemoryError'.
4969 at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:83)
4970 at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:80)
4971 at ....
org.openehealth.ipf.commons.flow.FlowManagerBase.purgeFlows(FlowManagerBase.java:100)
.....
4988 at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
4989 at $Proxy54.purgeFlows(Unknown Source)

In http://tim.oreilly.com/pub/a/onjava/2007/01/31/tuning-derby.html?page=1, it is stated that Derby does NOT provide something to restrict the result set like Oracle (where rownum< xxx) or MySQL (LIMIT xxx), so the restriction in Hibernate is useless and you have to work with scrollable result sets. The pattern described in the Hibernate docs is:

Session session = sessionFactory.openSession();
Transaction tx = session.beginTransaction();
Criteria query = session.createCriteria(myCriteria).setCacheMode(IGNORE).setFetchSize(200);
ScrollableResults results = query.scroll(ScrollMode.FORWARD_ONLY);
int count=0;
while ( results.next() ) {
Type result = (Type) results.get(0);
result.updateStuff(...);
if ( ++count % 100 == 0 ) {
//flush a batch of updates and release memory:
session.flush();
session.clear();
}
}

e.g. SegmentAdapter path is always ""

Tracking the path could allow validation processors include the exact error location of the validation error.

For example if there are multiple PID segments, and PID-5 is missing in the 1-st, and 5-th repetition of PID, the caller receives message like:
"Missing PID-5"
"Missing PID-5"
without the reference of the repetition. This is related to Issue #47

The IPF's HL7v2 DSL is now able to track path information. This data should be used to fill the "location" field of the Hl7v2Exception when a such exception is thrown (e. g. after failed message validation).

• Resolve maven plug-in dependencies
• Resolve all compile problems
• Resolve all test problems
• Update basic archetype
• Update wiki
• Do smoke tests, within Eclipse, in modules CDA, HL7 and HL7DSL

CustomModelClassFactory loads HL7 model extension classes via Class#forName(...)
To facilitate customizability, it should also provide the possibility to load HL7 model extension Groovy scripts using GroovyClassLoader#parseClass(...)

Can only reporoduce it on a MacBook Pro Snow Leopard with approx. every 3rd run

Until version 1.6.6, Quartz has a dependency to commons-collections 3.2, but fails to note this in its pom. If commons-collections 3.2 is not accidentally loaded by other modules, scheduling a Flow Purge triggers an error.
In commons-flow, depend on a recent quartz version (e.g. 1.8.3; note: groupId became org.quartz-scheduler) or explicitly depend on commons-collections 3.2.

Resolve issues with multiple registrations of CamelContext on MBeanServer and ActiveMQ waiting for locks on datastore

"Query for Existing Data" -- specification available under http://www.ihe.net/Technical_Framework/upload/IHE_PCC_Query_for_Existing_Data_QED_Supplement_TI_2008-08-22.pdf

see http://camel.apache.org/servicepool.html

For the issue described on https://groups.google.com/group/ipf-user/browse_thread/thread/e4dc776842fc39e5?hl=de the following solution is proposed: add the following method to SegmentAdapter.groovy:

void setObx5Type(String type, int desiredRepetitionsCount = 1) {
    if (! segment.getClass().name.endsWith('.OBX')) {
        throw new AdapterException('only OBX segments can be served by this method')
    }

    for (int i = 0; i < desiredRepetitionsCount - count(5); ++i) {
        nrp(5)
    }

    putAt(2, type)
    Varies.fixOBX5(target, target.message.parser.factory)
}

Make IPF's CustomModelClassFactoryConfigurer configurable to recursively delegate customModelClasses to its delegateFactory as long as the delegate is an instance of CustomModelClassFactory.

platform-camel/ihe/pixpdq/src/test/groovy/org/openehealth/ipf/platform/camel/ihe/pixpdq/iti21/TestIti21.groovy#testSSLFailure*() methods run under Windows, but fail under Linux (in Hudson). Temporarily @ignore'd.

• NakFactory should be the only place to map exception types to NAK messages. The code in MllpMarshallUtils should be moved to the BasicNakFactory. Btw, should not it be named ResponseFactory (it may create naks and acks)?

The following concerns the HL7v2ws components (and perhaps the rest of our Hl7v2.x based components):
Maybe we should allow configuration of hl7v2 endpoints with NakFactory to override the generation of error messages per endpoint instead of per component. With the option to configure the NAK factory in the endpoint, the route developer can override the mapping ExceptionType -> Error message in his/her custom NakFactory.

Comments are welcome.

SOAP Action and WS-Addressing action should be equal. This is not the case in the ITI-47 wsdl definition.

This issue is critical for using iti-47 with CXF 2.3.2 (comes with Camel 2.6.0).
Affected are all 2.2 milestones up to m5.

Automatically handle continuation intentions on both producer and consumer sides, as we already do in HL7 v2.

Due to addition of a TLS-aware sender, configuration of the framework is changed and is not backward compatible.

When

• IPF mapping services are activated, and
• an XML document is being built by means of Groovy markup builder, and
• a non-existent method of class String is being called,

then a MissingMethodException is thrown and handled by the Groovy markup builder in a special, but unfortunate way, which can lead to endless loops and, potentially, other problems.

The solution is to wrap the MissingMethodException generated by the mapper service into a RuntimeException.

...same as XDS and MLLP consumers are. Do not pass an instance to the create*() method, pass the class name or some kind of Factory instead.

When an IPF-based project needs some additional dependendencies, they should be compatible with the ones used by IPF --- e.g. the IPF uses spring-core while the project additionally needs spring-web. At the moment, the project's pom.xml must explicitly mention all versions numbers, and the project author must ensure that they are the same as in the IPF's root pom.xml. This issue relates to plugin dependencies as well (e.g. the gmaven plugin).

The possibility to reuse "dependencyManagement" and "pluginManagement" sections of IPF's root pom.xml in IPF-based projects would help to simplify the project author's life and to avoid potential errors.

Currently, when a distrubution ZIP of the IPF is created, all JARs are placed into two flat sub-folders --- "dist" for IPF JARs and "lib" for dependencies' ones. Would it be not better to "mirror" the Maven2 repository structure instead? In particular, this would give the possibility to create an off-line Maven2 build environment by simply copying the provided structure into ~/.m2/repository.

Your opinions are highly appreciated.

Although it's possible now to compile custom HL7 structures at runtime, creating these custom structures is still unintuitive.
I wonder if a DSL like the one used for HL7 validation could help, e.g. compare the custom definitions in modules-hl7 (below package org.openehealth.ipf.modules.hl7.parser.groovytest.hl7v2.def.v25, way more than 100 LOC) with:

forVersion('2.5')
.message('MDM', 'T01 T02')
.addSegment('ZBE')

.newSegment('ZBE')
.addRepeatingType('MovementId', EI, 999)
.addType('StartMovementDateTime', TS, 26)
.addType('EndMovementDateTime', TS, 26)
.addType('Action', ST, 10)

Exclude the servlet-api-2.5 library from dependency tree and use the geronimo-servlet_2.5_spec instead.

The javax.transaction:jta:jar:1.0.1B library not required by IPF therefore it should be excluded from dependency tree.

1. Integrate maven Eclipse plug-in to generate the IPF Eclipse projects files with mvn eclipse:eclipse.
2. Wiki should be updated accordingly.

We can replace the patched camel-jetty with the the camel-jetty-2.5.0

Implement a translator which provides a HL7v3 pix feed source message from its HL7v2 counterpart.

ehcache library should be used instead of org.openehealth.ipf.commons.core.purgeable.* and derived classes for implementing purgeable collections used for storing web service asynchrony correlation items and HL7v2 interactive continuation/unsolicited fragmentation pieces

ITI-38 and ITI-39 IHE transactions

Until the full support of MDHT we'll do the MDHT in paralel to the existing OHT CDA module.

This is a variant on an older issue (see http://gforge.openehealth.org/gf/project/ipf/tracker/?action=TrackerItemEdit&tracker_item_id=400&start=50 ).

When the UserID is empty the attribute should not be present:

audit message snippet:

<ActiveParticipant UserID="" UserName="618fa909-d68e-4982-aab2-4ea90a3ef15c" UserIsRequestor="true">

Complete audit message:

<AuditMessage xsi:noNamespaceSchemaLocation="healthcare-security-audit.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <EventIdentification EventActionCode="E" EventDateTime="2010-06-21T16:14:24.901+02:00" EventOutcomeIndicator="0">
        <EventID code="110112" displayName="Query" codeSystemName="DCM" />
        <EventTypeCode code="ITI-18" displayName="Registry Stored Query" codeSystemName="IHE Transactions" />
    </EventIdentification>
    <ActiveParticipant UserID="" UserName="618fa909-d68e-4982-aab2-4ea90a3ef15c" UserIsRequestor="true">
        <RoleIDCode code="110153" displayName="Source" codeSystemName="DCM" />
    </ActiveParticipant>
    <ActiveParticipant UserID="direct:GetDocuments" AlternativeUserID="4888" UserIsRequestor="false">
        <RoleIDCode code="110152" displayName="Destination" codeSystemName="DCM" />
    </ActiveParticipant>
    <AuditSourceIdentification AuditEnterpriseSiteID="PXS.UID" AuditSourceID="PXS.UID" />
    <ParticipantObjectIdentification ParticipantObjectID="urn:uuid:5c4f972b-d56b-40ac-a5fcc8ca9b40b9d4" ParticipantObjectTypeCode="2" ParticipantObjectTypeCodeRole="24">
        <ParticipantObjectIDTypeCode code="ITI-18" displayName="Registry Stored Query" codeSystemName="IHE Transactions" />       
    <ParticipantObjectQuery>dXJuOnV1aWQ6MTNiNmZlODYtYWI0Mi00N2M4LWIwMGMtOWE0YmI5N2NjMTczLA==</ParticipantObjectQuery>
        <ParticipantObjectDetail type="QueryEncoding" value="d2luZG93cy0xMjUy" />
        <ParticipantObjectDetail type="ihe:homeCommunityID" value="VW5rbm93bg==" />
    </ParticipantObjectIdentification>
</AuditMessage>

If a file, that causes validation failure (for example a .bat script), is copied in the {{input}} folder of the IPF reference application (tutorials-ref), that file will be processed infinitely.

Two modes:

1. "Plain": continuation configuration contained in HL7v3 requests will be translated 1:1 into HL7v2; and vice versa for continuation information contained in HL7v2 responses.
2. "Bridge": continuation information contained in HL7v3 requests will be ignored in translation, because the bridge is able to handle continuation by itself.

When a Web Service receives a request with WS-A ReplyTo header, it sends immediately an acknowledgement with HTTP code 202. This acknowledgement may contain a SOAP message, but not obligatory --- content length == 0 is acceptable as well [1]. The problem is that CXF 2.2 throws an exception when no SOAP payload is available. The current IPF's workaround is to simply ignore this exception, but It should be checked whether newer versions of CXF still suffer from this bug, and --- when they do --- a corresponding patch can be created and provided.

[1] http://www.w3.org/TR/2006/NOTE-soap11-ror-httpbinding-20060321/

see detailed comments in test code

In org.openehealth.ipf.modules.hl7.CompositeHL7v2Exception#populateMessage() we have to create a cumulative HL7v2 NAK from multiple exceptions. In the current implementation, a lot of information goes lost, because we try to put all possible data in a single ERR segment and not all fields there are repeatable --- for example, there can be only one numerical error code. A possible solution would be to use multiple ERR segments, when the message structure allowsus to have them.

The gdsl extensions for IDEA, and the DSL docs are not generated by the IPF Maven plug-in.The reason is that the generated groovy stubs do not contain java docs due to the Groovy/Gmaven update. Affects are milestones 2.2-m3, 2.2-m4 and 2.2-m5.