Close popover
Terrance Krolak (TerranceK4053)

TerranceK4053 Member since 2018 46 posts
Posted: December 7, 2018
Last activity: January 11, 2019

Supporting multiple implementations

I am building a product dealing with health care claims. I have a framework. I have a need to support multiple implementations off of this framework, one each for our different clients/customers. I create a separate division in the division layer that represents each client. Each client implementation has its own work pool and therefore its own work table. To create work objects for one implementation versus another it would seem separate activities are needed since the work class names are obviously different. Is there a way around having to create separate rules/activities for each implementation to spawn off work objects? Perhaps they can be parameterized I suppose might be the answer?

Each client will have their own claims so there is a common data class but we don't want claims for multiple implementations intermingled. Therefore it would seem we need a different table for each implementation to house their claims. This would seem to require each implementation to have their own data class representing their claims? This would then mean the code (-ie- activities and ..) using these data classes would have to be specific to each implementation which is unfortunate because for the most part the logic would all be the same.

The users of the implementations would all be our in house people so there is no segregation there.

How can we avoid having to support multiple copies of the same rules with the same logic for each implementation as described above? Split schemas? Multitenancy?

Low-Code App Development
Moderation Team has archived post