Hi Priyanka Adhav

You do not need to register custom SOA services anywhere in Mendix, you do not need WSDL generation/import, and yes, you consume them directly using the generic SOA call mechanism in the connector. The whole TC SOA layer works over a JSON/REST-style transport through the Teamcenter Connector, not classic SOAP WSDL.

I hope this helps.

From my experience working with Mendix and Teamcenter integrations, custom SOA consumption in Mendix is possible, but the implementation approach depends on how the custom service is exposed in Teamcenter.

Since you are already using the Teamcenter Connector with OOTB Java actions/microflows, you can continue using the same architecture for custom SOA services as well.

For your questions:

1. Do we need to register the custom SOA anywhere in Mendix?

No explicit registration is usually required in Mendix.

The important part is that the custom SOA service should be properly deployed and accessible in Teamcenter. Once it is available from the Teamcenter side, Mendix can consume it either through:

• Teamcenter Connector (“Call Teamcenter Service”)
• Custom Java actions
• SOAP/REST consumption (if exposed externally)

2. Can we consume it directly using “Call Teamcenter Service” activity?

Yes, if the custom SOA follows Teamcenter SOA standards and is accessible through the Teamcenter service layer.

In most cases:

• Create request/response entities in Mendix
• Configure export/import mappings
• Use operation mapping
• Invoke through “Call Teamcenter Service”

This works well for lightweight or standard SOA operations.

3. Do we need WSDL generation/import?

Not necessarily.

If you are using the Teamcenter Connector approach, WSDL import is usually not required because the connector works with Teamcenter SOA services directly.

WSDL import is mainly useful when:

• The service is exposed as a standalone SOAP endpoint
• You want to consume it through Mendix “Consumed Web Service”

In real enterprise implementations, I have seen most teams prefer:

• Teamcenter Connector
• Custom Java actions
  
• instead of large WSDL-based integrations, because maintaining operation mappings for complex payloads becomes difficult over time.

4. How should operation mappings and request/response objects be configured?

This is the main implementation effort.

You need to:

• Create Mendix entities matching the SOA request/response structure
• Create Export Mapping for request XML
• Create Import Mapping for response XML
• Ensure namespaces and XML hierarchy exactly match Teamcenter payload structure

Typical flow:

Microflow

→ Create Request Object

→ Export Mapping

→ Call Teamcenter Service

→ Import Mapping

→ Mendix Response Object

For deeply nested structures like BOMs or datasets, manual mapping becomes quite time-consuming.

My Recommendation (based on project experience)

For small/simple custom SOA:

• Use “Call Teamcenter Service”

For enterprise-level integrations:

• Use custom Java actions with Teamcenter SOA SDK

This gives better control over:

• Session handling
• Authentication
• Error handling
• Large payloads
• Dataset/file operations
• Performance optimization

Most production-grade Mendix + Teamcenter projects I worked on eventually moved important SOA logic into Java actions for easier maintenance and debugging.

One practical suggestion:

Before configuring Mendix mappings, first validate the custom SOA using:

• Teamcenter SOA client
• SOAP UI
• Postman (if REST/SOAP exposed)

Once request/response payloads are finalized, Mendix implementation becomes much easier.

You can also check out this blog which might be helpful:

https://medium.com/@sasidaran.s_17551/integrating-siemens-teamcenter-with-mendix-a-step-by-step-guide-ce4e0984679e

Hope this helps.

Kindly mark this as the accepted answer if it resolves your question.

Hello,

No, you don’t need to register custom SOA services in Mendix separately. If your custom SOA is already deployed in Teamcenter SOA layer, you can directly consume it using the existing “Call Teamcenter Service” activity, same as the OOTB services. You just need to make sure the service name, operation name, and input/output structure match what Teamcenter is exposing. WSDL import is not required in this case. WSDL is only needed if your custom SOA is exposed as a separate external SOAP web service outside of Teamcenter SOA. In most cases with Teamcenter Connector, custom services work just like standard ones.

Thanks !