Hi Community,
I am currently working on an integration scenario where I consume data from multiple external APIs (e.g., SAP, APLUs and 4 additional interfaces ).
Each API delivers data in a slightly different structure, but the overall processing logic in ThingWorx is quite similar:
Call external API
Receive data
Perform transformation / validation
Execute business logic
Return structured output
To avoid duplication and improve maintainability, I am considering the following generic approach:
Create a Thing Template that contains:
Generic input definitions (API endpoint, headers, payload, etc.)
A standardized output structure (e.g., JSON)
Shared services for:
API execution
Data transformation
Error handling
Logging
Then create individual Things inheriting from this Thing Template for each interface (SAP APLUs, Interface2, Interface3, etc.)
Override only specific logic where necessary
This way:
Core logic is centralized
Services are inherited
Interfaces remain configurable
Maintenance effort is reduced
Is using a Thing Template as a generic integration base considered a good architectural approach in ThingWorx? Would you recommend a different pattern (e.g., separate Integration Things + shared Utility Thing, Resource-based approach, etc.)?
Is there a more professional or scalable way to implement a reusable integration framework inside ThingWorx?
My goal is to build a clean, reusable, and enterprise-ready structure instead of copying services across Things.
Thank you very much in advance for your advice and best practices!
Hi @MA8731174
Your approach sounds reasonable to me. In particular, for reusable logic or common properties, I would recommend leveraging Thing Shapes as much as possible—especially in more complex implementations:
https://support.ptc.com/help/thingworx/platform/r10.0/en/#page/ThingWorx/Help/Best_Practices_for_Developing_Applications/ThingsThingTemplatesThingShapes.html
For building a more scalable and reusable integration structure, you may also want to reference the ‘Building Blocks’ concept. This provides best‑practice suggestions on creating modular, reusable components that can be applied across multiple interfaces:
