Do not input private or sensitive data. View Qlik Privacy & Cookie Policy.
Skip to main content

Announcements
Want to see what's currently in public preview? We've pulled it all together in one place. Check it out here
cancel
Showing results for 
Search instead for 
Did you mean: 
lakshmanvepuri
Creator
Creator

Orchestrating Sequential QVW Reloads Based on DB Table Freshness Check with Mail Alert on Failure

Environment
  • QlikView (QVW / QMC)
  • 12 Database Tables | 12 QVD Generator QVWs | 1 Dashboard QVW

Scenario

I have 12 database tables that receive data loads at random intervals every hour (i.e., the load time is not fixed). Corresponding to these, I have 12 QVW files (QVD Generators) — one per DB table — that need to reload and generate updated QVDs.


Requirements
  1. DB Table Freshness Check (Pre-Condition)

    • Before triggering any of the 12 QVWs, a DB table freshness check must run to validate that all 12 DB tables have received the latest data for the current hour.
    • The 12 QVWs must only be triggered once this freshness check passes successfully for all 12 tables.
  2. Sequential QVW Reload (Post Check)

    • Upon successful validation, all 12 QVD Generator QVWs should be triggered for reload via QMC.
  3. Dashboard Refresh (Final Step)

    • The dashboard QVW must refresh only after all 12 QVD Generator QVWs have completed their reload successfully.
  4. Failure Handling & Mail Alert

    • If any of the 12 DB tables is found to be not updated (stale data) during the freshness check:
      • An email alert must be triggered, identifying which table(s) failed the freshness check.
      • The reload of all 12 QVWs must be aborted — none of the QVWs should proceed.
      • The dashboard refresh should not be triggered in this case.
Labels (2)
1 Reply
marcus_sommer
MVP
MVP

I could imagine of going the following way:

  • first a QVW which reads the data-base system-tables to get the number of records or last change timestamp for each wanted table which are stored within a table and/or variables
  • then a logic which compares the current results with the previous ones to extract the changes (yes/no)
  • if there are not 12 yes then call an artificial load-error (line with: I'm an error ... ) to cause a task-error which would send an email-notification
  • parallel chained to the first qvw are then the 12 generator-qvw + an extra qvw which is checking the timestamps from the qvd's - again the ones from the current run against the previous one (embedded within a loop to be repeated n times to ensure that really all 12 generators have finished before ending the own execution)
  • on the extra qvw depends then the dashboard-qvw

If you have also a publisher-licence you could investigate if there are possibilities to chain a task to n tasks which would avoid the mentioned extra 13. qvw. Also if it's not necessary or possible to call n parallel queries against the data-base you may not need such extra check.