Condivisione degli HDI Container tra diversi progetti SAP CAP
Vediamo come è possibile riutilizzare le stesse tabelle all’interno di diversi microservizi che risiedono nello stesso space di Cloud Foundry.
Microservizi
Il primo microservizio, quello principale dove è definita l’entity che riutilizzeremo all’interno degli altri progetti CAP, è Anagrafica. Nel primo caso di studio troviamo l’applicativo Dipendenti che condivide con Anagrafica lo stesso HDI-Container e lo stesso namespace. Certificazioni utilizza lo stesso HDI-Container ma ha un namespace diverso. Infine, vedremo come collegare Anagrafica con Documenti che ha differenti sia il container HDI che il namespace.
Premessa
L’entity Anagrafica viene così definita nel file cat-service.cds
Mentre nel file mta.yaml definiamo l’HDI-Container
Caso 1: Anagrafica + Dipendenti
Il primo passo consiste nella definizione dell’entity da riutilizzare indicando che non è persistita attraverso l’annotation @cds.persistence.exists. In questo modo, stiamo indicando al framework CAP che l’entity esiste già all’interno dell’HDI-Container e che, non va creata di nuovo.
L’HDI-Container è stato già creato nel file mta.yaml del progetto CAP Anagrafica; quindi, bisogna indicare che la risorsa già esiste nello space, indicando come type org.cloudfoundry.existing-service
Caso 2: Anagrafica + Certificazioni
Come nel caso 1, l’entity Anagrafica, già presente nell’HDI-Container, viene definita attraverso la stessa annotation. Nell’esempio viene richiamata anche l’entity Dipendenti per la quale viene adottata la stessa configurazione di Anagrafica, poiché entrambe sono definite nel medesimo namespace. In seguito, si farà riferimento solo ad Anagrafica per semplicità.
In questo modo, è stata definita master.org.Anagrafica (diversa dall’entity “originale” master.hr.Anagrafica). Per comunicare al framework CAP che ci stiamo riferendo alla stessa tabella, bisogna configurare un file di tipo .hdbsynonym
Nel file mta.yaml la risorsa dell’HDI-Container è definita in modo analogo al caso precedentemente esposto.
Caso 3: Anagrafica + Documenti
In questo scenario, i due microservizi non condividono né il namespace, né l’HDI-Container. Per il primo adotteremo lo stesso principio del caso precedente, ovvero l’utilizzo dei sinonimi, mentre per la condivisione dell’HDI bisognerà implementare una configurazione più complessa per assegnare dei ruoli e dei privilegi al servizio chiamante.
Vediamo prima i file da configurare nel progetto CAP Anagrafica
Nella cartella db/src inseriamo due file .hdbrole per permettere l’accesso dall’esterno all’entity Anagrafica. Attraverso gli hdbrole possiamo indicare quali privilegi si hanno su determinate tabelle se si è in possesso di quel ruolo. Successivamente, nel progetto Documenti, assegneremo questi ruoli per permettere la comunicazione tra diversi HDI-Container.
I due ruoli sono molto simili tra loro. La differenza sta nel fatto che nel secondo si ha un privilegio con grant option sulla SELECT della tabella master.hr.Anagrafica.
Facciamo partire il deploy di Anagrafica e passiamo sul progetto Documenti
Utilizziamo la solita annotation per dichiarare l’entity non persistita
Definiamo il sinonimo in maniera leggermente diversa: il file .hdbsynonym è sostanzialmente vuoto perché la sua configurazione viene specificata nel file .hdbsynonymconfig sotto il path db/cfg. In questo modo possiamo fornire il nome dello schema al sinonimo.
Gli artefatti presenti nella cartella db/cfg verranno processati per primi durante la fase di deploy.
“master-db-hdi” è un alias per l’HDI-Container “master-db” che verrà definito nell’mta.yaml tramite la keyword SERVICE_REPLACEMENTS. In questo modo i file di configurazione non sono legati direttamente al nome del container. Eventuali modifiche al nome dell’istanza di “master-db” non influiranno sul nostro progetto (bisognerà solamente cambiare il nome della risorsa nell’mta.yaml)
Il prossimo passo consiste nell’assegnare i privilegi agli utenti dell’HDI-Container nel file .hdbgrants, affinché possano accedere all’entity Anagrafica. Assegnamo i ruoli creati in precedenza all’application_user, cioè l’utente finale che utilizzerà il progetto CAP, e all’object_owner, ovvero al creatore dell’oggetto nell’HDI-Container
Non ci resta che aggiungere la risorsa da riutilizzare (master-db) al nostro mta.yaml
Conclusioni
Abbiamo visto come riutilizzare delle entity all’interno dei microservizi deployati nello stesso space. Di seguito una tabella che riassume i vari scenari e indica quali sono i file da configurare in base alla corrispondeza tra i namespace e gli HDI-Container dei due servizi coinvolti.
Vuoi maggiori informazioni?
Vuoi approfondire l’argomento e ottenere maggiori informazioni o supporto da parte dei nostri developer?