FME Version
What are Enterprise Integration Patterns?
In enterprise integration, a pattern is a repeatable solution to a commonly occurring problem encountered when integrating applications or systems. A pattern is a template for how to solve a problem that occurs in many different situations.
Enterprise Integration Patterns were made famous by Gregor Hohpe and Bobby Woolf and are popular amongst IT architects and application integration specialists because they provide a common language for communicating requirements. To learn more about them, you can find the information at Enterprise Integration Patterns.
How does FME support Enterprise Integration Patterns?
Built on top of and relying on the notifications framework of FME Flow, automations provides a graphical interface, making it easy for users to build workflows consisting of event triggers and actions.
Automations workflows are able to orchestrate workspaces, which provides control over the sequence of actions that respond to events.
These orchestrations can be simple or complex, containing any number of FME workspace tasks(0+) and/or communicating with any number of other applications(0+). This is what makes building Enterprise Integration Patterns possible in FME.
Examples of Enterprise Integration Patterns
Aggregator
This pattern can be used to combine messages based on specified criteria. This can be based on an “ID ”, a “time period” or other characteristic they share. For example, you might have an FME Flow automation that manages work orders; at the end of the day triggers a “daily summary” that is sent to an email. If the work orders were processed using the same trigger action, the merge or split-merge block tools in automations will wait for all actions to complete before any further steps downstream, i.e. sending an email. Alternatively, you might schedule a workspace to check all work orders and group-by today's date and send a summary using that information.
Content-Based Router
This message-based routing pattern is used to examine a message’s content and routes the message based on what data is inside. In FME, this simple message-based routing can be built with the filter automation tool in automations. More complex routing based on message content can be done with the FME Flow Automation writer and the power of the FME Engine. A basic example can be found in this article, Access and Managing Automations.
Content Enrichment
This pattern uses the information inside of the incoming message to retrieve data from an external source and append the data to the message. This pattern is simple to build with the FME Flow Automation writer. Typically, a key or other information is part of the message that is passed to the FME workspace (as a user parameter). The workspace looks up the information in one of the data stores supported by FME and writes the enriched content to an output feature type using the FME Flow Automation writer. Our article on Dynamic Workspaces: Data Driven Parallel Processing in FME Flow Automations goes into detail about how to use this pattern.
Dynamic Router
In this pattern the routing of features changes based on the rules defined by another system or user input. The power of the FME Engine and the FME Flow Automation writer can make this as simple or complex as the “dynamic” rules specify. The dynamic rules can be stored in any format or system supported by the FME Engine.
Message/Content Filter
Simple filtering can be done by using the filter tool in automations and more complex filtering workflows can be done by building a workspace that consumes messages and only lets ones with certain criteria pass. Any of the filtering transformers in FME Workbench can be used inside these workflows.
Message Store
In this pattern, messages are stored for auditing, playback, testing, or other reasons so they are available later. In FME, a workspace embedded within an automation writes the inbound message to a data store, such as the log a message action.
Normalizer
In this pattern, messages come from different systems with the same content but different structures. This pattern can be used to “normalize” the messages so every message downstream has the same structure. This “syntactic” translation is what FME Engine was built to do. FME supports numerous formats and has numerous transformers available to work with schema transformations. An example of this can be seen in our Dynamic Workflows Destination Schema Derived from Multiple Sources article.
Process Manager
A Process Manager is a pattern that relies on a central processing unit to dynamically route tasks or messages to different ‘processing units’ (workspaces), without having a sequence or processing order predefined. This central processing unit needs to have some memory mechanism that stores information for which step in the sequence was executed last; this could be any of the data formats FME supports. The looping capability enables you to connect a custom output port to a previous input port in an automation workflow. Check out our article about Looping in Automations to learn more.
Resequencer
In the resequencer pattern, there is a defined order that the messages that need to be passed downstream in an automation in case they arrive “out of order”. In this pattern, a workspace is used to simply store the messages until it is their turn to be output. The transformers inside a workspace, such as the Sorter, can be used to sort features into their correct order, before being output through the FME Flow Automations writer.
Splitter
A splitter pattern is used to break the composite message into a series of individual messages, each containing data related to one item. This is simple to do within a workspace. If the incoming message is JSON or XML you could use the fragmenter transformers to split it into multiple features, which become individual messages. You can then use the FME Flow Automations writer to split the workflows. Read our article on Building Integrations with FME Flow Automations for an implementation of this pattern.
Comments
0 comments
Please sign in to leave a comment.