An integration between Siemens Teamcenter and SAP S/4HANA or SAP ERP can unlock tremendous value, but also can become challenging and complex. Since last year, Siemens and SAP joint forces to define and develop a new generation of SAP and Teamcenter integration which both companies offer their customers.
This is the second of three blogs (see first blog), with which we will introduce delivered capabilities, unique process and architecture characteristics, and share insights from our strategic software development collaboration between Siemens and SAP.
In this blog I would like to share, why I believe our architecture and technical approach is delivering on the promise of the “next generation”. I’ll cover the following aspects:
An integration between engineering and enterprise systems is a well-known requirement, but also a complex undertaking. Many organizations are looking for ways to increase their end-to-end process maturity, expand the integration breadth and depth and decrease related costs and efforts. When starting our collaboration with Siemens, we did jointly agree that we must tackle these issues, including:
To improve this situation we, Siemens and SAP, decided to build a standard solution, which offers a ready-to-run, end-to-end integration but at the same time is easy to adapt and tailorable to customer specific requirements. We did achieve this by building on the following development principles:
Our partnership is a “once in a lifetime” opportunity to approach the integration challenge in a unique manner. Existing integration approaches per definition build on a given “as-is” status quo. For example, a Teamcenter add-on calls standard SAP BAPIs or services. An SAP add-on calls standard Teamcenter APIs. Of course, these approaches are often implemented, but they rely on many specific implementation details in the Teamcenter and SAP context and create strong dependencies. And as a result, innovating gets harder, and efforts increase.
Examples:
These examples show, why integrations of engineering systems (like Teamcenter) and ERP (like SAP S/4HANA and SAP ERP) have become so complex in the past and caused so much effort on both sides. They also lead us to one of the major differentiators and a key measure to reduce this complexity:
Separation of Concerns
We define a common data model which supports the cross-system processes understandable for both sides, so the responsibility is clear, and “innovations” can happen without endangering the processes on the other side as long as the “meta domain model” stays the same; now the “concerns” are really “separated”:
To achieve this in a most efficient way, teams of Siemens and SAP have defined together cross-system processes, reducing the exchanged data to the bare minimum; the result is the first version of the “meta domain model”, an easy-to-understand “common language” to support processes which go through both systems.
The “meta domain model” simplifies the data exchange to a common data format, which is understandable also by business experts, so both sides will retain flexibility, and innovation can happen now on both sides independent from each other – as long as the “interface contract” given by the “meta domain model” is fulfilled.
In the current release, the following objects are part of the aligned “meta domain model”:
The “meta domain model” defines for all object types a “business key”:
The id and version should be recognized by the users directly in both systems (e.g. material number and revision level in SAP, item id and revision or special attributes in Teamcenter), while the type should be taken from the aligned code lists (see next chapter); the “real” keys of the corresponding objects in SAP and Teamcenter might be different, so a key mapping will be automatically maintained by the integration; this key mapping can be seen as “digital thread” between the Teamcenter objects and the corresponding SAP objects. The integration persists also the “real” system IDs (as tempPLMId and tempERPId) for tracing purposes but does not use them for any processing logic.
The "meta domain model" defines not only the object types, but also attributes which are used in both systems in the same semantic. The most important is the type; in the standard delivery, the integration contains a set of product types, document types, change types and “structure types” which can be used out-of-the-box, but also enhanced. Also, for other attributes (“level 1”, see below), aligned code lists are provided.
For the attribute mapping, the integration distinguishes between three different levels:
The main idea is to align as much as possible without mapping effort, while offering full flexibility for customer enhancements.
The SAP backend implements for all supported objects a synchronous REST endpoint (HTTPS only) to receive a list of objects from Teamcenter in JSON format. The system returns as response all relevant messages back to Teamcenter.
For the transfer of files, upload URLs are generated by the DocumentVersion objects, allowing a direct check-in; so the original files (like JT, PDF etc.) are not transferred by the ABAP layer, but with a direct HTTP(S) call to the content server.
To monitor the incoming HTTP requests, the responses and the application log, the SAP Application Interface Framework (“AIF”) is used. All necessary interfaces are delivered by BC-Sets (AIF namespace /PLMSI) and can be used directly.
The following components must be installed to use the integration, dependent on your SAP system:
As the "PLM system integration" is a standard SAP product, you can find more information in all usual places:
Finally, I want to thank the whole team of Siemens and SAP which made this happen, especially Siemens for the openness and the very good and productive collaboration.
Any feedback is very welcome, so feel free to like it or leave a comment.
This is the second of three blogs (see first blog), with which we will introduce delivered capabilities, unique process and architecture characteristics, and share insights from our strategic software development collaboration between Siemens and SAP.
In this blog I would like to share, why I believe our architecture and technical approach is delivering on the promise of the “next generation”. I’ll cover the following aspects:
- Guiding Principles: What we achieve with this new architecture
- Separation of Concerns – the “Meta Domain Model”: How we reduce complexity and allow continuous innovation on both sides
- Traceability – Key Mapping: How the integration creates relations between the objects in Teamcenter and SAP
- Field and Value Mapping and Aligned Code Lists: Harmonizing shared attributes
- Connectivity: Which technology we use
- Monitoring and Error Handling: How we ensure smooth integration operation
- Component View: Components of the integration
- Further Information
Components of the new SAP Teamcenter integration
Guiding Principles
An integration between engineering and enterprise systems is a well-known requirement, but also a complex undertaking. Many organizations are looking for ways to increase their end-to-end process maturity, expand the integration breadth and depth and decrease related costs and efforts. When starting our collaboration with Siemens, we did jointly agree that we must tackle these issues, including:
- High efforts for basic integration tasks
- Unclear responsibilities and high efforts to analyze and resolve issues
- Complex relations and dependencies between the systems
- Data replication leading to inconsistencies and confusion regarding leading system
- Changes and upgrades of one side leading to major redesign of the interface
To improve this situation we, Siemens and SAP, decided to build a standard solution, which offers a ready-to-run, end-to-end integration but at the same time is easy to adapt and tailorable to customer specific requirements. We did achieve this by building on the following development principles:
- Build integration on cross-system, end-to-end processes which are aligned between Siemens and SAP
- Deliver one solution, where both companies are committed to support joint customers
- Simplify integration with a harmonized and standardized data model following the “Separation of Concerns” principle
- Support the digital thread: full traceability, key mapping of business objects across systems
- Minimize the need for data replication
- Deliver out-of-the-box scenarios covering the most common processes in product development and production planning
- Extensibility and flexibility to support customer-specific adaptations
- Allow independent innovation on both sides without “breaking” the integration
- Allow existing customers to implement the integration on SAP ERP and SAP S/4HANA
Separation of Concerns – the “Meta Domain Model”
Our partnership is a “once in a lifetime” opportunity to approach the integration challenge in a unique manner. Existing integration approaches per definition build on a given “as-is” status quo. For example, a Teamcenter add-on calls standard SAP BAPIs or services. An SAP add-on calls standard Teamcenter APIs. Of course, these approaches are often implemented, but they rely on many specific implementation details in the Teamcenter and SAP context and create strong dependencies. And as a result, innovating gets harder, and efforts increase.
Examples:
- A Teamcenter add-on creates an engineering change master in SAP, a document info record, a material master with revision level and classification and also a BOM. This is realized by calling many standard SAP APIs in a specific sequence (TC-based mapping into SAP structures). After an upgrade, the customer wants to use SAP change records (innovation at SAP side). As consequence, the complete interface on Teamcenter side must be reworked (even if there was no change at all in Teamcenter), causing huge effort in development, testing, rollout etc.
- An SAP add-on receives data for specific item types by Teamcenter standard APIs and creates the SAP data objects (document info records, material masters, BOMs) from that (SAP-based mapping from Teamcenter structures). After an upgrade, the customer wants to separate design and part into different objects and use the new BOM management (innovation at Teamcenter side). As consequence, the complete interface on SAP side must be reworked (even if there was no change at all in SAP), causing huge effort in development, testing, rollout etc.
These examples show, why integrations of engineering systems (like Teamcenter) and ERP (like SAP S/4HANA and SAP ERP) have become so complex in the past and caused so much effort on both sides. They also lead us to one of the major differentiators and a key measure to reduce this complexity:
Separation of Concerns
We define a common data model which supports the cross-system processes understandable for both sides, so the responsibility is clear, and “innovations” can happen without endangering the processes on the other side as long as the “meta domain model” stays the same; now the “concerns” are really “separated”:
- The new Teamcenter add-on “T4ST” links data from specific TC item revisions to the “meta domain model” (“ChangeObject”, “ProductVersion”, “DocumentVersion”, “StructureVersion”). The new SAP add-on “PLM system integration” maps this data based on customizing entries to the corresponding SAP objects (material, document info record, BOM, change master).
- When the customer upgrades Teamcenter and wants to use different item types (e.g. using CAD-part separation), only the mapping in the Teamcenter part has to be adapted into the same objects of the “meta domain model”; no impact on the SAP side, no change is necessary there.
- When the customer changes the logic in SAP and wants to use e.g. different material types or different characteristics with special rules, only the mapping in the SAP part has to be adapted; no impact on the Teamcenter side, no change is necessary there.
Separation of Concerns - by using the “Meta Domain Model”
To achieve this in a most efficient way, teams of Siemens and SAP have defined together cross-system processes, reducing the exchanged data to the bare minimum; the result is the first version of the “meta domain model”, an easy-to-understand “common language” to support processes which go through both systems.
The “meta domain model” simplifies the data exchange to a common data format, which is understandable also by business experts, so both sides will retain flexibility, and innovation can happen now on both sides independent from each other – as long as the “interface contract” given by the “meta domain model” is fulfilled.
In the current release, the following objects are part of the aligned “meta domain model”:
Object Types in the “Meta Domain Model”
Traceability – Key Mapping
The “meta domain model” defines for all object types a “business key”:
- A ProductVersion, DocumentVersion and ChangeObject is defined by an id, a type and a version (for ChangeObject in the current release, the version will always be empty).
- A StructureVersion is defined by id, type and version of a ProductVersion and a type (“BOM type”).
The id and version should be recognized by the users directly in both systems (e.g. material number and revision level in SAP, item id and revision or special attributes in Teamcenter), while the type should be taken from the aligned code lists (see next chapter); the “real” keys of the corresponding objects in SAP and Teamcenter might be different, so a key mapping will be automatically maintained by the integration; this key mapping can be seen as “digital thread” between the Teamcenter objects and the corresponding SAP objects. The integration persists also the “real” system IDs (as tempPLMId and tempERPId) for tracing purposes but does not use them for any processing logic.
Field and Value Mapping and Aligned Code Lists
The "meta domain model" defines not only the object types, but also attributes which are used in both systems in the same semantic. The most important is the type; in the standard delivery, the integration contains a set of product types, document types, change types and “structure types” which can be used out-of-the-box, but also enhanced. Also, for other attributes (“level 1”, see below), aligned code lists are provided.
Aligned Code Lists
For the attribute mapping, the integration distinguishes between three different levels:
- “Level 0”: These so-called “Direct Attributes" are commonly used in both systems for the same purpose, and there is a common standard also for the values (like ISO-code etc.). No specific configuration is needed at all, they are mapped “automatically”.
- “Level 1”: The “Built-in Field Mapping” defines attributes which are also commonly used in both systems, but require a dedicated value mapping (e.g. status, maturity).
- “Level 2”: Further mappings like classification or customer extension fields can be mapped by the so-called “Field and Value Mapping”; in the SAP customizing, the user can define source and target field and (optionally) a conversion method (standard or BAdI).
The main idea is to align as much as possible without mapping effort, while offering full flexibility for customer enhancements.
Connectivity
The SAP backend implements for all supported objects a synchronous REST endpoint (HTTPS only) to receive a list of objects from Teamcenter in JSON format. The system returns as response all relevant messages back to Teamcenter.
For the transfer of files, upload URLs are generated by the DocumentVersion objects, allowing a direct check-in; so the original files (like JT, PDF etc.) are not transferred by the ABAP layer, but with a direct HTTP(S) call to the content server.
Monitoring and Error Handling
To monitor the incoming HTTP requests, the responses and the application log, the SAP Application Interface Framework (“AIF”) is used. All necessary interfaces are delivered by BC-Sets (AIF namespace /PLMSI) and can be used directly.
Monitoring with SAP Application Interface Framework
Component View
The following components must be installed to use the integration, dependent on your SAP system:
| Technical Name | Name | Description | Prerequisites |
| PLMSIFND | PLM system integration - foundation | Main SAP part of the PLM system integration; includes customizing and backend logic | SAP ERP EhP7 (>=SP0013) SAP ERP EhP8 (>=SP0005) SAP S/4HANA (>=1809) |
| PLMSI | PLM system integration - S/4HANA extension | S/4 extension to support long material numbers (and more S/4 functionality in future versions) | SAP S/4HANA (>=2020) |
| AIF | SAP Application Interface Framework | Generic SAP application for monitoring and error handling | SAP ERP EhP7 (>=SP0013) SAP ERP EhP8 (>=SP0005) (already part of SAP S/4HANA) |
| T4ST | Teamcenter Gateway for PLM system integration by SAP | Teamcenter add-on based on the “Active Integration Gateway” (see here). | Siemens Teamcenter 13.2 |
Further Information
As the "PLM system integration" is a standard SAP product, you can find more information in all usual places:
- Siemens Support Center (Siemens login required)
- SAP Help Portal
- Documentation of PLM system integration for SAP S/4HANA
- Documentation of PLM system integration for SAP ERP
- SAP Product Availability Matrix (SAP login required):
- Matrix for PLM system integration 2.0 for SAP S/4HANA
- Matrix for PLM system integration 2.0 for SAP ERP
- SAP Software Download Center (SAP license required)
- SAP price list:
- “PLM system integration for SAP S/4HANA” (7020639)
- “PLM system integration for SAP ERP” (7020640)
- SAP Roadmap Explorer:
Finally, I want to thank the whole team of Siemens and SAP which made this happen, especially Siemens for the openness and the very good and productive collaboration.
Any feedback is very welcome, so feel free to like it or leave a comment.
- SAP Managed Tags:
5 Comments
