Déployer et tester des API Wrapper pour Stablecoin

Déploiement du paquetage d'API de l'encapsuleur

Avant de déployer l'ensemble d'API d'encapsuleur, vous devez mettre à jour les variables de configuration requises. Certaines variables de configuration ont des valeurs par défaut, mais vous devez mettre à jour manuellement toute variable contenant un paramètre fictif en tant que valeur par défaut. Les variables de configuration sont stockées dans le fichier terraform.tfvars dans l'archive de l'API d'encapsulation. Pour plus d'informations sur le déploiement des API d'encapsuleur et sur les variables de configuration, voir API d'encapsulation dans Blockchain App Builder for Oracle Blockchain Platform. Le tableau suivant répertorie les variables de configuration et leurs valeurs par défaut pour le package API wrapper stablecoin.

Nom de variable Valeur par défaut Description
compartment_ocid <compartment_ocid> OCID du compartiment dans Oracle Cloud Infrastructure (OCI).
compartment_name <compartment_name> Nom du compartiment OCI.
identity_domain <identity_domain> Domaine d'identité à utiliser.
blockchain_channel <blockchain_channel> Nom du canal Oracle Blockchain Platform où le code de chaîne est déployé.
blockchain_url <blockchain_url> URL d'Oracle Blockchain Platform associée au déploiement du code de chaîne.
blockchain_chaincode Stablecoin Nom du code de chaîne pour lequel générer des API d'encapsuleur.
blockchain_sync true Valeur de synchronisation à inclure dans les données utiles pour les appels d'API.
blockchain_timeout 6000 Valeur de temporisation à inclure dans les données utiles pour les appels d'API.
vcn_display_name Stablecoin Nom d'affichage du réseau en nuage virtuel OCI.
application_display_name Stablecoin Nom d'affichage de l'application OCI.
gateway_display_name Stablecoin Nom d'affichage de la passerelle d'API.
deployment_display_name Stablecoin Nom d'affichage du déploiement dans la passerelle d'API.
deployment_path_prefix /Stablecoin Préfixe du chemin de déploiement dans la passerelle d'API, qui spécifie le chemin où les routes sont déployées. La variable deployment_path_prefix doit commencer par une barre oblique (/).
ocir_repo_name Stablecoin Nom du référentiel du registre OCI. La variable ocir_repo_name doit contenir toutes des lettres minuscules.
policy_name Stablecoin Nom de la politique qui permet la gestion contrôlée et l'accès aux API au moyen d'autorisations définies pour les groupes et les compartiments de l'organisation.

Flux de processus d'échantillonnage Stablecoin

Un flux de processus typique utilisant les API de wrapper stablecoin suit ces étapes de base.
  1. L'administrateur de jeton utilise la méthode initializeStablecoinToken pour initialiser un stablecoin avec une valeur currencyName fixe (par exemple, USD) et une valeur conversionRate.
  2. L'administrateur de jeton utilise les méthodes createAccount et associateTokenToAccount pour créer des comptes de jeton pour tous les utilisateurs (approbateurs à plusieurs niveaux, approbateurs, notaires, expéditeurs et destinataires).
  3. L'administrateur de jeton utilise la méthode createStablecoinAccountPolicyCheck pour créer des politiques de compte. Les politiques de compte sont obligatoires pour tous les comptes qui transfèrent ou détiennent des stablecoins. Chaque politique de compte comprend trois paramètres : KYC, AML et restrictionFlag.
    KYC (Connaître le client)
    Le transfert n'est autorisé que lorsque les valeurs Connaissance du client sont true pour les comptes d'expéditeur et de destinataire.
    AML (Anti-Money Laundering)
    Le transfert n'est autorisé que lorsque les valeurs de liste de fabricants approuvés sont true pour les comptes d'expéditeur et de destinataire.
    restrictionFlag
    Si l'indicateur de restriction est réglé à true pour le compte de l'expéditeur ou du destinataire, le transfert n'est autorisé que dans l'intervalle de tranches de politique d'approbation le plus bas, ce qui rend une politique d'approbation obligatoire.
  4. L'administrateur de jeton utilise createApprovalPolicyCheck pour créer une politique d'approbation. Les politiques d'approbation définissent les seuils de transaction, le nombre requis d'approbations et les détails de l'approbateur, et définissent la séquence des approbations à plusieurs niveaux. Une politique d'approbation est obligatoire pour une opération de blocage. Sans politique d'approbation, les utilisateurs ne peuvent pas bloquer ou transférer des jetons lorsque des restrictions s'appliquent.
  5. L'administrateur de jeton utilise la méthode addRole pour affecter les rôles d'hôte, de brûleur et de notaire aux comptes appropriés.
  6. Le minter utilise la méthode requestMint pour soumettre une demande de mint stablecoins.
  7. Le notaire utilise la méthode approveMint pour approuver la demande de frappe.
  8. L'expéditeur utilise la méthode holdTokens pour lancer un transfert. Le système exécute une vérification de la politique de compte pour l'expéditeur et le destinataire. Si la conformité KYC ou AML n'est pas satisfaite pour l'un ou l'autre des comptes, le transfert n'est pas autorisé. Si l'indicateur de restriction est réglé à true pour l'un ou l'autre des comptes, seul le montant dans l'intervalle de seuil de politique d'approbation le plus bas peut être bloqué. Le montant de transfert est ensuite comparé aux seuils de la politique d'approbation, et les approbateurs requis et leurs séquences d'approbation sont dérivés de la politique d'approbation.
  9. Les approbateurs multiniveaux utilisent la méthode approveTransaction pour vérifier et autoriser le transfert selon la séquence exacte définie dans la politique d'approbation. Si la politique d'approbation spécifie zéro approbateur, le notaire peut utiliser la méthode executeHoldTokens directement pour terminer la transaction. Le système revalide la conformité KYC et AML et l'indicateur de restriction lors de chaque appel à executeHoldTokens et approveTransaction. Si un chèque échoue, la transaction est bloquée.
  10. Une fois toutes les approbations terminées avec succès, le notaire affecté utilise la méthode executeHoldTokens pour terminer le transfert vers le compte du destinataire.
  11. Le brûleur utilise la méthode requestBurn pour soumettre une demande de gravure de stablecoins.
  12. Le notaire utilise la méthode approveBurn pour approuver la demande de gravure.
  13. Les administrateurs et les vérificateurs de jeton utilisent getStablecointAccountTransactionHistory et getStablecoinAccountTransactionHistoryWithFilters pour suivre tous les événements de jeton, y compris la frappe, le blocage, les flux d'approbation à plusieurs niveaux, les transferts et la gravure.

Collection Postman

La collection Postman du package API wrapper stablecoin comprend des attributs et des méthodes supplémentaires qui prennent en charge le code de chaîne stablecoin. Le tableau suivant montre les variables de collection Postman qui sont spécifiques au paquet stablecoin.
Variable Description Valeur par défaut
bc-instance-client-id ID client du service Oracle Blockchain Platform Cloud. bc-instance-client-id
bc-instance-client-secret Clé secrète client du service Oracle Blockchain Platform Cloud. bc-instance-client-secret
int-app-client-id ID client de l'application confidentielle Oracle Identity Cloud Service (IDCS), utilisée pour créer un utilisateur IDCS dans l'API d'utilisateur CreateIDCS. int-app-client-id
int-app-client-secret Clé secrète client de l'application confidentielle IDCS, utilisée pour créer un utilisateur IDCS dans l'API d'utilisateur CreateIDCS. int-app-client-secret

Pour plus d'informations, voir Composants d'ensemble d'API d'encapsulation dans Blockchain App Builder pour Oracle Blockchain Platform.