Package com.adaptris.core.http.jetty

Class JettyAsyncWorkflowInterceptor

  • All Implemented Interfaces:
    AdaptrisComponent, ComponentLifecycle, ComponentLifecycleExtension, StateManagedComponent, WorkflowInterceptor
    @ComponentProfile(summary="Interceptor that allows a HTTP request to be handled multiple workflows",
                  tag="interceptor,http,https",
                  since="3.7.3")
public class JettyAsyncWorkflowInterceptor
extends JettyWorkflowInterceptorImpl
    Allows you to handle a single HTTP request across 2 workflows within the same Interlok instance.

    Configure one of these with mode=REQUEST in the workflow with the JettyMessageConsumer; and then in your reply workflow, configure one of these with mode=RESPONSE. When the reply workflow is finished; then the jetty response will be committed back to the caller.

    Since:
    3.7.3

    In the adapter configuration file this class is aliased as jetty-async-workflow-interceptor which is the preferred alternative to the fully qualified classname when building your configuration.

    • Constructor Detail

      • JettyAsyncWorkflowInterceptor

        public JettyAsyncWorkflowInterceptor()

    • Method Detail

      • workflowStart

        public void workflowStart​(AdaptrisMessage inputMsg)
        Description copied from interface: WorkflowInterceptor
        Mark the start of a workflow. This doesn't mean the message has started processing but only that the message will - at some point - be processed by the workflow.
        Parameters:
        inputMsg - the message that will be processed by this workflow.

      • workflowEnd

        public void workflowEnd​(AdaptrisMessage inputMsg,
                        AdaptrisMessage outputMsg)
        Description copied from interface: WorkflowInterceptor
        Mark the end of a workflow.
        Parameters:
        inputMsg - the original message that was originally submitted to the workflow; in the event of an exception during processing, the exception will be stored in object metadata in the inputMsg
        outputMsg - the message contaning any changes that may have been applied by the services within the workflow.
        See Also:
        CoreConstants.OBJ_METADATA_EXCEPTION

      • cacheContains

        public static boolean cacheContains​(java.lang.String msgId)

      • removeEntry

        public static boolean removeEntry​(java.lang.String msgId)

      • getCacheKey

        public java.lang.String getCacheKey()

      • setCacheKey

        public void setCacheKey​(java.lang.String s)
        Set the key for the cache.

        Set the key in the cache that will be used to track the underlying response. If left blank, then it will use InterlokMessage.getUniqueId() as the key. If specified, then that key (after metadata solution via InterlokMessage.resolve(String)) will be used.

        Generally speaking JMS providers will assign a message-id for you when you create a javax.jms.Message; this becomes the InterlokMessage.getUniqueId() in most cases. If Interlok is in use at all stages, then this can be left blank, as we will try as much to preserve our message unique-id across JMS providers; if there is an external application integrated with JMS, then you might need to specify a value here so that the JMSCorrelationID (via MetadataCorrelationIdSource) is used to key the cache when responding back to the HTTP client.

        Note that because this is an interceptor; the only metadata you have is that which is present upon entry into the workflow (i.e. that set by the consumer); in REQUEST mode, you only get the metadata that is set by JettyMessageConsumer which is not much.

        Parameters:
        s - the cache key e.g. %message{JMSCorrelationID} when the mode is JettyAsyncWorkflowInterceptor.Mode.RESPONSE;