Skip to content
Business Data Cloud

BW Query Template Generator: BW queries to SAP BDC Analytic Models

What the SAP BW Query Template Generator for Business Data Cloud does, its prerequisites, its limits, and how to pair it with the Data Product Generator.

By 6 min read
Cover about the Query Template Generator: an SAP BW query turned into dimensions, a fact view and an Analytic Model in SAP Datasphere inside SAP Business Data Cloud
Table of contents

If you run a BW system with hundreds of queries, one question comes up in every SAP Business Data Cloud discussion: “what happens to our queries, do we rebuild them by hand?”. Since the summer SAP has had a partial answer, the Query Template Generator (QTG), and on 12 October 2026 SAP Community announced a webinar in which its product manager covers migrating BW queries to BDC. Here is what it actually does, what it needs and where it falls short.

What it is and its status

The Query Template Generator is a tool that runs in your BW system and reads the definition of one or more queries to generate their counterparts in SAP Datasphere inside BDC. For each query it creates, in a HANA-type space:

  • Dimensions for the InfoObjects that have texts or hierarchies, including those texts and hierarchies.
  • A fact view based on the CompositeProvider or InfoCube underneath the query.
  • An Analytic Model that mirrors the query structure: key figures become measures and characteristics become dimension associations.

According to the documentation, the QTG reads the full query definition, including formulas and variables, and before generating anything you can check on the Mappings tab which BW object turns into which Datasphere object. If a compatible dimension already exists in the target space, it is reused instead of duplicated.

Prerequisites: the small print

This is the most important filter. According to the official configuration guide, you need:

Requirement What SAP asks for
Release SAP BW 7.5 SP26 or higher, BW/4HANA 2021 SP04 or higher, or BW/4HANA 2023 SP00 or higher
Deployment The system must run as SAP BW, private cloud edition or SAP BW/4HANA, private cloud edition
BDC A BDC cockpit tenant with SAP Datasphere in the formation
Tools BW Modeling Tools 1.27 PL3 (dedicated Eclipse view) or transaction RSDWCTG_ADMIN in SAP GUI
Authorizations Authorization object S_ADT_RES, plus authorization for the queries you want to transfer
Target A HANA space (disk + in-memory) and an OAuth connection to Datasphere; no HANA Data Lake Files needed

In plain words: this is not a tool for an on-premise BW. If your BW still runs in your own data centre, or on a hyperscaler outside BDC, the lift to the private cloud edition comes first. One practical detail the documentation stresses: when you create the HANA space, the source language must match the default language of the BW system, or generation will fail.

What it does not do: data

This is where most of the confusion lies. The QTG transfers metadata, not data. It builds the semantic model, but someone still has to decide where that model reads from.

The tool that moves data is the Data Product Generator (DPG), which publishes BW data as file-based tables in Datasphere. There is an asymmetry worth understanding from day one:

  • The QTG works only with HANA spaces.
  • The DPG works with file spaces (HANA Data Lake Files).
  • Their targets are configured separately and neither tool sees the other’s.

In practice, bringing both together is modelling work. A partner that tested it on real systems (biX Consulting) describes sharing the DPG tables into the HANA space, adjusting the fact view to read from them and fixing field names and sources in the dimensions. Their verdict: doable, but tedious. They also report that the tool generates dimensions for every InfoObject in the provider, even if the query does not use it, and that in their experience queries on aggregation levels (that is, planning) are out of scope. Treat that as field experience, not official documentation.

How I would use it on a project

My take: the QTG is an inventory and first-draft accelerator, not an automatic migration. This is what I would do:

  1. Clean up before migrating. Use BW statistics to list the queries that are actually run. Migrating 600 queries when 80 are used just multiplies the mapping work.
  2. Prepare the queries you keep. Give technical names to structure elements and restricted key figures so the generated objects are readable.
  3. Use a prefix per domain when you create the templates. Generated names come from BW, and without a prefix it is hard to tell what came from the QTG and what you modelled yourself.
  4. Pilot with 3–5 representative queries: a simple one, one with two structures, one with currency conversion, one with hierarchies. Measure how much manual work is left after generation.
  5. Decide the data source before generating at scale: DPG, replication flows from S/4HANA, or SAP-managed Data Products. The generated Analytic Model is a starting point; if the source changes, so does the fact view.
  6. Reconcile against the original query with the same filters and variables, on totals and on a detailed sample, before signing off any query.

Questions I would ask SAP

  • Which query features are not supported (cells, exceptions, conditions), and where is the official list?
  • Is there a plan to align naming and space types between QTG and DPG, so the Analytic Model can point straight at the published data?
  • How should the generated objects be transported between Datasphere tenants?

Bottom line

The Query Template Generator goes after the most tedious part of a BDC migration: rebuilding by hand dimensions, views and models that already exist in BW. But it is only available once your BW lives in the private cloud edition, and it does not solve the data side. If that is your situation, try it now with a small pilot. If you are still deciding how to bring BW into BDC, factor it into the business case, together with what I wrote about the modernization option for BW NetWeaver.

Sources

Keep reading