– Standard Configuration and Bulk Solution for On-Premises and Private Cloud

This guide provides an overview of WorkCenter mapping in PLM System Integration (PLMSI). It covers the standard out-of-the-box mapping approach, the customizing entries involved, and a solution for customers who manage large numbers of work centers without to do big customizing steps. A dedicated section at the end addresses Windchill-specific considerations.

Why WorkCenter Mapping in PLMSI Matters

When an External PLM system
(e.g. Siemens -Teamcenter / .riess -Windchill/ Cenit -3DX/ Cideon -Autodesk Vault) sends Production Operation List (POL) data to SAP S/4HANA via PLMSI, each operation is typically associated with a work center in the SAP routing. The integration must therefore resolve the work area identifier sent by the External PLM system to the correct SAP WorkCenter. A misconfigured or missing mapping results in application errors (HTTP 201) or incorrect routing data, impacting production planning and shop-floor processes.

Contents

1. Prerequisites
2. Standard WorkCenter Mapping
   2.1 How the Default Mapping Works
   2.2 PLMSI Customizing: Define Work Area and Work Center
   2.3 Work Area Type – Mandatory Code List Entry
3. Solution for Customers with Many Work Centers
4. External PLM System-Specific Considerations
   4.1  Windchill: workAreaIdSource Property
   4.2  Windchill: WORK_AREA_TYPE_MAPPING_DEFAULT

1. Prerequisites

• PLMSI add-on or S/4HANA private or on-premises 3.0 onwards Support Packages is installed.
• PLMSI configuration is complete; the connection between the External PLM system and PLMSI is set up.
• The scenario in which POL data (routings) is transferred is configured in SPRO under PLMSI > Define Scenario and Version.
• Users need admin or business user authorization for PLMSI.

2. Standard WorkCenter Mapping

2.1  How the Default Mapping Works

When the External PLM system sends a POL (Production Operation List) request, each operation contains a WorkArea identifier and a WorkArea Type. PLMSI uses the following logic to resolve these values to an SAP WorkCenter:

1. PLMSI reads the WorkArea ID from the inbound JSON payload.
2. If an explicit mapping entry exists in the PLMSI customizing table “Define Work Area and Work Center” for that scenario and factory, PLMSI uses the mapped SAP WorkCenter.
3. If no explicit mapping entry exists, PLMSI applies a default logic: the WorkArea ID from the External PLM system is used directly as the SAP WorkCenter name (1:1 match).
4. In both cases, the Work Area Type must be present in the JSON and must match a valid entry in the PLMSI DM Code List for “DM Work Area Type”. This validation always applies, regardless of whether a mapping table entry exists.

Tip: Always start troubleshooting WorkCenter errors with the SLG1 application log and the PLMSI Workbench before checking or changing configuration. Want to know how this work take a look at this:

2.2  PLMSI Customizing: Define Work Area and Work Center

The explicit WorkCenter mapping is maintained in SAP customizing via transaction SPRO:

Path: SPRO → Cross-Application Components → PLM System Integration → DM Factory to SAP Plant → MAP DM Factory to SAP Plant → Define Factory Assignment (Select DM Factory ID) → Define Work Area and Work Center


Screenshot 1: SPRO – Entry: Define Factory Assignment (Scenario SAP_EBOM/ mapping table)]

Screenshot 2: SPRO – New Entries: Define Work Area and Work Center (Scenario SAP_EBOM / Factory Walldorf / mapping table

The screenshots above shows a typical mapping configuration. Each row defines how one Domain Model Work Area (as sent by the external PLM system) is resolved to a specific SAP WorkCenter in the plant.

The PLMSI mapping table contains the following key fields:

Field	Example Value	Description	Mandatory
Scenario ID	SAP_EBOM	Identifies the integration scenario	Yes
Scenario Version	1	Version of the scenario definition	Yes
DM Factory ID	Walldorf	Domain Model factory identifier	Yes
DM Factory Type	Production	Type of factory in the Domain Model	Yes
Domain Model Work Area	Testing Workbench	WorkArea ID as sent by the External PLM system	Yes
Domain Model Work Area Type	Cell	Work area type from External PLM	Yes
SAP WorkCenter	WDFFTL01	Target SAP WorkCenter name in the plant	Yes

2.3  Work Area Type – Mandatory Code List Entry

The Work Area Type field in the inbound JSON payload is always validated against the PLMSI DM Code List for “DM Work Area Type”, regardless of whether a WorkCenter mapping entry exists.

• The Work Area Type is a mandatory field and must exist in the DM Code List – values must be maintained in PLMSI IMG Customizing.
• Path: SPRO → Cross-Application Components → PLM System Integration → Domain Model Code List
• Sending an unknown value (e.g. “Potato”) results in a 201-application error: “There is no entry for it.” – this is expected (works as designed).

Screenshot 3: SPRO – New Entries: Define Work Area and Work Center (Scenario SAP_EBOM / Factory Walldorf / mapping table)]

Note: The default mapping logic (WorkArea ID = SAP WorkCenter name) only applies when WorkCenter assignments are missing from the mapping table. It does not bypass the Work Area Type Code List validation.

3. Solution for Customers with Many Work Centers

In large production environments, customers may have hundreds or thousands of work centers distributed across multiple plants. Maintaining a 1:1 mapping entry for every work center in the PLMSI customizing table quickly becomes impractical.

The Problem

• Manual maintenance of thousands of mapping entries is error-prone and time-consuming.
• New work centers created in either system require immediate customizing updates.
• Typos or missing entries cause integration errors that are hard to trace at scale.

The Solution: Direct Name Matching (No Explicit Mapping)

PLMSI supports a zero-configuration approach for WorkCenter resolution: if the WorkArea ID sent by the External PLM system matches exactly the SAP WorkCenter name, no mapping entry is required. The default logic resolves the WorkArea ID directly.

This means: if you ensure that the external PLM system sends the SAP WorkCenter name (or number, depending on the Ext. PLM System setting) as the WorkArea ID, you do not need any mapping table entries.

• No SPRO entries needed for those work centers.
• Adding new work centers in SAP automatically works as long as the External PLM system uses the same identifier.
• The Work Area Type still must be a valid DM Code List entry.

Practical Approach

1. Align with the External PLM team: identify which attribute the External PLM system uses as the WorkCenter identifier.
2. Set the WorkArea ID in External PLM and PLMSI property to match the chosen identifier
3. For Work Centers where the identifier does not match or can’t be changed (legacy names, special characters, etc.), add explicit PLMSI mapping entries only for those exceptions.
4. For substring-based matching (e.g. factory plant prefix), the External PLM system can pre-process the WorkArea ID before sending to produce the correct SAP identifier, reducing the mapping table to near zero entries.

Tip: This approach is especially effective for greenfield implementations or when the External PLM system already stores the SAP WorkCenter number/name as a native attribute.

4. External PLM System-Specific Considerations

In addition to the standard PLMSI configuration covered in the preceding sections, each External PLM system may introduce system-specific configuration requirements on its own side that directly affect how WorkCenter identifiers and Work Area Types are transmitted to PLMSI. These considerations are typically not visible from the SAP or PLMSI perspective alone and can only be identified in close collaboration with the respective External PLM integration partner or system owner.

The Windchill-specific example documented in the subsections below was developed and validated in alignment with .riess. It serves as a concrete reference to illustrate the type of PLM-side configuration adjustments that may be required in practice, and should be understood as a template for how such considerations ought to be identified and documented for each integrated system.

Note: Considerations for Other Integrated PLM Systems

It is to be expected that comparable system-specific considerations exist for the remaining External PLM systems currently supported in the PLMSI context. Please reach out to your responsible contacts or integration partners if there are questions reading the topic.

4.1  Windchill Consideration:
When the External PLM system is PTC Windchill, there are additional configuration points on the Windchill side that affect how WorkCenter identifiers are sent to PLMSI.

4.1.1 Windchill: workAreaIdSource Property:

Windchill uses a configurable attribute to determine which field of the work center object is sent as the WorkArea ID to PLMSI. This is controlled by the PLMSI property workAreaIdSource.

 

Property Key	Default Value	Description
workAreaIdSource	number	Logical attribute name for the source of the WorkArea ID mapping. Controls which Windchill attribute is sent as the WorkArea identifier to PLMSI.

 

Screenshot 4: Windchill – PLMSI Properties View

The property is maintained in the PLMSI Properties configuration (accessible via the Windchill PLMSI configuration UI or the properties file). Key points:

• Default value: number – Windchill sends the work center number as the WorkArea ID.
• Alternative value: name – Windchill sends the work center name as the WorkArea ID.
• Some customers have changed this to name to align with SAP WorkCenter naming conventions.
• It is essential that the value sent by Windchill (number or name) exactly matches the SAP WorkCenter identifier. If they do not match, a full mapping table must be maintained for all work centers in PLMSI customizing.

Note: If a Windchill customer reports that WorkCenter mapping is failing despite correct PLMSI customizing, verify the workAreaIdSource property first. A mismatch between “number” and “name” is a common root cause.

4.1.2  Windchill: WORK_AREA_TYPE_MAPPING_DEFAULT in wtsap_mapping_config.xml

Windchill uses a mapping configuration file (wtsap_mapping_config.xml) to translate its internal work center type values to the PLMSI DM Work Area Type values that are expected in the JSON payload. The relevant mapping table is:

WORK_AREA_TYPE_MAPPING_DEFAULT

<tableMapping id=”WORK_AREA_TYPE_MAPPING_DEFAULT” default=”Unit”>
    <entry key=”WorkStation” value=”Area”/>
    <entry key=”WorkUnit”    value=”Unit”/>
    <entry key=”WorkCell”    value=”Cell”/>
</tableMapping>

 

Windchill Work Center Type	Mapped PLMSI Work Area Type	Note
WorkStation	Area	Windchill work station type → SAP Area work center category
WorkUnit	Unit	Windchill work unit type → SAP Unit work center category (default)
WorkCell	Cell	Windchill work cell type → SAP Cell work center category

The mapped values (Area, Unit, Cell) must exist as valid entries in the PLMSI DM Code List for “DM Work Area Type”. If a custom Windchill work center type is used that is not listed in this mapping table, it will fall back to the default value “Unit” as defined by the default=”Unit” attribute.

Note: If a customer uses custom Windchill work center types, the WORK_AREA_TYPE_MAPPING_DEFAULT table in wtsap_mapping_config.xml must be Extended, and the corresponding entries must be added to the PLMSI DM Code List in SPRO.

Further Information

For more information, refer to the official SAP Help documentation:

• PLMSI for S/4HANA SAP Help Portal:
  PLM system integration for SAP S/4HANA 

Source link