Skip to main content

Product Requirements Document

Mission​

Users need more consistent and intuitive error messages in their UI, which allow them to quickly understand and diagnose issues within their deployment and flow configurations.

Background​

As users begin to have more granular control over their own data estate, they will begin to encounter the same errors that our own DAs and QA engineers encounter. However, they will not have the same mastery of Azure tech or experience with the platform tooling as our internal users do. They will be easily frustrated by some of the errors they encounter ("ERROR: PL_METADATA_SPARK"), not knowing what it means or how to fix it.

Users should be enabled to understand the error in front of them, be it a UI issue, and authorization error, backend API/server errors, or something in ADF/Spark. This should be done through the use of a universal status code system, which signifies the error occurring and (perhaps just as importantly) where the error occurred. These status codes should be pushed to a log and mappable to an error message that is user friendly. Additionally, this mapping system should be changeable outside of release cycles, so that in case a change to a message needs to occur on the fly, it can.

Targeted Personas​

Who is the primary beneficiary of this initiative? Why? Are there secondary beneficiaries?

  • Dario Data Professional: who will using this to diagnose issues within the deployment and during flow runs
  • Debbie Delivery Engineer: who will be doing the same ^

Current Behavior​

Today, errors are propagating up from ADF in the form of convoluted and unhelpful messages. Metadata errors are not yet captured either (fixing in 1.23!).

ADF​

For each ADF phase (metadata, extract, delta, model, publish, and powerbi) errors are referred to by the pipeline they are within, restricting triage to those already familiar with the ADF pipeline orchestration.

Spark​

Most errors within the Empower Spark package is bubbled up through ADF as an error "EXTRACT_SPARK_PL".

UI​

UI errors

Core API​

Data API​

Legacy API​

Legacy will not be a part of this initiative as it is actively becoming obsolete.

Outcomes / Goals​

  • Provide desired end product/workflow.
  • Will this be a singular effort or phased release?

User Stories​

Name/Descr​

  • story

Use cases​

Case group name​

  1. Case / user name
    1. Primary Actor:
    2. Description:
    3. Preconditions:
    4. Postconditions:
    5. Flow:
      1. Steps...
      2. Outcome

Requirements​

Functional​

  • List of functional description of the feature

Non-functional requirements​

  • List of NFRs to focus on

Out of Scope​

  • Funtionality and cases out of scope for planned feature
  • Might be treated as future updates that not yet planned and refined

Dependencies & Constraints​

  • Any kind of dependency

Assumptions​

Risks​

Timeline and Milestones​

Phase I​

  • Release #.##
  • Components, other deliverables

Questions?​