With the release of FME 2010, Safe Software introduced dynamic workflows which can bring a whole new level of flexibility to FME workspaces. Although dynamic workflows won’t be appropriate for every situation, there are many common scenarios where they can make your life a lot easier. Dynamic workflows allow us to create workspaces that are generic, reusable, and require much less maintenance when compared with using non dynamic solutions.
In the past, FME workspaces have been very closely tied to specific datasets. Let me describe a scenario that is just begging for dynamic functionality. Say you need to extract the parcel data for a particular city from a countywide parcel layer and then re-project it. This is a trivial task for the typical FME user. You start by adding a reader for the county parcel layer, and then another for the city boundary. Next you add the clipper to extract only parcels that fall within the city boundary, and the re-projection transformer. Finally you add a writer to save the extracted data. You’re done for now….
A week later you get a very similar request, but this time you need to extract streets data for the same city from a countywide streets layer. You think to yourself “simple”, open your previous workspace, and then update the reader and writer to point to the streets layer instead of the parcel layer. This solution works fine, but what happens when you start getting this same request for lots of different layers. Many FME users would continue modifying their original workspace, and creating copies that are specific to each of the layers they need to perform the process on. This is fine until someone throws a curve ball and tells you they need all of the extractions repeated and the output data in a different projection.
At this point you can either update all of your data specific workspaces, or you can get dynamic and realize there is an easier solution. The only part of the workspace that you are changing is the feature that is getting read in and written out from the translation. There is no logic within the workspace that is specific to a particular layer’s attributes. By using a dynamic reader and writer you can create a single workspace that will be able to perform the clipping and re-projection to any dataset. Centralizing everything into a single workspace can save you a great deal of time and effort. Down the road, if any other general logic needs to be added into the transformation, such as cleanup or validation of the geometry, you will be able to make this change in a single location instead have to update each data specific workspace.
Beyond just streamlining similar, repetitive tasks, dynamic workspaces allow you to create generic processing tools. We recently had a client ask for a way to spatially visualize the results of non spatial database queries from a Business Intelligence (BI) application. This was a very tricky problem because we had no idea what the results of the query from the BI application would look like, and we had to be able to join those results to one of many potential spatial layers. We achieved this through the creation of an FME workspace utilizing dynamic readers and writers, as well as a slew of published parameters to pass in data specific variables at runtime, such as which spatial data to utilize and what column the join should be performed with. (See my FME World Tour presentation FME Server as Geospatial add-on for Business Intelligence Querying” detailing this). Our FME workspace was able to read in any query results produced by the BI application and join the appropriate column with a spatial data layer such as state boundaries or census block groups that was being pulled from a spatial database. The solution is very generic in nature and could be used for any CSV data that contains attributes that can be associated with spatial data. Using FME to tackle this type of problem would simply not be feasible without dynamic workspaces!
