IPF Open eHealth Integration Platform

Standard Interceptor Chains

This section describes standard MLLP interceptors of IPF. Their classes belong to the following packages, depending on the served endpoint type (producer/consumer) and usability in non-MLLP context:

• org.openehealth.ipf.platform.camel.ihe.hl7v2.intercept.producer
• org.openehealth.ipf.platform.camel.ihe.mllp.core.intercept.producer
• org.openehealth.ipf.platform.camel.ihe.hl7v2.intercept.consumer
• org.openehealth.ipf.platform.camel.ihe.mllp.core.intercept.consumer

All class names obey the pattern Producer<Function>Interceptor and Consumer<Function>Interceptor`

For the sake of shortness, in the table below, only variable parts of package (hl7v2/mllp.core) and class names (placeholder <Function>) will be given. Interceptor IDs correspond to full class names if not otherwise stated.

Configuring Custom Interceptors

There is the possibility to enrich standard chains with custom (user-defined, project-specific) interceptors.

In order to be placed appropriately in the chain, custom interceptors should define lists of IDs of interceptors they should be placed “before� and “after�. Example:

    public class MyInterceptor extends InterceptorSupport {
        public MyInterceptor() {
            addAfter(ConsumerStringProcessingInterceptor.class.getName(),
                     ConsumerRequestDefragmenterInterceptor.class.getName());
            addBefore(ConsumerMarshalInterceptor.class.getName());
        }
        .....
    }

A list may contain multiple IDs when some of corresponding interceptors are optional. In general, the following rules are applied when inserting a custom interceptor “X� into the given chain (see class ChainUtils for implementation details):

1. If the chain already contains an interceptor with the same ID as “X�, “X� will be ignored.
2. All elements of the X’s “before� and “after� lists, which reference neither interceptors already present in the chain nor the ones waiting for inserting, are ignored.
3. If the “after� list is not empty, but “before� is empty, “X� will be inserted after the “bottommost� interceptor mentioned there.
4. If the “before� list is not empty, “X� will be inserted before the “uppermost� interceptor mentioned there.
5. If neither “before� nor “after� are defined, “X� will be inserted at the end of the chain (thus providing compatible behavior with older IPF versions).
6. If there are any conflicts, e.g. when the “bottommost� interceptor from the X’s “after� list is placed below the “uppermost� one from the “before� list, or when circular dependencies are discovered, the chain construction fails.

For thread-safety, the interceptor instances must be instantiated using a org.openehealth.ipf.platform.camel.ihe.core.InterceptorFactory together with the interceptorFactories parameter:

    from("pdq-iti21://0.0.0.0:18214?interceptorFactories=#myInterceptorFactory,#authenticationInterceptorFactory")
       ....

Each InterceptorFactory must implement the getNewInstance() method so that for each call a new instance of the interceptor is returned. For convenience, there is an abstract class InterceptorFactorySupport that takes the interceptor class as constructor parameter and instantiates interceptor instances by calling Class#newInstance().

In IPF 3.0.x, interceptors can also be instantiated as Spring beans with scope=“prototype�, and their bean IDs should be then listed in the endpoint URI parameter interceptors, e.g.:

    from("pdq-iti21://0.0.0.0:18214?interceptors=#myInterceptor,#authenticationInterceptor")
       ....

Notes that the interceptors parameter has been removed as of IPF 3.1.