Set up SAP ECC

✦TL;DR

Set up user accounts and permissions required for SAP ECC metadata extraction in Atlan.

||

|Connect

This guide explains how to create a dedicated communication user in SAP ECC and grant the authorizations Atlan needs to extract metadata over RFC.

How Atlan connects to SAP systems

Before setting up user accounts, understand how Atlan connects to SAP ECC.

Prerequisites

Before you begin, make sure you have:

• Administrative access to SAP ECC, including the ability to create users (SU01) and maintain roles (PFCG).
• Self-Deployed Runtime deployed that meets the system requirements. For installation, see Install Self-Deployed Runtime.
• SAP system details, including:
  • Host
  • System number
  • Client number

Create communication user

1. In the SAP GUI command field, enter SU01 and press Enter to open User Maintenance.
2. In the User field, enter a name for the new service user and click Create.
3. On the Address tab, provide the required contact information.
4. Open the Logon Data tab and:
   • Set User Type to C (Communications Data).
   • Set an initial password (enter it twice).
5. Click Save to create the user.

You assign the authorizations in the next section.

Grant required authorizations

Atlan extracts metadata over RFC using read-only function modules, so the communication user needs authorization to:

• Execute the RFC function modules, through S_RFC.
• Read the tables those modules query, through S_TABU_DIS or S_TABU_NAM.

Grant the following values. All activities are display or execute only, so Atlan never writes to your SAP system.

S_RFC for RFC execution

Object	Field	Value	Purpose
S_RFC	RFC_TYPE	FUGR	Authorize at the function-group level.
S_RFC	RFC_NAME	SDTX, /SAPDS/RS_BASIS, SYST, RFC1, RFC_METADATA	Function groups that contain the required modules (see below).
S_RFC	ACTVT	16 (Execute)	Allow execution only.

These function groups cover the function modules used during extraction:

Function module	Function group	Purpose
RFC_READ_TABLE	SDTX	Reads metadata tables.
/SAPDS/RFC_READ_TABLE2	/SAPDS/RS_BASIS	Reads tables with long-string (STRG) columns that RFC_READ_TABLE can't return.
STFC_CONNECTION	SYST	Verifies connectivity between Atlan and SAP ECC.
RFC_SYSTEM_INFO	RFC1	Retrieves system metadata such as SYSID, operating system, and release version.
RFC_METADATA_GET	RFC_METADATA	Reads the interface definitions of the function modules listed in this table. The RFC client calls it automatically before the first call to each module.
RFCPING	SYST	Confirms the RFC connection is alive. Called automatically by the RFC client.

Authorizing individual function modules

If your security policy requires authorizing individual function modules rather than function groups, add a second S_RFC authorization with RFC_TYPE = FUNC and RFC_NAME set to each function module name from the table in this article.

About /SAPDS/RFC_READ_TABLE2

/SAPDS/RFC_READ_TABLE2 ships with the SAP Basis Plug-In (PI_BASIS). Atlan uses it to read columns that the classic RFC_READ_TABLE returns as blank. If your ECC system doesn't have the Basis Plug-In installed, contact your Atlan team.

Table read authorizations

Atlan reads its metadata over RFC_READ_TABLE, which SAP protects with two authorization objects: S_TABU_DIS (by table authorization group) and S_TABU_NAM (by table name). SAP evaluates them as an OR, so either one on its own is enough—you don't need both.

All four approaches below use ACTVT = 03 (Display), so the communication user can never modify a table under any of them. They differ only in how much they scope which tables, and in how often your security team has to revisit the grant.

Atlan adds source tables as features ship

Each new asset type Atlan catalogs reads new SAP tables. A grant scoped to the tables of an earlier release stops covering the connector once you enable a newer asset type—the workflow then fails its preflight check or errors partway through extraction.

The approaches below carry different exposure to this. Read the Re-authorization column before choosing, and treat it as an ongoing commitment rather than one-time setup.

Choose approach

Approach	Object	Scope	Re-authorization
1. All table groups	S_TABU_DIS	Every table in the system, display-only	Never
2. Table name patterns	S_TABU_NAM	Atlan's table families	Only when a release adds a new pattern
3. Specific table groups	S_TABU_DIS	The groups holding Atlan's tables	Before enabling any new asset type
4. Specific table names	S_TABU_NAM	Exactly the tables listed	Every release that adds tables

Options 2, 3, and 4 need a list of the tables Atlan reads, which your Atlan team provides during implementation. Atlan doesn't publish that list in this documentation.

Recommended:

Where your security policy permits it, Option 1 is the best choice for both production and non-production. It's the only approach that covers every table Atlan reads in future releases, so it never needs revisiting as you enable new asset types—and the user stays display-only throughout. Pair it with activity monitoring and alerting on the communication user where that's warranted.

Where a broader grant isn't permitted:

• Non-production—Option 2. It scopes access to Atlan's tables and still absorbs most new tables automatically.
• Production—Option 2 or Option 3. Option 2 doesn't depend on how your system assigns table authorization groups. Option 3 suits organizations that already govern table access through authorization groups, and keeps the grant consistent with that model.
• Production under strict change control—Option 4, accepting a security review per release, for an exact and auditable list.

Your Atlan team can advise on the right approach for your security and governance policies.

Option 1: All table groups

Object	Field	Value	Purpose
S_TABU_DIS	ACTVT	03 (Display)	Allow read-only table access.
S_TABU_DIS	DICBERCLS	*	All table authorization groups.

Covers every table Atlan reads now and in future releases, whatever group it belongs to.

Because DICBERCLS = * grants display access across all table authorization groups, the grant is broader than the tables Atlan reads. Some security policies don't permit that scope for production.

Where they do, pair it with the access monitoring you already run. The communication user is dedicated to Atlan and connects only over RFC, so its reads are straightforward to attribute and review—you can monitor the user ID to confirm it accesses only what metadata extraction requires, and alert on anything outside that pattern. This keeps the grant stable across releases while your monitoring, rather than the authorization, sets the boundary.

Option 2: Table name patterns

Object	Field	Value	Purpose
S_TABU_NAM	ACTVT	03 (Display)	Allow read-only table access.
S_TABU_NAM	TABLE	Each pattern from the list Atlan provides	Atlan's table families, plus tables with no family.

S_TABU_NAM accepts a wildcard at the end of a table name, so each pattern covers a whole family of related tables. Because SAP groups related tables under a shared name prefix, a table added in a later release usually falls inside a pattern you already granted.

Atlan provides the patterns. Contact your Atlan team for the table name pattern list. The list isn't published in this documentation.

This approach needs no S_TABU_DIS grant and doesn't depend on your system's table authorization group assignments, so it needs no TDDAT review.

Future releases may require a security change

Patterns absorb most new tables, but a release that introduces a table family outside these patterns requires adding one. If that happens and the pattern isn't added, the workflow fails its preflight check or errors partway through extraction.

Ask your Atlan team for an updated pattern list before you enable a new asset type.

Option 3: Specific table groups

Object	Field	Value	Purpose
S_TABU_DIS	ACTVT	03 (Display)	Allow read-only table access.
S_TABU_DIS	DICBERCLS	SS, &NC&, and any group returned by the check below	Table authorization groups holding the tables Atlan reads.

Which groups you need depends on your system. SAP stores each table's group in TDDAT and leaves many application tables unassigned, and an unassigned table falls back to &NC&. Because your Basis team can reassign groups, the required values differ between systems.

Atlan provides the table list. The TDDAT check needs to know which tables to look up, so contact your Atlan team for the table name list first. The list isn't published in this documentation.

Then have your Basis team read TDDAT (field CCLASS) for those tables, using SE16, SE54, or transaction SUCU. Grant SS and &NC& alongside whatever groups the check returns.

Future releases may require a security change

New tables can sit in a table authorization group this grant doesn't include, and &NC& covers them only if your system left them unassigned. If a new table falls outside the granted groups, the workflow fails its preflight check or errors partway through extraction.

Ask your Atlan team for an updated table list and repeat the TDDAT check before you enable a new asset type.

Option 4: Specific table names

Object	Field	Value	Purpose
S_TABU_NAM	ACTVT	03 (Display)	Allow read-only table access.
S_TABU_NAM	TABLE	Each table name, no wildcards	Exactly the tables Atlan reads.

The most auditable option, and independent of table authorization group assignments.

Atlan provides the table list. Contact your Atlan team for the current table name list. The list isn't published in this documentation.

Future releases require a security change

This option has no margin for new tables. Every release that adds tables requires a corresponding security change, and without it the workflow fails its preflight check or errors partway through extraction.

Ask your Atlan team for an updated table list before you enable a new asset type.

Assign authorizations to user

You can grant the authorization objects directly or, preferably, bundle them into a single role.

Recommended: bundle into a PFCG role

1. In the command field, enter PFCG and press Enter to open Role Maintenance.
2. Enter a name for a new single role (for example, Z_ATLAN_RFC_METADATA) and click Single Role.
3. On the Authorizations tab, open the authorization data and add S_RFC plus the table read object for your chosen approach, using the field values from the previous sections.
4. Generate the authorization profile.
5. On the User tab, assign the role to the communication user you created, then Save.

Grant the objects directly

Add S_RFC and the table read object for your chosen approach, with the field values from the previous sections, to a profile assigned to the communication user. Use this approach when an existing role or profile already manages the user's authorizations.

note

The user must change the password on first login.

Next steps

• Crawl SAP ECC: Follow the instructions to extract metadata from SAP ECC using the configured service user.