Please enable JavaScript.

Coggle requires JavaScript to display documents.

Flow Server - Coggle Diagram

- - - - each managed by Akka Actor
      - first processor is considered to be the SOURCE
        
        Flow Source
        
        responsible for reliably receiving and storing payloads and ensuring they are processed all the way through the flow
        
        Variants
        
        Normal
        
        are created on every node
        
        are commonly used for server-like sources, such as REST and SOAP APIs
        
        normal sources are not sharded but scoped on single actor system instances
        
        Singleton
        
        are not sharded but scoped on single actor system instances
        
        are only created on one node
        
        are usually needed for polling endpoints such as file consumers
        
        use the Akka At-Least-Once Delivery mechanism to send incoming messages to their associated flow. This requires a stable and unique persistence id per FlowSourceActor. All sources and their persistence ids are managed by the GlobalFlowSourcesProvisionerActor persistently
        
        FlowSourceActor
        
        is persistent actor
        
        Each incoming message is stored and then forwarded to the flow pipeline for further processing
        
        The message is only deleted when the FlowSourceActor receives an acknowledgement from the flow pipeline that the message processing has completed
        
        is always coupled with SourceEndpoints
        
        SourceEndpoint
        
        is not an actor and forwards incoming data to the FlowSourceActor via the EndpointToSourceRouter
        
        is the component responsible for handling the actual transport and protocol of the source. E.g. a JAX-WS SOAP source endpoint
      - responsible for implementing the actual integration flow by processing the payload in various ways as configured by their processor spec
      - Intermediate processors pass their result on to the next processor in the pipeline
        
        Flow Pipeline
        
        built by creating a FlowPipelineActor from the received FlowSpecDto
        
        lifecycle events (creation, deletion, failure) are announced to the GlobalFlowSourcesProvisionerActor
      - The last processor produces a result/ack that is sent back to the source
    - - The message exchange pattern describes how the messages flow through the system, and what behavior the client expects from the flow-server
      - Types
        
        OneWay
        
        pattern for asynchronous processing where the client is concerned with delivering a message, but does not wish to wait for the result of the processing
        
        The client will receive a response/receipt that the message has been received, but further processing is performed asynchronously
        
        If further flow-processing should fail, the redelivery and dead letter strategy of the flow determines what happens to the persisted message
        
        Standalone
        
        pattern where messages are processed by a standalone component and is not subject to regular flow processing
        
        A standalone flow spec can only have a single processor
        
        This processor takes the full responsibility of processing messages
        
        RequestResponse
        
        traditional synchronous request, where the result of the processing is returned to the client in a response at the end of the processing
        
        Headless