Package com.adaptris.core.http.jetty

Class JettyAsyncWorkflowInterceptor

java.lang.Object
com.adaptris.core.interceptor.WorkflowInterceptorImpl
com.adaptris.core.http.jetty.JettyWorkflowInterceptorImpl
com.adaptris.core.http.jetty.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 Details

    • JettyAsyncWorkflowInterceptor

      public JettyAsyncWorkflowInterceptor()

  • Method Details

    • init

      public void init() throws CoreException
      Description copied from interface: ComponentLifecycle
      Initialises the component.

      Component initialisation includes config verification, creation of connections etc.

      Specified by:
      init in interface ComponentLifecycle
      Overrides:
      init in class JettyWorkflowInterceptorImpl
      Throws:
      CoreException - wrapping any underlying Exceptions

    • 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:

    • getMode

      public JettyAsyncWorkflowInterceptor.Mode getMode()

    • setMode

      public void setMode(JettyAsyncWorkflowInterceptor.Mode m)
      Set the mode.
      Parameters:
      m -

    • withMode

      public JettyAsyncWorkflowInterceptor withMode(JettyAsyncWorkflowInterceptor.Mode m)

    • cacheContains

      public static boolean cacheContains(String msgId)

    • removeEntry

      public static boolean removeEntry(String msgId)

    • getCacheKey

      public String getCacheKey()

    • setCacheKey

      public void setCacheKey(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;

    • withCacheKey

      public JettyAsyncWorkflowInterceptor withCacheKey(String s)