Share data or services between two independent modules within the same main project

[MA8731174]

Hello everyone,

I have a setup where I’m working with a main project (Project A) that contains all the Things with configurations for two sub-modules:

• Project A – SubModule 1

• Project A – SubModule 2

Each sub-module is component of Project A, and all configurations are stored in Project A’s Things.
We have already published Project A as an extension on the production server, so both sub-modules are currently working independently (i.e., there’s no direct dependency or linkage between SubModule 1 and SubModule 2).

Now, we have a new requirement where we need to access data from SubModule 1 inside SubModule 2.
However, due to the independent structure and the way Project A is packaged, I cannot simply make one module depend on the other.

---

My current idea:

I’m considering creating a ThingTemplate inside the main Project A, and then creating corresponding Things for both SubModules 1 and 2 based on that template.
I could then write shared services inside this template and use the “Allow Override” option if I need to customize the logic separately for each sub-module.

This way, both modules would stay independent, but still have access to a shared service layer through the template defined in Project A.

Is this the best practice for achieving communication between two independent modules under one main project?

OR

Is there any alternative pattern that allows controlled data exchange or service usage between sub-modules while keeping them decoupled?

Any suggestions or best-practice guidance would be highly appreciated.
Thank you!

[TonyZhang]

Hi @MA8731174,

How exactly did you implement the sub-module concept within a single project in ThingWorx?

How did you create a component (sub-module) for a project?

Are Sub-Module 1 and Sub-Module 2 two separate projects, both depend on Project A (Set Project A in the Project Dependencies field in Project > General Information tab)

Providing some screenshots of your setup or modeling in ThingWorx could help community members understand your question better.

Also, please provide more explanation on why you cannot simply make one module depend on the other.

Best,

[MA8731174]

Thanks for your response!

To clarify — I have Project A as my main core project, and Project B and Project C both depend on Project A. The reason for this setup is that some customers only require Project B and some only need Project C, so I’ve separated them to keep things modular and maintainable.

In Project A, I’ve defined all the core configurations, datasets (Things), and shared logic that both projects can use. Each project (A, B, C) is deployed as an extension, where:

• Project A has no dependencies.

• Project B and Project C both depend on Project A.

• Project B and C each have their own SQL databases.

Now, the new requirement is that some data entries from Project B need to be shared with Project C and vice versa, because certain operations in one affect the other.

However, I want to avoid any direct dependency between B and C — otherwise it will quickly become spaghetti code and hard to maintain.

My idea is to use Project A as a middle layer, probably with a ThingTemplate or common service structure, to allow both modules to exchange data indirectly through Project A. I’m also considering the Service Override option in Things to handle customized logic for each project cleanly.

Would appreciate your thoughts if this approach sounds good, or if there’s a better recommended way to structure this kind of cross-module

communication in ThingWorx.

[TonyZhang]

Hi @MA8731174,

Thank you for your clarification. I understand your use case now.

In this case, for example, if Project B needs access to data in Project C but cannot depend on Project C, the only options left are 1) move the required logic to Project B directly or 2) to Project A, which Project B depends on

If you think the logic is reusable by both Project B and C, then the second option - moving the logic to Project A is definitely better. So yes, I think your approach in mind sounds good.

As for whether to use ThingTemplate or ThingShape, you can refer to the following documents.

Example: Using Things, Thing Templates or Thing Shapes

Modeling: Why do I have Thing Shapes and Thing Templates?

Best,

[Constantine]

The answer depends on the amount of the _functional_ coupling you have between your apps.

In the easy scenario, where you just need to share some server-side logic between projects, it is done exactly as you described it.

A bigger challenge is to share user interface and ultimately _access_ to data. For example, in Navigate you can have a project which manages BOMs, and another one for document management. Your BOM users will want to view documents attached to parts, so you’d need to reuse that part of the functionality somehow.

Now, if you approach this through your “share code” way, you’ll end up with moving a large part of your document management project into the shared one. I saw cases where entire projects got effectively merged by doing that, which obviously defeats the purpose of separating them in the first place.

The most pragmatic way to solve this problem would be to simply redirect the users to other projects when necessary. It’s easier when all of them are deployed on the same server, and a bit more challenging if they are segregated (you’d need to setup SSO and make sure all your mashups accept parameters, so that you can navigate to them from the outside).

So, in other words, don’t reuse, but redirect the user to the right app.

[MA8731174]

Thanks a lot for your detailed explanation — that really helped me think about the architecture from a coupling perspective.

To share more context about my current setup:

I’ve structured the solution using multiple modular projects.

• Project A serves as the core logic layer. It contains all the main application components such as Things (business logic and shared services), Mashups, and rights management.

• Project B and Project C both depend on Project A. In Project A, I’ve implemented logic that dynamically calls data either from B or C — depending on the operation. I’ve also assigned the relevant user rights in Project A.

On top of these three projects, I created separate configuration projects: Project A Configs, Project B Configs, and Project C Configs.
Each of these holds configuration-related Things (datasets), User Groups, and Users. This allows me to keep business logic and configuration data independent.

My deployment flow is:

1. Deploy Project A, B, C as extensions.

2. Then import/export the Config projects (A Configs, B Configs, C Configs) normally.

In this setup, Project A remains the dependency for B and C. The dataset Things of B and C are stored in Project A and are used there to retrieve and process data. Users have platform-level permissions, but I’ve also implemented an additional service layer in Project A that checks if a user belongs to the correct User Group before allowing access to a specific Mashup or dataset.

Now, for data exchange between Project B and Project C, I’ve created a ThingTemplate in Project A and use the Service Override option. This allows both modules to exchange data through Project A without creating direct dependencies between them — essentially keeping the modules decoupled while still enabling controlled cross-communication.

For both B and C, I’ve created Things based on this shared ThingTemplate, and everything is currently working as expected.
I’ll share more details and final results later, but thanks again to both of you for your insights — it really helped refine the approach.

Best regards,

[Constantine]

@MA8731174 Do you split those into separate projects just to simplify maintenance, or also to be able to deploy them independently?