Teamcenter Customization & Extensions
Teamcenter can be extended in a dozen ways, and the cheapest long-term solution is usually the least custom one that meets the requirement. We start by establishing whether configuration can do the job, and write code when it genuinely cannot.
ITK and server-side extensions
Custom ITK utilities, batch jobs, dispatcher translators and server-side handlers. We build these as reusable libraries rather than one-off scripts where it makes sense, so the next requirement costs less than the last.
System integrations
Connecting Teamcenter to whatever else the business runs: enterprise applications, engineering and manufacturing systems, reporting and analytics platforms, supplier portals, and the in-house tools that only exist inside your network. The hard part is rarely the call itself. It is error handling, retries, and deciding what the system should do when the other side is unavailable.
Custom SOA services and REST APIs
Where the standard operations do not cover what a caller needs, we build custom Teamcenter SOA services for it rather than making every consumer assemble the same sequence of calls themselves. Above that, we build REST APIs in .NET Core or Spring Boot that sit in front of Teamcenter and give other systems a clean HTTP interface: documented endpoints, predictable payloads, proper status codes, and session and authentication handling kept in one place instead of reimplemented in every client.
Why put an API in front of Teamcenter
It decouples the systems that consume PLM data from the internals of the PLM system. A team integrating against a documented REST endpoint does not need to learn ITK or the SOA model, and does not break when something behind the interface is refactored or upgraded. It is also a far easier surface to secure, version, log and rate-limit than direct access, and it gives you one place to change behaviour rather than several.
Configuration-driven extensions
Where a requirement can be met with preferences, business rules, workflow handlers or stylesheet changes rather than compiled code, we will say so. Configuration survives upgrades more gracefully than customization does.
Upgrade-aware development
Customization written without an upgrade in mind becomes the reason an upgrade stalls. We document what each extension depends on, so the eventual upgrade assessment is a reading exercise rather than an excavation.
What you get
- Custom ITK utilities and reusable function libraries
- SOA and REST integrations with documented error handling
- Custom Teamcenter SOA services and REST APIs in .NET Core or Spring Boot
- Batch jobs, dispatcher translators and email handlers
- Multiplatform custom applications in .NET and Java
- Source, build instructions and handover documentation
Common questions
- Do we own the code you write?
- Yes. Custom development done for your environment is handed over with source and build instructions. Licensing for any of our pre-existing tools is agreed separately.
- Which stack do you build REST APIs in?
- .NET Core or Spring Boot, chosen to match what your team already runs and can maintain. Both sit comfortably in front of Teamcenter and in whatever container or application platform you already deploy to, so the API is not the thing that introduces a new technology into your estate.
- Can you take over customization someone else wrote?
- Usually. We start with an assessment of what exists and what it depends on, which is worth doing before committing to changes in unfamiliar code.
- Will customization break our next upgrade?
- Any customization adds upgrade cost. We reduce it by preferring configuration where possible and documenting dependencies where not, so the impact is known in advance rather than discovered during the upgrade.
Need help with Customization & Extensions?
Tell us about your Teamcenter environment and we will come back to you with how we would approach it.