Shape the future of FME with your ideas
Open ideas have been reviewed by our Product Management and are open for commenting and voting.
With the new job queue settings it is possible to add a queue tag to a Engine via Web Interface or via REST. To manage jobs for their daily or nightly run routine it would be great to set up time slots for those tags.For example: Engine 1 has the queue tag "Short", Engine 2 has the queue tag "Short" and "Long". Both tags will be used to manage different kind of workspaces. During the night Engine 1 should have the job queue "Long" between 7pm and 7am as well, so that both engines can run those workspaces.
The ArcGIS Server Feature Service Writer will be available soon for the 2023 beta version, however there is no option to add atachment as it is done with arcgis pro. The attachments known to be a useful way of providing additional info in the form of a specific file.
RealDWG has some support for textures and materials, however, the writer is not available in Linux (and FME Cloud).It would be really nice to have this support for ACAD as well as RealDWG. We use FME Cloud as the backend to a number of 3D City Export portals, and as it stands we can't support DWG exports with textures.
I would like to submit jobs to the queue such that they only run during certain times, and are on hold outside of those times, while other jobs not so tagged run as normal, even if they have equivalent or lower priority than the tagged jobs. Current scenario, I have a workspace I need to run ~6000 times. The workspace is resource intensive and causes network/connectivity issues if it’s run during business hours. I would like to queue up the jobs so that they only run between 6pm and 6am, but any other job will run as normal between 6am and 6pm. I am currently submitting 200 jobs a night manually, and sometimes they finish early so I miss out on potential processing time, and sometimes there’s a few left in the queue that I have to abort in the morning so that normal operations can proceed. Ideally I would submit all 6000 jobs at once and FME would process however many jobs fit into the 12 hour window, than pause that queue. While that queue is paused any jobs submitted normally would run according to standard priority.
A customer (using FME Server with 1 engine) asked:Would it be possible to limit a queue to a defined time window per day?That way I can avoid conflicts when users want to run a workspace on a time, that is reserved for other processes.I thought it was a good idea.Allowing queues to have a time window, so workspaces that are assigned to only that queue, can be executed during that time window only.
It would be nice if Automations Logs had the look and feel of Job Logs. I would like to be able to choose between viewing the log from the current Automation run or seeing a grid/list view of historical Automations Logs with one log for each start/stop cycle, similar to the completed job logs page. All the logs could be stored in shared resources like job logs. This would help with authoring, debugging, and auditing my FME Server Automations.
Add a new feature to the workbench tool menu: Automatic update workspace transformers to the latest version. 2 ways of behaviour: 1. New version of the transformer has the same parameters as the old one - automatic update 2. New version of the transformer has some difference in parameters - open transformer parameters for edit.
I'd like to have a kind of timechart in the FME Server GUI, just for easy planning my scheduled jobs.Why? Here are some reasons:- i wanna see, if there is a time, when my engines may be buisy- mybe there will be a timeslot with conflicts, because at the planned time there will be no engine available- get an graphical overview with all scheduled jobs (for a special day/for a week/for month)
To have the option to enable or disable the StatisticCalculator calculation port be switching on at least one calculation mode; "Summary", "Complete" and/or "Cumulative".The transformer would not process the unneeded calculation mode.
I've previously asked the question, why FME Server doesn't use something like "Shared Folders" in FME Desktop. The simple answer was, that it doesn't support such novelties, so I have to manually copy the needed files.But it's actually even worse, I just found out.I'be built numerous custom transformers with FMX and Python, and I can easily upload workspaces using these to FME Server, but the custom transformers are ignored, and thus FME Server can't find the neccessary Python files to run the workspace.I thought that I needed to copy the Python files, which are in a single shared location wrt. Desktop (<Shared>/Plugins/Python), to a similar fixed folder in the FME Server transformers search path.Alas this didn't work, and it occurred to me, that engines only use this to find FMX files.And (according to the job log) the only dynamically added folder to the Python search path is the folder, wherein the workspace (FMW) itself resides. NO common/shared ground for Python code, it seems.When I added the transformer's Python code file to this workspace-folder, it worked. But this is a bad situation.I think it would be a great idea, if FME Server had a single ressource folder for Python code files, that were also added to the engine's Python search path. That way a single folder could be used to store all Python code files regardless of which workspaces that uses them.
Support of awesome cloud optimized pointcloud https://copc.io/ https://twitter.com/DaleAtSafe/status/1455219629916246016
I think it is useful to save personalised template scripts for the PythonCaller transformer.Now, the template script looks like this: import fme import fmeobjects # Template Function interface: def processFeature(feature): pass # Template Class Interface: class FeatureProcessor(object): def __inti__(self): pass def input(self, feature): self.pyoutput(feature): def close(self): passPersonally, I always add e.g. the line,logfile = fmeobjects.FMELogFile()and almost never use the template function.Other FME-users might e.g. want to use by default:import mathTherefore, I think it is usefull that any FME-user can save his own, personalised, template PythonCaller scripts.
With a lot of relations between small jobs using automations, it would be nice to be able to filter jobs launched by the run of an automation to debug.
Currently, only files owned by the user (with posted credentials from personal OneDrive account) can be downloaded in FME with the OneDriveConnector. It would be good to be able to download files that have been shared with us by a different user
Would be great if there was a parameter in the Excel Writer for row height. Made a very rough screenshot (below) of where the option might be located, but open to other possibilities if anyone would like to make suggestions.Although now I'm thinking, if we had a parameter for Row Height, maybe change Cell Width to Column Width?Thanks to @MarkAtSafe
It would be nice to have a chart/dashboard that shows when engines are being used and when they aren't being used. Another interesting statistic would be engine utilization percentage, so you can see if you have a high utilization (which may warrant more engines) or low utilization (which may allow you to utilize less engines.
Add the ability to pass dates as keys in automations. Currently in automations it is not possible to pass a date published parameter from one workspace to another as a key. The current work around is convert the dates to strings and use a text published parameter, which requires the author to create more additional published parameters just for this purpose.
Each automation has "global keys" for settings that can be shared among the various actions inside that automation. There are certain (relatively) "constant" key/value pairs that I frequently use on multiple automations. Having to set them up each time in each new automation is time consuming, and if one of those "constants" change, I have to remember which automations use that key/value pair in order to keep them all updated.I would propose a new server-wide "global key" that would be accessible from any automation on the server. In fact, the first time I saw "global key" that's what I thought it would be. Perhaps "global key" could be used for this server-wide purpose, and the existing automation-based "global key" could be renamed to "automation key" (which more clearly identifies its scope and purpose.
The FILE_GDB writer has this capability, it saves a postprocessing step in ArcGIS
It would be great if FME can also support writing ArcGIS Pro annotation.
I've been asked to help classify some numeric data and I wondered about the possibility of FME having a dynamic attribute classifier of some sort to group data into ranges with no user-defined values. Like a natural breaks or even manual classification in ArcGIS where in the latter case you might define a number of breaks or ranges but again without giving actual data values.I know the AttributeRange Mapper has the ability to generate ranges based on specified max and min values, but you have to establish them first. This idea is around having FME do that on the fly.Thinking it can be a quick way to analyse and understand data without having to play around with it too much or manually get there in desktop GIS.
A generic mailbox watcher as a trigger for the new FME Server Automations. Set up rules similar to Outlook rules which if met, would trigger an automation. As an example, Microsoft Flow already has this as a trigger.
I am asking for Safe Software to develop a best practise in FME for moving workbenches scripts through Dev/Test/Prod. A quick search has not found this best practise. We all do this (or should): build a script in Dev and/or Test enviornment, then move to production. Each time, I grab the .fwm from Dev/Test and transfer it using fileservices to PROD. Then reconfigure and run. It's easy, but has a risk of error. Other users have suggested python scripts, ini files etc to allow configuraiton to be set by environment, so each script doesn't change. WHich is very clever, but still an add-on that itself has risk - does the python script have error handling? How do we know it worked? What if my python skills are very low? I bet the smart people at Safe can figure this out. It literally might save the world one day.
It would be very useful if FME could manage common parameters in a similar way to Database or Web Connections.Many of our workspaces use the same (private) parameters, when authoring a new workspace we need to recreate or copy the parameters over from an existing workspace. If the value of that parameter changes, then every workspace needs to be edited, whereas with a web connnection one can simply edit the connection in FME options once, and be done.This can also simply the moving of a workspace though the different DEV, STAGE, PROD environments in FME Server. A common issue we have is a private parameter that points to an internal REST API endpoint, and of course we have different endpoints for the different environments, and that parameter does not always get updated when promoting workspaces to the prod server. To prevent this, the "named parameter connection" would be pre-defined on the different FME servers with the appropriate data, and the workspace would remain unchanged between environments.
In-depth courses for all FME skill levels.
Explore our extensive collection of how-to guides and tutorials.
Log an issue with us. Our support team is ready to help.
