![]() ![]() The example ETL tool reports the command line I should use to run the workspace is: Mondays are getting problematic for me, I may forget. It has an official refresh rate of once a week, each Saturday local time I run the ETL tool when I remember to on Monday mornings (hey its only a demo). I use it to maintain a hosted feature service using data harvested from a Geoserver instance via an extended WFS API. If someone else needs to run it they should replace the named user credentials first.įor my example I'm going to recycle an ETL tool example from an earlier post. Provided the scheduled task you build automates the ETL tool on the machine you would use to run it interactively there should not be any licensing issues. Your ETL tool may embed these credentials. ![]() With ArcGIS Pro, Enterprise and OnLine you're living in a world of named user licensing. Lets dispense with some legalities first. fmw file, and any arguments the workspace needs. You may never have noticed, but when you run an ETL tool while being edited in Workbench, the very first line that appears in the log window is: Command-line to run this workspace: followed by the path to our new friend above and the path to the open workbench. This is the one that does all the work when an ETL tool runs. Your friend is this guy:Ĭ:\Program Files\ArcGIS\Data Interoperability for ArcGIS Pro\fme.exe You don't have to be the server and click 'Run' too. You have used Data Interoperability's Workbench app to wrangle services, databases, files and so on to achieve your own private batch 'service'. In the modern era there is a lot of emphasis on service oriented architecture and the ArcGIS stack has comprehensive publication and synchronization capabilities amongst apps, but you're reading this because you're working outside the stack, at least at one end of your synchronization workflow. We're going down the task scheduling path too, but without needing Python. You may have heard of this sort of automation in the context of Windows Task Scheduler with a Python script as the task and the script calling a geoprocessing tool or model. If you're on this kind of treadmill this post is for you! Typically the source data refresh 'trigger' is driven by a schedule and not some random event, and the frequency of updates is based on multiples of a working day. We're seeing many people using Data Interoperability to periodically synchronize datasets between systems of record. Note: This post originally discussed only one way to schedule ETL processing, but with the ArcGIS Pro 2.5 release, due out soon, job scheduling is coming to Desktop geoprocessing right from any tool's Run button! I'll leave the 'legacy' approach details in the post but do read through to the 'new' approach once you're able to deploy Pro 2.5. This post is about automating repetitive ETL processes right from your desktop. ![]()
0 Comments
Leave a Reply. |