Siemens Teamcenter is the most widely adopted product lifecycle management (PLM) software in the manufacturing industry. It enables manufacturers to connect people, processes, and data across their organizations. Maximizing the value of your core systems, like Teamcenter, is essential.

At Mendix we believe in the Adapt and Extend motion. Adapting your core systems allows you to offer new experiences to your core user base. This includes new data presentations and new form factors, like mobile and offline apps. Extending unlocks your Teamcenter data to reach non-core users and offers adjacent use cases such as field service, purchasing and supplier collaboration. In this blog post, we’ll explain how you can extend Teamcenter using Mendix.

Combine the strengths of Mendix and Teamcenter

To achieve the ‘Adapt and Extend’ vision, we offer seamless integration with Teamcenter through the Teamcenter Connector and Teamcenter Extension. Integration with Teamcenter is supported through its Service-Oriented Architecture (SOA). With this SOA you can retrieve and create data from Teamcenter, work with structured data such as bill of materials, interact with Teamcenter workflows and much more.

In 2019, Siemens delivered the Teamcenter Connector to help you develop Mendix apps using Teamcenter data, leveraging these SOA APIs. The Teamcenter Connector provides a set of Java actions that do the heavy lifting when it comes to integrating to Teamcenter for you. Supported integrations include login/logout, handling items, item revisions, datasets and workspace objects, working with Teamcenter workflows and more.

Last year, Mendix published the Teamcenter Extension to provide a true low code experience when building Mendix apps using Teamcenter data. The Teamcenter Extension is a Mendix Studio Pro extension that allows you to build apps that integrate with Teamcenter using familiar flows and UIs like those already known to Mendix developers. After the developer configures the integration, the Teamcenter Extension generates microflows and domain models that you need for your integrations. The generated microflows, in turn, make use of the Teamcenter connector.

Connector vs Extension – what’s the difference?

The Teamcenter Connector and the Teamcenter Extension both simplify integration with Siemens Teamcenter, but they serve different purposes.

Teamcenter Connector

This Mendix module handles the actual integration with Teamcenter, and it:

• Provides out-of-the-box Java actions that wrap commonly used SOA calls.
• Automatically converts Mendix request objects into JSON.
• Calls the appropriate SOA APIs and returns Mendix objects from the responses.
• Allows you to drag and drop a Java action into your app logic, no need to build a REST integration for the SOA calls from scratch.

Teamcenter Extension

The Extension is designed to simplify integrating Mendix with Teamcenter:

• A Mendix Studio Pro extension that provides low-code tooling to create integration building blocks.
• Addresses the complexity of Teamcenter’s many interrelated (and often custom) object types, which can be challenging even for experienced users.
• Brings the Teamcenter business model directly into Mendix Studio Pro.
• Lets you simply select the objects you need, while it automatically generates the necessary integration building blocks.

In short, the Connector executes the integrations, while the Extension empowers you to design them with low code ease.

Using the Teamcenter Extension

Before we dive in, let’s define a use case.

A tangible use case

Imagine we want to build a mobile app where users can create a change request for a part revision. The app will, very likely, include the following integrations with Teamcenter: searching for part revisions, creating a change request and triggering a workflow to process the change request.

Zooming in on Change Request creation

When the user clicks on the submit button in our imaginary UI, a microflow will be executed that, in the end, performs a REST call to Teamcenter SOA to create the object in Teamcenter.

Know your data before you build

When you develop such an app, you need to know what type of data you are dealing with. For example, you need to know what type of change request needs

creation. It could be the default Change Item Revision, a Problem Solving Report Revision, or a custom change request, specific to the Teamcenter instance.

The benefits of Teamcenter Extension

While the Teamcenter Connector allows you to configure which Teamcenter business objects are involved and which Mendix entities represent these business objects, it does not solve everything. For example: How do you know which business object types are available? Which properties do these business objects have? Which of these properties are users allowed to modify?

One of the main benefits of the Teamcenter Extension is that it provides you with direct access to the Teamcenter business model, while you are setting up your integrations. Without the extension, developers needed access to Teamcenter’s Business Modeler IDE (BMIDE) to lookup information on the Teamcenter business model.

It should be noted that often Mendix developers do not have access to BMIDE and this information needs to be communicated through other channels. Based on the data from BMIDE, you could manually construct a domain model in Mendix that mirrors the business model in Teamcenter, but this is an error-prone and elaborate exercise.

In contrast, with the Teamcenter Extension, you can just select what you need from Teamcenter inside Mendix Studio Pro. Using an import mapping page, you can configure how to map Teamcenter business objects to Mendix entities and select which properties, relations and/or references you are interested in.

During the import mapping, the extension shows, for example, the types of change request revisions that are available in Teamcenter. The extension shows the display names of the objects alongside the internal name. In the end, the Teamcenter connector needs the internal name for the integration, however, internal names can be cryptic. For example, the internal name of the Problem Solving Revision mentioned above is C3CapaRevision. By showing both the internal and display name, the extension helps you to effortlessly navigate the Teamcenter business model.

When selecting relevant properties, relations and references, the Teamcenter Extension also helps out. For the selected business object, the extension lists the properties, relations and references, again showing both the internal and display names, together with their type. As a developer you simply select the ones that are relevant for the app and that’s it. The Teamcenter extension makes sure the correct domain model will be generated for the integration.

To conclude, with the Teamcenter Extension you can:

• Speed up your development: a few clicks and you can drag-and-drop ready-to-use microflows into your app logic.
• Create tailored integrations: search for and select the Teamcenter objects, properties, relations and references you are interested in that are specific to your Teamcenter instance.
• Create integrations without the risk of errors and typos: use the display names of objects, properties, relations and references in the UI and have the extension generate the domain model and microflows that use the internal names for the integrations.

How it’s all connected

To summarize, the Teamcenter Connector makes sure you can, for example, retrieve your part revisions from Teamcenter, create change requests and submit the change requests to a workflow in Teamcenter. The Teamcenter Extension helps you to create the app logic you need, while utilizing the Java actions of the Teamcenter connector.

When you start your development journey, we advise you to start with the Teamcenter Extension. When your use case is supported by the extension, this is by far the easiest way to develop your app as it provides a true low code experience right there in your IDE:

• Launch the extension
• Choose your integration
• Configure your integration (including the mapping)
• Generate your domain model and microflows!

For more information on the supported use cases, please visit the Teamcenter Extension documentation.

Right now, the Teamcenter Extension supports a subset of most integrations from the Teamcenter Connector but it is not yet feature complete. We are adding new features as we go. For example, in the use case above we mentioned Teamcenter workflow. This is an integration that is supported by the Teamcenter connector, but not yet by the extension.

If that is the case, you can develop your integration using the Teamcenter connector, directly. A list of supported SOA API’s using out-of-the-box Java actions can be found in the Teamcenter connector documentation.

Teamcenter SOA provides over 1000 endpoints. As you can imagine, the Teamcenter Connector does not have a Java action for each endpoint. That doesn’t mean you are stuck. The Teamcenter Connector includes a generic Java action to call any SOA endpoint, including custom SOA endpoints that may be available in your Teamcenter instance.

Setting this up can be challenging, but the right tools can simplify the process. Start with the Teamcenter Extension; if your use case isn’t supported, move to the out-of-the-box Java actions provided by the Teamcenter Connector. Use the generic Teamcenter service call Java action only as a last resort, as it’s the most complex option. The image below summarizes this approach—while the scope of functionality increases from top to bottom, so does the complexity.

Your turn!

Ready to accelerate your Teamcenter integration journey and truly ‘Adapt and Extend’ your PLM landscape? Check out the resources below to get you started.

Resources

• Download Teamcenter Connector
• Download Teamcenter Extension
• Teamcenter Connector documentation
• Teamcenter Extension documentation
• Learning path: Integrate Teamcenter into Your App