Flusso di lavoro applicazione CBDC all'ingrosso

Dopo aver installato e configurato l'applicazione CBDC all'ingrosso di esempio, è possibile utilizzarla in scenari in cui un proprietario di sistema (una banca centrale) e le organizzazioni partecipanti (altri istituti finanziari) interagiscono in un mercato interbancario.

L'applicazione di esempio supporta undici ruoli o persone. Ogni ruolo ha un'interfaccia e un set di operazioni diversi che supportano l'intero flusso di lavoro della gestione dei token nello scenario CBDC all'ingrosso.

Ruoli sistema

  • Amministratore di sistema: gestisce l'intero sistema.
  • Creatore di sistema: crea i token. Una volta sottomessa, una richiesta di creazione viene inviata al manager di sistema, che approva o rifiuta la richiesta. Dopo l'approvazione della richiesta di conio, i token vengono accreditati sull'account del creatore del sistema. Il creatore può quindi trasferire questi token a un emittente di sistema.
  • System Manager: approva o rifiuta le richieste di generazione, masterizzazione e blocco dei token. Le approvazioni delle richieste di blocco vengono utilizzate per i trasferimenti tra organizzazioni.
  • Emittente del sistema: trasferisce i token ai funzionari dell'istituto finanziario o al pensionato del sistema per la combustione. Gli utenti con questo ruolo ricevono i token dal creatore del sistema e dai responsabili degli istituti finanziari. Il responsabile del sistema deve approvare qualsiasi trasferimento tra organizzazioni.
  • Auditor di sistema: dispone dell'accesso in sola lettura a tutti i dati organizzativi nel sistema.
  • Ritiro del sistema: brucia i token. Questo ruolo riceve i token dall'emittente del sistema. Una volta sottomessa, una richiesta di masterizzazione viene inviata al responsabile del sistema.

Ruoli dell'organizzazione

  • Amministratore organizzazione: gestisce l'organizzazione specifica.
  • Responsabile organizzazione: riceve i token dall'emittente del sistema. Possono trasferire questi token agli utenti di qualsiasi organizzazione o restituire i token all'emittente del sistema. Tutti i trasferimenti devono essere approvati dall'approvatore dell'organizzazione.
  • Utente organizzazione: riceve i token dai funzionari delle rispettive organizzazioni. Possono trasferire questi token a utenti e funzionari di qualsiasi organizzazione. Tutti i trasferimenti devono essere approvati dall'approvatore dell'organizzazione.
  • Responsabile organizzazione: approva o rifiuta le richieste di blocco per l'organizzazione specifica. Le richieste di blocco e le approvazioni vengono utilizzate per tutti i trasferimenti tra organizzazioni o all'interno di organizzazioni.
  • Auditor organizzazione: dispone dell'accesso in sola lettura ai dati specifici della propria organizzazione.

Inserimento

Dopo aver installato, configurato e posizionato nell'area intermedia dell'applicazione, attenersi alla procedura riportata di seguito per accedere all'applicazione.

  1. Dopo aver posizionato l'applicazione nell'area intermedia, tornare alla home page.
  2. Nel dashboard dell'applicazione, individuare l'applicazione posizionata nell'area intermedia. Lo stato viene visualizzato come In attesa accanto al nome dell'applicazione.
  3. Fare clic sul menu a discesa in In attesa e selezionare il nome dell'applicazione.
  4. Copiare il collegamento o aprire l'applicazione posizionata nell'area intermedia in una nuova scheda o finestra del browser per eseguire il test e rivedere l'applicazione.

In modalità generica, tutti gli account vengono visualizzati e tracciati in base agli ID utente. In modalità riservata, i conti vengono visualizzati e tracciati in base agli ID dei conti bancari. Gli ID conto bancario sono stringhe alfanumeriche casuali generate al momento della creazione del conto. In modalità riservata, l'ID conto bancario sostituisce l'ID utente nell'interfaccia dell'applicazione.

In modalità riservata, i saldi dei conti vengono calcolati su richiesta utilizzando un metodo di consolidamento (consolidateRunningBalanceInTransactions), definito nel codice concatenato. Quando viene eseguito il consolidamento, vengono elaborate tutte le transazioni in sospeso e viene aggiornato il saldo del conto. I saldi contabili sono disponibili solo dopo l'esecuzione del consolidamento per un'organizzazione. Se il consolidamento non è stato eseguito per un'organizzazione, i saldi dei conti vengono visualizzati come Riconciliazione in sospeso.

Il metodo consolidateRunningBalanceInTransactions consolida i saldi contabili per l'organizzazione del chiamante. Questo metodo può essere chiamato da un Token Admin o Org Admin. I proprietari del sistema devono eseguire l'autenticazione utilizzando l'account utente SYSTEM_ADMINS associato al ruolo token tokenAdmin. Le organizzazioni partecipanti devono eseguire l'autenticazione utilizzando i rispettivi account utente ORG_ADMINS, ognuno dei quali è associato al ruolo token orgAdmin.

Per garantire l'accuratezza dei saldi dei conti in tutta la rete, è necessario eseguire il metodo di consolidamento a intervalli regolari. È possibile utilizzare l'endpoint API REST scheduleTransactions in Oracle Blockchain Platform per eseguire il consolidamento automaticamente. Per ottenere risultati ottimali, impostare lo scheduler in modo che venga eseguito ogni due minuti e impostare la stringa di scadenza su un valore elevato, ad esempio 120M (dieci anni). Per ulteriori informazioni, vedere Programmazione della transazione da eseguire.

Quando un utente tenta di eseguire il login all'applicazione, il sistema controlla che l'utente disponga di un account e del ruolo appropriato. Se l'account non esiste o se il ruolo richiesto è assente, viene visualizzato il seguente errore.
Invalid Account. Please Contact Admin
L'interfaccia visualizzata dopo il login di un utente dipende dal ruolo di tale utente.

La prima volta che un utente tenta di eseguire il login all'applicazione, non è ancora stato creato alcun account utente. È possibile eseguire il login solo agli utenti del gruppo System_Admins a cui è assegnato anche il ruolo tokenAdmin. Tutti gli altri tentativi di login non riusciranno. La sezione seguente include ulteriori informazioni sull'eccezione per l'utente tipo SYSTEM_ADMINS.

Eccezione System_Admins

Il processo di login è diverso per gli utenti con l'utente tipo SYSTEM_ADMINS. Gli utenti del gruppo System_Admins possono eseguire il login anche se il loro account non è stato ancora creato, ma questi utenti devono avere il ruolo tokenAdmin.

Quando si distribuisce il codice concatenato, assicurarsi che gli utenti del gruppo System_Admins dispongano del ruolo tokenAdmin. I parametri passati durante l'inizializzazione del codice concatenato devono includere gli utenti amministratore di sistema come aventi il ruolo tokenAdmin. Ciò consente al gruppo System_Admins di eseguire il login all'applicazione per la prima volta per creare gli altri account utente.

Se si esegue il login all'applicazione come utente nel gruppo System_Admins e tale utente non è stato incluso come parametro di inizializzazione al momento della distribuzione del codice concatenato, è necessario assegnare manualmente il ruolo tokenAdmin all'utente. È possibile assegnare manualmente il ruolo tokenAdmin utilizzando una raccolta Postman.

Flusso di lavoro candidatura

I passi riportati di seguito mostrano le azioni dei vari ruoli in un flusso di lavoro completo dell'applicazione. Per utilizzare l'applicazione è necessario completare i primi sette passi.

  1. L'amministratore di sistema esegue il login.
  2. L'amministratore di sistema inizializza il token.
  3. L'amministratore di sistema crea il proprio conto bancario e quindi ricarica la home page per visualizzare i dettagli di rete aggiornati.
  4. L'amministratore di sistema crea conti bancari per tutti gli utenti tipo di CBDC, come illustrato nella tabella seguente.
    Gruppo di applicazioni Ruolo
    System_Admins Token Admin
    System_Auditors Token Auditor
    System_Creators Minter
    System_Managers Escrow
    System_Issuers nessuno
    System_Retirers Burner
  5. L'amministratore di sistema crea i conti bancari dell'amministratore dell'organizzazione che dispongono del ruolo Org Admin.
  6. Solo modalità riservata: l'amministratore di sistema e gli amministratori dell'organizzazione configurano lo scheduler per eseguire automaticamente il consolidamento. Ciò garantisce che i saldi contabili visualizzati siano accurati. Per ulteriori informazioni, vedere Programmazione della transazione da eseguire.
  7. L'amministratore dell'organizzazione esegue il login e crea account per gli utenti dell'organizzazione.
  8. L'amministratore di sistema assegna i ruoli ai nuovi utenti dell'organizzazione, come mostrato nella tabella seguente.
    Gruppo di applicazioni Ruolo
    Org_Admins Org Admin
    Org_Users nessuno
    Org_Officers nessuno
    Org_Managers Escrow
    Org_Auditors Org Auditor
  9. L'autore del sistema esegue il login e richiede la visualizzazione dei token.
  10. Il responsabile del sistema esegue il login e approva o rifiuta la richiesta di stampa. Se la richiesta viene approvata, i token vengono accreditati all'autore del sistema.
  11. Il creatore del sistema trasferisce i token all'emittente del sistema.
  12. L'emittente del sistema esegue il login e trasferisce i token a un responsabile dell'organizzazione. Se il trasferimento viene approvato dal system manager, i token vengono trasferiti. In alternativa, l'emittente del sistema può trasferire i token allo smobilizzo del sistema per la masterizzazione.
  13. L'auditor di sistema esegue il login, seleziona i criteri di audit ed esamina i dati delle transazioni pertinenti.
  14. Il pensionato di sistema esegue il login e richiede che i token vengano ritirati. Se il manager di sistema approva, i token vengono bruciati.
  15. Il manager di sistema esegue il login e approva o rifiuta la richiesta di emissione di token. Se il trasferimento viene approvato, i token vengono accreditati al responsabile dell'organizzazione, che può quindi trasferirli agli utenti dell'organizzazione.
  16. Il responsabile dell'organizzazione esegue il login e trasferisce i token agli utenti dell'organizzazione, ad altri funzionari dell'organizzazione o al proprietario del sistema. Tutti i trasferimenti richiedono l'approvazione del manager dell'organizzazione.
  17. Il manager organizzazione esegue il login e approva o rifiuta le richieste di trasferimento.
  18. gli utenti dell'organizzazione eseguono il login e trasferiscono i token ad altri utenti dell'organizzazione di qualsiasi organizzazione.
  19. Il revisore dell'organizzazione esegue il login, seleziona i criteri di audit ed esamina i dati delle transazioni pertinenti.