Composants d'ensemble d'API d'encapsuleur

Les ensembles d'API d'encapsulation contiennent un fichier d'archives des API d'encapsulation, un script Terraform pour le déploiement et une collection Postman correspondante.

  • Le fichier d'archives de l'API d'encapsuleur est nommé <ChaincodeName>WrapperAPI.zip. Il contient également un script Terraform qui doit être déployé dans la ressource de pile.
  • Le fichier de collection Postman est nommé <ChaincodeName>_WrapperAPI.postman_collection.json. Vous pouvez utiliser cette collection pour appeler toutes les API du wrapper.

Ensemble API d'encapsuleur

L'ensemble d'API d'encapsulation contient un script Terraform qui provisionne toutes les ressources Oracle Cloud Infrastructure (OCI) nécessaires à la création des API d'encapsulation. Il existe des fichiers de prise en charge Terraform supplémentaires et un dossier Oracle Functions pour chaque API. Les ensembles d'API d'encapsuleur créent les ressources OCI suivantes.

  • Réseau en nuage virtuel (VCN) : Établit l'infrastructure de réseau pour la communication.
  • Applications (Oracle Functions) : Déploie des fonctions sans serveur pour gérer la logique d'API.
  • Passerelle d'API : Crée la passerelle pour gérer et acheminer les demandes d'API.
  • Déploiement d'API : Configure et déploie les API sur la passerelle d'API.
  • Politique de déploiement d'API : Configure les politiques IAM nécessaires pour activer l'accès sécurisé.
  • Registre OCI : Fournit un registre de conteneurs pour la gestion des images Docker.
Après avoir généré des API d'encapsuleur, si vous voulez modifier des variables de configuration, vous pouvez les mettre à jour dans Visual Studio Code, ou vous pouvez extraire l'ensemble d'API d'encapsuleur et mettre à jour le fichier terraform.tfvars avec des points d'extrémité et des noms de ressource mis à jour et le fichier routes.go avec des points d'extrémité mis à jour. Modifiez la variable function_paths dans le fichier terraform.tfvars pour mettre à jour un point d'extrémité. La variable function_paths définit des points d'extrémité avec la syntaxe suivante : {endpoint, methodType}. Le texte suivant présente un exemple de variable function_paths.
function_paths="[{\"endpoint\":\"/activateCBDCAccount\",\"methodType\":[\"POST\"]},{\"endpoint\":\"/addCBAdmin\",\"methodType\":[\"POST\"]},{\"endpoint\":\"/approveBurn\",\"methodType\":[\"POST\"]}]"
Le fichier routes.go se trouve dans le dossier <ChaincodeName>OCIFunction. La variable routeData contient des métadonnées pour toutes les routes créées dans la passerelle, notamment le nom de la route, les arguments et l'existence d'arguments facultatifs. Lorsque vous mettez à jour un point d'extrémité dans la variable function_paths dans le fichier terraform.tfvars, vous devez également mettre à jour l'entrée correspondante dans la variable routeData dans le fichier routes.go, comme illustré dans l'exemple suivant.
var routeData = map[string]Route{
    "/activateCBDCAccount": {
        Args:           []string{"activateAccount", "orgId", "userId", "tokenId"},
        OptionalParams: true,
    },
}

Collection Postman

Les collections Postman prennent désormais en charge le code de chaîne confidentiel et l'authentification OAuth 2.0. Pour plus d'informations, voir Améliorations apportées aux collections Postman.

La collection Postman comprend des points d'extrémité et des données utiles mis à jour pour toutes les API. Le code suivant présente un exemple de données utiles.
{
    "orgId": "{{bc-org-id}}",
    "userId": "user1",
    "tokenType": "fungible",
    "applicationGroups": "[\"application_groups value\"]",
    "dailyLimits": "{\"max_daily_amount\":10000,\"max_daily_transactions\":100}",
    "endorsers": {{endorsers}}
}
Le tableau suivant présente les variables de collection Postman.
Variable Description Valeur par défaut
bc-admin-user L'utilisateur administrateur, qui a le rôle admin et peut accéder à toutes les demandes POST. Par défaut, cet utilisateur est l'appelant de toutes les demandes POST du code de chaîne. valeur bc-admin-user
bc-admin-user-password Mot de passe de l'administrateur. valeur bc-admin-user-password
bc-org-id ID organisation par défaut dans toutes les demandes POST, où orgId est le nom du paramètre valeur bc-org-id
bc-user-id ID utilisateur par défaut dans toutes les demandes POST, où userId est le nom du paramètre valeur bc-user-id
bc-token-id ID jeton par défaut dans toutes les demandes POST, où tokenId est le nom du paramètre valeur bc-token-id
endorsers Le tableau des endossateurs répertorie les pairs spécifiques (par exemple : peer1, peer2) pour endosser cette transaction. ["org1-xyz-abc.blockchain.ocp.oraclecloud.com :20009", "org2-xyz-abc.blockchain.ocp.oraclecloud.com :20009"]
api-gateway-endpoint Point d'extrémité de chaque demande, qui sert de chemin de base pour les points d'extrémité d'API d'encapsulation.

S'il y a moins de 50 API, un seul point d'extrémité est utilisé. S'il existe plus de 50 API, les points d'extrémité sont générés dynamiquement en tant que api-gateway-endpoint1, api-gateway-endpoint2, etc., en fonction du nombre d'API.

https://xyz.apigateway.region.oci.customer-oci.com/CBDC
bc-url URL mandataire REST de l'instance Oracle Blockchain Platform. https://test-xyz-abc.blockchain.ocp.oraclecloud.com:7443/restproxy
access-token-url URL du jeton d'accès Oracle Identity Cloud Service (IDCS). Par exemple : <idcs_endpoint>/oauth/v1/token valeur access-token-url
client-id ID client de l'instance Oracle Blockchain Platform. client-ID
client-secret Clé secrète client de l'instance Oracle Blockchain Platform. client-secret
peer Cette variable n'existe que pour la collection Postman de l'API d'encapsuleur de code de chaîne confidentiel, qui nécessite l'en-tête pair pour toutes les API de programmeur et d'accesseur. org-xyz-abc.blockchain.ocp.oraclecloud.com :20009

Après le déploiement de l'ensemble d'API d'encapsuleur, la sortie du déploiement de ressource de pile est un objet JSON qui contient les valeurs de point d'extrémité de passerelle. Si vous générez plus de 50 API, plusieurs points d'extrémité de passerelle sont générés, un pour chaque 50 API. Vous devez mettre à jour les variables de collection Postman associées à ces points d'extrémité. Les variables liées au point d'extrémité de la collection Postman doivent être mises à jour avec les valeurs appropriées provenant de la sortie du déploiement du paquetage d'API d'encapsuleur dans le gestionnaire de ressources de pile.

Toutes les API de réglage de la collection Postman de l'API d'encapsuleur incluent le paramètre endorsers ou sameOrgEndorser dans les données utiles de la demande. Les informations qui spécifient les API nécessitant le paramètre sameOrgEndorser sont définies dans le paramètre sameOrgEndorserOptionInWrapperAPI dans le fichier .ochain.json du code de chaîne. Pour les API listées dans ce paramètre, sameOrgEndorser sera réglé à Vrai dans leurs données utiles. Toutes les autres API de réglage incluront plutôt le paramètre endorsers. L'exemple suivant montre le paramètre pour le code de chaîne CBDC gros.
"sameOrgEndorserOptionInWrapperAPI": ["addConversionRate","addTokenAdmin","addTokenAuditor","approveBurn","approveMint","burnTokens","createExchangePoolAccounts","deleteHistoricalTransactions","initializeCBDCToken","initializeExchangePoolUser","mintWithFundingExchangePool","rejectBurn","rejectMint","removeTokenAdmin","removeTokenAuditor","requestBurn","requestMint","updateCBDCToken","updateConversionRate"]
Vous pouvez personnaliser le paramètre sameOrgEndorserOptionInWrapperAPI dans le fichier .ochain.json selon vos besoins. Lorsque vous générez des API d'encapsuleur, les API spécifiées incluent ensuite le paramètre sameOrgEndorser en tant que true dans leurs données utiles.
Pour plus de détails sur l'utilisation des collections Postman, consultez les rubriques suivantes.