Scheduled emailed reports in ArcGIS Pro/ArcGIS Enterprise (centralized; server-based, no-code)

594
2
03-26-2023 02:58 PM
Status: Open
Labels (1)
Bud
by
Notable Contributor

I want to be able to open a pane in ArcGIS Pro that is a list of scheduled emailed reports.

Examples (weekly):

  • Email me if there are any construction project records that are out-of-date: STATUS=FORECAST and YEAR is in the past.
  • Email me if there are no sidewalk construction projects for any years in a ten-year range: sysyear + 9.
  • Both reports are examples of data that goes out of date over time. The data was correct when it was entered; the issues couldn’t be prevented at the time of data entry using an attribute rule or something like that. So we need to catch these issues using scheduled email notifications/reports.

Each row in the ArcGIS Pro report list pane would have information like:

  1. Report name
  2. SQL query
  3. Schedule
  4. Send condition:
    1. Always
    2. Only when rows are found in the query
    3. Only when rows are not found in the query
  5. List of email recipients
  6. Email subject
  7. Email body message
  8. Simple textual notification vs. report data (HTML table, PDF attachment, etc.)

The list of reports would be stored somewhere central, such as an enterprise geodatabase system table. The scheduled job mechanism would be built into ArcGIS Server. The SMTP setup would be part of the ArcGIS Enterprise setup or upgrade, giving system administrators no excuse to not set it up for us.

Notebook Server is not an option. 

  1. We don’t need the majority of the functionality in Notebook Server. We’re not a data science shop or a system admin shop. We’re construction/business people. We just want scheduled emailed reports.
  2. Even if IT did purchase Notebook Server, they wouldn’t let non-IT users like us use it. We really need to create and manage our own reports. We don’t want to have to submit an IT ticket every time we need a report added or modified.
  3. Notebook Server requires custom code. We. shouldn’t need to write customizations to make simple reports.


I want to emphasize that the reports need to be server-based, not PC based. For the same reasons our data is in a corporate enterprise database, not in a shapefiles on a user's hard drive: it needs to be in a robust, secure, centralized location. I don’t want to rely on my PC being turned on and logged in for a report to run (i.e. a local windows scheduled task).

I’ve tried submitting similar ideas in the ArcGIS Enterprise community. But haven’t gotten much traction there. The default answer is to use Notebook Server. But Notebook Server doesn’t help me for the reasons described above (and neither do Windows Scheduled Tasks on a server).


Most enterprise systems have scheduled emailed reports baked in. It's unusual that ArcGIS doesn’t have equivalent functionality. For example, IBM Maximo, an Esri work management competitor, has scheduled emailed report functionality for all users built into ALL Maximo implementations. It’s an amazingly powerful tool; a true game-changer for all areas of business.

I like to compare this topic to attribute rules. I didn’t know how much I needed them until I had them. The same applies to OOTB scheduled emailed reports. If you knew how useful they are, I think you’d want them too.

2 Comments
YetiRider

From reading your message, I would consider FME Server which can do all the things you describe plus many things more. It is a server-based and configurable application (e.g. IT can set it up for GIS Teams to safely/securely manage). Furthermore it integrates pretty seamless with Arc products, noting you will need an (additional) Arc Server for licensing purposes if you want to run FME Server against SDE. Obviously, some customisation will be required as you outline specific reporting requirements.

I heard someone talk about stats/audit-traces being looked into and improved by Esri at the moment at the recently held developer summit. Something perhaps worth waiting for. As I'm not an Esri representative, any further information should better come from the source.

Bud
by

@YetiRider Thanks for the suggestion.