This guide explains data enrichment in SAP Datasphere: how to add external company data to the business data you already hold, where that data lives, how it is loaded, how it is matched to business partner records and what the enriched views expose. The examples use Fokals tables for technology, hiring and announcements, but the structure fits any licensed company dataset.
Fokals is delivered direct, by REST API and bulk files in JSON, JSON Lines or CSV, which you load into a space with SAP Datasphere's own loaders. The SAP Datasphere Data Marketplace for data buyers covers data that is bought through it.
What SAP Datasphere is
SAP's learning pages describe SAP Datasphere as a service that combines data integration, cataloguing, semantic modelling and data warehousing, with connections to SAP and non-SAP sources and a marketplace for third-party data. SAP lists it, with SAP Analytics Cloud, SAP HANA Cloud and SAP BW, among the components of SAP Business Data Cloud, where it is named as a core component. Work happens in spaces, and the rest of this guide follows a Fokals table from landing to a business partner view.
A space for licensed data
SAP's page on spaces calls a space a secured virtual work environment. A space isolates its objects and resources, sets a storage quota and workload limits, keeps its own source connections and manages access for its members. The page states that space data cannot be accessed outside the space unless it is shared to another space or exposed for consumption. A space has one of two storage types: SAP HANA database storage, in disk and memory, or file storage in the object store, which SAP describes as an inbound staging area for large quantities of data.
That rule suits licensed data. Create one space for the external tables, share into other spaces only the views that other teams need, and expose for consumption only what your agreement allows. SAP's page on views says a view exposed for consumption becomes available to SAP Analytics Cloud, other analytic clients and ETL tools, so exposure is where data can leave the space.
Getting the files in
Remote tables give direct access to data that stays in its source system, according to SAP's page on integration options. Fokals data is delivered direct, so it is loaded into local tables with the routes below. That page and SAP's page on flows describe the routes.
| Route | What SAP's pages say | Use for Fokals data |
|---|---|---|
| Import CSV file | Creates a local table from a file, with columns derived from its structure; manual uploads are under 25 MB | A sample file or a small table |
| Data flow | Transforms data first and then stores it. Sources are SAP and non-SAP systems and local tables, and the target is a local table without delta capability. Operators include join, union, projection, calculated column, aggregation and Python script | Reshaping a landed file, such as expanding JSON columns |
| Replication flow | Extracts and loads first, then transforms. Load types are initial only, initial and delta, and delta only, with filters and projections, and a failed run restarts where it failed | Tables from a source that supports it, when delta loads matter |
| Transformation flow | Processes data from one local table to another through a graphical or SQL view transform | Building enriched tables after the load |
SAP's reference architecture page Integration with AWS data sources describes importing non-SAP data from Amazon S3 into SAP Datasphere with a data flow. If you land Fokals files in a bucket of your own, that is the pattern to follow. For any other store, check its connection type in SAP's help before you plan around it.
Fokals daily and weekly tables are written once after the period closes and never changed, so loading each closed period once is enough. Tables that describe a state, such as Job Postings, need an upsert on the posting ID, so check that the route you choose can write one. Keep the export's manifest with the landed files: it names the sources, period, label versions and licence, so the terms stay attached to the data.
Which tables, at which grain
A business partner is one row, and most Fokals tables hold many rows for each company. Reduce each table to the grain of the partner before you join, or the join multiplies partner rows.
| Question | Dataset and fields | Grain | Reduce to one row by |
|---|---|---|---|
| Which technologies does the partner run? | Technology Stack: the domain, technology name, technology category, first-seen and last-seen dates | A website and a technology | Counting tools by technology category, or flagging the tools you care about |
| Is it hiring? | Hiring Activity: the day, open, new and closed postings | A company and a day | Taking the latest day, and summing new postings over 30 days |
| What has it announced? | Company News: the time, event types, title and URL | One announcement | Counting by event type over 90 days |
| Which topics are active? | Intent Scores: the topic, score and surge flag | A company, a topic and a week | Taking the latest week and the top topics by score |
The technology table comes from the marketing stack dataset, and every column is defined in the data dictionary.
Joining to business partners
In SAP S/4HANA, SAP's learning pages describe the business partner as the central master data object for natural and legal persons. Number, name, address, bank data and tax number are kept at business partner level, and customer and supplier records are created in the background according to the partner's roles. The category is a natural person, a group or an organisation, and it cannot be changed after the partner is created. Fokals describes companies, so organisations are what you enrich. Filter the partner view to that category first.
The join keys are the company ID, the website domain on the technology and traffic tables, and for listed companies ISIN, LEI, FIGI, ticker and MIC; the identifiers that make company data joinable are described in their own guide. Match in this order, and record how:
- A website you hold against the partner, reduced to its registrable domain and matched to the domain, which is domain matching.
- An LEI or ISIN, wherever your organisation records one, matched to the LEI or ISIN of a listed company.
- Normalised name and country, with a person reviewing the result.
Keep the result in a local table of your own, with one row for each partner and company, a match_basis, a confidence and the reviewer, and join through it. Each company has one stable company ID, so a confirmed match stays valid, and later runs need to look only at new and unmatched partners. Several partners can describe one company, so total a Fokals measure by company ID before you sum across partners, or it is counted once for each partner. A brand or subsidiary carries the identifiers of its listed parent in Fokals, so map a group of partners to the level at which you report; the corporate hierarchy of your own customers decides that level.
SELECT
bp."BusinessPartner",
bp."BusinessPartnerName",
m."company_id",
h."day" AS "HiringDay",
h."open_postings" AS "OpenPostings",
h."new_postings" AS "NewPostings"
FROM "BP_ORGANISATIONS" AS bp
INNER JOIN "FOKALS_BP_MAP" AS m
ON m."BusinessPartner" = bp."BusinessPartner"
LEFT OUTER JOIN (
SELECT "company_id", "day", "open_postings", "new_postings",
ROW_NUMBER() OVER (PARTITION BY "company_id" ORDER BY "day" DESC) AS "rn"
FROM "FOKALS_HIRING_DAILY"
) AS h
ON h."company_id" = m."company_id" AND h."rn" = 1The object and column names are illustrative: use those of your own partner view. SAP's page on views separates a join, which combines the data from two sources at once, from an association, which only prepares the condition for a join later and is how semantic relationships between facts, dimensions, text entities and hierarchies are defined. Use a join where every consumer needs the enrichment, and an association where only some analytic models do.
How to read the data
Fokals is company-level data throughout, so enrichment works on organisation partners. A row records what a company published or did at a dated observation, so read a hiring row as the roles a company advertises that day. Match on a sample for the companies you track first, and read the unmatched list before you plan on a match rate. SAP's pages are the reference for connection types and current feature status; the pages used here were read on 4 October 2026.
SAP Datasphere is where this work belongs when the question joins company signals to your SAP business partners, which its spaces and models are built to hold. The same Fokals tables load into whichever platform your team already works in, as the other platform guides show.
Frequently asked questions
How does Fokals data reach SAP Datasphere?
Fokals is delivered direct, by REST API and as bulk files in JSON, JSON Lines or CSV. You load the data into a space with SAP Datasphere's own loaders, by uploading a file or by a flow that reads files from storage you control. A first load comes from a bulk export, and the API keeps it current.
Which licence terms apply to Fokals data in a space?
Fokals licenses by written agreement for internal use, embedding in a product or redistribution. A space is a secured work environment whose data stays inside it unless you share or expose it, so create one space for the licensed tables and share into other spaces only the views the agreement allows.
Which key matches a business partner to a Fokals company?
Fokals carries several keys: the company ID, the website domain on some tables and, for listed companies, ISIN, LEI, FIGI, ticker and MIC. Match on a website you hold first, then on an LEI or ISIN, then on normalised name and country with a person reviewing, and keep the result in a mapping table.
How do I enrich business partners with company data?
Filter the partner view to the organisation category, map each partner to a Fokals company ID in a table of your own, then join views of Hiring Activity, Technology Stack, Company News and Intent Scores reduced to one row per company. Each row carries its observation time, so the enrichment can be read as of any date.
Should a data flow or a replication flow load Fokals files?
It depends on where the files sit and what you need. SAP's pages describe a data flow as transforming data and then storing it in local tables without delta capability, and a replication flow as loading first, with initial, initial and delta, and delta only load types. Fokals daily and weekly tables are written once, so loading each closed period once is enough. Check which sources your chosen flow supports before you design around it.
The queries and code on this page are examples to adapt. Test them in your own environment before you rely on them.
What this page says about the products it names was checked against their public documentation on 4 October 2026. Product and company names are trademarks of their owners. Fokals is not affiliated with them or endorsed by them.