Posted: 7 Dec 2018 9:13 EST Last activity: 11 Jan 2019 13:26 EST
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?
If you have the Work and Data classes defined with Data-Admin-DB-Tables routing them to the appropriate tables, you should be able to design your application in such a way that most of the work is done on the primary page. Then you have one activity that you stub out at the shared layer and create at the implementation layer to call the process with a page of the correct class. You might be able to parameterize this, but you'll still need something somewhere to populate that parameter, so I'm not really sure what more it gets you. Once you are in the proper class context, you can leverage things like the class specific pyDefault data transform to load implementation specific data into the clipboard.