hana icon
Query icon
IonToCsv icon
Upload icon
SlackIncomingWebhook icon
Schedule icon

Export a SAP HANA analytics view to an S3 data lake

Schedule a backfill-safe SAP HANA analytics view export to CSV and upload it to a partitioned S3 data lake with Kestra retries and Slack alerts.

Categories
Data

Export a SAP HANA analytics or calculation view to CSV and land it in a partitioned Amazon S3 data lake on a daily schedule. This blueprint solves the recurring HANA to lake-house extract problem: getting governed SAP analytics data out of HANA and into a format that Athena, Spark, or Snowflake can read, with the load window driven by an explicit load_date input instead of CURRENT_DATE so backfills and replays always select the correct day and write it to the matching partition. Remote calls carry retries and failures alert to Slack.

How it works

  1. The daily_export trigger (io.kestra.plugin.core.trigger.Schedule) fires at 05:00 Europe/Berlin on cron 0 5 * * *. The load_date input defaults to {{ (trigger.date ?? execution.startDate) }}, so a manual backfill exports that exact day.
  2. The extract_view task (io.kestra.plugin.jdbc.hana.Query) runs the SQL against the view named by the analytics_view input, binding load_date to the :loadDate parameter. With fetchType: STORE it streams the result set to Kestra internal storage as Amazon ION. A 30-minute timeout and a 3-attempt constant retry guard against transient HANA disconnects.
  3. The convert_to_csv task (io.kestra.plugin.serdes.csv.IonToCsv) converts the ION file to CSV with a header row.
  4. The upload_to_data_lake task (io.kestra.plugin.aws.s3.Upload) writes the CSV to the data_lake_bucket under a date-partitioned key like hana/daily_sales/2026/06/17/daily_sales.csv, with its own retry for S3 throttling.
  5. On any failure, the errors block posts a Slack alert via io.kestra.plugin.slack.notifications.SlackIncomingWebhook with the execution id.

What you get

  • A daily, partitioned CSV snapshot of a HANA view in your S3 data lake, ready for query engines.
  • Deterministic object keys per load_date, so re-runs overwrite cleanly instead of duplicating.
  • A stable column contract: the SQL selects explicit columns, not SELECT *, so downstream tables survive view changes.
  • Built-in retries on both the HANA read and the S3 upload, plus Slack failure alerts.

Who it's for

  • Data engineers feeding SAP analytics into a lake house or warehouse.
  • Analytics teams building Athena or Spark tables on top of HANA exports.
  • Platform teams that need governed, repeatable, backfillable SAP extracts.

Why orchestrate this with Kestra

HANA's own scheduling and SAP job tools stop at the database boundary: they can run a query, but they cannot also convert the output, push it to S3, retry each external step independently, and alert your team in one declarative, versioned unit. Kestra ties the HANA read, format conversion, and S3 upload into a single event-driven flow defined in YAML, with per-task retries, a bounded timeout, full execution lineage and replayable runs, and a Slack error path. The load_date input makes every run backfill-safe, something a plain CURRENT_DATE query in a scheduler cannot offer.

Prerequisites

  • A reachable SAP HANA instance. The JDBC URL uses port 39015; adjust the instance number and databaseName for your tenant. The HANA JDBC driver (ngdbc) ships with the Kestra JDBC plugin.
  • An Amazon S3 bucket you can write to, with credentials granting s3:PutObject.
  • A database user with SELECT on the target analytics view.

Secrets

  • HANA_HOST: hostname or IP of the SAP HANA server.
  • HANA_USERNAME: HANA database user with read access to the view.
  • HANA_PASSWORD: password for that user.
  • AWS_DEFAULT_REGION: AWS region of the destination bucket.
  • AWS_ACCESS_KEY_ID: AWS access key id with write access.
  • AWS_SECRET_ACCESS_KEY: AWS secret access key.
  • SLACK_WEBHOOK: Slack Incoming Webhook URL for failure alerts.

Quick start

  1. Add the secrets above to your Kestra instance.
  2. Set the analytics_view and data_lake_bucket inputs to match your environment.
  3. Adjust the SQL column list to match your view's schema.
  4. Trigger the flow manually once to validate connectivity, then let the schedule take over.

How to extend

  • Swap the S3 upload for another destination (GCS, Azure Blob) by replacing upload_to_data_lake.
  • Add a downstream task to register the new partition in Athena or Glue, or to trigger a dbt run.
  • Parameterize the column list and partition layout to template this across many views.
  • Change fetchType or add compression for very large exports.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.