Skip to main content

13.8 — Hands-on Labs & Architect Exercises

13.102 Hands-on Lab 2 — Task-chain failure and retry​

Objective​

Understand dependency-aware recovery.

Build​

Task A | v Task B | v Task C

Intentionally introduce a controlled failure in Task B.

Exercise​

  1. Run the chain.
  2. Identify the first failed child.
  3. Inspect logs.
  4. Correct the issue.
  5. Retry the failed run.
  6. Confirm Task A was not unnecessarily repeated.
  7. Validate Task C.
  8. Record the recovery path.

Architect question​

Why is idempotency important when designing Task B?

13.103 Hands-on Lab 3 — Data freshness SLO​

Objective​

Build a freshness control.

Define:

Refresh cadence = 30 minutes SLO = 45 minutes

Create a monitoring query or operational check that records:

  • latest successful load;
  • current time;
  • age;
  • SLO status.

Test:

GREEN WARNING BREACH

Document the owner and recovery action.

13.104 Hands-on Lab 4 — Reconciliation control​

Objective​

Detect technically successful but incomplete data.

Build:

source_count target_count source_amount target_amount

Compare them after a controlled load.

Introduce a test discrepancy.

Expected result:

technical status = SUCCESS data quality status = FAIL

This teaches why task status alone is insufficient.

13.105 Hands-on Lab 5 — Data Pipeline Analyzer​

Objective​

Find where data disappears.

Build a small dependency chain:

Source | Flow | Local Table | View | Analytic Model

Introduce a controlled filter that removes a known record.

Use the Data Pipeline Analyzer and lineage to identify the first point of divergence.

13.106 Hands-on Lab 6 — Slow view investigation​

Objective​

Use Runtime Metrics and View Analyzer.

Create a model with:

  • a large fact;
  • a dimension;
  • a second large input;
  • a join;
  • an aggregation.

Establish a baseline.

Then test:

  1. projection pruning;
  2. filter placement;
  3. join reduction;
  4. aggregation placement;
  5. persistence.

Record every experiment.

13.107 Hands-on Lab 7 — Remote query investigation​

Objective​

Understand federation behavior.

  1. Create a controlled remote-table query.
  2. Execute a selective query.
  3. Execute a broad query.
  4. Open Remote Queries monitoring.
  5. Compare runtime and transferred work where available.
  6. Identify source-side latency.
  7. Decide whether replication would be justified.

13.108 Hands-on Lab 8 — Agent troubleshooting​

Objective​

Learn the on-premise connector boundary.

  1. Identify a test Data Provisioning Agent.
  2. Inspect resource status.
  3. Review logs.
  4. Correlate an agent event with a Datasphere task.
  5. Identify the earliest failure.
  6. Document whether the root cause is agent-side or Datasphere-side.

13.109 Hands-on Lab 9 — Incident runbook​

Pick one critical data product and write:

  • service owner;
  • business owner;
  • SLO;
  • dependencies;
  • monitor;
  • alerts;
  • failure modes;
  • recovery;
  • validation;
  • escalation.

The runbook should fit on one or two pages.

13.110 Hands-on Lab 10 — Build an operational scorecard​

Track:

  • freshness;
  • success rate;
  • failed tasks;
  • runtime;
  • reconciliation;
  • quality;
  • storage;
  • remote-source latency.

Review the scorecard for seven simulated days.

Identify:

  • trend;
  • anomaly;
  • recurring failure;
  • improvement opportunity.

13.111 Hands-on Lab 11 — RCA exercise​

Create a controlled incident:

Source schema change | v Replication warning | v Transformation failure | v Persistence stale | v Dashboard stale

Produce:

  • incident timeline;
  • evidence;
  • root cause;
  • contributing factors;
  • recovery;
  • prevention.

13.112 Hands-on Lab 12 — Capacity early warning​

Track storage and runtime over multiple simulated periods.

Calculate:

  • growth rate;
  • runtime trend;
  • partition growth;
  • projected threshold date.

Design an alert before capacity becomes critical.

13.113 Architect Exercise 1 — Finance reporting platform​

Design monitoring for:

  • S/4HANA finance extraction;
  • daily transformation;
  • persisted reporting model;
  • SAC consumption.

Define:

  • SLO;
  • freshness;
  • reconciliation;
  • failure classification;
  • escalation;
  • recovery.

13.114 Architect Exercise 2 — Procurement data product​

Design monitoring for:

Purchase Orders | v Suppliers | v Spend Model | v SAC

Business requirement:

  • data available every hour;
  • no silent data gaps;
  • source system must be protected.

Explain your monitoring architecture and trade-offs.

13.115 Architect Exercise 3 — Federated analytics​

A business user reports:

The dashboard is fast in the morning and slow after 10:00.

Investigate:

  • concurrency;
  • source load;
  • remote query volume;
  • query shape;
  • persistence;
  • schedule overlap.

Do not assume the dashboard changed.

13.116 Architect Exercise 4 — 100x growth​

Current:

5 million rows/day

Future:

500 million rows/day

Design:

  • monitoring;
  • freshness;
  • partitioning;
  • persistence;
  • capacity;
  • alerts;
  • recovery;
  • source protection.

The goal is not merely to make today's workload faster.

13.117 Architect Exercise 5 — Global platform​

You have:

20 spaces 8 source systems 200 data products 1 central platform team

Design:

  • monitoring standards;
  • ownership;
  • SLO taxonomy;
  • scorecards;
  • alert routing;
  • runbooks;
  • escalation;
  • audit evidence.