Connectors SAP BW and BW/4HANA to Google BigQuery

SAP BW and BW/4HANA to Google BigQuery: full history landed and reconciled, then kept current.

Lima Backbone reads SAP BW and BW/4HANA through open Hub destinations, types the data correctly on landing, writes it into Google BigQuery as raw, conformed and history datasets, and keeps it current from the source’s changes. Every run ends with a row count and a control total per table.

OUT OF SAP BW AND BW/4HANAItemsBills of materialStockOpen ordersLIMA BACKBONEExtractOpen Hub destinations · Active-table rea…Checknine checks before anything loadsShapetypes, keys, deletes, partitionsLoadParquet to Cloud Storage, load jobs into…INTO GOOGLE BIGQUERYGoogle BigQueryRaw, conformed and history datasets; tab…
The path from SAP BW and BW/4HANA to Google BigQuery. Objects come out through the source's methods, are typed and checked, land in Google BigQuery and are kept current from the source's changes.
220M rows
615 tables · ~30 GB in ~30 min on 64 vCPU
performance estimate
80 GB/day
moved and transformed every day
production · semiconductor enterprise
8
checks on landing
product
1
count and control total per table per run
product
What Google BigQuery expects

The model the load has to fit.

ModelRaw, conformed and history datasets; tables partitioned by date and clustered by key.LoadParquet to Cloud Storage, load jobs into raw, MERGE into conformed; counts and control totals per table.BackResults can be written back to the ERP by Lima, confirmed per write.
The hardest part of this path

Choosing partition and cluster keys so MERGE stays cheap on large tables.

The Google BigQuery connector page →

What comes out of SAP BW and BW/4HANA

Objects and methods.

ObjectPlain meaning
ADSO active tablesadvanced data store objects: the tables that hold the data
InfoObjectsmaster data and texts
CompositeProviderscombined views for reporting
Open Hub tablesexported data sets

The SAP BW and BW/4HANA connector page →

How SAP BW and BW/4HANA is read

Open Hub destinations and released interfaces. No ODP RFC (SAP Note 3255746). Direct active-table reads are used only where the customer's licence permits database access; confirm with the licence owner.

The path, step by step

Six steps, one report at the end.

ConnectRegister SAP BW and BW/4HANA and Google BigQuery with credentials from the vault; test both connections.
ExtractFirst load through open Hub destinations; then incremental reads by change columns.
CheckNine checks run before anything loads; a failed row becomes an exception with an owner and the load continues with the valid rows.
ShapeTypes are set from the source, keys kept complete, deletes and late changes applied in order.
LoadParquet to Cloud Storage, load jobs into raw, MERGE into conformed; counts and control totals per table.
Keep currentChanges from SAP BW and BW/4HANA are applied on the schedule you set; every run ends with the same report.
The checks that run before anything loads

8 checks, each with a plain example.

Every check either passes a row or turns it into an exception record with an owner. Nothing is dropped silently.

CheckKindWhat it catches, with an example
Types set from the sourcetypingSAP dates and times stored as text become dates and times; currency decimals shifted by the currency's rule
Keys complete and uniquekeysclient or organisation columns kept in the key; zero-padded keys preserved
Deletes appliedconsistencyrows deleted in the source are marked or removed in the copy
Late changes land in orderconsistencya change that arrives after a later one is applied by its source timestamp
Wide and cluster tables completecompletenessevery column of a wide table lands; cluster tables read through the released module
Partitions cover the rangecompletenessevery date partition present; gaps reported
Counts and control totals matchreconciliationrows and amounts per table compared between source and target
Schema changes noticeddrifta new or changed column is flagged before it breaks a downstream query
Cadence and offer

How the copy stays current, and how the work is priced.

After the first landing, Google BigQuery receives the source's changes: incremental reads. A migration month costs the same as a quiet month on the same tier.

Terms on this page

Plain meanings.

LandingWriting rows into the target's raw layer as they arrived, typed, before any business transformation.
Referential orderLoading parents before children so every row finds what it refers to.
Control totalThe sum of a key amount column compared between source and target, along with the row count.
Exception recordA row that failed a check: kept, routed to an owner, replayed once fixed.
Change captureReading only the rows that changed, from a log, change pointers or timestamps.
Questions

Asked about this path.

How long until the first load is live?

Days for the first tables; a full-history migration is sized by table count and volume, and read in partitions inside the run windows your administrators allow.

What does the data team see?

Counts per step, the check that stopped a row, the owner and the replay point, and the lineage of any number back to its source column.

Who runs it after go-live?

Your team, on the schedule you set, with the same report after every run; or your systems integrator; or Lima's team under the subscription.

Land your first tables in Google BigQuery.

One call scopes the dataset, the run window and the tier. The reconciliation report at the end is the acceptance test.