Yes, that's a real pain in the neck. There's a column in background_jobs called "correlation_id" that joins to the Tasks table. From there, you can join to workbooks or datasources on the obj_id and obj_type columns. That provides a better result in most cases, but I have noticed that if you refresh your extracts on an ad-hoc basis with tabcmd, it won't show up in the results using that method, presumably because it has no permanent scheduled "task" record, but generates one on the fly.
Thanks Matt. I will check this workaround and will get back to you for any issues. Thank you
You really just can't win right now with the background_jobs or historical_events tables for monitoring what's up with your backgrounder processes. Historical events won't show what's currently happening, only what has already happened, but worst of all it lacks a critical metric for measuring resource consumption--the duration of the task. Background_jobs gives you everything that is happening right now, and has happened up to 30 days in the past, with the duration information. But it's method for joining to a Task record is flawed, since even switching a schedule on the workbook or datasource in question, or refreshing it manually, will cause the CorrelationId to no longer match up with a TaskId in the Tasks table. And while there's a hist_tasks table that contains historical Task ids, it doesn't contain any other information that would allow you to map it to a workbook or datasource! You'd be stuck again mapping it based on the Title field to the name of the item...an imprecise method that results in the wrong answer when there are two items named the same. ARRRGGGG.
I'm taking a hybrid approach of using background_jobs when correlation_id does map to a valid Task, then falling back to the Title method if it's no longer available. Increases complexity and decreases performance, but hopefully there'll at least be better information. I'll post my version soon in another thread.