cancel
Showing results for 
Search instead for 
Did you mean: 

Design Guidelines for SAP CAP Reusable Data Models

iperez-sofos
Participant
0 Kudos

Greetings.

I am working on a project to develop an application for the field of agriculture. I am working with SAP CAP and SAP HANA DB.

In addition to the data models typical of the problem domain, I have also created a small data model of commonly used objects/concepts: Geographic Regions, Units of Measure, Periodic Dates, and other minor ones.

For this second data model (which, for simplicity, I'm going to name here as COMMON), in addition to the model definition file (CDS file), I have several store procedures written in SAP HANA SQLScript. That's all.

However, since the second model is more or less "Universal" I would like to separate it into a separate project and use it in my agriculture app., as well as being able to reuse it in later projects.

This is to raise general doubts about whether it is convenient (or a good design practice) to do what I think, and above all the best way to do it (have certain guidelines in this regard).

Particular questions:

1. Should I create a new project for my model COMMON or just create another module within my agricultural application (which follows the SAP CAP model)?

2. In case of creating another project for COMMON (the option that in principle I have thought to choose), I understand that I must use synonyms for the tables, views, store procedures, etc. Is this correct? How do you do with the CDS file (the definition of the model COMMON)? Can you also create a synonym for that? I need to be able to use the definitions in there (entities, views, and types) in the CDS models of my agriculture app. Is it possible?

3. If I put the COMMON model in another project, would it be convenient to define a UI (service module) for it or should the project only have the Database module?

Thank you in advance for any help and/or suggestions regarding these questions.

Accepted Solutions (0)

Answers (1)

Answers (1)

lbreddemann
Active Contributor
0 Kudos

Ok, you have some stuff that you believe may be reusable in other projects.

How sure are you that you actually will reuse it in exactly the same way? If that's anywhere below 100% I'd recommend considering "sharing" the solution via copy & paste instead of tying the two otherwise independent projects together by a shared dependency.

And in no way should these considerations lead to expanding the scope, i.e. building a UI where there is none right now. If your solution needs the UI to work; by all means, build that UI. Otherwise, keeping things as simple as possible is the guideline that served me best so far.

Concerning the "universal" concepts like unit of measure, dates, etc. - these often turn out to be not that universal and the best representation highly depends on how these will be used. Standardising these "obvious universals" across different projects can easily turn out to be painting yourself into a corner.

So, there you go. Now you know! At least my opinion 🙂