ExternalId sembra essere nient'altro che una funzione che fornisce il login SAP attuale.
Quando si descrive una registrazione di attività, inclusa l'identificazione di chi ha svolto l'attività è normale. È previsto. Decidere quale ID usare è diverso.
Sei interessato a registrare il nome utente esterno come determinato dal sistema sottostante, o sei interessato a fornire il nome utente per quanto riguarda il dominio dell'applicazione logica?
È plausibile che la società acquirente abbia più di un acquirente autorizzato. Probabilmente, questo è uno scenario comune. Questo è probabilmente un caso chiaro in cui è importante includere l'identificazione dell'attore in questo disco d'azione.
In questo caso, l'ID utente in questione non è un ID utente interno logico. Invece, è un ID utente esterno fornito da un sistema fisico. Mentre utilizzare l'ID utente del sistema esterno come mezzo di comodo per l'autenticazione è ottimo, sarei riluttante a raccomandare l'utilizzo come base dell'identificazione interna per le domande di autorizzazione. Invece, armonizza o traduci gli ID utente esterni in ID utente interni logici dell'applicazione.
La registrazione degli ID utente esterni è ottima perché offre l'opportunità di controllare l'accesso al sistema e i modelli di utilizzo. Tuttavia, c'è un conflitto. È un utente logico che accede da una macchina Windows diversa da un utente che accede da una macchina UNIX anche quando effettivamente è la stessa persona o servizio? Cosa succede se lo schema / database viene portato / ospitato / replicato su un sistema diverso, che utilizza un controllo di accesso al database diverso e utilizza uno schema di nome del database diverso? Invece di aggiungere un'altra mappatura degli ID utente esterni all'ID utente logico interno, potrebbe essere necessario trasformare anche i dati precedenti.
Separando gli ID utente esterni in una tabella utente, è possibile scegliere di associare diversi accessi al sistema con utenti logici identici o diversi. Prevenendo anche il sanguinamento degli ID utente di sistema esterni nei dati delle applicazioni logiche, si fornisce una certa protezione ai dati nel caso in cui le future implementazioni forniscano schemi di autenticazione diversi.
La terza ragione per isolare i nomi utente esterni dai nomi utente del dominio logico interno è nel caso di rappresentazione o delega. A volte un utente è autorizzato e prevede di eseguire azioni per conto di terzi, in cui l'azione dovrebbe essere normalmente vista come eseguita dal delegante, ma forse con qualche passo importante che indica che si è verificata la delega e chi ha assunto l'identità successiva (e altre informazioni pertinenti della sessione ).
User
|UserId(PK) |PersonaId |AuthExternSAP |GoogleOAuth2 |
|1 |1 |PO0313-0001 | |
|2 |1 | |345345324 |
Customer
|CustomerId(PK) |UserId |
|1 |1 |
CustomerPurchase
|CustomerPurchaseId (PK) |CustomerId |TotalQty |SellableResourceId |
|1 |1 |10 |1 |