Teamcenter SOAP (WSDL) Integration in Mendix – How to Store and Display Data in UI?

0
Hi Team,I am integrating Teamcenter with Mendix using a SOAP Web Service (WSDL).Current approach:Imported the Teamcenter WSDL into Mendix.Created a microflow to call the Teamcenter operation (getVariantInformation).Imported the XML response using the generated import mapping.Retrieved the VariantOption list from the response.Iterated through VariantOptions and AllowedValues.Created Mendix entities (VariantOption and VariantOptionValue) and committed the records.My microflow currently looks like:Call Web Service → Import XML → Retrieve VariantOption List → Loop VariantOption → Create VariantOption → Loop AllowedValues → Create VariantOptionValue → CommitI am stuck on the implementation and would like guidance on the following:Is this the correct architecture for Teamcenter-to-Mendix integration using SOAP/WSDL?Should I map the XML response directly into my domain model entities instead of creating objects manually in microflows?What is the recommended way to store Teamcenter response data in Mendix?How should I design the domain model for VariantOption and VariantOptionValue?Once the data is stored in Mendix entities, what is the correct way to display it on a Mendix page?Should I use a Data Grid, List View, or Data Grid 2 to display the imported Teamcenter data?Are there any best practices regarding commits inside loops and performance optimization?My goal is:Fetch Variant data from Teamcenter.Store the data in Mendix entities.Display the data on a Mendix UI page.I have attached my microflow screenshot for reference.Any suggestions, examples, or sample implementations would be greatly appreciated.Thank you.
asked
1 answers
0

Hi Priyanka,

Overall, your approach is valid and is how I've implemented several SOAP integrations where the external system response needs to be available in the Mendix UI.

1. Is the architecture correct?

Yes. A typical flow is:

Call Web Service
      ↓
Import Mapping
      ↓
Parse Response
      ↓
Store in Domain Model
      ↓
Display in UI

The main question is whether the data is temporary or needs to be persisted.

2. Should you map directly to domain entities?

If the Teamcenter data needs to be viewed, searched, reported on, or reused later, I would store it in your own domain model entities.

If the data is only needed for immediate display, you can use the imported proxy entities generated from the WSDL and avoid creating permanent records.

3. Recommended storage approach

I'd typically use:

VariantOption
    1 ---> *  VariantOptionValue

Example:

VariantOption
- TeamcenterId
- Name
- Description

VariantOptionValue
- Value
- DisplayValue

with a 1-* association between them.

4. Commits inside loops

This is the one thing I would improve.

Instead of:

Loop
  Create
  Commit
EndLoop

Prefer:

Loop
  Create
  Add to List
EndLoop

Commit List

For a small number of records it doesn't matter much, but for larger Teamcenter responses the performance difference can be significant.

5. Displaying the data

Once stored in the domain model:

  • Data Grid 2 → best for sorting/filtering
  • List View → best for hierarchical/nested data
  • Classic Data Grid → if you're still on Mendix 9 and don't need modern features

Since VariantOption contains a child collection (AllowedValues), I would normally use:

Data Grid 2 (VariantOption)
     ↓
Row Details / Nested List View
     ↓
VariantOptionValue

or a List View containing another nested List View.

6. Teamcenter-specific recommendation

I would keep the Teamcenter-generated WSDL entities separate from your business entities.

Teamcenter SOAP Response
        ↓
Import Mapping
        ↓
Proxy Objects
        ↓
Mapping Microflow
        ↓
Business Entities

This prevents your domain model from breaking if the Teamcenter WSDL changes in the future.

My recommendation

For a production solution:

  • Keep SOAP proxy entities separate.
  • Map to your own VariantOption and VariantOptionValue entities.
  • Avoid commits inside loops where possible.
  • Use Data Grid 2 or nested List Views for display.
  • Store Teamcenter IDs so records can be refreshed later.

That's generally the cleanest and most maintainable Teamcenter-to-Mendix pattern I've used.


answered